Ransomware Hit. What Now?

Files are encrypted. There's a ransom note on the domain controller. People are panicking. Phones are ringing. Nobody knows what to do first.

This is the guide for that moment. Step by step — what to do, what NOT to do, who to call, and how to get through it. Everything here is based on real-world incident response, not theory.

The First 15 Minutes

Everything you do in the next 15 minutes determines how the next 24 days go. The average ransomware recovery takes 24 days. Your actions right now decide whether you're on the short end or the long end of that average.

What NOT to Do

Under pressure, people do the wrong thing fast. Here are the six mistakes that make a ransomware incident worse:

Hour 1: Contain & Assess

The initial 15 minutes are past. Now you contain and assess systematically:

1. Confirm isolation is holding. No new systems should be getting encrypted. Monitor for C2 callbacks and lateral movement.
2. Activate the full incident response team. IC, Security Lead, VMware Admin, Network Admin, Legal, Insurance contact, Comms lead. Open a dedicated bridge call.
3. Assess the blast radius. How many systems? Which tiers? Which business functions are down?
4. Check backup infrastructure status. Is the backup server compromised? Is the hardened repo intact? Can you access immutable copies?
5. Establish the timeline. When was the first indicator? What was the attack vector? How long has the attacker been inside? This determines your clean RPO.
6. Notify your cyber insurance provider. Most policies require notification within 24-72 hours. They'll assign an IR firm, legal counsel, and potentially a negotiator.

The Backup Question

This is the moment that determines everything. Three possible outcomes based on one architectural decision you made months ago:

The difference between these three columns is one thing: immutable backups with sufficient retention. That single architectural decision — made weeks or months before this moment — determines which column you're in right now.

Clean Room Recovery

Never restore directly to production. The attacker may have planted persistence mechanisms — backdoors, scheduled tasks, compromised service accounts — that survive a simple restore. You need a clean room.

1. Build an isolated recovery environment. Separate VLAN, no connectivity to production. Fresh vCenter. Fresh AD forest. No domain trust.
2. Verify backup integrity before restore. Check immutability timestamps. Verify no encryption reached the backup chain. Validate checksums.
3. Restore to the clean room first. Power on. Let the IR team scan for IOCs, persistence mechanisms, and backdoors.
4. Validate application functionality in isolation. Smoke tests. Data integrity checks. Confirm no ransomware artifacts.
5. Harden before reconnecting. Reset ALL credentials — every password, every service account, every API key. Patch the exploited vulnerability. Enable MFA. Segment the network. THEN connect to production.
6. Monitor aggressively for 30+ days. EDR on every endpoint. 24/7 SOC monitoring. 69% of organizations that paid ransom were attacked again. The attacker may try to come back.

The Ransom Decision

This is a business decision, not a technical one. The IC decides with legal and insurance input. Here are the factors:

Arguments against paying: you have verified backups and can recover; 69% of payers were hit again; payment funds criminal operations; no guarantee the attacker deletes exfiltrated data; no guarantee decryption keys work; average payment is $1M and you still spend $1.53M on recovery anyway.

Factors that complicate: no usable backups exist; the business will cease without the data; exfiltrated data creates existential legal risk; lives are at risk (healthcare, critical infrastructure); insurance recommends payment; rebuild cost far exceeds ransom.

The Recovery Timeline

Here's the realistic timeline from detection to full recovery:

This is the realistic timeline. Not the vendor marketing timeline. Twenty-four days average for a reason.

How to Never Be Here Again

Six things that prevent you from ever being in this situation again:

1. Implement 3-2-1-1-0 backups. Three copies, two media, one offsite, one immutable, zero errors. The immutable copy is the one that saves you. Hardened Linux repo, S3 Object Lock, or tape offsite.
2. Segment backup credentials. If your backup admin accounts are in Active Directory, an attacker with domain admin can delete every backup. Use local accounts or a separate auth system.
3. Enable MFA on everything. VPN, vCenter, email, backup console, cloud accounts. MFA blocks 82% of credential-based attacks for under $10K/year.
4. Run ransomware tabletop exercises. Quarterly. With the full team. The team that's practiced doesn't panic.
5. Test your immutable backups monthly. Try to delete a test backup from the immutable repo. It should fail. If it succeeds, fix it immediately.
6. Assume breach. Plan accordingly. Zero trust. Network segmentation. Least privilege. The question isn't whether you'll be attacked — it's whether you'll survive it.

Watch the Video