Containment Playbooks

Why Playbooks Matter

During an active incident, responders are under extreme pressure. Decisions must be made in seconds, and the stakes are high — a wrong move can destroy evidence, spread the attack, or cause business disruption. Playbooks eliminate the need to make ad-hoc decisions by pre-scripting the containment steps for each incident type.

A playbook is not a narrative document — it is an executable procedure. Each step is a specific action with a clear expected outcome. The responder follows the playbook like a checklist, executing each step in order.

Playbook Structure

playbook:
  name: "Ransomware Containment"
  description: "Isolate affected hosts and block ransomware C2 to prevent spread"
  triggers:
    - alert.rule.category: "ransomware"
    - alert.severity: "critical"
  steps:
    - step: 1
      action: "isolate_host"
      target: "{{alert.host.name}}"
      method: "network_isolation"
      expected_outcome: "Host has no network connectivity"
      verification: "ping {{alert.host.ip}} — should timeout"
    - step: 2
      action: "block_c2"
      target: "{{alert.network.dest_ip}}"
      method: "firewall_block"
      expected_outcome: "C2 IP blocked at perimeter firewall"
      verification: "Check firewall rule exists"
    - step: 3
      action: "capture_memory"
      target: "{{alert.host.name}}"
      method: "memory_capture"
      expected_outcome: "Memory dump saved to evidence share"
      verification: "File exists and hash recorded"
    - step: 4
      action: "notify"
      target: "soc_manager"
      method: "email"
      expected_outcome: "SOC manager notified of ransomware containment"

Design Principles

1. Specific over general — "isolate host WS-042 from the network" not "isolate the affected systems"
2. Verifiable — each step has a verification method so the responder knows it worked
3. Ordered — steps are numbered and must be executed in sequence
4. Conditional — include decision points: "if the host is a domain controller, skip step 1 and notify the IC first"
5. Reversible — document how to undo each step if it was done in error

Incident-Type Playbooks

Ransomware Playbook

1. Isolate affected hosts from the network (do NOT power off — preserve memory)
2. Block ransomware C2 IPs at the firewall
3. Identify the ransomware variant (check file extensions, ransom notes)
4. Determine the initial attack vector (phishing? RDP? vulnerability?)
5. Check for lateral movement — are other hosts encrypted?
6. Capture memory from affected hosts
7. Notify SOC manager and CISO
8. Engage cyber insurance carrier
9. Begin eradication planning (restore from backup vs. rebuild)

Data Exfiltration Playbook

1. Block the destination IP/domain at the firewall and proxy
2. Isolate the affected host from the network
3. Identify what data was accessed (review file access logs, database query logs)
4. Determine the exfiltration method (HTTP, DNS, cloud storage)
5. Preserve evidence — memory capture, disk image
6. Notify legal counsel — regulatory notification may be required
7. Engage forensic team for detailed analysis

Phishing / Credential Compromise Playbook

1. Identify all users who received the phishing email
2. Delete the phishing email from all mailboxes
3. Reset credentials for users who clicked the link or entered credentials
4. Revoke active sessions and tokens for compromised accounts
5. Check for mailbox rules created by the attacker (forwarding rules, hidden rules)
6. Scan all endpoints for malware delivered via the phishing email
7. Block the phishing URL at the proxy and DNS

Insider Threat Playbook

1. Do not alert the suspect — covert monitoring only
2. Preserve all evidence — do not tip off the suspect
3. Coordinate with HR and legal before any action
4. Monitor the suspect's network and file access activity
5. Document all evidence for potential legal proceedings
6. Plan the termination and access revocation for a coordinated moment

The Isolation Decision: How to Stop the Attack Without Destroying Evidence

Containment requires stopping the attack from spreading. The method you choose determines whether you preserve forensic evidence or destroy it. The golden rule: isolate, do not power off.

Network Isolation

Network isolation disconnects the host from the network while keeping it running. This stops the attack from spreading to other systems and prevents C2 communication, but preserves memory, running processes, and disk state.

Windows (PowerShell)

# Disable all network adapters
Get-NetAdapter | Disable-NetAdapter -Confirm:$false

# Verify isolation
Test-NetConnection -ComputerName 10.0.0.1 -Count 1
# Should fail — host is isolated

Linux

# Disable all network interfaces
ip link set eth0 down
ip link set eth1 down

# Verify isolation
ping -c 1 10.0.0.1
# Should fail — host is isolated

Cloud (AWS)

# Modify the security group to deny all traffic
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --groups sg-isolated

# Or move to an isolated security group
aws ec2 create-security-group --group-name "isolated" --description "Quarantine SG"
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --groups sg-isolated-12345678

Why Not Power Off?

Powering off a host destroys the most valuable forensic evidence:

• Memory — all running processes, network connections, encryption keys, and injected code are lost
• Temporary files — swap files, temp directories, and cache are lost or corrupted
• Volatile registry keys — some registry hives are only in memory

The only exception: if the host is actively destroying evidence (e.g., a wiper malware is running) and you cannot isolate it fast enough, powering off may be the lesser evil. But this is a last resort.

Account Isolation

For credential compromise incidents, isolate the compromised account:

# Disable the account
Disable-ADAccount -Identity compromised_user

# Revoke all active sessions
# Azure AD
Revoke-AzureADUserAllRefreshToken -ObjectId (Get-AzureADUser -Filter "userPrincipalName eq 'user@domain.com'").ObjectId

# Office 365
Revoke-SPOUserSession -User "user@domain.com"

Account isolation stops the attacker from using the stolen credentials while preserving the account's audit logs and history for investigation.

Network-Level Isolation

For widespread incidents, isolate at the network level rather than per-host:

• VLAN isolation — move affected hosts to a quarantine VLAN with no routing to production
• Firewall rules — block traffic between network segments
• DNS sinkhole — redirect malicious domains to a sinkhole server
• BGP blackhole — null-route malicious IPs at the router level

# Cisco ASA: block a malicious IP
shun 185.220.101.4

# iptables: block outbound to a malicious IP
iptables -A OUTPUT -d 185.220.101.4 -j DROP

# Windows Firewall: block an IP
netsh advfirewall firewall add rule name="Block C2" dir=out action=block remoteip=185.220.101.4

Containment Verification

After isolation, verify that the containment worked:

1. Network isolation — ping the host from another system; should timeout
2. Account isolation — attempt to authenticate with the compromised account; should fail
3. Firewall block — check that the firewall rule exists and is logging hits
4. C2 communication — check firewall/proxy logs for connection attempts to the C2 IP (should show blocked attempts)

Verification is critical. A containment step that was not actually executed gives a false sense of security while the attack continues.

After Containment: Closing the Doors the Attacker Used

Containment stops the attack from spreading. But the attacker's initial access vector and any persistence mechanisms remain. Post-containment actions close these gaps to prevent re-compromise.

Credential Rotation

If the attacker obtained credentials — through phishing, credential dumping, or database theft — those credentials must be rotated. The rotation scope depends on what was compromised:

Single User Compromise

1. Reset the user's password
2. Revoke all active sessions and tokens
3. Check for MFA bypass (did the attacker register a new MFA device?)
4. Review the user's recent activity for unauthorized actions

Domain Admin or Service Account Compromise

1. Reset the account password
2. Reset the KRBTGT account password twice (to invalidate all Kerberos tickets)
3. Revoke all Kerberos tickets
4. Check for Golden Ticket attacks (unusual ticket lifetimes)
5. Review all systems the account has accessed

Widespread Credential Compromise

If the attacker had access to a credential store (LSASS, NTDS.dit, cloud IAM), assume all credentials in that store are compromised:

1. Reset all potentially affected passwords
2. Rotate all API keys and service account credentials
3. Revoke all active sessions across the environment
4. Review authentication logs for unauthorized use of other credentials

# Reset KRBTGT password twice (Golden Ticket mitigation)
# First reset
Set-ADAccountPassword -Identity krbtgt -NewPassword (ConvertTo-SecureString -AsPlainText "[complex-password-1]" -Force)
# Wait for replication
Start-Sleep -Seconds 300
# Second reset
Set-ADAccountPassword -Identity krbtgt -NewPassword (ConvertTo-SecureString -AsPlainText "[complex-password-2]" -Force)

Persistence Removal

After credential rotation, search for and remove persistence mechanisms:

• Registry Run keys — HKLM\Software\Microsoft\Windows\CurrentVersion\Run
• Scheduled tasks — review all tasks, especially those running as SYSTEM
• Services — check for recently created or modified services
• WMI subscriptions — permanent event subscriptions that execute code
• Startup folders — shell:startup for each user
• Cron jobs — Linux persistence via crontab
• SSH keys — unauthorized authorized_keys entries
• Web shells — recently modified files in web directories

# Check for WMI permanent event subscriptions
Get-WmiObject -Namespace root\Subscription -Class __EventFilter
Get-WmiObject -Namespace root\Subscription -Class __EventConsumer
Get-WmiObject -Namespace root\Subscription -Class __FilterToConsumerBinding

# Check for recently created services
Get-WmiObject Win32_Service | Where-Object { $_.CreationDate -gt (Get-Date).AddDays(-7) }

Vulnerability Patching

If the attacker exploited a vulnerability for initial access, patch it immediately:

1. Identify the vulnerability (from the attack vector analysis)
2. Apply the patch or workaround
3. Verify the patch was applied successfully
4. Scan for other systems with the same vulnerability

Enhanced Monitoring

After containment, increase monitoring on affected systems and the surrounding environment:

• Enable verbose logging on affected systems
• Increase log retention for the investigation period
• Add detection rules for the specific TTPs used by the attacker
• Monitor for re-compromise indicators (same C2 IPs, same malware hashes, same techniques)

The enhanced monitoring period should last at least 14–30 days — long enough to detect re-compromise but not so long that it becomes the new normal.

SOAR Automation

Security Orchestration, Automation, and Response (SOAR) platforms automate containment playbooks. When an alert fires, the SOAR platform executes the playbook steps automatically:

# SOAR playbook: automated ransomware containment
trigger:
  alert.rule: "Ransomware Detected"
  alert.severity: "critical"

actions:
  - name: "Isolate host"
    integration: "crowdstrike"
    action: "contain_host"
    params:
      device_id: "{{alert.device_id}}"
    on_failure: "notify_soc_manager"

  - name: "Block C2 IP"
    integration: "palo_alto"
    action: "add_address_object"
    params:
      ip: "{{alert.dest_ip}}"
      list: "ransomware-c2"

  - name: "Create case"
    integration: "service_now"
    action: "create_incident"
    params:
      short_description: "Ransomware on {{alert.host.name}}"
      priority: "P1"
      assigned_to: "tier2-oncall"

  - name: "Notify SOC manager"
    integration: "slack"
    action: "send_message"
    params:
      channel: "#soc-critical"
      message: "Ransomware contained on {{alert.host.name}}. C2 blocked. Case created."

Automated containment reduces response time from minutes to seconds and eliminates human error during high-pressure situations. However, automation should be carefully tested — a buggy automated playbook can isolate critical production systems or block legitimate traffic.