Ransomware and Destructive Attack Resilience
Assume the adversary targets backups and identity
The exam tests whether you can design resilience against ransomware and destructive attacks that deliberately disable recovery. Ransomware commonly gains initial access through phishing, exposed services, or stolen credentials, then escalates privileges, moves laterally, steals data, and encrypts. Destructive wipers may go further: delete backups, corrupt hypervisors, and disable identity systems. Resilience assumes prevention will fail and focuses on surviving the attack with trusted recovery.
Core rules
- Reduce initial access with MFA, patching, email filtering, endpoint detection and response, least privilege, and network segmentation. Protect identity as a control plane: tiered admin accounts, just-in-time access, and separate recovery credentials.
- Backups must be immutable, offline or in a separate trust domain, with tested restores. Protect backup catalogs and key management too.
- Detection should cover unusual encryption, mass file renaming, backup deletion, and identity changes. Have a low threshold for isolating segments.
- Decide ransomware policy in advance: who negotiates, whether payment is permitted, legal and sanctions review, insurer involvement, and law enforcement contact. Payment does not guarantee decryption or prevent data leak.
- Plan for extended degraded operations and for rebuilding from clean media, not just restoring in place.
Worked example
A wiper attack destroys virtualization hosts and the backup server. The organization has an immutable cloud copy in a separate account, with a 30-day lock and separate credentials. Recovery starts by rebuilding identity and network services from clean images, then restores priority applications in dependency order. Forensic images are captured before rebuild. The team validates data integrity and scans restored systems before reconnecting. The exercise reveals that the recovery account's MFA tokens were stored in the compromised password manager, so the corrective action moves them to offline hardware tokens.
Traps
Do not assume a decryptor will work or that paying ends the incident. Do not keep backup credentials in the production directory. Do not test only encryption scenarios and ignore wipers, identity destruction, and data theft. Do not reconnect restored systems before validation. Do not improvise the ransom decision during the crisis.