Tabletop Scenario: Ransomware & Malware¶
A SnowOps incident-response tabletop (
K5) — discussion-based, no real consoles. Facilitation method:facilitation-guide.md. Pack overview:README.md.
Exercises runbook: ../incident/ransomware.md — Ransomware & Malware.
| Field | Value |
|---|---|
| Scenario | Ransomware on a prod VM workload + encrypted Azure Files share |
Incident class (K1) |
ransomware |
| Duration | 60 min |
| Participants | 4–8 |
| Difficulty | standard (+1 curveball) |
| Last run | <YYYY-MM-DD> |
Objective¶
Validate that the team can isolate, investigate, and recover from a ransomware
outbreak on a prod VM workload using
../incident/ransomware.md, and surface gaps in the
runbook, the K3 "quarantine VM" SOAR playbook, and — critically — whether
backups (L1) are actually clean and restorable.
Success looks like: the team isolates without rebooting (preserving forensics), prevents lateral spread, confirms a clean backup point, and recovers to an isolated staging environment — citing the runbook at each phase.
Scope & assumptions¶
- In scope: the prod VM-based workload
vmss-snowops-app(Linux scale set) and the Azure Files SMB sharefs-snowops-prodit mounts. - Out of scope: AKS workloads (different DR path), client tenants.
- Assumptions (state at kickoff):
K2paging is live;K3SOAR in dry-run; Defender for Servers + Endpoint deployed; Recovery Services Vault (L1) with soft-delete + immutability; restore drills (L4) pass monthly. - Standing rule: discussion only — no real isolation, no real restore.
Roles¶
| Role | Played by | Responsibility |
|---|---|---|
| Incident Commander (IC) | <name> |
Declares severity, owns the response. |
| On-call responder | <name> |
Drives ransomware.md. |
| Platform/VM SME | <name> |
Compute, NSG, Defender for Endpoint actions. |
| Backup/DR SME | <name> |
L1 vault, restore path, immutability. |
| Communications | <name> |
Internal + client updates. |
| Scribe (optional) | <name> |
Timeline + decisions. |
Injects (timeline)¶
| # | T+ | Inject (read to the room) | Maps to K1 phase |
Facilitator notes (don't read aloud) |
|---|---|---|---|---|
| 1 | 0 min | Defender for Servers alert on two vmss-snowops-app instances: "Suspicious file encryption activity" + mass file renames to .lockd. On-call also has a Slack message: "app is throwing 500s, files look weird". |
Identification | If asked: ~40% of the share's files already renamed; spreading. Don't let them reboot. |
| 2 | ~8 min | A third instance starts showing the same pattern; the Azure Files share fs-snowops-prod (mounted by all instances) now has encrypted files appearing. |
Containment | Lateral movement via the shared SMB mount. Containment must include suspending share access. |
| 3 | ~16 min | NSG flow logs + AzureActivity show the initial instance had an exposed SSH port (22) to 0.0.0.0/0 via a recently-added NSG rule, with a successful login from an unknown IP 3 hours ago. |
Eradication & Investigation | The entry point. A managed identity on the VMs has Storage Blob Data Contributor — possible spread vector to rotate. |
| 4 | ~26 min | The team wants to restore. The most recent daily backup (last night) is also encrypted — the encryption started 26 hours ago. | Recovery | Forces them to find an earlier clean point + check immutability. Tests whether they actually know the restore path. |
| 5 | ~34 min | Restore to an isolated staging RG validated; clean point is 48h old (some data loss). Workload cut over. No new encryption for 30 min. | Post-Incident | Drive Lessons-Learned: patch the exposed port, RTO/RPO performance. |
| 6 | ~40 min | Curveball: legal asks "did any data leave, or was it only encrypted?" Do you know? What logs answer that? | any | Hold for stretch; ransomware ≠ no exfil (double extortion). |
Discussion Questions (by K1 phase)¶
Push the team into
../incident/ransomware.md.
Phase 1 — Identification¶
- The runbook's Initial Triage says determine affected workloads and do not reboot (preserve volatile memory). Does everyone know why not to reboot, and is anyone about to?
- Which VMs/shares are affected, and how fast is it spreading?
Phase 2 — Containment¶
- Walk the Containment steps: isolate infected VMs (isolated VNet / strict NSG, or Defender for Endpoint "Isolate Device") and prevent spread (suspend the Azure Files SMB share, rotate the workload's managed identity / SPs). Which do you do first given the share is the spread vector?
- Would you trigger the
K3"quarantine VM" playbook — dry-run or enforce? What does it actually change (NSG? Defender isolation?) and what's the blast radius for a scale set?
Phase 3 — Eradication & Investigation¶
- Per the runbook: scan with Defender for Servers, take forensic disk snapshots
(don't attach to prod), review
AzureActivity+ NSG flow logs for the entry point. What did you find (the exposed SSH NSG rule)? - What credentials/identities must you rotate to stop re-entry and lateral movement (the VMs' managed identity, any SP)?
Phase 4 — Recovery¶
- The runbook says verify backup integrity first, check WORM/immutability locks (F6 / L-series), restore to a clean isolated staging env, verify, then cut over. Last night's backup is encrypted — how do you find and validate an earlier clean point? Does immutability/soft-delete save you here?
- How do you re-attach storage shares and remove quarantine NSG rules only on the clean restored resources?
Phase 5 — Post-Incident / Lessons Learned¶
- The runbook says patch the entry vector, ensure endpoint protection is active
everywhere, and assess RTO performance. We lost 48h of data — was that within
RPO? Why was an SSH-to-the-world NSG rule even possible (policy/
E0gap)? - Double-extortion: did data leave (curveball)? If yes, this also runs
data-leak.md. Which finding becomes a trackedK4action item, with owner and due date?
Evaluation Rubric¶
Score 1–4 per dimension; total /20.
| Dimension | 1 — Ad hoc | 2 — Partial | 3 — Solid | 4 — Strong | Score |
|---|---|---|---|---|---|
| Detection & triage | Missed/rebooted | Identified, nearly rebooted | Correct, preserved forensics | Fast + scoped spread immediately | |
| Runbook fluency | Didn't open it | Improvised | Followed ransomware.md |
Followed + caught a gap | |
| Containment decisions | VMs left connected | Isolated VMs only | VMs + suspended share + rotated identity | All that + correct K3 use, no spread |
|
| Roles & comms | Role confusion | IC late | Clear IC + DR SME engaged | Crisp roles + legal/client comms on time | |
| Recovery & learning | No clean point found | Restored blind | Found clean point + validated in staging | Validated + RPO assessed + entry-vector K4 item |
|
| Total | /20 |
After-Action¶
Fill live; expand into
after-action-template.mdand route findings toK4(apps/post-incident-review/).
- Date / facilitator / attendees:
<…> - Rubric total:
<n>/20 - What went well:
<…> - Top gaps found (cite runbook step):
<e.g. ransomware.md doesn't say how to identify the newest clean restore point when recent backups are encrypted> - Improvement items:
<item — owner — due date — destination>