Containment, Eradication, Recovery
Stop the bleeding without torching the evidence that tells you how it started.
What you will learn
- -Isolate a compromised host without wiping volatile evidence
- -Apply the order of volatility when collecting artifacts
- -Sequence eradication and recovery so the attacker cannot return
The instinct when you find a compromised box is to yank the power cord. Do that and you just deleted everything in RAM: the attacker's running process, their open connections, the decryption keys, the injected code that never touched disk. is a balance. You have to cut the attacker off while keeping the evidence alive.
Isolate the network, not the power
Pulling a off the network stops lateral movement and exfiltration while leaving memory intact. That is almost always the right first move. You can do it at the host or, better, at the or so the attacker does not see the interface drop from inside.
$sudo iptables -A OUTPUT -d 185.220.101.4 -j DROP$sudo iptables -I INPUT 1 ! -s 10.10.14.7 -j DROP$sudo ip link set eth0 downThe surgical version, dropping just the IP, keeps the host usable for investigation while denying the attacker their channel. Full interface-down is the blunt option when you cannot trust anything the box is doing. Either way, the machine stays powered so you can grab what is in RAM.
Order of volatility: grab the fragile stuff first
Evidence disappears at different speeds. Collect from most volatile to least, or you lose the good parts. Memory and live network state evaporate the instant the box reboots. Disk survives.
- CPU and cache: gone in nanoseconds, you will not catch these.
- RAM, running processes, network connections: gone on reboot. Grab first.
- Disk, , file timestamps: survive a reboot, collect after.
- Backups and archives: least volatile, collect last.
Capture memory before you do anything that might reboot the host. On Linux, AVML produces a clean image without needing a matching kernel module.
$sudo ./avml /mnt/evidence/INC-2026-0042/mem.limeHash every artifact the moment you collect it so you can prove it was not altered
later. A sha256sum mem.lime > mem.lime.sha256 next to the image is the whole
chain-of-custody habit in one line.
Eradicate, then recover, in that order
removes the foothold: kill the malicious process, delete the web , disable the rogue account, remove the cron job or scheduled task giving them . The trap is doing this before you understand the full . If they have three persistence mechanisms and you find two, just hands the box back to them.
Recovery restores clean systems from known-good backups, ones taken before the compromise window, and watches them hard. Validate the host is actually clean, rotate every that touched it, and monitor for the attacker trying the same door again. Attackers routinely come back within days to check whether you missed something.
For anything past a trivial infection, rebuild from a trusted image instead of cleaning in place. You can never fully prove you found every on a box that had a real intruder. A rebuild from known-good media is faster to trust than a scrub you are only 90 percent sure of.
Containment actions like dropping traffic or downing an interface affect real production systems and real people's work. Take them only on hosts inside your authorized scope, and coordinate with the owner unless the runbook grants you standing authority to act. Off-scope containment is how a responder causes an outage worse than the .
You arrive at a running compromised host with an active attacker session. What do you do first?