Triage and containment
The first hour decides everything. Scope the blast radius before you act, then contain in a way that cuts the attacker's access without nuking the volatile evidence you'll need to prove what they did and when.
2:14 a.m. The alert is one line: a service account that normally touches one S3 bucket just listed forty. The on-call engineer’s hand goes to the obvious move — kill the pod, rotate the key, go back to bed. They do it. And in doing it they reboot the host, the in-memory reverse shell evaporates, the attacker’s process tree is gone, the /tmp payload is wiped by the fresh boot, and the only artifact left is a CloudTrail line that says “something happened.” Three weeks later legal asks the question every incident eventually reaches — what exactly did they take, and when did they get in? — and nobody can answer it, because the evidence was destroyed by the containment. The breach was survivable. The blind spot was self-inflicted.
By the end of this lesson you’ll know how to scope an incident’s blast radius before you touch anything, and how to contain it in an order that cuts the attacker off without erasing the evidence you’ll need afterward.
Triage: decide what this is before you decide what to do
The first job in an incident is not to fix it — it is to understand its shape well enough to act proportionately. That is triage: a fast, structured read of severity and scope so you spend the right amount of force on the right problem. Treat every alert as a five-alarm fire and you exhaust the team on false positives; treat the real intrusion as routine and you let it metastasize. NIST SP 800-61 frames this as the handoff from detection to analysis: confirm the incident is real, classify it, and assign a severity that drives the rest of the response.
Triage answers three questions in order. Is it real? Distinguish a true positive from a misconfigured alert or a benign anomaly — the 2 a.m. service account might be a new batch job nobody documented. How bad could it be? Severity is impact × confidence: a possible RCE on an internet-facing host with database credentials outranks a confirmed but sandboxed crypto-miner. How far does it reach? This is the question most teams under-ask, and it is the bridge to the next idea.
Scoping: find the blast radius before you cut
Scoping is the work of answering how far did this go? — which identities, hosts, services, and data the incident actually touches. It is the single most consequential step in triage, because every containment decision is only as good as the scope it’s based on. Contain too narrowly and you isolate one pod while the attacker’s second foothold keeps working; the industry calls this “whack-a-mole,” and it is how a one-host incident becomes a three-week incident.
The blast radius is rarely the thing that alerted. An attacker who lands on a web server uses it to pivot: they read environment variables for database creds, assume an over-permissive IAM role, enumerate the network, move laterally. The alert fired on step five; the foothold was step one. Scoping is reconstructing that chain backward to patient zero and forward to every place the access could have reached — using the logs and telemetry you set up long before tonight. MITRE ATT&CK is the map here: knowing the typical progression (initial access → execution → persistence → privilege escalation → lateral movement → exfiltration) tells you which adjacent systems to check before you assume you’ve found the edge.
Containment: cut the access without nuking the evidence
Containment is the move that stops the bleeding — but the order and the method decide whether you keep the ability to investigate. The destructive trap from the Hook is the most common senior-level mistake in incident response: the volatile state that proves what happened lives in exactly the places that a reboot, a re-image, or a kill -9 destroys.
The canonical capture priority is order of volatility — preserve the most ephemeral artifacts first, because they vanish the moment you act:
| Capture order | Artifact | Destroyed by | What it proves |
|---|---|---|---|
| 1 (most volatile) | RAM, running processes, open sockets | Reboot, shutdown, power loss | In-memory shells, injected code, live C2 |
| 2 | Network connections, ARP, DNS cache | Network isolation done wrong, time | Where the attacker is talking to |
| 3 | Disk: /tmp, logs, malware payload | Re-image, fresh boot, disk wipe | Dropped tooling, persistence, lateral steps |
| 4 (least volatile) | CloudTrail / audit logs, backups | Retention expiry (often the limit) | Timeline, identity used, API calls made |
The senior move is to contain in a way that freezes state rather than erasing it. Don’t power off a compromised VM — snapshot its memory and disk, then isolate it. In a cloud setting, the cleanest containment is often network isolation: move the instance into a quarantine security group that allows nothing in or out except your forensic access, so the box stays up (RAM intact, processes alive) while the attacker is cut off from it. For a compromised identity, you deny the credential rather than delete the user — an explicit deny policy or a session-revocation kills the access immediately and leaves the IAM principal and its history intact for the investigation. The principle is the same everywhere: isolate, don’t annihilate.
▸Why this works
Why preserve evidence at all, when the priority is obviously to stop the attacker? Three reasons a senior internalizes. First, scope: you cannot contain what you haven’t scoped, and the volatile evidence is what reveals the second foothold — destroy it and you contain blindly. Second, legal and regulatory: breach-notification laws (and many contracts) require you to state what data was accessed; “we don’t know because we re-imaged the box” is not an acceptable answer and can convert a contained incident into a reportable, litigable one. Third, recurrence: without the root-cause artifacts you fix the symptom, the attacker walks back in through the same door next week, and you’ve spent the whole response budget learning nothing.
The tension: contain now vs. watch and learn
There is a real tradeoff senior responders sit with, and it is not “always preserve.” Sometimes the fastest, most aggressive containment is correct — active ransomware encrypting a fileserver is not the moment to gently snapshot RAM; you pull the network cable. The judgment is speed of containment vs. completeness of evidence, weighed against blast radius growth rate. The faster the damage compounds, the more you tilt toward decisive containment even at the cost of some forensics.
A service account in your cloud account is making anomalous, escalating API calls — listing buckets, then reading objects. It's active right now and the rate is climbing. Pick the best containment move.
A workable order of operations
Put it together as the sequence a senior runs under pressure: triage to confirm and rate, scope to find the real blast radius, then contain in a way that freezes evidence — snapshot before you isolate, deny before you delete, isolate before you re-image. Only once the access is cut and the volatile state is captured do you move to eradication and recovery. The whole discipline is refusing to let the urge to do something destroy your ability to know what was done.
An alert fires on one compromised web server. Why is scoping the blast radius the step that most often determines whether containment works?
You need to contain a compromised cloud VM that has an in-memory reverse shell. Which action preserves the evidence while cutting the attacker off?
Order the incident response steps as a senior runs them under pressure, from first to last:
- 1 Triage — confirm it's real and assign severity
- 2 Scope — reconstruct the blast radius from logs/telemetry
- 3 Preserve — snapshot memory and disk before you act
- 4 Contain — isolate the host / deny the credential
- 5 Eradicate & recover — remove the attacker, restore service
- 01Walk through triage → scoping → containment and explain why scoping sits in the middle and drives the rest.
- 02Explain 'isolate, don't annihilate' and order of volatility — why does destructive containment cost you more than the breach itself?
The first hour of an incident is won or lost on order of operations. Triage is the fast read — is it real, how bad, how far — that turns a one-line alert into an understood incident and assigns a severity proportional to impact × confidence. Scoping is the pivot: because the alert almost always fires several steps into the attack chain, you reconstruct the blast radius backward to patient zero and forward across every identity, host, and data store the access could have reached, with ATT&CK as the map — and you do it before containing, because containing the wrong scope leaves the attacker’s second foothold alive. Containment then cuts the access without destroying the evidence: capture in order of volatility (RAM and processes first, then network, then disk, then audit logs), and isolate rather than annihilate — snapshot before you reboot, network-quarantine instead of powering off, deny or revoke a credential instead of deleting the user. The one exception is fast-compounding damage like active ransomware, where decisive containment outranks forensic completeness. The discipline that ties it together: never let the urge to do something destroy your ability to prove what was done — because scope, the law, and stopping recurrence all depend on the evidence you almost threw away.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.