Topic 19 ยท Deep Dive

19.4 Recovery, Backups, and Safe Rebuilding

Clean Rebuild Beats Salvage

Once eradication begins, resist the siren math of cleaning an infected host in place. A determined intruder leaves persistence in odd corners — scheduled tasks, services, bootkits, firmware modules — that signature scans routinely miss. The doctrine is therefore blunt: wipe and rebuild compromised systems from a known-good image, and rotate every secret the machine could have observed. If a true rebuild is impossible on specialty equipment, reimage the operating system and treat residual trust as zero until a fresh compromise assessment says otherwise.

Backups Are a Target, Not a Safety Net

Ransomware crews now hunt backups first: they delete Volume Shadow Copies, enumerate cloud buckets, and exfiltrate backup archives before encrypting, so the restore path becomes a second extortion lever. The defenses are mechanical — a 3-2-1 layout (three copies, two media types, one off-site), immutability or object-lock so no credential can rewrite a restore point, backup admin credentials segregated from domain admin, and scheduled restore tests, because an untested backup is a rumor. Scan the recovery dataset for malicious indicators before any restoration: verify file-integrity hashes, and inspect archives for webshells and modified autostart entries.

The Rebuild Pipeline

Production rebuilds follow a gated sequence: mount the golden image, patch it to current, pass a scan-clean gate (anti-malware, vulnerability scan, configuration baseline check), then reconnect progressively — staging segment first under heightened monitoring, and only then full production. Reintroducing a "clean" rebuild onto the same network that failed to notice the original intruder is just a rerun of the same film.

The Restore That Reinstalls the Attacker

The classic failure is restoring from an infected backup: a snapshot taken inside the infection window rehydrates the implant along with the data. Dwell time runs weeks or months, so "yesterday's backup" is exactly the wrong instinct. Establish the earliest indicator-of-compromise timestamp from the incident timeline, choose a restore point comfortably older than it, and treat everything in between as suspect.

Architecture Diagram

Rebuild pipeline with a scan-clean gate Known-good image golden baseline Patch to current Scan-clean gate AV + vuln + config Reconnect staged segment restore from infected backup snapshot inside infection window older than earliest IoC only
Patch and scan before reconnecting — and never restore from a backup taken inside the infection window, the crossed-out path that makes incidents chronic.

Key Takeaways

« Back to Topic 19« 19.3 / 19.5 »