Most ransomware responses do not fail because the team lacked skill. They fail because the first 15 minutes had no clear order of action.
You get the alert.
Mass file modifications. Shadow copy deletion. A suspicious process spawning PowerShell. Maybe a ransom note has already appeared on a file server.
And immediately, one question matters more than almost anything else:
Is encryption still in progress, or has the damage already been done?
That question changes everything.
If encryption is still active, every minute spent organizing thoughts instead of stopping spread is a minute lost. If encryption appears complete, the priorities shift: preserve evidence, assess scope, protect recovery paths, and start planning the response properly.
The problem is not that ransomware triage is too difficult. The problem is that too many teams are still rebuilding the response path from scratch when the pressure is already highest.
This is the workflow I use now to make those first 15 minutes less chaotic — and much more repeatable.
Why the first 15 minutes go wrong
Ransomware is different from most security alerts because the cost of delay is immediate.
When a ransomware alert lands, a typical analyst is often trying to do all of this at once:
- confirm whether the alert is real
- work out how many systems are affected
- decide whether to isolate immediately
- figure out what to tell the team lead or incident manager
- start documenting while the situation is still evolving
None of those actions are wrong.
The problem is doing them without a sequence.
Isolate too early and you may lose visibility into how the attack spread. Isolate too late and the encryption may move into file servers, shared drives, or backup infrastructure. Document too early and the write-up becomes outdated before the first paragraph is finished.
The first 15 minutes of ransomware response are chaotic by default. A repeatable workflow does not remove pressure, but it does give that pressure a structure.
The question that changes the response
Before anything else, I want to answer one question:
Is encryption still in progress, or does it appear complete?
That is not a minor detail. It determines the order of response.
If encryption is still active:
- stopping spread becomes the priority
- broad containment matters more than perfect visibility
- evidence preservation becomes secondary to operational survival
If encryption appears complete:
- you shift toward impact mapping, evidence preservation, and recovery planning
- containment still matters, but it can be more deliberate
- the response becomes less about seconds and more about sequencing
A lot of ransomware playbooks bury this distinction. I put it first because getting it wrong leads to the rest of the response being ordered the wrong way.
The workflow I use now
Step 1 — Confirm the indicators
The first thing I want to know is whether this is actually ransomware, or whether it only looks like ransomware.
Plenty of legitimate activity can resemble a ransomware signal in isolation:
- backup jobs can trigger mass file modifications
- admin tools can interact with shadow copies
- scripted maintenance can create noisy process chains
I look for a combination of indicators:
- rapid mass file modification within a short time window
- file extension changes like
.locked,.encrypted, or random suffixes - ransom note creation across multiple directories
- shadow copy deletion via
vssadmin,wmic, orbcdedit - suspicious process chains, especially
cmd.exeor PowerShell spawned from unusual parents - movement into network shares or remote systems before or during encryption
One signal can be noisy. A cluster of signals is where confidence comes from.
Step 2 — Decide whether the spread is still active
Once indicators strongly suggest ransomware, I try to answer the timing question quickly: Is this still moving?
I look for:
- whether file changes are still occurring
- whether new hosts are starting to show the same indicators
- whether suspicious processes are still running
- whether SMB activity or remote execution is still active
- whether backup systems or file servers are just now being touched
If yes — active containment mode. If probably not — focus shifts to blast radius, evidence, and recovery paths.
Step 3 — Assess the blast radius fast
This is the part analysts often skip under pressure, but isolating the wrong system first creates false confidence.
What I want to know:
- how many systems are already showing indicators
- whether shared drives, file servers, or hypervisors are involved
- whether backup infrastructure has been touched
- what the earliest observable indicator was
- which host appears to be the likely entry point
- which accounts were involved in execution or spread
- whether any privileged credentials appear in the chain
That gives me: entry point → lateral movement path → affected assets
If domain admin activity appears anywhere in that chain, the entire incident changes in severity.
Step 4 — Contain in the right order
Containment is an order of actions, not a single action:
- stop the spread
- protect recovery paths
- preserve evidence where possible
- stabilize communication and ownership
The backup protection step is the one teams most often miss. Ransomware operators know backups are the recovery path. More mature actors target backup infrastructure before defenders even understand the blast radius.
Step 5 — Start the report while triage is still happening
The incident report should begin during triage, not at end of day.
A useful ransomware report needs two layers:
- an executive summary for non-technical decision-makers
- a technical summary for the next analyst or IR team
Writing while the situation is still moving forces one important discipline: separating evidence from inference.
What a useful ransomware triage output should include
- whether ransomware is confirmed, highly likely, or still unconfirmed
- whether encryption appears active or complete
- blast radius summary: affected systems, accounts, shared resources, backups at risk
- immediate containment actions with urgency and ownership
- extracted IOCs
- ransomware family if identifiable, decryptor availability if known
- downstream requirements: legal, insurance, regulatory, law enforcement
A simple example
EDR alert fires at 03:17 AM on a file server: 4,847 files modified in under three minutes, all renamed .locked, HOW_TO_RECOVER.txt in every folder, vssadmin delete shadows ran five minutes earlier.
Instinct: isolate the file server now.
But scope assessment shows the earliest indicator was on a finance workstation two hours earlier. That host accessed the file server over SMB. A connection attempt hit the backup server at 03:10 AM — seven minutes before the EDR alert.
The alert landed on the file server. The entry point was the finance workstation. The backup environment may already have been targeted before the team knew anything was happening.
Isolating the visible victim first would have left the real risk path untouched.
The newer ransomware reality: exfiltration first
Encryption is not always the first or only objective anymore.
A growing number of ransomware operators now use:
- exfiltration before encryption
- extortion without full encryption
- theft of sensitive data as leverage even when recovery is possible
Ransomware triage should include checks for:
- large outbound data transfers
- unusual archive creation
- movement into sensitive data repositories
- pre-encryption staging activity
If your workflow starts only when files begin changing, you may already be late.
If you want to use this response path
I built this workflow into SOC.Workflows so it can be used in the same order during a live incident.
Free, no login required, designed for practical analyst use. There are also workflows and analyzers for phishing, alert triage, VPC flow logs, and credential dumping.
Final thought
Ransomware responses do not usually fail because analysts are slow.
They fail because the first 15 minutes had no clear sequence, and sequence is hardest to improvise when the pressure is highest.
If you build the order of response before the incident, you do not have to invent it during one.
Top comments (0)