What is Containment?

NIST's current incident response guide defines containment as "preventing the expansion of an incident" and notes that most incidents require some form of it. Containment stops the damage from growing. Removing the attacker's persistence is eradication, and bringing systems back to production is recovery. Containment buys the time for both. Reimage a host before the accounts the attacker stole are contained, and the attacker logs in somewhere else while the evidence you needed is gone.

Containment in NIST SP 800-61 Rev. 3

Most explanations of containment still use the four-phase life cycle of NIST SP 800-61 Rev. 2: Preparation; Detection and Analysis; Containment, Eradication and Recovery; Post-Incident Activity. NIST withdrew Rev. 2 on 3 April 2025 and replaced it with Rev. 3, which organizes incident response around the six functions of the Cybersecurity Framework (CSF) 2.0 instead of a cycle of phases. Rev. 3 maps the old "Containment, Eradication and Recovery" phase onto the Respond and Recover functions, plus the Improvement category (ID.IM).

Containment now sits in the Incident Mitigation category of Respond:

For RS.MI-01, Rev. 3 recommends:

• letting security tools contain some incidents on their own, for example quarantining malware, moving a compromised endpoint to an isolated remediation network or halting an infected container;
• keeping the option for incident handlers to choose and run containment actions by hand, instead of or alongside the automation.

For the RS.MI category as a whole, it adds:

• writing criteria in advance by incident type (a cloud services compromise needs different actions from ransomware on a laptop) and deciding how long each measure should last: an emergency workaround removed within hours, a temporary one removed within two weeks, or a permanent fix;
• talking to legal before redirecting an attacker to a sandbox to watch them, because it delays containment and the attacker can escalate access in the meantime.

The rest of the framework is on the NIST CSF page, and the full life cycle on incident response.

Short-term and long-term containment

Short-term containment limits the damage within minutes: isolate the workstation (leave it powered on so memory survives for forensics), disable the account, block the attacker's IPs and domains at the firewall or proxy. Long-term containment holds that position while eradication is prepared: move affected servers to an isolated VLAN, add monitoring on the affected segment, apply emergency patches, turn off a service the attacker is abusing.

In a ransomware case, the short-term step isolates the hosts that are encrypting files and disables the service account used to spread. Over the following hours, the long-term work checks backup integrity, segments the affected subnet and turns off SMB where nothing needs it.

How wide to contain depends on how much you can see. If the attacker's full footprint is unknown, contain more than the confirmed compromise, an entire VLAN instead of one host, and accept the business cost. Containing too little lets the attacker return through a foothold nobody found.

Containment actions and the log that proves each one held

Each common containment step leaves a record that confirms it worked, and each one has a gap you still have to check.

The disable row needs a closer look. Kerberos V5 has no account revocation check on service ticket requests, so a stolen ticket-granting ticket (TGT) keeps working while it is valid. Microsoft's implementation narrows the window: domain controllers recheck the account once the TGT is more than 20 minutes old. Service tickets already issued are a separate problem. Microsoft's policy documentation warns that disabled users "might be able to continue accessing network services by using valid service tickets that were issued before their account was disabled", and the default domain policy gives a service ticket 600 minutes. A connection that is already open does not drop when its ticket expires either.

A simulated case: did the disable hold?

Simulated example generated by SOCSimulator Research. The domain, accounts, hosts and times are invented; the event IDs, fields and status codes are Microsoft's.

At 10:31 an alert flags the service account svc-backup authenticating from workstation WS-114 (10.20.4.17), which has never used it. At 10:41 the tier-2 analyst disables the account and resets its password. The domain controller logs:

10:33:05  DC01  4768  0x0   svc-backup               Client ::ffff:10.20.4.17                 TGT issued
10:41:07  DC01  4725        svc-backup               Subject CORP\soc.t2                       account disabled
10:41:30  DC01  4724        svc-backup               Subject CORP\soc.t2                       password reset
10:48:12  DC01  4769  0x0   svc-backup@CORP.EXAMPLE  Service FS02$   Client ::ffff:10.20.4.17  service ticket issued
10:56:40  DC01  4769  0x12  svc-backup@CORP.EXAMPLE  Service SQL01$  Client ::ffff:10.20.4.17  KDC_ERR_CLIENT_REVOKED
10:57:02  DC01  4768  0x12  svc-backup               Client ::ffff:10.20.4.17                 KDC_ERR_CLIENT_REVOKED

Seven minutes after the disable, the stolen TGT from 10:33, then 15 minutes old, still obtained a service ticket for file server FS02. At 10:56 the TGT was 23 minutes old, the domain controller rechecked the account and refused with 0x12, which Microsoft documents as KDC_ERR_CLIENT_REVOKED (account disabled, expired or locked out). The fresh TGT request at 10:57 failed the same way, which shows the disable now blocks new Kerberos TGT requests (event 4768). The session on FS02 is still open on a service ticket that, under the default policy, is valid until 20:48. The case is contained once WS-114 is isolated and the isolation shows as completed, and that timestamp, not 10:41, is the one to record as the time to contain.

This query runs the same check in Microsoft Sentinel for any account you disable:

// Kerberos activity for an account after it was disabled (event 4725)
let Account = "svc-backup";
let DisabledAt = toscalar(
    SecurityEvent
    | where EventID == 4725 and TargetUserName =~ Account
    | summarize min(TimeGenerated));
SecurityEvent
| where TimeGenerated > DisabledAt
| where EventID in (4768, 4769)
| where tostring(split(TargetUserName, "@")[0]) =~ Account
| project TimeGenerated, EventID, Status, ServiceName, IpAddress, Computer
| order by TimeGenerated asc

A row with Status 0x0 after the disable is a ticket the attacker still got, and 0x12 rows are the refusals you want to see. IpAddress on either points at the host to isolate next. The query is written against the documented SecurityEvent schema and assumes domain controllers audit the Kerberos Authentication Service and Kerberos Service Ticket Operations subcategories.