Ransomware encrypts production AND attempts to encrypt backup vault
Your Vault posture shows 30-day WORM and 28 days since last restore test. This scenario exercises the restore decision tree under time pressure with a sophisticated attacker.
Hand out attendee links — no screen sharing required
At drill kickoff you hand out two URLs so every attendee can follow + participate live from their own device, no Teams call needed:
- 1Spectator URL — read-only timer + current inject + delivery progress, refreshes every 3 seconds. For observers, security leadership, anyone watching but not participating. Works on a conference-room TV too.
- 2Participant URL — each attendee picks their role from your org-shape roster and submits their own written answer per inject. Submissions stream onto your facilitator screen in real time, role-tagged. When you Drop the inject, their answers are locked into the evidence record next to the team’s consensus response — full attribution preserved in the auditor ZIP.
Demo note: only the spectator URL is wired in the demo. The participant flow requires real auth and your tenant’s org-shape roster, so it doesn’t run client-side.
Scenario
On a Sunday at 03:42 UTC, a ransomware operator with prior persistence in your environment triggers encryption across 4 file servers, 12 database hosts, and the M365 tenant's SharePoint sites. By 04:15 UTC, your monitoring tools page on-call. By 04:30, you've isolated the affected network segments. At 05:02, the attacker — who clearly knows you have Veri-Vault — attempts to authenticate against the Vault management plane using a stolen privileged identity. Your immutability window saves you: writes to existing backups are denied. But the attacker can attempt to *delete* the Vault if they reach a sufficiently privileged identity. They don't, today. Now you face the actual question: do you pay, or do you restore?
Threat actor + attack chain
Sophisticated ransomware operator (Conti-affiliate or similar). Goal: ransom payment. Has researched your Vault posture before encrypting.
- 1Pre-encryption recon: Attacker has had persistence for 11 days. Uses time to map Vault's protection model: WORM window, immutability period, who has delete rights.
- 2Encryption: Triggers encryption across production. Demands ransom: $4.2M in 48 hours; $8.4M after.
- 3Vault attack attempt: Attempts to authenticate to Vault management plane to delete or encrypt backups. WORM denies writes; delete-attempt requires privilege the attacker has not yet escalated to.
- 4Decision point: You have backups. They survive the attack. Question becomes: how fast can you actually restore, what data was post-last-backup, and is your restored environment safe to bring back online?
Timed injects
Each inject lists its scheduled trigger time. When the drill clock passes that time, the inject highlights amber as a hint — but YOU pace the drill: click Drop inject to mark it delivered (timestamp captured for the audit record), then capture the team’s response. The “Expected action” line is your facilitator-only debrief reference.
On-call engineer pages the IC at 04:15 UTC: 'Production is encrypted. We're seeing the ransom note. Backup status is unknown.' IC has 5 minutes to give first orders.
Expected action (facilitator-only): IC instructs: (1) network-segment isolation per IR plan, (2) Vault status check + lock down management plane, (3) executive escalation to CEO/legal/board per IR plan.
Share the participant URL to invite team input. Submissions reveal here as they land.
Vault admin reports: 'Someone tried to authenticate against the Vault management plane at 05:02 UTC from an unfamiliar IP. WORM denied writes. They didn't escalate to delete privileges. Vault is intact.' What's your move? Facilitator note (added in v1): if the team cannot answer within the inject window, the IR pre-built escalation tree applies — escalate to the named owner one tier above before the response runs over.
Expected action (facilitator-only): Team confirms: (a) revoke all Vault management-plane sessions, (b) rotate admin credentials, (c) enable additional MFA challenge on Vault delete operations if not already, (d) document timeline.
Infrastructure lead delivers the bad news: 'We restored a sample database from Vault — it took 6 hours wall-clock. Multiply by 12 hosts, plus the file servers, that's 36-48 hours minimum if we go serial.' Customer SLA is 24 hours.
Expected action (facilitator-only): Team discusses: (a) parallel restore capacity, (b) priority order (which apps must come back first), (c) interim communications with customers about extended outage, (d) pay-vs-restore reconsideration in light of restore timeline.
CFO + legal + insurance broker join. CFO: 'Ransom is $4.2M. Restore costs maybe $400K but we breach SLA on multiple customers, possibly $2M in penalties. Insurance covers ransom but with conditions. Recommend?' Decision required by T+70.
Expected action (facilitator-only): Team walks through: (a) does insurance condition payment on FBI notification?, (b) what's the chance the decryption key works at all?, (c) what's the moral/policy stance — does company pay?, (d) make a documented decision with named decision-maker and full reasoning.
Comms lead: 'When do we tell customers? Employees? Regulators?' If healthcare data restored from Vault contains PHI, the §164.402 4-factor applies — even though attacker didn't exfiltrate (or did they?).
Expected action (facilitator-only): Team documents the cascade: customer-first or employee-first? Regulator timing per HIPAA §164.404 (60 days) or GDPR (72 hours) or state breach laws (varies). Identifies whether this is a notification event at all (depends on data exfiltration evidence).
Wrap-up + rubric scoring + remediation list.
Expected action (facilitator-only): Top items: (1) restore drill schedule + tooling for parallel restores, (2) documented pay-vs-restore decision tree, (3) Vault delete-permissions audit + 4-eyes enforcement, (4) per-app RTO validation, (5) customer communications template.
Scoring rubric
0.00 / 5running average
Rate the team’s performance on each criterion (1 = poor, 5 = excellent). Notes are optional facilitator commentary.
Restore time validation (recency)
weight: 20Threshold reference
- 5:
- Full restore drill within last 30 days; RTO measured
- 4:
- Restore drill within 90 days
- 3:
- Restore drill within 180 days (current state: 28 days)
- 2:
- Restore drill within 365 days
- 1:
- >365 days or never
Vault delete-attack survivability
weight: 20Threshold reference
- 5:
- WORM + 4-eyes + JIT on delete + alert on attempt
- 4:
- WORM + 4-eyes + alert on attempt
- 3:
- WORM + alert (current state)
- 2:
- WORM only
- 1:
- No immutability
Pay-vs-restore decision tree maturity
weight: 15Threshold reference
- 5:
- Documented tree with criteria, named decision-maker, insurance pre-aligned
- 4:
- Documented tree, named decision-maker
- 3:
- Decision-maker known, criteria informal
- 2:
- Decision ad-hoc
- 1:
- No process
Per-app RTO validation
weight: 15Threshold reference
- 5:
- All critical apps have measured RTO + matches commitment
- 4:
- Most apps validated
- 3:
- Some apps validated
- 2:
- RTO documented, not measured
- 1:
- No RTO commitments
Restore validation procedure
weight: 15Threshold reference
- 5:
- Hash verification + known-clean checkpoint + isolated restore environment
- 4:
- Hash verification + isolated environment
- 3:
- Restore validated by application functional test
- 2:
- Restore validated by 'looks right'
- 1:
- No validation
Communications cascade
weight: 15Threshold reference
- 5:
- Cascade documented per audience with timing + owner
- 4:
- Cascade discussed, owners identified
- 3:
- Audiences identified, timing ambiguous
- 2:
- Some audiences considered
- 1:
- No cascade
Lock & save
Locking the session writes an immutable, SHA-256-checksummed evidence record into Veri-Vault. Once locked, this session cannot be edited — it becomes the auditor-grade record of the drill alongside the source bundle.
All criteria must be scored before lock — currently scored 0 of 6.