What Is Incident Response?

NIST SP 800-61 Revision 3 shipped in April 2025 and removed the four-phase incident response lifecycle that everyone quotes. The phases did not stop being true. NIST decided the details of how to run them change too fast to freeze in a static document, so Revision 3 reorganizes everything around the CSF 2.0 Functions instead. If you learned incident response from a slide with four boxes on it, that slide now cites a superseded publication.

Start there, because it forces the question the frameworks exist to answer. Incident response is the discipline of making decisions with incomplete information while a clock runs. You will never have full scope. You will be tired. The lifecycle exists so that at 3am you do not skip the step that costs you the case.

The two lifecycles

NIST SP 800-61 Revision 2 (August 2012, Computer Security Incident Handling Guide) used four phases: Preparation, Detection and Analysis, Containment Eradication and Recovery, and Post-Incident Activity. Revision 3 (Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile) replaces those with the six CSF 2.0 Functions. Its executive summary splits them cleanly. Govern, Identify and Protect cover preparation and improvement. Detect, Respond and Recover cover the live work. Revision 3 keeps a table specifically to map the old phases onto the new Functions, which tells you NIST did not think the old model was wrong.

SANS teaches six steps, memorized as PICERL: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. It is the model in the SANS Incident Handler's Handbook and in SEC504.

The differences are real but small. SANS splits containment, eradication and recovery into three named steps, which matters because they are three decisions with three different failure modes. NIST r2 bundled them. NIST r3 pushes the whole thing into risk management vocabulary a CISO can map to controls, which helps governance and does nothing at 3am. The value is the ordering, not the branding.

Containment is a tradeoff, not a step

Containment is where most of the damage to your own investigation happens. Every action that stops the bleeding also destroys something you needed.

Kill the malicious process and you lose whatever was only in its address space: the decrypted C2 config, the staging buffer, the injected region that never touched disk. Sinkhole the C2 domain and the operator learns you are watching. Disable the compromised account and you find out whether there was a second one, but only after they use it. Reimage the host and you have destroyed the only copy of the artifact that would have told you how they got in.

RFC 3227 (BCP 55, February 2002) names the version of this that catches people out:

When removing external avenues for change note that simply disconnecting or filtering from the network may trigger "deadman switches" that detect when they're off the net and wipe evidence.

The practical answer on Windows endpoints is EDR host isolation rather than a physical disconnect, because isolation keeps the agent channel up. You still have telemetry, you can still pull a memory image over the wire, and the host still looks partially connected to anything checking for a network.

Pulling the cable and pulling the power are different decisions

They get discussed as if they are the same escalation. They are opposites.

Pulling the network cable preserves RAM and stops egress. It does not stop local encryption, which for T1486 is the thing actually destroying your data. It may trip the deadman switch above.

Pulling the power preserves the disk in its exact state and stops encryption mid-run. It destroys every byte of RAM. On a BitLocker volume where you do not hold the recovery key, a hard power off can leave you with a disk you cannot mount at all. Capture the key or suspend protection before you touch the power.

A graceful shutdown is the worst of the three and gets chosen most often, because it feels responsible. RFC 3227 is blunt: "Don't shutdown until you've completed evidence collection. Much evidence may be lost and the attacker may have altered the startup/shutdown scripts/services to destroy evidence." Windows adds its own trap. Set to 1, this value makes a clean shutdown zero the page file on the way out:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ClearPageFileAtShutdown

If you must power a Windows host down and cannot image memory first, hibernating it writes a compressed memory image to hiberfil.sys. Worse than a live capture, far better than nothing.

Order of volatility

RFC 3227 section 2.1 gives the ordering that still governs acquisition, 24 years on. Collect top down:

• registers, cache

• routing table, arp cache, process table, kernel statistics, memory

• temporary file systems

• disk

• remote logging and monitoring data that is relevant to the system in question

• physical configuration, network topology

• archival media

Note where disk sits. Fourth. Teams routinely acquire disk first because disk imaging is the thing they have a documented procedure for, and by then memory is gone.

What memory gets you that disk does not: live network connections mapped to owning process IDs, code in private memory regions never written to a file, the plaintext configuration a packed sample only decrypts at runtime, credential material resident in LSASS after T1003.001, and processes whose on-disk image is already deleted. WinPmem and Magnet RAM Capture produce the image, Volatility 3 parses it. KAPE and Velociraptor are the common triage collectors. We have not benchmarked these against each other, so treat tool selection as preference, not recommendation.

Eradication fails when scoping was wrong

Eradication is mechanical. Scoping is not, and eradication inherits every mistake scoping made.

The pattern is consistent enough to state plainly. A host is reimaged, the environment goes quiet, days later the same tooling returns. That is rarely a fresh intrusion. It is a persistence mechanism or an identity that was never in scope. We have no public dataset splitting re-infections into missed persistence versus new access, so treat that as an observation from published writeups rather than a measured rate. When a report carries enough timeline detail to tell, the second wave usually reuses something present during the first.

The mechanisms that survive a reimage are the ones that do not live on the reimaged host. A domain account created during the intrusion (T1136), a service account whose password the operator now knows (T1078), a web shell on a second server (T1505.003), a scheduled task on a file server nobody looked at (T1053.005). Reimaging patient zero addresses none of these.

Four scoping questions that change the eradication plan:

1. Every account that authenticated from a known-compromised host, not every account flagged as suspicious.

2. Every host those accounts touched afterwards.

3. Every persistence mechanism on those hosts, enumerated, not assumed.

4. Every credential resident in memory on the compromised hosts, whether or not you saw dumping.

The loop back to detection

This is the part that compounds. The strongest output of an incident is not the report. It is the detection that would have caught it three days earlier.

Take a reconstructed sequence, the shape that shows up repeatedly in published ransomware writeups. Initial access on a workstation. Credential access. Lateral movement to a file server. Ransomware on day four. Eradication reimages the workstation and the file server. On day nine the tooling comes back, and the origin is a WMI event subscription (T1546.003) registered on a third host during lateral movement, which nobody enumerated.

The incident finding is a fact: a CommandLineEventConsumer existed on a host that was never in scope. The detection engineering question is different. What signal existed on day two that nobody was querying?

Sysmon logs WMI subscription activity under Event IDs 19, 20 and 21 (filter, consumer, binding registered). Event ID 20 fires the moment the consumer is created. That is the day-two signal.

title: WMI event consumer created with an interpreter destination
id: 7c2f1a9e-4d63-4f0a-9b21-5e8d6c3a7f14
status: experimental
description: >
  Detects registration of a WMI event consumer whose destination invokes a
  command interpreter, scripting host or signed proxy binary. Consumer
  registration is a common persistence mechanism that survives host reimaging
  elsewhere in the environment.
references:
  - https://attack.mitre.org/techniques/T1546/003/
author: HuntRule
date: 2026-07-31
tags:
  - attack.persistence
  - attack.t1546.003
logsource:
  product: windows
  category: wmi_event
detection:
  consumer_created:
    EventID: 20
    Operation: 'Created'
  interpreter_destination:
    Destination|contains:
      - 'powershell'
      - 'pwsh'
      - 'cmd.exe /c'
      - 'wscript'
      - 'cscript'
      - 'mshta'
      - 'rundll32'
      - 'certutil'
  condition: consumer_created and interpreter_destination
falsepositives:
  - Configuration Manager, monitoring agents and hardware vendor tooling
    register command-line consumers at install time on golden images
  - Internal automation that uses WMI subscriptions for inventory triggers
level: high

What it catches: the registration event, once, at creation. What it misses is more important. It is blind to every consumer that existed before Sysmon was deployed, because Event ID 20 is not retroactive. It misses an ActiveScriptEventConsumer whose script text calls GetObject and Win32_Process directly without naming any string above. It produces nothing at all if your Sysmon config excludes 19, 20 and 21, which trimmed configs often do to cut volume.

So the rule needs a partner that does not depend on catching the moment. Enumerate existing state on every host in scope:

Get-CimInstance -Namespace root/subscription -ClassName __EventFilter
Get-CimInstance -Namespace root/subscription -ClassName __EventConsumer
Get-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding

Two outputs from one incident finding. A rule for next time, and a sweep for this time. That is the loop, and it is the same loop described in what detection engineering actually is: incidents produce logic, logic produces earlier incidents, earlier incidents are cheaper.

Summary

Incident response is a decision discipline, and the lifecycles exist to stop you skipping steps under fatigue. NIST SP 800-61 Revision 3 (April 2025) moved to CSF 2.0 Functions and superseded the four-phase model from Revision 2, while SANS PICERL keeps six named steps. Same shape, and the shape matters more than the source. Containment always costs evidence, so decide what you are willing to lose before you act rather than during. Eradication does not fail on its own, it fails because scoping missed a host or an identity. Close every incident by writing the detection that would have fired earlier.

Collect these before containment, not after:

Security 4624   Successful logon (map source IP and logon type)
Security 4648   Logon with explicit credentials
Security 4672   Special privileges assigned to new logon
Security 4688   Process creation (needs Audit Process Creation, plus the
                command line inclusion policy for arguments)
Security 4698   Scheduled task created
Security 4720   User account created
Security 4732   Member added to a security-enabled local group
Security 1102   Audit log cleared
System   7045   Service installed
Sysmon   1      Process creation
Sysmon   3      Network connection
Sysmon   10     Process access (LSASS handles)
Sysmon   11     File create
Sysmon   13     Registry value set
Sysmon   19/20/21  WMI filter / consumer / binding registered
PowerShell/Operational 4104  Script block logging
TaskScheduler/Operational 106  Task registered

ATT&CK techniques referenced above: T1003.001, T1053.005, T1078, T1136, T1486, T1505.003, T1546.003.

Persistence and credential access rules for Windows hosts are in the catalog at /rules?domain=windows. If you are scoping an active case, /rules?severity=critical is the shorter list to start from.