Chapter 12: Ransomware Recovery — When Your Files Are Encrypted by Criminals

Where you are: Part II, Chapter 12 of 40. The recovery chapters so far have fought accidents and failures — a reformatted drive (Ch. 6), a corrupted file system you carved past (Ch. 7), a head-crashed platter (Ch. 8), a TRIM-wiped SSD (Ch. 9), a degraded RAID (Ch. 10), a locked phone (Ch. 11). This chapter introduces an adversary who wants your data gone and has the mathematics to keep it that way. It is the home of the book's third anchor case — the ransomware recovery — and it is where the cheerful promise of "deleted ≠ destroyed" finally meets its hardest limit: data that was never deleted, only locked, by encryption you cannot break.

Learning paths: This is a four-track chapter. 💾 Data Recovery lives here for the recovery-options triage and the brutal honesty about partial outcomes. 🛡️ Incident Response owns the first-hour triage, scoping, and preserve-before-you-restore discipline. 🔍 Forensic Examiner comes for evidence preservation, family attribution, and the artifacts the attacker leaves behind. 📜 Legal/eDiscovery must internalize the OFAC, breach-notification, and chain-of-custody stakes that turn a technical incident into a regulated event.

The phone call you don't want

It is a Monday in early March. A regional accounting firm — fourteen people, two partners, the busiest six weeks of their year — opens the office to find that nothing works. The shared drive shows folder after folder of files renamed to gibberish: 2023-Smith-1040.pdf is now 2023-Smith-1040.pdf.{A7F1C0D9}.eking. Every directory contains a new text file named Restore-My-Files.txt. It opens politely. It explains that the firm's files have been encrypted with "military-grade" cryptography, that the only copy of the key sits on a server the firm will never find, and that for the equivalent of US$48,000 in Bitcoin the key can be theirs. There is a countdown. There is a Tor address. There is, near the bottom, a second threat the owner reads twice: we have also downloaded 240 GB of your files, and if you do not pay we will publish your clients' tax returns.

The owner's first instinct is to do something — reboot the server, run an antivirus scan, try to open a file, maybe pay before the timer runs out. Every one of those instincts is wrong, and the difference between a bad week and a catastrophic quarter is whether the next hour is spent reacting or responding.

This is the scenario this chapter teaches you to work. We will start where you must start — with the mathematics, because understanding how ransomware encrypts files tells you immediately which recovery options are real and which are wishful thinking. Then we will walk the first-hour triage, the forensic-preservation step that recovery-only thinking skips at its peril, and the five recovery options in order of reliability. We will close on the section that matters more than all the others combined: prevention, because the single most important sentence in this entire chapter is one you already suspect.

Why This Matters. Almost every other recovery technique in this book exploits the same lucky fact: when data is "deleted," only the pointer is removed, and the bytes persist until overwritten (theme one, the foundation laid in Chapter 2). Ransomware breaks that assumption on purpose. Properly implemented, it does not delete your data — it transforms it into ciphertext that is statistically indistinguishable from random noise, and it controls the only key. There is no pointer to follow, no header to carve, no platter to read. The bytes are right there on the disk, perfectly intact, and perfectly useless. When the data itself is the lock, the old tricks stop working — and you fall back on copies, flaws, and leftovers. That is the whole story of ransomware recovery.

How ransomware encrypts your files

To recover from ransomware you must first accept what you cannot do: you cannot break the encryption. Modern ransomware uses the same cryptographic primitives that protect banking, government secrets, and the device in your pocket. AES-256 and RSA-2048 are not "hard" to brute-force; they are, for any attacker without the key, computationally infeasible — the heat-death-of-the-universe kind of infeasible. If a vendor ever offers to "crack" strong, correctly-implemented ransomware encryption by brute force, they are selling you a fantasy. Recovery never comes from beating the math. It comes from copies the attacker missed, mistakes the attacker made, or keys someone else already holds.

So why does the encryption hold up so well? Because of a clever design called hybrid cryptography, and understanding it precisely is the foundation of everything that follows.

Symmetric versus asymmetric: why ransomware uses both

There are two families of encryption, and they make opposite trade-offs.

Symmetric encryption — AES (Advanced Encryption Standard), or stream ciphers like ChaCha20 and Salsa20 — uses one key for both locking and unlocking. It is extremely fast: a modern CPU with the AES-NI instruction set encrypts gigabytes per second. That speed is exactly what ransomware wants, because it needs to encrypt a victim's entire file collection before anyone notices and pulls the plug. The fatal weakness of symmetric encryption for an attacker is the key-distribution problem: if the same key that locked your files can unlock them, and that key must exist on your machine long enough to do the locking, then a careful examiner might catch it — in memory, in a swap file, in a crash dump, or left carelessly on disk. An attacker who relied on symmetric encryption alone would be handing you the means of your own recovery.

Asymmetric encryption — RSA, or elliptic-curve schemes like Curve25519 — uses a pair of mathematically linked keys. What the public key locks, only the private key can open, and you cannot derive the private key from the public one in any practical amount of time. This solves the distribution problem elegantly: the attacker can publish the public key to the whole world (even embed it openly in the malware) while keeping the private key on a server you will never touch. The weakness is speed. RSA is thousands of times slower than AES and is impractical for encrypting large files directly.

Ransomware authors want AES's speed and RSA's key-distribution safety, so they combine them. This is the hybrid model, and it is the heart of the lock on your files.

The hybrid model, step by step

Here is the canonical scheme, in enough detail that you can reason about every recovery option against it:

  ATTACKER (offline, holds the secret)         VICTIM MACHINE (at "detonation")
  ------------------------------------         --------------------------------
  RSA master key pair:                         For each target file:
    PUB_master   (shipped IN the malware,        1. generate a random AES-256 key  K_file
                  or fetched from C2)             2. C = AES_encrypt(K_file, file_bytes)   [FAST]
    PRIV_master  (NEVER leaves the attacker)      3. K_enc = RSA_encrypt(PUB_master, K_file)
                                                  4. write C ; append K_enc to the file
                                                  5. DELETE / overwrite the original
                                                  6. zero K_file out of memory

  To read your file again you need  K_file (the AES key).
  K_file is sealed inside           K_enc.
  K_enc opens with ONLY             PRIV_master  --->  which only the attacker holds.

Read that diagram until it is obvious. The malware never needs to phone home to encrypt — it carries the public key with it, so it works even on an air-gapped machine. Each file gets its own random AES key (some families use one key per victim instead; the principle is identical), the bulk encryption is fast, and the only sensitive secret on your machine — the AES key — exists for milliseconds and is then sealed inside an RSA blob you cannot open and wiped from memory. The encrypted AES key rides along, appended to the very file it locked, taunting you. You are holding the key to your data in your hands. You simply cannot open the box it is in.

This is why the entire game reduces to one question: can you obtain K_file (or PRIV_master) by some route other than breaking the math? Every recovery option later in this chapter is a different answer to that question — a backup that never got encrypted, a vendor who recovered the key from a flawed implementation, a snapshot the malware forgot to delete, a leftover plaintext copy, or, in the last resort, paying the attacker to run PRIV_master for you.

Per-file encryption versus full-disk — and why your computer still boots

A telling detail of that ransom note: the firm could read it. The machine booted. Windows ran. This is not an accident.

Most ransomware performs per-file encryption of user data only. It walks the file system, targets files by extension — documents, spreadsheets, images, databases, archives, virtual-machine disks, source code, mailboxes — encrypts each one, renames it (appending an extension like .eking, .lockbit, .crypt, or a random string), and drops a ransom note in each directory it visits. Crucially, it skips the operating system, the page file, executables, and boot files. The reason is coldly commercial: if the malware bricked the machine, the victim could not read the ransom note, could not browse to the payment portal, and could not pay. Functioning ransomware leaves you just enough working computer to become a customer.

A few families instead attack the file system's structure rather than each file. The classic example is Petya, which encrypted the NTFS Master File Table (the MFT — the index of every file on the volume, see Chapter 4) and replaced the Master Boot Record with a fake CHKDSK screen. Encrypting one small, central structure is far faster than encrypting millions of files, and it renders the volume unmountable just as effectively. True "full-disk" ransomware that encrypts every sector is rare, precisely because it is slow and self-defeating.

Limitation. The "your machine still boots" design is a small mercy, not a recovery path. The booting OS is intact because the attacker chose not to touch it; your data — the only part you cannot reinstall from a Windows ISO — is exactly the part they encrypted. Do not mistake a working desktop for a recoverable one.

What actually happens on disk — the recovery opening

Here is the single most important recovery fact in this chapter, and it hinges on a behavioral choice the malware author made, not on the cryptography. When ransomware encrypts a file, it does one of two things at the storage layer:

1. Copy-encrypt-delete. It reads the original file, writes the ciphertext to a new file, and then deletes (unlinks) the original. On a traditional hard drive, this is your opening. The original plaintext is now unallocated space — the pointer is gone, but the bytes survive until something overwrites them. This is theme one, alive and well: deleted ≠ destroyed. You can sometimes carve the originals back (Option 4, later).

2. In-place overwrite. It opens the original file and overwrites its contents with ciphertext in the same clusters. Now the plaintext is genuinely gone — overwritten, not merely unlinked — and carving will not save you.

Which behavior a given family uses is a research question you answer by analysis, ideally on a copy in a lab. It varies by family and even by file size within a family. The difference is enormous: the same incident on the same data can be 60% recoverable or 0% recoverable depending solely on whether the malware author wrote a MoveFile-then-DeleteFile routine or an in-place WriteFile. And note the brutal asymmetry introduced by Chapter 9: even with copy-encrypt-delete, an SSD's TRIM command may have told the controller to zero the deleted blocks within seconds, erasing your opening before you ever arrived. Hard drives forgive; flash forgets. Hold that thought — it returns in the anchor case, where the firm's HDD-based server and its SSD-based workstations had completely different recovery outcomes.

Let us look at what encryption does to a file at the byte level. Here is a normal JPEG header — the same FF D8 FF signature you carve on in Chapter 7 and catalog in Appendix A:

Original photo.jpg  (intact — note the recognizable structure)
Offset    Hex                                              ASCII
00000000  FF D8 FF E0 00 10 4A 46  49 46 00 01 01 00 00 48  ......JFIF.....H
00000010  00 48 00 00 FF DB 00 43  00 08 06 06 07 06 05 08  .H.....C........
00000020  07 07 07 09 09 08 0A 0C  14 0D 0C 0B 0B 0C 19 12  ................

And here is the same file after encryption. The header is gone; every byte is high-entropy ciphertext, statistically indistinguishable from random data. At the very end, the malware has appended its key blob and a family marker — the encrypted AES key and a victim ID — so the attacker's decryptor knows what it is looking at:

photo.jpg.{A7F1C0D9}.eking  (encrypted — body is noise; trailer is the wrapped key)
Offset    Hex                                              ASCII
00000000  3A 9C 7E 04 D1 6B B2 8F  55 E0 12 A7 F9 4C 0D 6E  :.~..k..U....L.n
00000010  A8 33 C5 1F 90 7B 2D E6  4A 11 B8 5C 02 F3 9D 70  .3...{-.J..\...p
   ...    (high-entropy ciphertext for the entire file body)         ...
-- appended trailer (illustrative; layout is family-specific) --
00A3F000  <-- 256 bytes: K_enc = the AES key sealed with PUB_master -->
00A3F100  B5 C4 ... (RSA-wrapped key, high entropy) ...    ................
00A3F1F0  65 6B 69 6E 67 7B A7 F1  C0 D9 7D 00 00 00 00 00  eking{....}.....
                                       ^^ family marker + 8-byte victim ID

Two practical lessons live in that trailer. First, the appended key blob and marker are forensic gold: they identify the family and version, which tells you whether a decryptor exists. Second — and this is the recovery nuance that surprises people — not every byte of every file is necessarily encrypted.

Partial and intermittent encryption — where plaintext survives

Encrypting terabytes takes time, and time is the attacker's enemy. So many families cut corners on coverage, and those corners are recovery openings.

The widespread consumer family STOP/Djvu is the canonical teaching case. It encrypts only approximately the first 150 KB of each file using the Salsa20 stream cipher, then appends its key/ID trailer. For a small document that means the whole thing is locked. But for a large file — a video, a database, a disk image — everything past the first 150 KB is untouched plaintext. You cannot simply open such a file (the header is encrypted, so the application chokes), but a knowledgeable examiner can sometimes reconstruct usable content from the intact tail, or repair the file by splicing a generic header onto the surviving body. STOP/Djvu offers a second, even more important lesson, covered under decryptors below: its distinction between recoverable "offline IDs" and unrecoverable "online IDs."

The human-operated "big-game" families — LockBit, BlackCat/ALPHV, Play, and others — popularized intermittent encryption: encrypt only part of each file (say, every other block, or the first N bytes of each chunk) to roughly double throughput. For a photo, intermittent encryption can leave large recognizable regions. For a structured file like a database or a virtual disk, though, even partial encryption is usually fatal — corrupt every other 64 KB block of a SQL database and it will not mount, even though half its bytes are pristine. So partial encryption helps unstructured media far more than structured data. Knowing which files in a victim's set are which lets you prioritize the salvageable ones.

Try This. On a copy of a couple of encrypted files (never the originals — theme two, the original is sacred), compute a sliding-window Shannon entropy across the file. Plaintext and structured data sit well below 8.0 bits/byte; encrypted regions sit at ~7.99–8.0. A file that is high-entropy for the first 150 KB and "normal" thereafter is shouting STOP/Djvu, partial encryption, tail recoverable at you. You will build exactly this measurement in the triage script below.

When "ransomware" is really a wiper

One more category determines whether recovery is even theoretically possible: some malware looks like ransomware but is actually a wiper, designed to destroy, not extort. The 2017 NotPetya outbreak is the defining example. It displayed a ransom note and a payment address, but the "installation ID" it showed victims was random noise — it tracked nothing, so even the attacker could not map a payment to a key. There was no recovery, for anyone, at any price; the encryption was one-way by design. NotPetya was a destructive cyberweapon wearing ransomware's clothes.

This is why family identification comes before any recovery attempt. If the strain is a known wiper, paying is not a last resort — it is throwing money into a furnace, and your only options are backups and carving. Identifying the family also tells you whether a free decryptor exists, whether the family is known to exfiltrate data (changing your legal obligations), and whether it leaves implementation flaws you can exploit. Attribution is not academic. It directly sets your strategy.

Technology changes, principles don't. The cipher names change — DES gave way to AES, RSA shares space with Curve25519, families rebrand every season — but the method you apply does not (theme four). Understand the technology, identify precisely what you are facing, preserve the evidence, then work the recovery options from most to least reliable. A new ".xyz" extension on the news this week does not change a single step of that process.

The first hour: triage before you touch anything

The minutes after discovery are where incidents are won or lost, and almost every untrained instinct makes things worse. Burn this short list into muscle memory, because the firm's office manager — the one who found the screens that Monday — needs to do exactly this, and not one thing more, before help arrives.

• Isolate, do not power off (yet). Disconnect the affected machines from the network — pull the Ethernet cable, disable the switch port, isolate the VLAN, turn off Wi-Fi. This stops the malware spreading to other hosts and stops ongoing data exfiltration. But do not yank the power on a still-running machine, because volatile memory may hold the encryption keys, the live malware process, and active connections to the attacker's infrastructure — evidence (and possibly the key itself) that vanishes the instant power drops. Containment and preservation are different goals; serve both by isolating the network while leaving the machine running until you can capture memory.
• Do not reboot, do not run cleanup tools, do not "scan and remove." Rebooting can trigger a second encryption stage, destroy in-memory keys, and rotate logs. Antivirus "remediation" may delete the very malware binary you need for analysis and the very files you need as samples.
• Do not start deleting the encrypted files or "trying things" on the originals. The encrypted files are evidence and may be your only path back if a decryptor or seized key later surfaces. Work on copies.
• Do not pay anything in the first hour. Paying is a last-resort decision with legal weight (OFAC, below), and you have not yet established whether you even need to. There is no recovery-related reason to rush a payment in the first hour; the countdown is a sales tactic.
• Start a written timeline immediately. Who found what, when, on which machine, what was done. This document becomes the spine of the forensic report (Ch. 26), the insurance claim, and any law-enforcement referral.
• Call for help. Cyber-insurance carrier (they often require you to use their incident-response panel and may void coverage if you go it alone), an IR/recovery firm, and — for many sectors, mandatorily — law enforcement.

Scope the blast radius

Before you plan recovery you must know its size: which machines, which shares, how many files, and — critically — whether the backups survived. A simple, fast measurement is file entropy. Encrypted files are nearly maximal entropy; most ordinary files are not. Here is an illustrative triage scanner. It is reading-only and meant to run against a copy or a mounted forensic image — never the live originals.

#!/usr/bin/env python3
"""ransomware_triage.py - classify files as likely-encrypted vs intact.
Illustrative only. Run against a COPY or a forensic image, never originals.
See Appendix B for the maintained version of this toolkit."""
import math
import os
import sys
from collections import Counter

SAMPLE = 8192          # bytes sampled from the front of each file
ENC_THRESHOLD = 7.90   # Shannon bits/byte above which we suspect ciphertext

# Known-good magic numbers (see Appendix A) reduce false positives on
# formats that are legitimately high-entropy because they are compressed.
MAGIC = {
    b"\xFF\xD8\xFF":            "jpeg",
    b"\x25\x50\x44\x46":        "pdf",        # %PDF
    b"\x50\x4B\x03\x04":        "zip/ooxml",  # docx/xlsx/pptx/zip
    b"\x89PNG\r\n\x1a\n":       "png",
    b"\x49\x49\x2A\x00":        "tiff (LE)",
}

def shannon_entropy(data: bytes) -> float:
    if not data:
        return 0.0
    counts = Counter(data)
    n = len(data)
    return -sum((c / n) * math.log2(c / n) for c in counts.values())

def has_known_magic(head: bytes) -> bool:
    return any(head.startswith(sig) for sig in MAGIC)

def classify(path: str) -> tuple[str, float]:
    with open(path, "rb") as fh:
        head = fh.read(SAMPLE)
    ent = shannon_entropy(head)
    if has_known_magic(head):
        return ("intact (valid header)", ent)
    if ent >= ENC_THRESHOLD:
        return ("LIKELY ENCRYPTED", ent)
    return ("intact (low entropy)", ent)

def main(root: str) -> None:
    encrypted = total = 0
    for dirpath, _dirs, files in os.walk(root):
        for name in files:
            p = os.path.join(dirpath, name)
            try:
                verdict, ent = classify(p)
            except OSError:
                continue
            total += 1
            if verdict.startswith("LIKELY"):
                encrypted += 1
            print(f"{ent:5.2f}  {verdict:24s}  {p}")
    pct = (encrypted / total * 100) if total else 0.0
    print(f"\n{encrypted}/{total} files flagged as encrypted ({pct:.1f}%).")

if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else ".")

Run against a copy of the firm's share, it produces a quick census:

 7.99  LIKELY ENCRYPTED          /mnt/copy/Clients/Smith/2023-1040.pdf.{A7F1C0D9}.eking
 7.98  LIKELY ENCRYPTED          /mnt/copy/Clients/Jones/payroll.xlsx.{A7F1C0D9}.eking
 1.20  intact (low entropy)      /mnt/copy/Clients/_README/Restore-My-Files.txt
 4.31  intact (valid header)     /mnt/copy/Admin/firm-logo.png
 7.99  LIKELY ENCRYPTED          /mnt/copy/QuickBooks/company.qbw.{A7F1C0D9}.eking

18,442/18,907 files flagged as encrypted (97.5%).

That 97.5% number is your blast radius. The ransom note sits at low entropy (it is plaintext, by design — they want you to read it). A handful of files survived untouched (the malware skipped them, or finished before reaching them). Now you know the scale, and you can plan.

Limitation. Entropy is a screen, not a verdict. Already-compressed files — ZIP archives, JPEGs, MP4s, encrypted-by-you-on-purpose files — also score near 8.0 and will false-positive without the magic-number check. And a file can be partially encrypted (STOP/Djvu's first 150 KB) yet score "encrypted" on its head while its tail is recoverable. Use entropy to triage, then confirm with the appended family marker, the extension, and the ransom note. Never report "all files lost" from an entropy scan alone.

The forensic angle: preserve before you destroy

Here is the tension that defines professional ransomware response, and the place where the recovery mindset and the forensic mindset must be reconciled rather than allowed to fight.

The recovery instinct is to restore service as fast as possible: wipe the machines, rebuild, get the firm back to filing tax returns. The forensic and incident-response instinct is to preserve the scene first — because once you wipe, you can no longer answer the questions that determine whether the nightmare is actually over. How did they get in? Are they still in? What did they take? Is the backup safe to restore, or is it compromised too? Those questions have legal, financial, and safety consequences, and they cannot be answered from a freshly-imaged blank machine.

Recovery vs. Forensics. The encrypted disk is the chapter's signature dual-purpose artifact. To 💾 Recovery, it is a haystack to carve unencrypted originals from, as fast as possible. To 🔍 Forensics and 🛡️ IR, it is the crime scene — it holds the malware binary, the attacker's tools, the deleted-shadow-copy commands in the event log, the staged exfiltration archive, the timeline of the intrusion. Treat it as recovery-only and you may carve back some photos while destroying the proof of how the breach happened and what was stolen — proof your lawyers, your insurer, your regulators, and law enforcement all need. The reconciliation is simple and non-negotiable: image first (theme two — the original is sacred), preserve the image with hashes and chain of custody, and do all recovery and analysis on copies. One acquisition serves both disciplines. Skipping it serves neither.

Order of volatility: capture memory first

Recall the order of volatility from Chapter 15: the most fleeting evidence is captured first. For ransomware, that order has a special payoff. The encryption keys may be in RAM. If you capture a memory image of a still-running infected machine before it reboots or powers off, you sometimes capture the live malware process, its configuration, its network connections to command-and-control infrastructure — and, for certain flawed families, the symmetric keys themselves, recoverable by memory analysis (Volatility, Chapter 22). This is why "isolate but do not power off" matters so much: a hasty shutdown can throw away the one copy of the key your machine ever held in the clear.

So the preservation sequence on a live, infected, network-isolated machine is:

1. Capture volatile memory — a full RAM image — before anything else.
2. Document and collect the on-screen ransom note, network state, and running processes.
3. Then acquire a forensic disk image (write-blocked source where possible — see Chapter 14).

Image with a verifying tool so the hash is computed during acquisition, not bolted on afterward:

# Image-first. The source is write-blocked; we compute SHA-256 inline.
sudo dcfldd if=/dev/sdb of=/evidence/acct-server.dd \
     hash=sha256 hashlog=/evidence/acct-server.sha256 \
     bs=4M conv=noerror,sync

# Independently verify the image matches what dcfldd recorded.
sha256sum /evidence/acct-server.dd
cat /evidence/acct-server.sha256
# -> the two SHA-256 values MUST match. Record both on the chain-of-custody form.

Chain of Custody. A ransomware incident is presumptively headed somewhere legal — an insurance claim, a breach-notification filing, a lawsuit from affected clients, a law-enforcement case, possibly all four. From the first image, treat every piece of evidence as courtroom-bound: a unique evidence number, the acquisition hash, who held it and when, where it is stored. The blank chain-of-custody and report forms in Appendix F exist for exactly this moment. "I recovered some files" is a service. "I can prove these files came from this drive, unaltered, acquired on this date" is evidence — and you usually do not know in the first hour which one the client will end up needing, so produce the second.

What to collect

Beyond the images, a ransomware case has a standard evidence set. Collect each item to a copy and log it:

• The ransom note(s). Each one is an artifact: filename, full text, the payment address, the Tor URL, the contact email, the victim/campaign ID. These drive family identification and may tie this incident to others in law-enforcement databases.
• Several sample encrypted files (with their new extensions) and, where you can find them, a matching unencrypted version from a backup or another machine. A plaintext/ciphertext pair is invaluable for analysis and is required by some decryptor tools.
• The malware binary, dropper, or script, if present — preserved, never executed in your environment. (Analysis of the binary itself is malware forensics, Chapter 32.)
• Logs: Windows Event Logs, firewall/VPN logs, RDP gateway logs, EDR/antivirus telemetry, email gateway logs (for the phishing vector), and the backup system's own logs (did the attacker log into it and delete jobs?).

The traces the attacker leaves

Theme three — every action leaves a trace, and the absence of a trace is itself a trace — is loud in ransomware. The attacker took deliberate steps to destroy your safety nets, and each step is recorded somewhere. The most reliable tell is the shadow-copy deletion. Essentially every human-operated strain runs commands like these at detonation to ensure you cannot restore from Windows' built-in snapshots:

vssadmin.exe delete shadows /all /quiet
wmic.exe shadowcopy delete
bcdedit.exe /set {default} recoveryenabled No
bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures
wbadmin.exe delete catalog -quiet
vssadmin.exe resize shadowstorage /for=C: /on=C: /maxsize=401MB   (forces old copies out)

Those commands are evidence. If process-creation auditing (Event ID 4688 with command-line capture) was enabled, you will see them with timestamps — and the time of the vssadmin delete shadows is, to a close approximation, the detonation time of the attack. The execution also leaves Prefetch entries (VSSADMIN.EXE-XXXXXXXX.pf) and AmCache traces (Chapter 16). Hunt for them on the live system or in the image:

# Inventory shadow copies first (live system or mounted image).
vssadmin list shadows
# Common result on a hit machine: "No items found that satisfy the query."
# -> the attacker deleted them. That absence is itself a finding.

# Find the deletion in process-creation auditing (Event ID 4688).
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} |
  Where-Object { $_.Message -match 'vssadmin|wmic|wbadmin|bcdedit' } |
  Select-Object TimeCreated,
                @{N='CmdLine'; E={ ($_.Message -split "`n" |
                  Where-Object { $_ -match 'Command Line' }) -join ' ' }}

# RemoteInteractive (RDP) logons - a top initial-access vector (Logon Type 10).
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object { $_.Message -match 'Logon Type:\s+10' } |
  Select-Object TimeCreated

# A burst of failed logons (Event ID 4625) before a success = RDP brute force.
# A cleared Security log (Event ID 1102) = the attacker covering their tracks.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102}

Stitching these timestamps into a single timeline (the technique you will master in Chapter 21) reconstructs the whole intrusion: initial access (often an exposed RDP port brute-forced, or a phished credential), a dwell period of days or weeks, privilege escalation, lateral movement, data exfiltration, deletion of backups and shadow copies, and finally encryption. That timeline answers the questions wiping the disk would have erased — and the exfiltration finding, in particular, determines whether you are dealing with a mere availability incident or a reportable data breach.

Legal Note. If the timeline shows data was exfiltrated — and most human-operated ransomware now steals before it encrypts — you likely have a data breach under one or more regimes: U.S. state breach-notification laws, HIPAA if the firm held protected health information, GLBA/IRS rules for tax preparers, GDPR's 72-hour clock if any data subjects were in the EU. The forensic question "was data taken, and whose?" is not optional curiosity; it starts legal clocks. The frameworks are catalogued in Appendix E and developed in Chapter 25.

Recovery options, in order of reliability

Now the question the client actually asked: can I get my files back? There are five answers, and professionals work them strictly in this order — most reliable first, last resort last. Skipping straight to "should we pay?" is the mark of someone who does not understand the earlier options.

                  Files encrypted by ransomware
                              |
        [ STOP ]  Isolate. Don't wipe. Don't pay yet. Preserve.
                              |
        Capture RAM image, then disk image. Hash. Chain of custody.
                              |
  +--------------------------------------------------+
  | 1. Good OFFLINE / immutable backup?              |-- YES --> wipe, rebuild CLEAN, restore.  DONE
  +--------------------------------------------------+
                              | NO / partial
  +--------------------------------------------------+
  | 2. Known free decryptor? (ID Ransomware / NMR)   |-- YES --> decrypt on COPIES, verify
  +--------------------------------------------------+
                              | NO
  +--------------------------------------------------+
  | 3. Volume Shadow Copies survive?                 |-- YES --> restore Previous Versions
  +--------------------------------------------------+
                              | NO
  +--------------------------------------------------+
  | 4. Carve unencrypted originals / slack / temp    |-- SOME --> PARTIAL recovery (HDD >> SSD)
  +--------------------------------------------------+
                              | insufficient
  +--------------------------------------------------+
  | 5. Negotiate / pay  (LAST resort)                |  OFAC + ethics + no guarantee
  +--------------------------------------------------+

Option 1 — Restore from backup (the only reliable solution)

If the firm has a good, recent backup that the attacker could not reach, the entire incident collapses into a routine restore. Wipe the affected machines, rebuild clean, restore the data, and you are done — with no key, no payment, and no dependence on the criminal. This is the only reliable recovery method that exists. Every other option on this list is a way of salvaging something from a situation where this option failed. That is why the prevention section below is the most important part of the chapter.

But there are non-obvious caveats that separate professionals from amateurs:

• The attacker probably hunted your backups first. Modern human-operated ransomware dwells in the network for days specifically to find and destroy backups before detonating — deleting shadow copies, encrypting the NAS, logging into the backup console with stolen domain-admin credentials and deleting the jobs and the cloud copies. A backup that was online and reachable from a compromised admin account is presumed compromised until proven otherwise. This is why offline and immutable backups (next section) are the whole game.
• Verify the backup is clean and complete before you trust it. Confirm it is not itself encrypted, and that it predates the intrusion — restoring a backup taken after the attacker was already inside can reintroduce their access or their dormant tooling.
• Do not restore onto a still-compromised environment. If you restore your data onto the same network with the same exposed RDP port and the same stolen credentials still valid, you will be re-encrypted within days — sometimes within hours. Close the initial-access vector, rotate every credential, rebuild from known-good media, then restore. The forensic timeline (above) is what tells you what the vector was.
• Preserve evidence first. Capture your images before you wipe; the wipe is irreversible.

Option 2 — Check for a known decryptor

Sometimes the criminals make mistakes, and sometimes someone else already holds the key. Free decryptors exist for dozens of families, for several reasons: implementation flaws (weak or predictable random-number generation, keys recoverable from disk or memory, hardcoded or reused keys, buggy crypto), master keys leaked by the operators (the Shade/Troldesh gang released ~750,000 keys when they shut down in 2020), keys released after the group "retired" (GandCrab), or keys seized by law enforcement and turned into universal decryptors (a REvil/Sodinokibi decryptor followed the 2021 takedowns). You cannot break good crypto, but you can absolutely benefit from the attacker's errors and others' victories.

The workflow:

1. Identify the family precisely. Upload the ransom note and a sample encrypted file to ID Ransomware (id-ransomware.malwarehunterteam.com) or the Crypto Sheriff at No More Ransom (nomoreransom.org). No More Ransom is a joint project of Europol, the Dutch police, Kaspersky, and McAfee, launched in 2016, and is the authoritative clearinghouse for free decryptors.
2. Check whether a decryptor exists for that exact family and version. Operators patch the flaws that decryptors exploit, so a tool for v1 frequently fails on v2.
3. Download the decryptor only from the original vendor or from No More Ransom. This matters: "ransomware decryptor" is a favorite lure for more malware. Never run a decryptor from a random forum or search ad.
4. Test on copies of a few files first, then verify the output before trusting it at scale.

=== ID Ransomware result (illustrative) ===
Uploaded:    Restore-My-Files.txt  +  2023-1040.pdf.{A7F1C0D9}.eking

Identified:  STOP/Djvu  (variant: .eking)
Cipher:      Salsa20 (file body, ~first 150 KB) + RSA-2048 (key wrap)
Note:        _readme.txt / Restore-My-Files.txt
Decryptable: PARTIAL - only "OFFLINE ID" victims (personal ID ends in 't1').
             Offline keys are reused across victims and are known to Emsisoft.
             "ONLINE ID" victims have a unique server-side key -> NOT decryptable.
Tool:        Emsisoft Decryptor for STOP/Djvu  (obtain via nomoreransom.org)

That output captures the most instructive lesson in the whole decryptor landscape, using STOP/Djvu. When the malware could not reach its command-and-control server at encryption time, it fell back on a hardcoded "offline" key — the same key for every offline victim — and the personal ID ends in t1. Those victims can be decrypted, because the offline key becomes known. When the malware did reach C2, it used a unique per-victim key held only on the server (an "online ID"), and those victims cannot be decrypted without that server key. Same malware, same victim, wildly different outcomes — decided by whether a network connection happened to succeed during the attack. That is the razor's edge that recovery so often balances on.

Tool Tip. Maintain a private library of legitimate decryptors and bookmark the authoritative sources rather than searching in a crisis: No More Ransom, Emsisoft (the largest free collection), Kaspersky (RakhniDecryptor, RannohDecryptor), Avast/AVG, Bitdefender, and Trend Micro. Catalogued in Appendix C. The minutes you save not searching are minutes you do not spend tempted by a poisoned download.

Option 3 — Volume Shadow Copy recovery

Windows' Volume Shadow Copy Service (VSS) maintains point-in-time snapshots of NTFS volumes — the mechanism behind "Previous Versions" and System Restore (see Chapter 4 and Chapter 6). If snapshots predating the attack survive, you can restore earlier, unencrypted versions of your files at the click of a button. It is a wonderful recovery path — when it works.

The bad news, which you already met under the attacker's traces: essentially every serious strain deletes the shadow copies first thing, precisely to close this door. So most of the time vssadmin list shadows returns "No items found," and the door is shut.

But not always all the way. VSS stores its differential data as files inside the System Volume Information folder on the protected volume. When vssadmin delete shadows runs, it deletes the catalog entries — but the underlying differential blocks are not necessarily overwritten immediately (theme one again: deleted ≠ destroyed, even here). Specialized tools can sometimes reconstruct snapshots from those surviving blocks in a forensic image even when Windows reports none. It is a low-probability play, but it is free and worth attempting on the image:

# Try to recover Volume Shadow Copies from the IMAGE, even if vssadmin says none.
# libvshadow (Joachim Metz) enumerates and mounts VSS stores from a raw image.
vshadowinfo /evidence/acct-server.dd          # list any recoverable stores
mkdir /mnt/vss
vshadowmount /evidence/acct-server.dd /mnt/vss
ls /mnt/vss
#   vss1  vss2   -> historical volumes you can now mount read-only and browse
#   (empty)      -> differential blocks were overwritten; this door is closed

On Windows, Arsenal Image Mounter and ShadowExplorer do the equivalent — exposing historical snapshots from a live system or a mounted E01 image. When even a partial snapshot survives, you may recover a meaningful slice of the data for free, with no key and no payment.

Limitation. Do not pin your hopes on VSS. Against any competent human-operated attack it is gone, and even the carving-the-VSS-store trick succeeds only when the attacker did not also run vssadmin resize shadowstorage (which actively forces the old differential blocks out) and when subsequent disk activity has not overwritten the freed space. Treat a surviving shadow copy as a happy bonus, never as the plan.

Option 4 — Carve for unencrypted originals, slack, and temporaries

This is theme one's last stand, and on a hard drive it is often the difference between "we lost two months" and "we lost two months except for the irreplaceable things we carved back." Recall that many families do copy-encrypt-delete: they write the ciphertext to a new file and unlink the original. The original plaintext now sits in unallocated space until overwritten. File carving (the full technique is Chapter 7) ignores the file system entirely and scans the raw image for file signatures — the FF D8 FF of a JPEG, the %PDF of a PDF, the PK\x03\x04 of an Office document — recovering files by their content even though their directory entries are gone.

# Carve known file types from unallocated space of the image (theme: deleted != destroyed).
photorec /d /evidence/carved /cmd /evidence/acct-server.dd search

# Targeted carve when you know what matters most:
foremost -t jpg,pdf,doc,docx,xlsx,pst -i /evidence/acct-server.dd \
         -o /evidence/foremost-out

Foremost finished.
FILES EXTRACTED
-------------------------------------------------------------
jpg:=  3,114
pdf:=  1,902
docx:=   774
xlsx:=   421
pst:=      2
-------------------------------------------------------------
6,213 files carved to /evidence/foremost-out/

Beyond unallocated space, several other reservoirs frequently hold unencrypted copies the malware never touched:

• Application temporary and autosave files — Microsoft Office leaves ~$ lock files and .tmp/.asd autosave copies; many apps write working copies the ransomware's extension filter skipped.
• Thumbnail caches — thumbcache_*.db holds small renders of images and document previews; not the full file, but sometimes enough to identify or partially reconstruct what was lost.
• The recycle bin, the print spooler, browser caches, and email databases — all may contain copies that predate the attack.
• File slack — the space between a file's logical end and the end of its last cluster (Ch. 2) can hold fragments of older, larger files that once lived there.

Carving's results are partial and unpredictable. You recover what survived, in no particular order, usually with the original filenames and folder structure lost (carved files come out as 0001.jpg, 0002.pdf, and so on), so a human must triage them. But when there is no backup and no decryptor, this is often the only thing that gives the client back anything of the work they thought was gone forever.

Recovery vs. Forensics. The same carve serves both masters. For 💾 Recovery, the carved JPEGs and PDFs are the deliverable — the family photos and client documents handed back to a grateful client. For 🔍 Forensics, carving the unallocated space of a ransomware-hit machine also resurrects the attacker's staged exfiltration archive — the .7z or .rar they built of your stolen data before uploading it — proving what was taken and confirming the breach. One pass over the image, two completely different wins.

Limitation. Carving's great enemy is the SSD (the hard truth of Chapter 9). On a TRIM-enabled SSD, the moment the malware deleted the original, the file system told the controller those blocks were free, and the controller's garbage collection likely zeroed them within seconds — before you ever powered the machine off. Carving a ransomware-hit SSD typically returns almost nothing. The same incident on an HDD can return thousands of files. This single fact is why the firm's HDD server and its SSD workstations had opposite recovery stories.

Option 5 — Negotiate and pay (the last resort)

If — and only if — there is no usable backup, no decryptor, no surviving shadow copy, and carving cannot recover enough of what is business-critical or irreplaceable, an organization may consider negotiating and paying. This is a genuine last resort, never a first move, and it is wrapped in legal, ethical, and practical hazards that you must lay out for the client honestly and dispassionately. You are not their decision-maker here; you are the professional who ensures they decide with their eyes open.

The legal hazard — OFAC and sanctions. In the United States, paying a ransom can itself be a crime if the recipient is a sanctioned person or entity, or operates in a sanctioned jurisdiction. The Treasury Department's Office of Foreign Assets Control (OFAC) issued an advisory on October 1, 2020, updated September 21, 2021, warning that facilitating ransomware payments to sanctioned actors risks civil penalties under a strict-liability standard — meaning you can be liable even if you did not know the recipient was sanctioned. Several prolific ransomware groups have been specifically designated. OFAC identifies mitigating factors — full cooperation with law enforcement, timely self-reporting to OFAC/CISA/FBI, and having strong cybersecurity controls in place — which is one more reason the preservation and reporting steps above are not optional. Paying may be unlawful; counsel must be involved before any payment is contemplated. (See Appendix E and Chapter 25.)

No guarantee you get your data back. You are trusting a criminal. Attacker-supplied decryptors are frequently slow, buggy, or only partially functional — some corrupt a fraction of files, some never arrive, some groups take the money and vanish. During the 2021 Colonial Pipeline incident the company paid the DarkSide group roughly 75 BTC (about US$4.4M), received a decryptor — and found it so slow that they restored from their own backups anyway. Payment bought them very little speed.

Double and triple extortion. Modern operators steal your data before encrypting it and threaten to publish it on a leak site (the Maze group pioneered this in 2019; it is now standard). This means a perfect restore from backup does not end the incident — the criminals still hold your data. Paying "for deletion" buys an unverifiable promise; you have no way to confirm the data was destroyed, and you may simply be marking yourself as a payer worth re-targeting. Some groups escalate further — DDoS attacks, direct harassment of your customers — hence "triple extortion."

The mechanics, and a glimmer of accountability. Payment is demanded in cryptocurrency, usually Bitcoin or Monero, typically arranged through a Tor negotiation portal. Specialist ransomware-negotiation firms (often supplied by the cyber-insurer) handle this routinely and frequently reduce the demand substantially. And crypto is not as untraceable as the criminals imply: blockchain analysis (Chapter 33) sometimes follows the money — in the Colonial Pipeline case, the DOJ later clawed back about 63.7 of the 75 BTC by seizing the attacker's wallet. Reporting the payment to law enforcement is not only a legal mitigating factor; it occasionally leads to recovery of the funds or the keys.

Ethics Note. Every ransom paid funds the next attack, trains the criminal market that this victim profile pays, and contributes to an ecosystem that has shut down hospitals and delayed cancer treatment. The FBI's stated position is that it does not support paying, while acknowledging it is ultimately the victim's business decision. There is real moral weight here, and it sits on the organization's leadership, not on you — but your job is to make sure they weigh it, alongside the genuine possibility that not paying means permanent loss of irreplaceable data. The human cost (theme six) cuts both ways: the patient whose records are gone, and the future victim funded by today's payment. Present both. Decide neither for them. The ethics of this choice are developed in Chapter 28.

Prevention: the section that matters most

Read the five options again and notice the shape of them: option one is reliable and complete; options two through four are luck, leftovers, and partial salvage; option five is paying criminals with no guarantee and possible legal jeopardy. The entire downhill slide from "routine restore" to "negotiate with extortionists" is determined by decisions made before the attack. You cannot, in good conscience, teach ransomware recovery without teaching the prevention that makes recovery a footnote rather than a crisis. If you take one thing from this chapter, take this: the recovery plan is the backup plan, and the backup plan must be built for an adversary who is actively trying to destroy it.

The 3-2-1 rule, hardened for ransomware

The classic backup discipline is 3-2-1: keep 3 copies of your data, on 2 different types of media, with 1 copy offsite. It is good, and it is no longer sufficient by itself, because a network-resident attacker with domain-admin rights can reach and destroy online backups — even offsite ones, if they are reachable with stolen credentials. The modern extension is 3-2-1-1-0: add 1 copy that is offline or immutable (air-gapped, or write-once), and 0 errors verified by test restores.

• Offline / air-gapped: media physically disconnected after the backup — rotated tapes, external drives stored in a safe, a backup target powered off between jobs. What is not connected cannot be encrypted.
• Immutable / WORM: storage that, once written, cannot be altered or deleted until a retention period expires — cloud object storage with Object Lock, purpose-built immutable backup appliances, write-once media. Even an attacker with full admin rights cannot mutate it.
• Separate credentials and separate authentication domain for the backup system, with multi-factor authentication on the backup console. The single most common way modern attackers neutralize backups is logging into the backup server with the same domain-admin account they already stole. Break that link.
• Test restores. An untested backup is a hope, not a backup. The accounting firm in our anchor case had a backup job — it had been silently failing for weeks, and nobody checked. The "0" in 3-2-1-1-0 means you have actually restored from it and verified the data.

Why This Matters. A correctly configured immutable backup turns the entire contents of this chapter — the cryptography, the triage, the five options, the agonizing pay/don't-pay calculus — into a single calm sentence: "We isolated the affected machines, preserved evidence, rebuilt clean, and restored from our offline backup; total data loss, near zero." Everything else in ransomware recovery is what you do when that sentence is unavailable. The human cost of an attack (theme six) is real and heavy; a backup you can trust is how you refuse to pay it.

Closing the door the attacker came through

Backups get you back; the controls below stop the attack from succeeding in the first place, and stop the re-attack after you restore:

• Eliminate exposed RDP and harden remote access. Internet-facing Remote Desktop with weak passwords is one of the most common initial-access vectors in human-operated ransomware. Put remote access behind a VPN with MFA, or behind a properly secured gateway; never expose RDP directly to the internet.
• Patch the perimeter fast. Unpatched VPN concentrators, firewalls, email servers, and other edge devices are routinely exploited within days of a vulnerability becoming public. The internet-facing attack surface is the highest patching priority.
• Multi-factor authentication everywhere, especially on remote access, email, and administrative accounts. MFA defeats the stolen-password attack that begins so many intrusions.
• Network segmentation and least privilege. Flat networks let one compromised workstation become a domain-wide encryption event. Segment, restrict lateral movement (block workstation-to-workstation SMB where possible), tier administrative accounts, and isolate the backup network entirely.
• Endpoint detection and response (EDR), email filtering, macro restrictions, and user awareness. Many intrusions still start with a phished credential or a malicious attachment; defense-in-depth shrinks the odds.
• A written, tested incident-response plan — including who to call (insurer, IR firm, counsel, law enforcement), how to isolate, and how to restore. The first hour is not the time to improvise; the firm that has rehearsed isolates in minutes while the firm that has not reboots the server.

Worked example: the accounting firm (anchor case)

Return to that Monday morning, and watch the whole method run end to end. This is the book's third anchor case — the ransomware recovery — and its lesson is meant to land hard.

The situation. Fourteen-person accounting firm, peak season. A Windows Server 2019 file server (a hardware RAID 1 mirror of two 7,200-RPM SATA hard drives — see Chapter 10) held the client files and the QuickBooks company files; the staff worked on Windows 11 workstations with NVMe SSDs. The firm believed it had backups: a backup job wrote nightly to an external USB drive left permanently connected to the server, and there was an older external drive the owner had taken home months earlier and forgotten.

The intrusion (reconstructed later from the timeline). RDP was exposed on the server so the bookkeeper could work from home. Six days before detonation, the attacker brute-forced that RDP login (a flood of Event ID 4625 failures followed by a Type-10 4624 success at 02:14 on a Tuesday). Over the next days they escalated privilege, mapped the network, and built a 240 GB archive of client files which they exfiltrated. On Sunday they ran vssadmin delete shadows /all /quiet (captured in Event ID 4688), encrypted the server and every reachable share — including the always-connected USB backup drive — and dropped the ransom note. The forgotten drive at the owner's home, being disconnected, was untouched.

The response. The office manager — trained on exactly the first-hour list above — disconnected the server and workstations from the network but left the server running, and called the firm's IR contact instead of rebooting. On site:

1. Preserve. A memory image of the still-running server was captured first (order of volatility), then write-blocked forensic images of the server's RAID members and a representative workstation. Each image was hashed and logged on a chain-of-custody form. Nothing was attempted on the originals.

text Evidence ACCT-001 acct-server (RAID member 0) dd image SHA-256: 9f2c1a7b4e0d8c63...a51 (acquisition log == verify == MATCH) Evidence ACCT-002 workstation-07 (NVMe SSD) E01 image SHA-256: 4d77e1c0ab93f25e...0c2 (MATCH)

2. Identify (Option 2 check). The ransom note and a sample file went to ID Ransomware. The strain was a current human-operated affiliate family with no public decryptor. Option two was closed.

3. Shadow copies (Option 3). vssadmin list shadows on the image: "No items found." Event ID 4688 showed the deletion command and its timestamp. vshadowmount against the image exposed no recoverable stores — the differential blocks were gone. Option three was closed.

4. Backups (Option 1). The always-connected USB drive had been encrypted along with everything else — an online backup is not a ransomware backup. But the forgotten drive from the owner's home was clean. It held a full copy of the firm's data as of two months earlier. That restored the bulk of the historical files — but the two most recent months, the height of tax season, the busiest and most valuable work of the year, were not on it.

5. Carving (Option 4). This is where the storage medium decided everything. On the server's hard drives, the malware had used copy-encrypt-delete, so the recent originals lingered in unallocated space. photorec and foremost against the server image carved back roughly six thousand files — many of the recent client PDFs, spreadsheets, and scanned documents — though with original filenames and folder structure lost, requiring a person to identify and re-file each one. On the workstation SSDs, TRIM had zeroed the deleted originals within seconds of encryption; carving there returned almost nothing. The HDD forgave; the SSD had forgotten.

6. The pay/don't-pay assessment (Option 5). With the stale backup plus the carved server files, the firm had recovered most of what mattered, though not cleanly and not all. The attacker had also exfiltrated client tax data and threatened to publish it, so this was simultaneously a reportable breach. Counsel reviewed the OFAC exposure; the IR firm noted the attacker's decryptor reliability was unknown and that paying for "deletion" of the stolen data was unverifiable. Weighing the partial recovery already in hand against an unlawful-payment risk, an unguaranteed decryptor, and the funding of future crime, the firm chose not to pay. They rebuilt the server clean from known-good media, closed the RDP exposure, enforced MFA, rotated every credential, restored from the clean backup, re-filed the carved files, and notified affected clients as the breach laws required.

War Story. The reconstruction is unglamorous and exact: the originals carved off the server came from clusters that the file system had marked free when the malware unlinked them, never yet reused — sector 31,114,752 onward on partition 2, recovered as f0488.pdf, re-identified by a staffer as a client's amended return. Thousands of such small resurrections added up to a saved season. None of it was needed for the two months of data the firm could have restored in an afternoon if the one extra backup drive had been kept offline and immutable instead of permanently plugged into the server. A US$120 second external drive, rotated weekly into a desk drawer, would have made this a one-day restore. That is the lesson, and it costs less than a single billable hour.

The honest accounting: the firm got most of its data back, after a week of intense work, at the cost of significant stress, a client-notification obligation, some permanently lost recent work, and a hard-earned new respect for offline backups. Without backups, ransomware recovery is partial at best. That is not pessimism; it is the structural truth of the cryptography we opened with. When the attacker controls the only key, your recovery is exactly as good as the copies and leftovers they failed to reach.

Common mistakes

• Rebooting or powering off the infected machine immediately. This destroys the in-memory encryption keys (your possible free decryption), the live malware process, and active C2 connections — and can trigger a second encryption stage. Isolate from the network; leave it running until memory is captured.
• Running antivirus "remove" or cleanup tools before preserving evidence. Remediation can delete the malware binary you need for family analysis and even the encrypted files you need as samples or for an eventual decryptor.
• Restoring onto a still-compromised network. Same exposed RDP, same valid stolen credentials, same result — re-encryption, often within hours. Close the vector and rotate credentials before restoring.
• Trusting a backup without testing it. The single most common cause of "we had backups but couldn't recover" is a backup job that had been silently failing, or a backup that was online and got encrypted too. An untested, reachable backup is not a ransomware backup.
• Declaring total loss from an entropy scan. Entropy is a screen; it false-positives on compressed files and misses partial-encryption tails. Confirm with the family marker and test carving before telling a client their data is gone.
• Downloading a "decryptor" from a search ad or forum. Many are malware. Use only No More Ransom or the original vendor, and test on copies.
• Rushing to pay because of the countdown timer. The timer is a sales tactic. Paying is a last resort with OFAC and ethics implications; it requires counsel, and it must follow — not precede — the cheaper, legal options.
• Skipping the forensic image to "save time." Wiping before imaging is irreversible and erases the proof of how you were breached and what was stolen — exactly what your insurer, regulators, and lawyers will demand. Image first, always.
• Assuming an SSD will carve like a hard drive. TRIM usually zeroes the deleted originals within seconds. Set expectations accordingly (Ch. 9).

Limitations: knowing when to stop

Theme five governs this chapter more than any other in Part II, because here the limit is not a worn-out platter or an overwritten cluster — it is mathematics that is working exactly as designed.

You cannot break correctly-implemented strong encryption. If the family used AES-256 or ChaCha20 for the file body and RSA-2048 (or larger) or Curve25519 to wrap the keys, and the implementation has no flaw, and the keys are not in memory or on disk, and no backup or shadow copy or unencrypted leftover survives, then the data is unrecoverable by you, by the vendor, and by law enforcement, at any price short of the attacker's private key. No amount of skill, time, or computing power you can muster changes that. The honest professional says so plainly. Promising a client you can "crack" the encryption is a lie, and chasing it wastes the time you should spend on the options that can actually work.

The other limits are sharp too. Carving fails on TRIM-enabled SSDs and on families that overwrite in place. Decryptors exist only for specific families and versions, and operators patch the flaws they exploit. Shadow copies are deleted by nearly every serious strain. And paying is gated by law (OFAC), by uncertainty (no guaranteed working decryptor), and by the unverifiable promise to delete exfiltrated data. The skill of knowing when to stop — when to tell a client "the encrypted files are unrecoverable; let us focus on what we can restore and on making sure this never happens again" — is as professional as any recovery technique in this book. "The evidence is insufficient" and "the data is unrecoverable" are both valid, defensible findings when they are true.

There is a final, humane limit. Even a technically successful recovery does not undo a breach. If client data was exfiltrated, restoring the firm's files does not un-steal it; the legal and reputational consequences run their own course regardless of how many files you carve back. Recovery is not absolution. Set that expectation with the client honestly, alongside everything you can do.

Progressive project: the recovery-versus-preservation memo

Your Forensic Case File (begun in Chapter 5, assembled through Part III, delivered at the capstone, Chapter 38) is a forensic investigation, not a ransomware job — but real investigations collide with ransomware constantly, and the preserve-before-you-recover judgment is a case-file skill worth banking now.

Add a one-page Recovery-vs-Preservation decision memo to your case file's working notes. Imagine that the evidence machine in your case is discovered mid-encryption by a ransomware strain. Document, in the order you would actually perform them: (1) the containment step that does not destroy volatile evidence (isolate, do not power off); (2) the acquisition order (memory image, then disk image, with hashes); (3) which of the five recovery options you would attempt and why, given the medium (note explicitly whether the target is HDD or SSD and how that changes carving); and (4) the legal triggers you would flag (exfiltration → breach notification; payment → OFAC review). Cite the appendix and chapter for each control. This memo demonstrates the single most valuable habit in incident work: producing a defensible, written rationale for fast decisions before you make them. File it; you will reference its structure again in Chapter 26.

Summary

Ransomware is the chapter where "deleted ≠ destroyed" finally meets its match — not because the bytes are gone, but because they have been transformed by strong, correctly-implemented encryption you cannot break. We opened with the cryptography, because it dictates strategy: modern ransomware uses a hybrid scheme, encrypting each file's contents with a fast symmetric cipher (AES or ChaCha20/Salsa20) and then sealing that file's symmetric key with the attacker's RSA or elliptic-curve public key, so that only the attacker's private key — which never leaves their control — can unlock it. Most strains encrypt user files per-file while leaving the OS bootable so you can pay; some attack the file-system structure instead; a dangerous few are wipers in disguise (NotPetya) with no recovery at any price, which is why precise family identification comes first. The crucial recovery variable is behavioral, not cryptographic: families that copy-encrypt-delete leave the original plaintext in unallocated space (recoverable on HDDs, usually lost to TRIM on SSDs), while families that overwrite in place destroy it; and partial/intermittent encryption (STOP/Djvu's first ~150 KB; LockBit-style block-skipping) can leave salvageable plaintext, especially in unstructured media.

The professional response is a disciplined sequence: triage the first hour (isolate, do not power off; do not reboot, scan, or pay; preserve and document), then reconcile recovery with forensics by imaging first — capturing volatile memory (where keys may live) before the disk, hashing everything, and maintaining chain of custody, because a ransomware incident is presumptively bound for insurance, regulators, and possibly court. Then work the five recovery options strictly in order of reliability: (1) restore from a clean offline/immutable backup — the only reliable solution; (2) a known free decryptor via No More Ransom or a vendor (exploiting implementation flaws, leaked, or law-enforcement-seized keys); (3) surviving Volume Shadow Copies, usually deleted by the malware but occasionally reconstructable from the image; (4) carving unencrypted originals, temp files, and slack for partial recovery; and (5) negotiate/pay as a last resort, gated by OFAC sanctions law, the absence of any guarantee, double-extortion realities, and genuine ethical weight. Above all stands prevention — the hardened 3-2-1-1-0 backup rule with offline/immutable copies on separate credentials, network segmentation, perimeter patching, MFA, and tested restores — because every option below "restore from backup" is a way of salvaging fragments from a situation that good backups would have made a footnote. The anchor case made it concrete and unsentimental: a firm with no usable current backup recovered most of its data through a stale offline drive plus HDD carving, lost what lived only on its SSDs, faced a breach on top of an outage, and learned that without backups, ransomware recovery is partial at best.

You can now: - Explain hybrid AES/RSA ransomware encryption and reason from it to which recovery options are real and which are wishful thinking. - Run the correct first-hour triage — isolate without powering off, preserve, document, and resist the countdown — and scope the blast radius with an entropy/signature scan. - Reconcile recovery with forensics: capture memory then disk, hash, and maintain chain of custody before any recovery attempt destroys evidence. - Work the five recovery options in order of reliability — backup, decryptor, shadow copies, carving, and (last resort) payment — and identify the ransomware family with ID Ransomware / No More Ransom. - State the legal and ethical stakes of paying (OFAC strict liability, breach notification, double extortion, no guarantee) clearly enough for a client to decide with open eyes. - Design ransomware-resistant backups (3-2-1-1-0: offline/immutable, separate credentials, test restores) and explain why they make recovery a footnote.

What's next. Chapter 13 — The Data Recovery Business — turns from the bench to the business: how recovery shops price jobs and set "no recovery, no fee" expectations, how to handle clients in the worst moment of their digital lives (the wedding-photos client returns), the cleanroom-and-tooling economics, and the ethics and liability of charging money to handle other people's most precious — and most sensitive — data.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.