Ransomware-ready posture: the assume-breach scenario every board should fund

"Are we ransomware-ready?" is a question every board is asking in 2026, and no board should accept "yes, we have backups" as the answer.

Ransomware-ready means one thing: if an attacker gets a foothold, what stops them from reaching crown-jewel data and encrypting it? The only honest way to answer that is to have someone try.

What "ransomware-ready" actually tests

We run a specific engagement shape for this: assume-breach with a ransomware objective. The contract is:

• Pre-placed foothold: a low-privilege account or workstation, same way a phish would land.
• Objective: demonstrate the ability to exfil and encrypt crown-jewel data within 72 hours.
• Stop conditions: we stop at the demonstration — no actual encryption, no actual exfil.
• Deliverables: a time-to-objective measurement, a detection-coverage matrix, and a prioritized detection-engineering backlog.

The value is the measurement

Most engagements produce findings. A ransomware-ready engagement produces a *number*: how fast did we reach the objective, and how many of our stages did the customer's SOC catch?

A good number isn't "zero stages caught in 72 hours". A good number is "we reached the objective in 6 hours and the SOC caught us at stage 4 of 7 — here are the three atomic tests to close stages 1, 2, and 3".

A typical progression

1. Initial access: phishing + MFA fatigue OR consent phishing. Usually lands in under 90 minutes.
2. Privilege escalation: AD CS ESC1–8, Kerberoasting, or a cloud-identity abuse depending on the environment.
3. Discovery: domain enumeration, crown-jewel inventory, backup system locate. BloodHound or SharpHound.
4. Credential harvest: LSASS dumping, DCSync, or a service-account with over-broad rights.
5. Lateral movement: WMI / SMB / RDP to file shares and data stores.
6. Objective execution: staging of "would-be-encrypted" data, staging of exfil channel.
7. Backup disruption: demonstrate ability to reach and corrupt backup repositories.

Stage 7 is the one customers most often haven't tested. Backups are "somewhere else" — usually the same AD, usually with a service account that has too many rights.

Three questions your board should demand answers to

1. What's our time-to-objective? If you don't have one, you don't know whether your controls make a difference.
2. Which stages did our SOC detect? A stage-by-stage detection matrix is the only honest scoreboard.
3. What's the shortest path to backup destruction? If your answer contains "we assume" anywhere, the answer is wrong.

The non-obvious finding

The single most common ransomware-ready finding we ship isn't a CVE. It's a service account — usually backup or hypervisor — with enough rights to encrypt the backup server. That one account, discovered with an hour of BloodHound, collapses the time-to-objective from "days" to "minutes".

You don't need a red team to find it. You need to ask, for every service account: what could someone do if they owned this credential? The red team is what proves the answer is true.