Ransomware incident response: containment, eradication, and 3-2-1 recovery

The shape of a ransomware incident

Ransomware follows a predictable arc, and so does the response to it. The incident response process taught for the exam runs through seven phases: preparation, detection, analysis, containment, eradication, recovery, and lessons learned. Preparation happens before anything goes wrong: a written incident response plan, tested backups, defined roles, and playbooks. Detection is the moment a defender notices trouble, such as files renamed with a strange extension, a ransom note in every folder, or an alert for a burst of mass file writes. Analysis confirms the scope: which hosts, which accounts, and which data are affected. Only after analysis does the team act to stop the spread (containment), remove the malware and the attacker's access (eradication), restore service from known-good data (recovery), and finally hold a blameless review (lessons learned).

A common and costly mistake is to jump straight to wiping and rebuilding the first infected machine. That destroys evidence and usually misses the attacker's foothold elsewhere on the network. The disciplined order matters: understand the blast radius before you eradicate, and preserve forensic artifacts (memory captures, disk images, and logs) under chain of custody before you rebuild, because ransomware cases frequently become legal, regulatory, or insurance matters where that evidence is decisive.

Containment and eradication without destroying evidence

Containment for ransomware is about cutting propagation without tipping off the attacker or throwing away evidence. The fastest reliable action is network isolation: administratively disable the switch port or drop the host into a quarantine VLAN so the infected machine can no longer reach file shares, domain controllers, or its command-and-control (C2) server. Pulling the network cable achieves the same isolation, but powering the machine off is usually the wrong move, because a shutdown wipes volatile memory that may hold the encryption keys, the malware in RAM, or the intruder's live tooling.

Segmentation done ahead of time makes containment far easier. If the network is already divided into VLANs with an internal firewall enforcing least-privilege rules between segments, a single compromised workstation cannot reach the whole estate, and responders can sever one segment at a time. The diagram shows this: the infected host's access port is disabled at the core switch (contained and isolated) while the file server, whose shares the ransomware has begun encrypting, stays reachable to the backup infrastructure for the restore.

Eradication comes only after the scope is understood. It means removing the malware, closing the initial access vector (a phished credential, an unpatched service, or an exposed remote-desktop port), resetting compromised credentials, and revoking the attacker's persistence such as newly created accounts, scheduled tasks, or web shells. Rebuilding from a trusted image beats cleaning in place, because you can rarely prove a box is truly clean. Patch the exploited weakness before the host rejoins the network, or you simply invite reinfection.

The 3-2-1 rule and a clean recovery

Recovery from ransomware lives or dies on backups the attacker could not reach or encrypt. The 3-2-1 rule is the classic guideline: keep at least three copies of your data, on two different types of media, with at least one copy stored offsite. The three copies are your live production data plus two backups. The two media types (for example disk and tape, or disk and cloud object storage) protect against a failure mode that hits one technology. The offsite copy survives a fire, flood, or site-wide compromise that takes out the primary location.

Modern ransomware deliberately hunts for and deletes backups, so the offsite copy should also be offline or immutable, meaning write-once or air-gapped storage that cannot be altered or deleted, even by an administrator account, during its retention window. That immutability is what turns a backup into a recovery guarantee rather than one more target for the attacker to encrypt.

Two planning numbers govern the restore. The recovery point objective (RPO) is how much data you can afford to lose, and it drives backup frequency: a one-hour RPO requires at least hourly snapshots or replication. The recovery time objective (RTO) is how long you can be down, and it drives how fast the restore path must be. Before restoring, confirm the backup predates the compromise and is free of the malware, restore into a clean, rebuilt environment rather than onto still-infected hosts, and test your backups regularly, because an untested backup is only a hope, not a plan.