Advanced·600 points·2 solves

Full SOC Incident Response

Work a complete incident from detection to lessons learned, and learn the two failures that make otherwise competent responses ineffective: scoping on the artefact you happened to find rather than on the credential the attacker reuses, and eradicating the malware without eradicating the access. You will establish the true origin, the true blast radius, and demonstrate from the evidence that the response failed.

The vulnerability

A response can be textbook at every step and still leave the attacker in place. This one was: the alert was triaged promptly, the host isolated the same morning, malware found, the machine wiped and rebuilt from clean media, the destination blocked at the perimeter. Nothing in the closed ticket is false. It is merely incomplete in two specific ways, and both are visible in the evidence. The first is scoping. An alert tells you where an intrusion was NOTICED, which is rarely where it began, and the phase that decides whether a response works is the one that asks where else this is. The instinct is to take the artefact you found — a task name, a file, a registry value — and hunt the estate for it. That fails against anyone who varies their persistence per host, because it returns the machines where they did not bother and clears the ones where they did. A credential is different: it is expensive to vary and it is the thing that is genuinely shared. Enumerate by account, then look for artefacts on each host you find. Be careful, though — the account in question has a real job and is used legitimately all day, so its mere presence proves nothing. The distinction is in the type of logon. The second is eradication. Rebuilding a machine removes what was ON that machine. It does nothing about a credential the attacker already holds, about persistence on a host nobody scoped, or about a session still valid elsewhere. A rebuilt host is reachable with a valid password exactly as the original was. If the credential was the way in and the credential is unchanged, the rebuild has bought hours — and this evidence contains what happened next. Evidence is in /var/log/soc. change-management.csv records every action the responders took, which is what lets you judge the response rather than only the intrusion. Read ir-playbook.md for the phases.

Your tasks

Detection and triage: establish what fired, and where

Find the alert that opened the incident in alerts.json — there is ordinary noise around it, so identify the one the brief describes. Record its rule id and the host it fired on. That host is where the intrusion was noticed. Nothing yet says it is where the intrusion began, and you should not assume it.

Scope on the credential, not on the artefact

Identify the account involved, then find every host it authenticated to. Filter carefully: this account has a genuine job and logs on to field machines constantly as part of it, so you must distinguish the logon type that represents its normal work from the type that represents someone moving between machines. Count the hosts reached that way — the number is asked for, and it is considerably larger than the one host the incident was opened on. Then find the EARLIEST such logon and record the host and the exact time: that, not the alert, is where this started.

Establish the real blast radius

For each host in scope, look in edr-process.json for something being established that would survive a reboot. Count the hosts where that happened. Then count how many DIFFERENT mechanisms were used across them — this is the number that explains why the original response missed most of the incident, because hunting the estate for the artefact found on the alerted host would clear every host where a different one was used.

Judge the response from the change record

change-management.csv is a complete record of what the responders did and when. Work through it and note what was isolated, what was rebuilt and when that rebuild completed, and what was blocked. Record the rebuild completion time. Then note what is NOT in that file — the review comment at the foot of it points at the omission, and asset-inventory.csv explains why that step had been made awkward long before this incident began.

Prove the eradication failed

Look at the telemetry for the rebuilt host AFTER the rebuild completed. The same account authenticates to it again, and persistence is re-established within minutes. Record when that logon happened and how many whole hours after the rebuild it was. Then identify the source address of that logon and resolve it to a host — it is one of the machines your scoping found and the response never touched. Record the command-and-control destination as well, and note that it had already been blocked at the perimeter before this happened.

Lessons learned

Be able to state which single control would have changed the outcome, and name it specifically rather than saying "better monitoring". Then map the technique that describes an attacker operating with legitimate credentials rather than malware — it is the technique that makes both failures in this incident possible, and the one a report that only lists the persistence mechanisms would omit.

Answer the questions

Start the lab, investigate the evidence in the terminal, and answer the questions here.

Hints

Loading…

Official write-up

Loading…

Frequently Asked Questions

What are the main incident response steps?

The common lifecycle covers preparation, detection and analysis, containment, eradication, recovery and lessons learned. Each phase must be verified, because partial remediation often leaves attackers access.

Why can a closed incident still be unresolved?

Isolating a host, rebuilding it and blocking one destination can all be correct yet incomplete if other systems, accounts or persistence remain. Verification and scoping prove the threat is truly gone.

Is the incident response capstone lab free?

Yes. You review a utility's closed incident in your browser, bringing together triage, scoping and remediation checks.

NEW350+ rooms now have a live terminal, so you can learn by typing the commands, right in your browser.Learn in a live terminal. 350+ rooms.Try a labCodelivly is 100% free, no paywall. If it helped you, chip in to keep it running.100% free. Help keep it so.Support us