--- title: "The Last Two Steps Are Not in Scope. What Makes Them Survivable Is." description: "Part five of testing the ransomware playbook: an assessment stops before exfiltration and encryption, and it should. But the two properties that decide how bad either gets — egress and backup reachability — are fully testable, and almost never in scope." date: 2026-02-06 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/posts/ransomware-playbook-05-impact/ --- ## Impact and recovery in 60 seconds This is where the series has to be honest about its own limits. An assessment does not exfiltrate the client's data and does not encrypt anything. There is no version of this stage that gets tested, and there should not be. But that is a statement about the *actions*, not about the outcome. Two properties decide how much damage those actions can do, both are ordinary configuration, and both can be measured without touching a single file. They are also the two that turn up in scope least often. ## The stage itself is the least interesting part Encryption is mundane. It is file enumeration and a crypto library, run in parallel, on everything reachable. The affiliate is not being clever here; the cleverness all happened in parts one through four, and by this point they simply have the reach. Exfiltration is similarly plain: archive, split, upload to something that looks like normal outbound traffic. Neither is where the leverage is. The leverage is in two questions asked much earlier. ## Question one: can data leave, and would anyone notice Not "is there a DLP product". Whether an arbitrary volume of data can reach an arbitrary destination, and whether that produces a signal anybody acts on. This is testable with benign data. Generate a few gigabytes of random content, move it out by the paths that actually exist — HTTPS to a cloud storage provider, DNS if it resolves recursively, an outbound SSH that was left open for a vendor — and then ask what was recorded. ``` # Not a covert channel. The point is to measure the ordinary path. $ dd if=/dev/urandom of=/tmp/benign.bin bs=1M count=2048 $ curl -sT /tmp/benign.bin https://storage.example-lab.net/upload/ # Then the question that matters, asked of the other team: # was 2 GB outbound to a first-seen destination recorded? # did it generate an alert, or only a log line? # how long would it have taken anyone to look? ``` The answer is frequently that the traffic was permitted, logged, and unremarked — which is a finding with a specific remediation, and it is far more useful than an inventory of which protocols are theoretically blocked. ## Question two: does recovery survive the domain This is the one that decides whether an incident is expensive or existential, and it comes down to a single structural property: **is the backup system inside the same trust boundary as the thing it is backing up?**

Nothing here is about ransomware technique. It is about whether one set of credentials governs both the production estate and the copy you would recover from — which is a design decision, testable long before anyone needs it.

It is testable directly, and it does not require touching a backup. With the privileges obtained in [part three](/posts/ransomware-playbook-03-privilege-escalation/), simply establish reachability and authority: - Is the backup server domain-joined? - Are its administrators domain accounts, or nested into a domain group? - Can the credentials already obtained authenticate to its management interface? - Is retention immutable, or can an authenticated administrator shorten it? - Is there a copy that is genuinely offline, and when was a restore last proven? Every one of those is a yes-or-no answered from the position you already hold. None of them requires deleting or modifying anything. ## The finding is always upstream This is the closing argument of the series, and it is worth stating plainly. Every part of this playbook was preventable at a stage before the one it appears in. Initial access was an uncovered endpoint. Enumeration was unwatched because the measurement was allowlisted away. Escalation used permissions granted years earlier for reasons that expired. Lateral movement used one credential that worked everywhere. Impact was total because recovery shared a trust boundary with production. Not one of those is a ransomware problem. They are ordinary findings, and they were mostly already known — written up somewhere, categorised as medium, scheduled behind something with a CVE attached. The value an assessment adds is not discovering exotic techniques. It is connecting those findings into the chain they form, so that the one worth fixing first becomes obvious. ## Evidence matrix | Signal | What it proves | Negative control | Defender verification | | --- | --- | --- | --- | | Harmless canary data leaves through the approved test route | Egress control and monitoring allow a realistic exfiltration path | Block the category/destination and confirm transfer and alert behavior change | Correlate proxy, DNS, endpoint, and cloud-upload telemetry for the canary marker | | Domain compromise reaches backup administration or deletion controls | Recovery shares the same failure domain as production | Use a separately administered backup identity and confirm domain credentials fail | Map identity, network, hypervisor, storage, and control-plane dependencies for backups | | Immutable/offline copy resists deletion from the production admin plane | At least one recovery copy survives the assumed compromise | Attempt an authorized deletion through production credentials and expect denial | Verify retention lock, separation of duties, and break-glass access independently | | Restore exercise meets integrity and time objectives | Recovery capability is demonstrated rather than inferred from job success | Restore a known canary set and compare hashes and elapsed time | Record full restore evidence, dependencies, and operator steps on a schedule | ## What to hand the defenders **Egress as a measurement, not an inventory.** How much left, to where, and what was recorded — not a list of blocked protocols. **Backup reachability as a structural finding.** Not "backups exist" but "the backup system is governed by the same identity provider as the systems it protects, and here is the credential path from a standard user to it." That framing survives triage; "improve backup security" does not. **The chain, once.** The five stages, the specific finding at each, and the single earliest one whose removal breaks the rest. That is the deliverable this whole series has been building toward — and it is one page, not a hundred. --- *This concludes the series. The four internal-network notes it draws on — Kerberoasting, delegation, relay, and BloodHound edge triage — cover the individual mechanisms in the depth this overview deliberately skipped.*