9.2 Containment, Eradication, Recovery, and Lessons Learned
Key Takeaways
- After analysis, the SSCP order is contain, then eradicate, then recover. Restoring while the host is still on the production network re-infects neighbors.
- Short-term containment stops the bleeding (isolate a port, disable an account). Long-term containment is a more durable holding pattern while eradication is planned.
- Do not recover from infected backups. Validate a known-clean restore point, or you re-introduce the encryptor.
- Recovery includes incident documentation: timeline, actions, evidence references, and decisions — not just "server is up."
- Post-incident activities are lessons learned, new countermeasures, and continuous improvement. Closing the ticket without a review wastes the incident.
Containment, eradication, recovery — in that order
After detection, analysis, and escalation, the SSCP outline continues knowledge area 4.1 with Containment, Eradication, and Recovery (incident documentation), then Post incident activities. The order is operational, not decorative. If you restore a file server while the encryptor is still running on the same virtual local area network (VLAN), you recover into an active incident. If you wipe a host before you contain the attacker's other sessions, you eradicate one foothold and leave the rest. Contain, then eradicate, then recover.
NIST SP 800-61 Revision 2 bundled those three into a single phase. The SSCP outline unbundles them. Treat them as three decisions with three exit criteria. Revision 3 maps the same work onto Respond and Recover in Cybersecurity Framework (CSF) 2.0; that mapping still includes containing, eradicating, and restoring. Do not skip a step because a diagram grouped it.
Containment: stop the bleeding without pretending you are done
Containment limits the incident's scope and damage so you can think. It is not cleanup. Two time horizons matter on the exam and on a shift.
| Short-term containment | Long-term containment | |
|---|---|---|
| Goal | Stop spread now | Hold a durable, monitored state while you plan eradication |
| Typical actions | Disable the switch port or quarantine VLAN; disable the compromised account; block command-and-control; take the share offline; isolate the backup server so it is not encrypted next | Temporary hardened jump path, segmented "dirty" VLAN with logging, patched holding servers, compensating firewall rules that can last days |
| Risk if you skip it | Lateral movement while you debate | Users reconnect too soon, or you live in emergency isolation forever |
| Risk if you overdo it | Pulling power and destroying volatile evidence; isolating the only domain controller | A "temporary" VLAN that becomes undocumented production |
Scenario. FILESERVER01 is encrypting the accounting share. Short-term containment is immediate: disable the switch port or the virtual NIC, unmap the share from workstations (or disable Server Message Block (SMB) for that host), disable acct-batch and any interactive admin session that launched the process, and block outbound command-and-control if a beacon is present. You also protect the backup infrastructure — ransomware operators target last-known-good copies. Isolating the backup server is containment, not recovery.
Do not confuse containment with:
- Paying the ransom. That is a legal, cyber-insurance, and executive decision. The SSCP's operational job is still to contain. Payment does not replace isolation.
- Rebooting to "clear it." Reboot can lose memory and kick off persistence. Coordinate with forensics.
- Recovery. Taking the share offline is not "we are back." Users will pressure you to bring the Q drive back. That pressure is how reinfection happens.
Long-term containment for the same incident might be: accounting works from a clean file server built from gold images, on a new VLAN, with new credentials, while FILESERVER01 stays isolated for imaging and malware analysis. That holding pattern can last through a weekend. Document it as containment, not as recovery, until eradication criteria are met.
Short-term versus long-term is a favorite exam contrast. Short-term is the emergency stop (pull the port, freeze the account). Long-term is the monitored holding pattern that lets the business limp while you still distrust the original host. Moving users back onto the original server is recovery, and it is too early until eradication is done.
Eradication: remove the cause, not just the symptoms
Eradication eliminates the attacker's presence and the root cause so recovery will not immediately fail. For file-server ransomware that usually means:
- Identify the initial access (stolen virtual private network (VPN) account without multi-factor authentication (MFA), exposed Remote Desktop Protocol (RDP), malicious macro, vulnerable backup agent).
- Remove malware, persistence (services, scheduled tasks, Group Policy logon scripts, new local admins), and leftover encryptor binaries.
- Rotate credentials the attacker could have stolen — not only
acct-batch, but domain admins, backup service accounts, and VPN tokens. - Close the hole: patch, disable unused remote desktop, fix the Group Policy object, remove the rogue scheduled task.
- Confirm with endpoint detection and response (EDR), file-integrity monitoring, and a hunt that the family is gone from other hosts, not only from
FILESERVER01.
Eradication that only deletes README_RESTORE.txt is theater. The note is a symptom. If the attacker still has a domain admin gold ticket, recovery will be a short interval before the next encryption wave.
Coordinate eradication with evidence handling. If legal wants a forensic image, image first, then rebuild. Eradication by live "cleaning" on a disk that will be an exhibit is how you get a chain-of-custody argument. When in doubt, isolate, image, rebuild from known-good media. Wiping a host while it is still on the production VLAN is not eradication — it is uncontained destruction that can miss other footholds and destroy evidence.
Recovery: restore service from known-good state, and write it down
Recovery returns systems to normal operation after the cause is gone. The outline's example is incident documentation — recovery is not only "the share is up." It is a controlled restore with a paper trail.
Do not recover from infected backups
This is a high-yield trap. Last night's backup of FILESERVER01 may already contain the encryptor, a webshell, or a staging folder. Restoring it because your recovery point objective (RPO) is 24 hours re-introduces the incident.
| Restore candidate | Use it? | Why |
|---|---|---|
| Last night's incremental that includes the hours the encryptor ran | No | You restore malware and encrypted files |
| Weekly full from before initial access, stored online on the same VLAN | Maybe, after isolation and malware scan — still risky if the attacker reached it | Online backups are a common second victim |
| Offline / immutable / air-gapped copy from before the precursor | Preferred, after integrity check | Known-clean point in time |
| Vendor gold image plus data from a verified clean export | Preferred when operating-system persistence is suspected | Faster than trusting a dirty volume |
Recovery procedure the exam expects you to recognize:
- Confirm eradication criteria (or rebuild from gold if you cannot trust the volume).
- Select a restore point before initial access, not before the ransom note.
- Restore to an isolated network, scan, and compare hashes or file-integrity baselines.
- Rotate secrets again if the restored image contains old passwords.
- Reconnect in stages (one share, watch EDR, then the rest).
- Monitor longer than it feels necessary. Ransomware often has a dwell time measured in days.
Incident documentation during recovery includes: timeline of detection and actions, systems and accounts involved, containment measures still in place, what was restored from where, hashes of forensic images, who authorized reconnect, residual risk, and open follow-ups. That record feeds legal, insurance, regulators, and the lessons-learned meeting. A ticket that says "fixed" is not documentation.
Scenario continued. Leadership wants the Q drive back before the 08:00 customs filing. The latest backup finished at 02:00 — after encryption started. The SSCP refuses that restore. The last known-clean offline copy is from Saturday, before the stolen VPN account was used. You restore Saturday's data to a new server, scan it, and bring a read-only share up for the filing. FILESERVER01 stays isolated for imaging. You just traded a smaller RPO miss for not paying the incident twice. That is recovery done correctly.
Post-incident activities: lessons learned, new countermeasures, continuous improvement
The outline's last 4.1 bullet is Post incident activities (e.g., lessons learned, new countermeasures, continuous improvement). NIST SP 800-61 Revision 2 called this Post-Incident Activity. Revision 3 maps a lot of it into CSF 2.0 Identify (improvement) plus the learning that belongs in Govern and Protect. ISO/IEC 27035's lessons learnt phase is the same idea: the incident is wasted if the program does not change.
A lessons-learned meeting is facilitated, blameless about honest mistakes, and ruthless about control gaps. It is not a public shaming of the accountant who mapped the share.
Typical agenda:
| Question | Example answer after the file-server ransomware |
|---|---|
| What happened, in time order? | Stolen VPN account Friday; encryptor Saturday night; detection Sunday 06:12 via EDR plus help-desk call |
| What worked? | Help desk used the incident number; EDR was on the file server; offline backup existed |
| What failed? | VPN lacked MFA; file server allowed unconstrained SMB from the whole campus; last night's backup was on the same VLAN and was also hit |
| Evidence and documentation gaps? | First reboot by an admin before memory capture |
| New countermeasures? | MFA on VPN, SMB segmentation, immutable backups, EDR coverage gap closed, unused admin shares disabled |
| Who owns each action, by when? | Named owners, dates, and how you will test (tabletop or control test) |
New countermeasures are the corrective and preventive controls you add: MFA, network segmentation, disable SMBv1, application allowlisting on servers, offline backups, alert on mass file-rename. Continuous improvement is putting those into the risk register, the playbook, and the next tabletop — not a slide that says "be more careful."
Do not skip post-incident because you are tired. Do not delete documentation "to reduce legal risk" without counsel; destruction after a known incident can be its own problem. Do not reopen the dirty VLAN as a shortcut around the action items. Do not treat "the share is up" as the end of knowledge area 4.1.
When a CAT stem gives you a restored server and asks what is next, look for lessons learned and countermeasures — not "close the ticket." When it gives you an infected backup, do not restore it. When it asks for sequence, contain, eradicate, recover.
Analysis has confirmed ransomware encrypting accounting shares on FILESERVER01. What is the correct next sequence on the SSCP outline?
After the file server is isolated, operations wants to restore FILESERVER01 from last night's backup. That backup job finished after the encryptor started writing files. What should the SSCP do?
A replacement file server is serving accounting from a scanned Saturday backup, and users can work. What post-incident activity does the SSCP outline require?