Chapter 56 — Ransomware and destructive-attack resilience

In one sentence

Modern ransomware is a full intrusion — initial access, lateral movement, privilege escalation, and specifically disabling your backups and detection tools before encrypting — so resilience means immutable backups the attacker cannot reach or delete, segmentation that limits how far one foothold spreads, and detections tuned to the pre-encryption behaviours that give you a window to act.

Where we are

Every control in this guide — segmentation (Part 4), identity (Part 2/5), detection (Ch 51-54), backups (G1 Ch 49, Part 7 Ch 44/46) — comes together against the threat that most consistently ends organisations' ability to operate. This chapter is ransomware specifically, because it's common enough and distinctive enough to warrant its own playbook.

How it works

The modern ransomware kill chain (know this to know where to intervene):

   1. INITIAL ACCESS   phishing, an exposed RDP/VPN endpoint, an
      exploited unpatched vulnerability, or -- increasingly -- buying
      already-compromised access from an INITIAL ACCESS BROKER (a
      distinct criminal specialisation: they get in, then sell the
      foothold to a ransomware operator).
   2. EXECUTION, DISCOVERY, LATERAL MOVEMENT   often "LIVING OFF THE
      LAND" -- using legitimate admin tools already present (PsExec, WMI,
      RDP, PowerShell, or, in cloud environments, the cloud's OWN APIs)
      rather than custom malware, specifically to blend in with normal
      administrative activity and evade tools looking for "malware."
   3. PRIVILEGE ESCALATION   the target is usually DOMAIN ADMIN
      (on-prem) or CLOUD-ADMIN-EQUIVALENT (Part 2 Ch 6's privesc
      primitives, in the wild) -- broad reach is what makes mass
      encryption possible.
   4. DISABLE DEFENSES AND BACKUPS FIRST -- a hallmark, not an
      afterthought: deleting Volume Shadow Copies (`vssadmin delete
      shadows`), targeting and destroying/encrypting BACKUP SERVERS
      specifically (often before touching production, precisely because
      backups are the recovery path they need to remove), disabling
      EDR/antivirus, and disabling logging -- this stage is a
      DETECTION OPPORTUNITY (below) because it's distinctive and rarely
      has a legitimate explanation.
   5. STAGE AND EXFILTRATE (double extortion) -- steal data BEFORE
      encrypting, so even a successful restore-from-backup doesn't
      remove the leverage: "pay or we publish/sell what we already
      took", independent of whether you can recover operationally.
   6. ENCRYPT AT SCALE, drop the ransom note, begin negotiation
      (sometimes via a dedicated leak-site countdown for double-extortion
      pressure).

Defences mapped to each stage (this guide's controls, applied specifically):

   STAGE 1 (initial access): MFA everywhere, especially VPN/RDP (G1
     Ch 46); patch exposed remote-access services promptly (G1 Ch 47's
     vulnerability-management discipline); phishing-resistant auth
     (WebAuthn/passkeys, G1 Ch 46) for anything reachable from the
     internet.
   STAGE 2 (lateral movement): SEGMENTATION specifically limits how far
     ONE compromised endpoint reaches (G1 Ch 39, Part 4's NetworkPolicy/
     multi-tenancy) -- the single highest-leverage architectural control
     against ransomware SPREAD, independent of how the initial foothold
     happened. Monitor/restrict living-off-the-land tool usage (PsExec,
     WMI, unusual PowerShell) heavily, since blocking it entirely often
     breaks legitimate admin work.
   STAGE 3 (privilege escalation): every control from Part 2 Ch 6 and
     Ch 63 (enterprise identity) -- PAM, no standing admin, JIT elevation
     (Part 7 Ch 49) -- directly reduces how far ONE compromised account
     reaches.
   STAGE 4 (disabling defenses/backups) -- THE KEY DETECTION OPPORTUNITY:
     [ ] shadow-copy deletion commands (`vssadmin delete shadows`,
         `wmic shadowcopy delete`) -- near-zero legitimate frequency,
         extremely high-confidence detection.
     [ ] backup-agent SERVICE STOPS or backup-server authentication
         anomalies -- backups being specifically targeted is itself the
         signal, independent of encryption having started yet.
     [ ] EDR/logging AGENT TAMPERING OR UNINSTALL events.
     [ ] MASS FILE MODIFICATION/RENAME RATE anomalies -- a "ransomware
         canary": a HONEYFILE (a decoy file placed specifically to be an
         early tripwire) that alerts THE INSTANT it's touched, renamed,
         or its extension changes, giving you a chance to isolate before
         mass encryption completes across the estate.
     A detection firing at STAGE 4 is your last chance to intervene
     BEFORE stage 6's damage -- this is why these specific,
     distinctively-abnormal behaviours deserve dedicated, high-priority
     detections (Ch 51) even though they're "late" in the kill chain.
   STAGE 5/6 (exfil/encryption): by this point, resilience is about
     RECOVERY, not prevention -- which is why backups are this
     chapter's central architectural control.

Immutable, resilient backups — the "3-2-1-1-0" rule:

   3 copies of your data (the original plus two backups)
   2 different media/storage types (reduces correlated failure)
   1 copy OFFSITE (a regional/facility disaster doesn't take everything)
   1 copy IMMUTABLE or OFFLINE/AIR-GAPPED (this is the ransomware-
     specific addition to the classic "3-2-1" rule) -- Object Lock/WORM
     storage (G1 Ch 49, Part 2 Ch 9) where even an account with delete
     permissions CANNOT remove or modify the backup within its retention
     window, or a genuinely offline/logically-air-gapped copy the
     ransomware's network-based reach cannot touch at all.
   0 errors -- VERIFIED by actual TEST RESTORES on a schedule. An
   unverified backup is a hope, not a control -- test restoring from it
   regularly, and specifically test the IMMUTABLE copy, since it's the
   one you'll actually need if the ransomware operator specifically
   targeted your other backups per stage 4.

The pay/no-pay decision — genuinely disputed, know the factors:

   Simplified: this decision involves legal, insurance, law-enforcement,
   and executive stakeholders, not a unilateral engineering call --
   engineering's job is to have done the recovery-architecture work
   (above) so the decision is made from STRENGTH (a real recovery option
   exists) rather than DESPERATION (paying is the only path back to
   operating).
   FACTORS:
     - LEGALITY: paying certain SANCTIONED groups/jurisdictions can
       itself be illegal in some countries (in the US, OFAC has issued
       advisories on this) -- legal counsel must be involved before any
       payment consideration, not after.
     - PAYING DOES NOT GUARANTEE a working decryptor, and does NOT
       guarantee exfiltrated data won't be leaked/sold anyway --
       "double extortion" specifically exists to make payment less
       reliably protective even when technically "successful."
     - LAW ENFORCEMENT ENGAGEMENT (FBI/CISA or your national equivalent)
       is generally recommended regardless of the pay decision -- they
       may hold decryption keys from prior investigations of the same
       group, and reporting improves collective intelligence (Ch 53).
     - Debated: the business-continuity cost-benefit math (downside of
       extended downtime and rebuild cost vs the ransom amount) is a real
       consideration organisations weigh, but it also NORMALISES paying,
       which funds and incentivises the criminal ecosystem targeting the
       NEXT victim -- there is no consensus position, and this guide
       takes none; know the factors and ensure the RIGHT PEOPLE (not
       just engineering) make the call, informed by the actual recovery
       options your architecture provides.

Recovery, and the second-encryption trap:

   REBUILD from known-good IaC/images (Part 3's paved road) rather than
   restoring a "cleaned" compromised system -- you cannot be confident
   you found every persistence mechanism (Ch 55's rebuild principle,
   at maximum stakes here).
   STAGED REINTRODUCTION to the network with heightened monitoring --
   attackers FREQUENTLY retain a SECOND, less-obvious foothold and
   RE-ENCRYPT organisations that restore without thoroughly verifying
   eradication (G1 Ch 51's eradication phase, and this is the single
   most costly place to shortcut it). Confirm the INITIAL ACCESS vector
   itself is actually closed, not just that this round's encryption
   payload is gone.
   THE RECOVERY-TIME MATH: this is exactly why the immutable-backup
   investment (above) pays for itself -- restoring from a VERIFIED,
   TESTED, immutable backup after confirmed eradication is measured in
   hours to days; discovering your backups were ALSO encrypted because
   stage 4 succeeded against them is measured in weeks and sometimes
   ends the organisation.

Worked example

A near-miss caught at stage 4, and the recovery drill that validated it would have worked anyway.

   DETECTION: the honeyfile canary (a decoy file in a rarely-accessed
   file share, monitored for ANY access/modification) fires at 2:14am --
   its extension has been changed, consistent with an in-progress mass-
   encryption sweep. Within the same minute, the backup-agent service-
   stop detection (Ch 51's lifecycle, built specifically for this stage 4
   pattern) ALSO fires for the backup server.

   RESPONSE (Ch 55's isolate-don't-terminate, at network scale): the
   on-call, following a PRE-BUILT ransomware-specific playbook, isolates
   the affected network segment IMMEDIATELY (accepting the availability
   cost) rather than investigating first -- for this SPECIFIC, high-
   confidence pattern (two independent stage-4 signals within one minute),
   the playbook explicitly authorises fast, broad, human-triggered
   isolation ahead of full investigation, because the cost of being
   slightly wrong (isolating a segment that turns out to be a false
   positive) is far lower than the cost of being slow against a real,
   in-progress encryption sweep.

   SCOPE: because segmentation (G1 Ch 39, Part 4) limited this
   particular foothold's reach to ONE business-unit's file-share segment
   rather than the whole environment, the blast radius is contained
   BEFORE mass encryption completes across the estate -- exactly the
   payoff of the architectural investment, independent of how fast the
   detection fired.

   RECOVERY VALIDATION: the affected segment's data is restored from the
   IMMUTABLE backup copy (the attacker's attempt to reach the backup
   server was DETECTED at stage 4, but the immutable copy was, by design,
   unreachable via account-level delete permissions regardless). The
   scheduled TEST-RESTORE drills (run monthly, independent of any
   incident) meant the recovery procedure was already rehearsed, not
   improvised -- restore completes in under four hours.

   POST-INCIDENT: the initial-access vector (an unpatched, internet-
   facing service, per stage 1) is identified and patched; law
   enforcement is notified per the organisation's pre-agreed policy even
   though no ransom demand was ultimately received (the intrusion was
   caught before stage 5-6); the pay/no-pay decision NEVER HAD TO BE
   MADE, because containment and recovery worked -- the strongest
   possible outcome, and the direct result of segmentation, honeyfile
   detection, and tested immutable backups all doing their specific jobs.

Practice (75 min)

Implement a honeyfile canary: a decoy file in a realistic-looking location, monitored (a simple file-integrity check or an OS-level audit rule is enough for the lab) for any access or modification; confirm it alerts.
Write and test a detection for shadow-copy deletion commands and backup-agent service stops, using Atomic Red Team's ransomware-adjacent techniques (T1490 "Inhibit System Recovery") for live validation, per Ch 51's lifecycle.
Audit your own (or a lab) backup architecture against the 3-2-1-1-0 rule specifically — identify which element is currently missing (immutability is the most commonly absent piece in real environments).
Run an actual test restore from your immutable/offline backup copy on a schedule (even once, for the lab); time it and document the procedure so it's rehearsed, not improvised.
Write a ransomware-specific incident-response playbook for your organisation: the specific stage-4 detections that trigger it, the fast-isolation authorisation threshold (what confidence level justifies isolating before full investigation), and who (beyond engineering) is looped in for the pay/no-pay decision path, even if you expect to never use it.

Common mistakes

Treating ransomware as "just" malware requiring antivirus. It's a full intrusion with lateral movement and privilege escalation; the same controls from Parts 2-5 of this guide are the actual defense, not signature-based detection alone.
Backups that are network-reachable with delete permissions from the same credentials that could be compromised. If the ransomware operator's escalated access can also delete your backups, you don't have a real recovery path — this is EXACTLY what stage 4 targets.
Never test-restoring. An unverified backup is a hope. Test restores regularly, especially the immutable/offline copy.
No segmentation, so one phished laptop reaches everything. The single highest-leverage architectural control against spread; revisit G1 Ch 39 and Part 4 specifically with ransomware in mind.
No fast-isolation authorization threshold defined in advance. Deciding in the moment, during a 2am incident, whether isolating a segment is "justified enough" costs precious minutes against an in-progress encryption sweep.
Treating the pay/no-pay decision as engineering's call. It involves legal, insurance, and executive stakeholders and has real legal constraints (sanctions); engineering's job is ensuring a real recovery option exists so the decision is made from strength.
Restoring without confirming the initial-access vector is closed. Re-encryption from a retained second foothold is a common, costly failure of incomplete eradication.

Check yourself

Walk through the modern ransomware kill chain's six stages.
Why is stage 4 (disabling defenses and backups) specifically a high-value detection opportunity?
What does the "1-1" addition to the classic "3-2-1" backup rule specifically defend against, and name two ways to implement it?
Why must backup test-restores happen on a schedule rather than only after an incident?
Name three factors in the pay/no-pay decision, and who should be involved beyond engineering.
Why is restoring from backup without confirming eradication a risky shortcut?