Containment, Eradication & Recovery

The Most Intense Phase

Detection tells you something is wrong. Analysis tells you what is wrong. But containment, eradication, and recovery is where you actually stop the attacker, remove their presence, and restore your environment. This is the phase where decisions have immediate, irreversible consequences — isolate the wrong server and you take down production; wait too long to isolate and the attacker pivots to more systems.

NIST groups these three activities into a single phase because they overlap in practice. You do not finish containment, then start eradication, then start recovery in neat sequential steps. In a real incident, you are containing one system while eradicating malware from another while recovering a third that was already cleaned. The skill is knowing when to transition between activities and how to run them in parallel without losing control.

Short-Term Containment

Short-term containment is the emergency response — stop the immediate threat within minutes. The goal is to limit damage without destroying evidence.

Network Isolation

The most common short-term containment action. Isolate the compromised system from the network so the attacker cannot use it to pivot, exfiltrate data, or communicate with C2 infrastructure.

On Linux:

# Block all network traffic except local loopback and established SSH (for remote forensics)
iptables -I INPUT 1 -i lo -j ACCEPT
iptables -I INPUT 2 -p tcp --dport 22 -s 10.0.1.0/24 -j ACCEPT
iptables -I INPUT 3 -j DROP
iptables -I OUTPUT 1 -o lo -j ACCEPT
iptables -I OUTPUT 2 -p tcp --sport 22 -d 10.0.1.0/24 -j ACCEPT
iptables -I OUTPUT 3 -j DROP

On Windows (PowerShell as Administrator):

# Disable all network adapters except the management interface
Get-NetAdapter | Where-Object { $_.Name -ne "Management" } | Disable-NetAdapter -Confirm:$false

# Or use Windows Firewall to block everything except forensic access
New-NetFirewallRule -DisplayName "IR-Block-All-In" -Direction Inbound -Action Block -Priority 1
New-NetFirewallRule -DisplayName "IR-Allow-Forensic" -Direction Inbound -Action Allow -RemoteAddress 10.0.1.0/24 -Protocol TCP -LocalPort 5985 -Priority 0
New-NetFirewallRule -DisplayName "IR-Block-All-Out" -Direction Outbound -Action Block -Priority 1
New-NetFirewallRule -DisplayName "IR-Allow-Forensic-Out" -Direction Outbound -Action Allow -RemoteAddress 10.0.1.0/24 -Protocol TCP -RemotePort 5985 -Priority 0

Account Disabling

If compromised credentials are identified, disable the accounts immediately:

Active Directory (PowerShell):

# Disable the compromised account
Disable-ADAccount -Identity "compromised.user"

# Reset the password (prevents any cached credential use)
Set-ADAccountPassword -Identity "compromised.user" -Reset -NewPassword (ConvertTo-SecureString "TempP@ss!IR2026" -AsPlainText -Force)

# Force logoff of all active sessions (requires PSExec or similar)
# Check for active sessions first
Get-CimInstance -ClassName Win32_LogonSession | Where-Object { $_.LogonType -eq 10 }

Linux (disable user and kill sessions):

# Lock the account
usermod -L compromised_user

# Expire the account immediately
chage -E 0 compromised_user

# Kill all active sessions for this user
pkill -u compromised_user

# Revoke SSH keys
rm -f /home/compromised_user/.ssh/authorized_keys

Blocking Malicious Infrastructure

Block known C2 IPs and domains at the network perimeter:

Long-Term Containment

Short-term containment stops the immediate bleeding. Long-term containment allows continued operations while you prepare for eradication. This phase exists because eradication takes time — you cannot always wipe and rebuild every system immediately, especially if the attacker has compromised critical infrastructure.

Long-term containment strategies:

The Containment Decision Matrix

Not every containment decision is straightforward. Isolating a developer laptop is easy. Isolating the primary database server during business hours requires balancing security against business continuity.

Click to enlarge

Key principles:

• High threat + any impact = containment wins. An attacker with domain admin access justifies taking down production systems.
• Low threat + high impact = monitoring may be acceptable temporarily, but document the risk acceptance decision with IC sign-off.
• Never delay containment solely because of business impact without documented approval from the Incident Commander. This decision must be in the incident log.

Evidence Preservation During Containment

Evidence preservation and containment happen in parallel — not sequentially. You cannot wait to finish forensic imaging before isolating a system that is actively exfiltrating data. But you also cannot destroy critical evidence through careless containment actions.

What to Preserve Before Remediation

The Golden Rule

Image before you eradicate. Once you delete malware, remove a web shell, or reset an account, you have destroyed the evidence of how the attacker operated. The forensic image preserves the compromised state for post-incident analysis, legal proceedings, and threat intelligence extraction.

# Linux: Create forensic disk image with verification
dc3dd if=/dev/sda of=/mnt/evidence/EVD-001-linux-web-01.dd hash=sha256 log=/mnt/evidence/EVD-001.log

# Verify the hash matches
sha256sum /mnt/evidence/EVD-001-linux-web-01.dd

# Windows: Memory capture with winpmem
.\winpmem_mini_x64.exe C:\Evidence\EVD-002-memory.raw

# Disk image with FTK Imager CLI
ftkimager.exe \\.\PhysicalDrive0 C:\Evidence\EVD-003-disk --e01 --verify

Eradication

Eradication removes the attacker's presence from your environment. This is not "delete the malware file and call it done." Eradication must be comprehensive — if you miss a single backdoor, the attacker returns.

Eradication Checklist

Eradication on Linux

# Remove identified web shell
rm -f /var/www/html/.hidden/cmd.php

# Remove malicious cron job
crontab -l -u www-data | grep -v "evil-c2.example.com" | crontab -u www-data -

# Remove unauthorized SSH keys
find /home -name "authorized_keys" -exec grep -l "attacker-key" {} \;
# Then remove the offending keys from each file

# Remove rogue systemd service
systemctl stop backdoor.service
systemctl disable backdoor.service
rm /etc/systemd/system/backdoor.service
systemctl daemon-reload

# Verify: Run YARA scan against the filesystem
yara -r /opt/yara-rules/incident-ir2026-047.yar /var/www/ /tmp/ /home/

Eradication on Windows

# Remove malicious scheduled task
Unregister-ScheduledTask -TaskName "SystemUpdate" -Confirm:$false

# Remove rogue service
Stop-Service -Name "WindowsHelperSvc" -Force
sc.exe delete "WindowsHelperSvc"

# Remove malicious registry persistence
Remove-ItemProperty -Path "HKLM:SoftwareMicrosoftWindowsCurrentVersionRun" -Name "SystemHelper"

# Remove unauthorized local admin account
Remove-LocalUser -Name "helpdesk_backup"

# Verify: Check for remaining persistence mechanisms
Get-ScheduledTask | Where-Object { $_.State -ne "Disabled" } | Select-Object TaskName, TaskPath
Get-Service | Where-Object { $_.StartType -eq "Automatic" -and $_.Status -eq "Stopped" }
Get-ItemProperty -Path "HKLM:SoftwareMicrosoftWindowsCurrentVersionRun"

Recovery

Recovery restores compromised systems to normal operation. The goal is not just "the system is running" — it is "the system is running, verified clean, and monitored for attacker return."

Recovery Strategies

Recovery Validation Checklist

Before returning a recovered system to production, verify every item:

Click to enlarge

Communication During Active Incidents

Communication failures during active incidents cause as much damage as technical failures. Stakeholders left in the dark make bad decisions. Analysts working in silos duplicate effort or miss critical connections.

Communication Cadence by Severity

Status Update Template

Every status update during a P1/P2 should follow a consistent structure:

INCIDENT STATUS UPDATE — IR-2026-0047
Time: 2026-02-23 06:00 UTC | Update #4 | Severity: P2

CURRENT STATUS: Containment in progress
WHAT HAPPENED SINCE LAST UPDATE:
- Forensic image of linux-web-01 completed (EVD-001, SHA-256 verified)
- Web shell identified and removed: /var/www/html/.hidden/cmd.php
- Velociraptor hunt across all Linux servers: no additional compromises found

WHAT IS HAPPENING NOW:
- Credential reset for www-data and all web application service accounts
- Reviewing 48 hours of proxy logs for additional C2 communication
- Patching CVE-2026-1234 on all internet-facing web servers

NEXT UPDATE: 2026-02-23 08:00 UTC
DECISIONS NEEDED: None at this time

Monitoring for Attacker Return

Recovery is not the end. Attackers who are evicted often try to return — especially if the initial access vector was not fully remediated or if they established persistence that survived eradication.

Post-recovery monitoring (minimum 30 days):

• Increase Wazuh alerting sensitivity on recovered systems (lower thresholds)
• Deploy Suricata rules specifically targeting IOCs and TTPs from the incident
• Run Velociraptor hunts weekly on recovered systems checking for persistence artifacts
• Monitor for the same C2 infrastructure across the entire environment (not just the recovered system)
• Watch for new accounts, services, scheduled tasks, or SSH keys on recovered systems
• Monitor DNS logs for queries to domains associated with the attacker

What's Next

You have now covered the full operational lifecycle of incident response — from the frameworks that structure your process (Lesson 13.1), through the case management tools that track it (Lesson 13.2), to the containment, eradication, and recovery actions that resolve it (this lesson). In Lesson 13.4: Post-Incident Review, you will learn how to close the loop — conducting structured lessons learned meetings, writing incident reports that drive real change, calculating incident cost, and feeding findings back into preparation to make your team stronger for the next incident. But first, Lab 13.3 puts containment into practice: you will work through a simulated incident where you must isolate a compromised system, preserve evidence, execute eradication steps, and validate recovery — all under time pressure.