Skip to content

CH9: Containment Strategies

Introduction

In Chapter 8, we invested the time to understand the full scope of the breach. We identified compromised hosts, traced lateral movement, mapped the attacker's Command and Control (C2) infrastructure, and constructed a unified timeline of the intrusion. The Analysis phase gave us the X-ray. Now it is time to operate.

Containment is the phase where the Incident Response team shifts from observer to actor. Containment is the deliberate, coordinated act of cutting off the attacker's access, stopping the spread of damage, and stabilizing the environment so that eradication and recovery can proceed safely.

However, containment is not as simple as "pull the plug." Isolating a server preserves evidence but disrupts business operations. Disabling an account stops an attacker but may alert them, causing them to accelerate destruction or activate dormant backdoors. Powering off a ransomware-infected machine halts encryption but destroys volatile memory that may hold decryption keys.

This chapter treats containment as what it truly is: a series of strategic decisions, not reflexive reactions.

Learning Objectives

By the end of this chapter, you will be able to:

  • Differentiate between short-term and long-term containment strategies and identify when each is appropriate.
  • Evaluate containment tradeoffs, including the tension between evidence preservation, business continuity, and adversary awareness.
  • Apply network-based containment techniques—DNS sinkholing, null-routing, firewall ACL modifications, and VLAN quarantine—to isolate compromised systems.
  • Execute identity and access containment actions, including account disablement, credential resets, session and token revocation, and privileged access review.
  • Analyze the unique containment challenges posed by ransomware incidents, including the power-off vs. isolate decision and its impact on encryption keys and forensic evidence.

9.1 The Logic of Containment

Before executing any containment action, the team must understand what containment is and, equally important, what it is not.

Containment is not eradication. The goal is to stop the bleeding—to prevent the attacker from expanding their foothold, exfiltrating additional data, or detonating destructive payloads. Containment does not remove the attacker from the environment. After successful containment:

  • Their malware may still reside on disk.
  • Their backdoor accounts may still exist.
  • Their persistence mechanisms (scheduled tasks, Registry run keys, WMI subscriptions) remain in place.

Those are problems for Chapter 10 (Eradication). Containment is the tourniquet, not the surgery.

The "Contain, Don't Cure" Principle

The instinct during a live incident is to fix everything immediately—wipe the infected machine, patch the vulnerability, reset every password. This instinct is dangerous. Premature remediation destroys evidence, introduces chaos, and often fails to address the full scope because the team has not yet finished mapping the attacker's reach.

Containment operates under disciplined restraint: stop the spread, preserve the evidence, and hold the line until the team is ready for a coordinated eradication.

Short-Term vs. Long-Term Containment

Containment is not a single action but a phased approach. The distinction between short-term and long-term containment reflects the difference between emergency stabilization and sustained operational control.

Short-Term Containment is the immediate response. It prioritizes speed over elegance—preventing the situation from getting worse right now.

  • Disconnecting a compromised host from the network (pulling the Ethernet cable or disabling the switch port).
  • Blocking a known C2 IP address at the perimeter firewall.
  • Disabling a compromised user account in Active Directory.

These actions are fast but blunt, and they are not sustainable for extended periods.

Long-Term Containment is a measured posture designed to sustain operations while maintaining control over the threat. It involves architectural changes that allow the business to continue functioning while the attacker's access is neutralized or monitored.

  • Moving compromised hosts to a quarantine VLAN for continued analysis without risking lateral spread.
  • Implementing network segmentation to isolate affected business units while others continue to operate.
  • Deploying enhanced monitoring on contained systems to detect breakout attempts.

Long-term containment often runs in parallel with continued analysis.

Warning

Containment Reveals New Scope

Containment is not a one-way door. When you isolate a system and the attacker loses access to it, they may attempt to "break out" through alternate footholds the team has not yet discovered. This means containment actions can trigger new detection alerts, which loop the team back to the Analysis phase (Chapter 8). The IR lifecycle is iterative, not linear—expect to cycle between Analysis and Containment multiple times during a complex incident.


9.2 Containment Tradeoffs and the Approval Framework

Triangle diagram illustrating the three competing priorities in every containment decision: Evidence Preservation at the top, Business Continuity at the bottom left, and Stopping the Spread at the bottom right. Each side of the triangle labels the tension between adjacent priorities: preserving data versus staying operational, forensic integrity versus immediate action, and uptime versus isolation speed.

Every containment action exists at the intersection of three competing priorities:

  1. Evidence Preservation: Forensic investigators need systems intact. Powering off a server destroys volatile memory. If the incident may lead to litigation, evidence integrity is paramount.
  2. Business Continuity: The organization needs to operate. Isolating the email server stops the attacker but also stops every employee from communicating.
  3. Stopping the Spread: Every minute the attacker retains access, they can escalate privileges, exfiltrate data, or deploy ransomware.

These priorities frequently conflict. A forensic investigator wants a compromised Domain Controller running to capture memory. The CISO wants it isolated immediately. The CFO wants the whole thing resolved before Monday. There is no universal "right answer"—only the best decision given the specific circumstances.

The Approval Question

Containment actions that affect production systems require authorization. If a SOC analyst unilaterally disconnects the ERP server at 2:00 PM on the last day of the fiscal quarter, the business impact could rival the breach itself.

Chapter 5 introduced the RACI model for incident response. During containment, these assignments become critical. The SOC analyst executes the action (Responsible). The Incident Commander approves it and accepts the associated risk (Accountable). Business owners and Legal Counsel are Consulted. Executive leadership and the CMT are Informed.

Chapter 6 established that the IR Policy grants the CSIRT authority to act. This authority prevents hesitation, but it is not a blank check—high-impact containment actions (isolating a Domain Controller, disabling the CEO's account) should still flow through the Incident Commander for approval.

Decision Documentation

Every containment action must be logged in the case management system (Chapter 5). The log entry should capture:

  • What action was taken (e.g., "Disabled switch port Gi0/24 on core-sw-01, isolating host WS-FIN-042").
  • Who authorized it (e.g., "Approved by IC Martinez, verbal approval at 14:32 UTC").
  • Why it was necessary (e.g., "Host confirmed as actively beaconing to C2 infrastructure").
  • What risks were accepted (e.g., "Finance quarterly reporting offline until replacement provisioned").

This documentation creates accountability and feeds the post-incident review (Chapter 11).

Containment Decision Matrix

The following matrices provide a reference for evaluating common containment actions against their tradeoffs. These are not exhaustive, but they frame the cost-benefit analysis that should precede every containment decision.

Short-Term Containment Actions

Containment Action Evidence Impact Business Impact Adversary Awareness Risk
Network cable disconnect Preserves disk; loses active network connections High — immediate outage for host High — attacker sees host go offline
Switch port disable Preserves disk; loses active connections High — same as above, centrally managed High
EDR network isolation Preserves disk and RAM; host stays online for remote forensics Moderate — host loses network but remains powered Moderate — attacker's C2 fails silently
Firewall ACL block (C2 IPs) Minimal — traffic is blocked, not deleted Low — only malicious traffic affected Low — attacker sees failed callbacks
Account disable Minimal Moderate — legitimate user loses access High — attacker's next login attempt fails
Power off host Destructive — volatile memory lost High — immediate outage High — host disappears from network

Long-Term Containment Actions

Containment Action Evidence Impact Business Impact Adversary Awareness Risk
DNS sinkhole Positive — captures beacon attempts as evidence Low — only malicious domain resolution affected Low — attacker's C2 resolves but reaches a dead end
VLAN quarantine Preserves all data; enables continued monitoring Moderate — host is functional but isolated Low — attacker may not notice immediately
Null-routing (C2 IPs) Minimal — traffic is dropped silently Low — only malicious traffic affected Low — attacker sees timeouts, not resets
Forced password reset (enterprise-wide) Minimal High — all users disrupted simultaneously High — signals active response to attacker
Network segmentation Preserves all data Moderate — cross-segment communication restricted Low — internal routing changes are not visible to attacker


9.3 Network-Based Containment

Network-based containment targets the attacker's ability to communicate—both with their external C2 infrastructure and with other systems inside the network. The principle is straightforward: if the attacker cannot talk to their tools, they cannot issue commands, exfiltrate data, or spread.

Immediate Isolation

The most direct form of network containment is severing the compromised host's connection. Switch port disablement is preferred for wired hosts—fast, centrally managed, and requires no physical access. For remote or VPN-connected endpoints where switch port control is not applicable, a host-based firewall lockdown (deny all inbound/outbound except management traffic) can be pushed remotely via Group Policy or endpoint management tools.

The key limitation is bluntness. If the host was running a production service, that service is now down—which is why the approval framework from Section 9.2 exists.

VLAN Quarantine

When the team needs to maintain access to a compromised host for continued forensic analysis, a VLAN quarantine provides a middle ground. The host is moved from its production VLAN to a dedicated quarantine VLAN with no routing to the corporate network, but with access to designated forensic workstations and monitoring tools.

This requires advance preparation (Chapter 6). The quarantine VLAN, routing rules, and authorized forensic subnets should be pre-configured before an incident occurs.

DNS Sinkholing

Many C2 implants rely on domain names rather than hardcoded IPs to reach their operators. DNS sinkholing exploits this dependency by configuring the organization's internal DNS server to override resolution for the known malicious domain. Instead of returning the attacker's real IP address, the DNS server returns the address of an internal sinkhole server controlled by the IR team (e.g., 10.0.0.200).

The malware continues to beacon, but its traffic reaches a dead end. This has two benefits: the attacker loses command and control, and the sinkhole captures every beacon attempt, helping identify all infected hosts in the environment. Any system querying the sinkhole is compromised.

Before-and-after comparison of a DNS sinkhole containment technique. On the left, the infected host queries a malicious domain that resolves to the attacker's C2 server, enabling beacon traffic and data exfiltration. On the right, the same DNS query is redirected by the internal DNS server to an internal sinkhole IP, causing the beacon to reach a dead end while logging every attempt to reveal all infected hosts on the network.

Analyst Perspective

When you configure a DNS sinkhole, the SIEM becomes your best friend. Create a detection rule that alerts on any DNS resolution pointing to the sinkhole IP. Within minutes of activating the sinkhole, you may see hosts you did not know were compromised suddenly appearing in the logs. Each beacon attempt is a new lead. This is one of the rare containment techniques that simultaneously acts as a detection mechanism—it stops the bleeding and reveals the full wound.

Null-Routing

Null-routing (also called blackholing) operates at the routing layer. The network team adds a static route that sends all traffic destined for a known malicious IP address to a "null" interface—a dead end where packets are silently dropped. Unlike firewall ACL changes, which operate on specific ports and protocols, null-routing drops all traffic to the target IP regardless of port, making it harder for the attacker to evade by changing communication ports.

Firewall ACL Modifications

The perimeter firewall is the most common enforcement point for network containment. The IR team provides the firewall administrator with C2 IP addresses and domains identified during Analysis, and explicit deny rules are added to the Access Control List (ACL).

Warning

Coordinate Before You Block

A common mistake during containment is implementing firewall rules piecemeal—blocking a C2 IP on one firewall while forgetting about the VPN concentrator, the cloud security group, or the branch office router. The attacker only needs one open path. Before executing network containment, the IR team should compile a complete list of all egress points and assign an owner for each. The containment action should be executed simultaneously (or as close to simultaneously as feasible) across all points. A partial block is worse than no block because it creates a false sense of security.


9.4 Endpoint Containment

While network-based containment controls the paths an attacker can use, endpoint containment targets the hosts where the attacker has established a presence. Modern endpoint containment relies heavily on Endpoint Detection and Response (EDR) platforms.

EDR-Based Network Isolation

Most enterprise EDR solutions (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Carbon Black) include a network isolation feature. When activated, the EDR agent blocks all inbound and outbound traffic except communication with the EDR management console.

This makes EDR isolation the preferred containment method in most modern IR engagements because it achieves three objectives simultaneously:

  • Stops the attacker — C2 and lateral movement paths are severed.
  • Preserves evidence — the machine stays powered on, retaining volatile memory and running processes.
  • Maintains investigative access — the analyst can still remotely query the host, pulling process lists, collecting artifacts, or running forensic scripts through the EDR console.

Disabling Persistence (Selectively)

During containment, the team may identify specific persistence mechanisms—a scheduled task that re-launches malware, a malicious Windows service, or a rogue startup entry. The containment-appropriate action is to disable rather than delete. Disable the scheduled task so it no longer fires, but leave the task definition intact for forensic documentation. Stop the malicious service but do not uninstall it. This prevents reactivation while preserving evidence for the eradication phase and any potential legal proceedings.


9.5 Identity and Access Containment

In modern enterprise environments—especially those with heavy cloud and SaaS adoption—the attacker's most valuable asset is often not a piece of malware on a server, but a stolen credential. Compromised accounts provide the attacker with legitimate access that blends seamlessly with normal user activity, making detection difficult and network-based containment insufficient.

Identity containment addresses this by targeting the accounts and sessions the attacker is using, not just the machines and networks they are traversing.

Account Disablement and Credential Resets

The most direct identity containment action is disabling the compromised account. In Active Directory, this means setting the account to "Disabled." In cloud identity providers (Entra ID, Okta, Google Workspace), this means suspending the account or revoking its sign-in capability.

However, disabling an account does not kill active sessions on many platforms. If the attacker is logged into a cloud application with an OAuth token, that token may remain valid for hours or days even after the underlying account is disabled. This is one of the most commonly misunderstood aspects of identity containment.

Credential resets must accompany account disablement. The aggressiveness of the reset depends on the account type:

  • Standard users: Forced password change.
  • Privileged accounts (Domain Admins, service accounts, root): New passwords, rotated Kerberos keys (resetting the password twice), and verification that no cached credentials remain on compromised hosts.

The priority order for credential resets during containment:

  1. Confirmed compromised accounts — accounts the attacker demonstrably used.
  2. Privileged accounts on compromised systems — any admin account that was cached or logged into an affected host.
  3. Service accounts with broad access — accounts used for application-to-application authentication that may have been harvested from memory.
  4. Broader user population — typically deferred to eradication unless the scope suggests enterprise-wide credential theft.
Vertical priority stack showing the order for credential resets during incident containment from highest to lowest urgency. Priority 1 is confirmed compromised accounts, Priority 2 is privileged accounts on affected hosts, Priority 3 is service accounts with broad access, and Priority 4 is the broader user population typically deferred to eradication. A callout emphasizes that each account requires all three actions: disable, reset password, and revoke tokens.

Warning

Disabling ≠ Disconnecting

On many cloud platforms (Microsoft 365, Google Workspace, Salesforce), disabling a user account does not immediately terminate their active sessions or invalidate their OAuth/SAML tokens. The attacker may continue operating with a valid token for the duration of its lifetime—sometimes 60 minutes, sometimes 24 hours. Containment requires both account disablement and explicit session/token revocation. In Microsoft Entra ID, this means using "Revoke Sessions" in addition to disabling the account. In Google Workspace, it means resetting the user's sign-in cookies. Skipping this step is a containment gap that sophisticated attackers will exploit.

Timeline diagram illustrating the identity containment gap. After an account is disabled at T+0, the attacker retains full access through valid OAuth tokens and SAML sessions until the token lifetime expires around T+24 hours. The gap between T+0 and T+1 hour highlights the window where the attacker still operates despite the account being disabled, with three required actions listed: revoke OAuth tokens, terminate SAML sessions, and force cloud sign-out.

Session and Token Revocation

Revoking active sessions and tokens is the identity equivalent of pulling the network cable. It forces the attacker to re-authenticate—and if the account is already disabled or the password changed, they cannot. Key revocation actions include:

  • OAuth token revocation: Invalidating all tokens issued to the compromised account, including those granted to third-party applications.
  • SAML session termination: Ending active federated sessions across all integrated applications.
  • Cloud session sign-out: Forcing sign-out across all devices and browsers via the identity provider's admin console.
  • Kerberos key rotation: In Active Directory, resetting the account password twice to invalidate issued tickets.

If Kerberos ticket-granting tickets may have been forged (Golden Ticket attacks), a KRBTGT account reset must be on the containment team's radar, though this high-impact action is typically deferred to eradication.

Privileged Access Review

During containment, the team must audit whether the attacker created, elevated, or modified accounts to maintain access. Common indicators include:

  • New accounts added to Domain Admins or equivalent cloud administrator roles.
  • Service accounts with newly granted permissions.
  • Changes to Conditional Access policies or MFA configurations.
  • New OAuth application consents (a technique used in cloud account takeover to maintain access even after password changes).

This review identifies attacker-created access that must be revoked and uncovers additional scope that feeds back into Analysis.

Conditional Access Tightening

If the organization uses Conditional Access policies, containment may include emergency changes:

  • Enforcing device compliance requirements (blocking sign-ins from unmanaged devices).
  • Restricting sign-ins to known corporate IP ranges or geographic regions.
  • Requiring step-up MFA for all privileged actions.
  • Blocking legacy authentication protocols that bypass MFA.

These changes must be carefully scoped to avoid locking out the IR team itself—nothing derails containment faster than the responding analysts losing their own access.


9.6 The Ransomware Containment Decision

Ransomware presents a unique containment challenge because the threat is both immediate and irreversible. Unlike data exfiltration (where the damage is the copy, and the original data remains intact), ransomware actively destroys the usability of data by encrypting it in place. Every second the ransomware runs, more files are lost. This urgency compresses the decision timeline from hours to minutes.

The Three Options

Three-column comparison of ransomware containment options when active encryption is detected: Power Off stops encryption and is scalable but destroys RAM evidence, Suspend or Hibernate stops encryption and preserves RAM but is not scalable, and Network Isolate preserves RAM and is scalable but allows local encryption to continue. Each column includes a recommended use case, with a warning that every second of delay means more encrypted files.

When ransomware is detected on a host, the responder faces three primary containment choices. Each carries distinct consequences.

Option 1: Power Off the Host

Pulling the power stops encryption immediately, but destroys all volatile memory (RAM). If the encryption keys were stored only in the malware's running process memory (common for many ransomware families), those keys are now gone.

When to use: When the host is actively encrypting critical data and no other isolation method is available. If the data being encrypted is more valuable than the potential forensic evidence in RAM, power off.

Option 2: Suspend or Hibernate the Host

Suspending the machine halts all processes while preserving RAM contents in a hibernation file on disk—theoretically the best of both worlds.

When to use: When the responder has physical access and the host supports hibernation. In practice, this is difficult to scale beyond a single workstation.

Option 3: Network Isolate the Host

Severing the host's network connection stops lateral spread but allows the ransomware to continue encrypting local files until it finishes.

When to use: When preventing enterprise-wide encryption is the priority. This is often the correct choice for the first detected host, because the primary threat is not one encrypted workstation—it is the entire network.

The EDR Factor

If the EDR agent on the compromised host is still functional, EDR network isolation is typically the fastest and most scalable containment action. However, sophisticated ransomware operators increasingly target EDR agents—disabling processes, exploiting kernel-level vulnerabilities, or unloading drivers before detonating the payload. If the EDR agent is compromised, the team falls back to network infrastructure controls (switch port disablement) or physical intervention.

Ransomware is also one of the most common triggers for activating the Crisis Management Team (CMT) described in Chapter 4. When the IR team confirms active ransomware with evidence of lateral movement or data exfiltration (double extortion), the Incident Commander should immediately escalate.


Putting It Together: A Coordinated Containment Operation

To illustrate how these concepts work in practice, consider the following scenario.

The Situation: Meridian Financial Services, a mid-size financial services firm with 2,000 employees, has been under investigation by the CSIRT for the past six hours. The Analysis phase (Chapter 8) has produced the following findings:

  • Patient Zero: A phishing email delivered a malicious macro document to a Finance department employee (WS-FIN-042) three days ago.
  • Lateral Movement: The attacker used stolen credentials from the initial host to move laterally to the HR file server (FS-HR-01) and a Domain Controller (DC-02).
  • Privilege Escalation: The attacker dumped credentials from DC-02's memory using a Mimikatz variant, obtaining the password hash for a Domain Admin service account (svc-backup).
  • C2 Infrastructure: All three compromised hosts are beaconing to an external C2 server at 198.51.100.47, resolving the domain cdn-analytics-update[.]com.
  • Data Staging: The team has identified a compressed archive (data_export.7z) staged on FS-HR-01 containing employee PII. No evidence of successful exfiltration yet, but the archive was created two hours ago.

The Incident Commander calls a containment planning meeting. Here is how the operation unfolds.

Step 1: Establish Priorities

The Incident Commander, working with Legal Counsel and the CISO, determines the priority order:

  1. Prevent data exfiltration. The staged archive has not left the network yet. Stopping it is the top priority.
  2. Sever C2 communication. Cut the attacker's ability to issue commands.
  3. Contain lateral movement. Prevent the attacker from reaching additional systems.
  4. Preserve evidence. Maintain forensic integrity where possible.

Step 2: Coordinate the Actions

The team assigns specific tasks for simultaneous execution (a "coordinated lockout") so the attacker does not have time to react to partial containment:

  • Network Team (T+0): Block all traffic to/from 198.51.100.47 on all perimeter firewalls, the VPN concentrator, and cloud security groups. Configure a DNS sinkhole for cdn-analytics-update[.]com pointing to 10.99.0.10 (internal sinkhole server).
  • SOC Analyst 1 (T+0): Activate EDR network isolation on WS-FIN-042 and FS-HR-01.
  • SOC Analyst 2 (T+0): Disable the svc-backup Domain Admin account; reset its password twice (Kerberos key rotation). Disable the compromised Finance user account and revoke all cloud sessions.
  • Identity Team (T+5 min): Audit all Domain Admin group memberships, check for newly created accounts in the last 72 hours, and review Conditional Access policy changes.

Timeline diagram of a coordinated containment lockout showing three teams executing simultaneously at T+0: the Network Team blocks C2 IPs and activates a DNS sinkhole, SOC Analysts isolate two endpoints via EDR, and the Identity Team disables a compromised service account. A T+5 minute follow-up phase and T+15 minute validation check confirm sinkhole captures, no new lateral movement, and discovery of an additional compromised host requiring a return to analysis.

Step 3: Handle the Domain Controller

DC-02 is the hardest decision. Isolating it would affect authentication for a significant portion of the enterprise. The Incident Commander approves a measured approach:

  • The firewall rules blocking the C2 IP sever the attacker's command channel to DC-02 (no full isolation needed).
  • Enhanced monitoring is deployed—real-time process monitoring and authentication log forwarding at maximum verbosity.
  • The Identity Team begins emergency credential rotation for all privileged accounts cached on DC-02.
  • A plan is developed to demote and rebuild DC-02 during eradication, with DC-01 and DC-03 absorbing its FSMO roles.

Step 4: Document and Validate

Every action, approval, and timestamp is logged in the case management ticket. Within 15 minutes, the team validates:

  • The SIEM confirms that beacon attempts from WS-FIN-042 and FS-HR-01 are now resolving to the sinkhole IP (10.99.0.10). Containment is working.
  • The DNS sinkhole is logging beacon attempts from a fourth host the team had not previously identified (WS-MKTG-019). New scope—the Incident Commander assigns an analyst to begin analysis on this host immediately.
  • No new lateral movement is detected from DC-02 following the firewall block. Enhanced monitoring is in place.

Analyst Perspective

The sinkhole discovery of WS-MKTG-019 is a textbook example of why containment and analysis are iterative. The "containment is complete" moment rarely exists in a single clean step. Every containment action is also a detection action—when you close one door, you learn who was trying to walk through it. Stay alert for new leads in the hours immediately following containment execution. Your SIEM dashboards should be running real-time queries against the sinkhole IP and any newly blocked C2 indicators.


9.7 Containment Validation and Transition to Eradication

Executing containment actions is only half the job. The team must verify that containment is effective and monitor for signs that the attacker has found a way around it.

Validating Containment Effectiveness

After containment actions are executed, the team must verify they are working:

  • C2 Communication: Confirm that no traffic is reaching the attacker's C2 infrastructure. The SIEM should show blocked or sinkholed connections, not successful ones.
  • Lateral Movement: Monitor for new authentication events or network connections originating from contained hosts.
  • New Indicators: Watch for backup C2 domains or IPs that activate when primary channels are severed.
  • Sinkhole Activity: Review sinkhole logs for unexpected hosts—each represents a potentially compromised system outside the original scope.

The Containment Hold

Before transitioning to eradication, experienced IR teams impose a deliberate containment hold—a monitoring window of 12 to 48 hours where the team watches for attacker breakout or re-compromise. During this window:

  • All contained systems remain isolated.
  • Enhanced monitoring runs at full verbosity on critical systems.
  • The team actively hunts for alternate access paths—additional backdoors, secondary C2 channels, and unidentified compromised accounts.

The containment hold exists because moving to eradication prematurely—before all attacker access has been identified—risks re-compromise through undiscovered footholds.

Circular diagram showing the iterative relationship between Analysis and Containment during incident response. Analysis maps compromised hosts, traces lateral movement, and identifies C2 infrastructure, which feeds into Containment actions like isolating systems, blocking C2 channels, and revoking credentials. New indicators discovered during containment loop back to expand the analysis scope, with a 12 to 48 hour containment hold before progressing to Eradication.

Formal Handoff to Eradication

When the Incident Commander is satisfied that containment is effective and scope is fully defined, the team transitions to Eradication. The handoff package should include:

  • A complete list of contained systems and the method used for each (EDR isolation, VLAN quarantine, powered off, etc.).
  • A complete list of contained accounts and the actions taken (disabled, password reset, tokens revoked).
  • The current C2 blocklist (IPs, domains, and sinkhole entries).
  • Known persistence mechanisms identified during Analysis and Containment that must be removed.
  • An updated incident timeline incorporating all containment actions and their results.
  • Any new scope discovered during containment (like WS-MKTG-019 in our scenario) and its analysis status.

Chapter Summary

Containment is the turning point of the incident response lifecycle—the moment the team stops gathering intelligence and starts actively fighting the adversary.

  • Containment is not eradication. The goal is to stop the spread and stabilize the environment. Eradication (Chapter 10) follows once containment is validated.

  • Short-term containment prioritizes speed (immediate isolation, firewall blocks). Long-term containment sustains operations while restricting the attacker (VLAN quarantine, sinkholing, segmentation).

  • Every containment action has tradeoffs between evidence preservation, business continuity, and adversary awareness. The Incident Commander approves actions based on the RACI model, and every decision is documented.

  • Network containment (DNS sinkholing, null-routing, firewall ACLs, VLAN quarantine) targets the attacker's communication paths. DNS sinkholing is particularly valuable because it simultaneously contains and detects.

  • Endpoint containment leverages EDR isolation to sever attacker access while preserving evidence and maintaining remote investigative capability.

  • Identity containment is critical in cloud-heavy environments. Disabling accounts alone is insufficient—active sessions and tokens must be explicitly revoked, and privileged access must be audited for attacker-created accounts.

  • Ransomware containment compresses decision timelines to minutes. The power-off vs. isolate decision depends on whether data preservation or evidence preservation takes priority.

  • Containment is iterative. Actions frequently reveal new scope, feeding back into the Analysis phase.

In the next chapter, we will take the stabilized environment produced by containment and begin the Eradication process—systematically removing every trace of the attacker's presence and closing the vulnerabilities that allowed the breach.