ransomware response — methodology
ransomware response is not “malware response.” malware is a delivery mechanism. what you are dealing with is encryption + exfil + extortion, run by an organized commercial operation with weeks of dwell, a clear playbook, and a deadline. the first 48 hours are not about decryption. they are about scoping the breach, anchoring patient zero to the onset minute, preserving staging evidence, mapping lateral movement, checking whether backups were targeted, and parsing the ransom note before the actor wipes logs and your backup admin pulls the wrong lever.
what evidence exists and how fast it dies
| artifact | volatility | time to loss |
|---|---|---|
| memory (RAM) | volatile | minutes on reboot |
| Security.evtx / System.evtx | persistent (rolling) | hours if actor wipes · 1102 cleared |
| shadow copies / VSS | persistent | often deleted before encryption |
| backup config + job logs | persistent | hours if actor targets Veeam/repo |
| MFT / file-system metadata | persistent | days unless restored from backup |
| M365 unified audit log | persistent | 90 days default · 7 years with E5 audit |
| firewall / proxy logs | persistent | 14–90 days depending on retention |
the first 10 minutes
- isolate at the network layer — do not power off unless you must preserve memory.
- snapshot VMs that are still running before anyone reboots them.
- pull Security.evtx + System.evtx from each suspected host — now, not after lunch.
- export M365 audit log for 14 days back if identity was involved.
- photograph or save the ransom note as plain text — do not forward it.
- check shadow copies before backup admin does anything.
- preserve Veeam/backup config and job history exports.
- save firewall logs for the last 14 days.
- identify patient zero before negotiating — onset timer first.
- do not pay yet. preserve first.
the path
1. encryption onset timer
drop mft csv and security evtx. produces the onset minute, patient-zero cluster, and pre-encryption event chain.why first: every other ransomware analysis is anchored to the onset timestamp. you need this to scope everything else.
2. ransomware staging detector
security + system evtx and process tree. surfaces vssadmin, bcdedit, persistence, and staging phases before encryption.why second: staging actions tell you what the actor did to disable recovery before they flipped the switch.
3. lateral movement chain visualizer
security evtx — 4624/4688/7045 chains across hosts.why third: patient zero is rarely the entry point. you need the hop chain to scope affected systems.
4. backup deletion artifact analyzer
system evtx + backup job logs. finds shadow-copy wipes, service stops, and repository tampering.why fourth: actors target backups first. if recovery is gone, your containment decision changes.
5. mass rename detector
file listing derived from mft. finds bulk extension-change bursts at onset.why fifth: confirms the encryption wave pattern independent of the onset timer.
6. crypto ransom note parser
plain-text ransom note. extracts btc address, onion URL, deadline, contact strings.why sixth: the note is the artifact you hand to law enforcement and insurers.
7. ransomware family identifier
note text + extension list from mft. scores against known family signatures.why seventh: family ID drives decryptor availability and TTP expectations.
8. double extortion evidence collector
ransom note + edr detections. correlates exfil/staging indicators with impact claims.why last: confirms whether the actor is claiming exfil you can independently support.
common false leads
- the first encrypted file is patient zero — ransomware often encrypts breadth-first; the earliest .alphv file is the cluster anchor, not necessarily entry.
- encryption time equals breach time — dwell averages days to weeks before detonation.
- Cobalt Strike equals APT — commodity ransomware uses CS; do not over-classify.
- backups are safe — actors target backup repos and shadow copies in the same playbook.
- paying stops the leak — double-extortion actors may still publish after payment.
what we can tell you, what we can't
we can tell you:
- encryption onset time and patient-zero cluster from mft + evtx
- staging actions (vssadmin, bcdedit, backup tampering) from system logs
- lateral movement chains from security evtx
- ransom-note IOCs (btc, onion, deadline) from the note itself
- likely ransomware family from note + extension patterns
we can't tell you:
- who the operators are — attribution requires intel you do not have locally
- whether a decryptor will work — that is negotiation / reverse-engineering territory
- whether insurance will pay — lawyer and policy territory
- full exfil volume — browser tools see artifacts, not the actor's cloud bucket
handing it off
- law enforcement (FBI IC3): ransom note, btc address, onion URL, leak-site URL, patient-zero host, onset UTC timestamp, IOC list from tools.
- insurance: timeline doc, scope of encrypted systems, backup status, whether exfil is claimed vs supported.
- outside counsel: preservation log — what you saved, when, SHA-256 of exports, chain of custody notes.
- IR retainer / MSSP: full evtx + mft + firewall exports; do not scrub before handoff.
further reading
reference investigation
synthetic fixture ransomware-acme-corp — healthcare MSP scenario, deterministic seed ransomware-acme-corp:v1. run the path locally and compare output to published goldens via npm run check:flagship.
proof page: /forensics/proof/ransomware-acme-corp · case playbook: case type tools