This SOP is triggered by ransomware behavioral alerts from Defender for Endpoint — mass file renaming, shadow copy deletion, canary file modification, or a ransom note drop. It is T2/IR Lead territory — escalate from T1 immediately on confirmation. Time compression is the single biggest factor in outcome: every minute of delay = more files encrypted, more shares reached.
The phases are ordered by time urgency. Phases 1–3 run as fast as possible in sequence. Phases 4–5 run in parallel once blast radius is contained. Phase 6 is a hard gate — nothing reconnects to the network until all checks pass.
◈ Table of Contents
📋
PHASE 00 — QUICK REFERENCE
METADATA| SOP ID | SOP-05 |
| Owner | T2 SOC Analyst / IR Lead — T1 escalates immediately on first ransomware indicator |
| Trigger | MDE ransomware behavioral alert · Mass file rename/extension change · Shadow copy deletion command · Canary file modified · Ransom note (README.txt, DECRYPT.html) dropped |
| Time Targets | Patient zero isolated: < 5 min from confirmation · Blast radius scoped: < 15 min · All affected hosts isolated: < 30 min · C2 blocked: < 45 min |
| Escalate To | IR Lead + Management + Legal on confirmation. If Domain Admin was used: treat entire AD as compromised — major incident. |
| Hard Rules | DO NOT REBOOT any affected device. DO NOT WIPE before forensic image. DO NOT RESTORE before confirming C2 is dead. DO NOT reconnect an isolated device until clean rebuild confirmed. |
| Tools Required | security.microsoft.com · portal.azure.com · Microsoft Sentinel · Backup console (Veeam / Azure Backup / DPMM) |
🚨
PHASE 01 — CONFIRM & ISOLATE
TARGET: < 5 MIN — CLOCK STARTS NOW01
Confirm Patient Zero + Immediate Isolation
CRITICAL — NO DELAY
◈ Steps
- !DO NOT REBOOT any device. Communicate to user and IT helpdesk immediately.
- 1Run KQL to identify patient zero — the earliest device showing mass file renames. Sort ascending by time; the earliest entry is patient zero:
KQL — PATIENT ZERO DETECTION (mass file rename = encryption pattern)
DeviceFileEvents
| where Timestamp >= ago(2h)
| where ActionType == "FileRenamed"
| extend
OldExt = tostring(split(PreviousFileName, ".")[-1]),
NewExt = tostring(split(FileName, ".")[-1])
| where OldExt in~ ("docx","xlsx","pdf","jpg","png",
"txt","csv","pptx","bak","sql","mdb","vhd")
| where OldExt != NewExt // extension changed = encrypted
| summarize
RenameCount = count(),
FoldersHit = dcount(FolderPath),
SampleFiles = make_set(FileName, 3),
FirstEncryption = min(Timestamp)
by DeviceName, AccountName, bin(Timestamp, 5m)
| where RenameCount > 20
| order by FirstEncryption asc // earliest = patient zero
- 2Confirm with shadow copy deletion KQL — most ransomware deletes VSS before or during encryption:
KQL — SHADOW COPY DELETION (ransomware anti-recovery)
DeviceProcessEvents
| where Timestamp >= ago(2h)
| where ProcessCommandLine has_any (
"vssadmin delete shadows",
"wmic shadowcopy delete",
"bcdedit /set {default} recoveryenabled no",
"bcdedit /set {default} bootstatuspolicy ignoreallfailures",
"wbadmin delete catalog",
"diskshadow",
"Remove-Item")
| project Timestamp, DeviceName, AccountName,
InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp asc
- 3Patient zero confirmed. ISOLATE NOW:
security.microsoft.com → Devices → [patient zero device] → … → Isolate device → Full isolation. Enter incident ticket ID in the comment. Confirm. - 4Wait 90 seconds. Refresh device page. Confirm Status = Isolated. If still showing Connected: check MDE agent health on the device (
Devices → [device] → Health state). If agent is offline, escalate to IT to pull the network cable physically. - 5Alert IR Lead and Management now. Do not wait for full scope. Ransomware = major incident declaration from the moment patient zero is confirmed.
Do not collect the investigation package before isolating — isolation takes priority. Package collection can run in parallel after isolation is confirmed.
📡
PHASE 02 — BLAST RADIUS ASSESSMENT
TARGET: < 15 MIN FROM ISOLATION02
Scope Infected Hosts + Network Share Encryption Check
KQL REQUIRED
◈ Steps
- 1Run the patient zero KQL from Phase 1 without the DeviceName filter — check if other devices show the same mass-rename pattern. Every device with >20 renames in a 5-min window is infected:
KQL — ALL INFECTED DEVICES (fleet-wide encryption scan)
// Same as Phase 1 KQL but no DeviceName filter — scope the fleet
DeviceFileEvents
| where Timestamp >= ago(2h)
| where ActionType == "FileRenamed"
| extend
OldExt = tostring(split(PreviousFileName, ".")[-1]),
NewExt = tostring(split(FileName, ".")[-1])
| where OldExt in~ ("docx","xlsx","pdf","jpg","png","csv","bak","sql")
| where OldExt != NewExt
| summarize RenameCount = count(), FirstSeen = min(Timestamp)
by DeviceName, bin(Timestamp, 5m)
| where RenameCount > 20
| summarize EncryptionStart = min(FirstSeen) by DeviceName
| order by EncryptionStart asc
- 2For every additional device returned: isolate using the same Defender process. Do not wait to scope them all — isolate as you find them.
- 3Check network shares being encrypted from patient zero (ransomware reaching mapped drives and SMB shares):
KQL — SMB LATERAL SPREAD FROM PATIENT ZERO
// Replace PATIENT_ZERO with actual device name
DeviceNetworkEvents
| where DeviceName =~ "PATIENT_ZERO"
| where Timestamp >= ago(2h)
| where RemotePort in (445, 139) // SMB ports
| where ActionType == "ConnectionSuccess"
| summarize
ConnectedHosts = make_set(RemoteIP),
ConnectionCount = count()
by DeviceName, bin(Timestamp, 5m)
| order by Timestamp asc
- 4Identify network shares that were hit. These paths may have encrypted files — the file servers hosting those shares need to be checked and potentially isolated too.
- 5Collect investigation package from patient zero (run in parallel now that it's isolated):
Devices → [patient zero] → … → Collect investigation package.
🔐
PHASE 03 — IDENTITY LOCKDOWN — ENTRA ID
DISABLE ALL ATTACKER ACCOUNTS03
Identify + Disable Compromised Accounts
ENTRA ID ACTION
◈ Steps
- 1Identify which accounts were used to execute the ransomware payload. Run KQL for network logons across all affected devices:
KQL — ACCOUNTS USED ACROSS AFFECTED HOSTS (attacker account identification)
// Replace with all confirmed affected device names
DeviceLogonEvents
| where Timestamp >= ago(6h)
| where DeviceName in~ ("HOST1", "HOST2", "PATIENT_ZERO")
| where LogonType in (3, 10) // Network (3) and Remote Interactive (10)
| summarize
LogonCount = count(),
Devices = make_set(DeviceName),
FirstSeen = min(Timestamp)
by AccountName, AccountDomain
| order by LogonCount desc
- 2For each account returned that is NOT a legitimate IT admin currently working the incident:
—portal.azure.com → Entra ID → Users → [account] → Edit → Block sign-in = Yes → Save
—Entra ID → Users → [account] → Revoke sessions - 3If a Domain Admin or Global Admin account was used: this is a catastrophic compromise indicator. All Kerberos tickets in the environment are suspect. Escalate to IR Lead + Legal immediately. The krbtgt account password must be reset twice (spaced 10 hours apart to allow replication) to invalidate all golden tickets. Do not attempt this without IR Lead sign-off.
- 4If service accounts were used: disable them in Entra ID and in Active Directory (
ADUC → [service account] → Account → Account is disabled = checked). - 5Check: did the attacker add any new admin accounts during the attack?
Entra ID → Audit logs → filter: OperationName = "Add member to role" · Date range = last 48h. Remove any unauthorized role assignments immediately.
Do not re-enable any accounts until the entire environment is confirmed clean and rebuilt. Ransomware operators frequently maintain backup access accounts and will re-encrypt if given any opportunity.
🌐
PHASE 04 — C2 IDENTIFICATION & BLOCK
CUT THE ATTACKER'S COMMS04
Find C2 Beaconing + Block IPs/Domains in Defender
KQL + DEFENDER ACTION
◈ Steps
- 1Look for C2 beaconing in the period BEFORE encryption started (recon/staging phase). Ransomware typically beacons to C2 for 30 min – several hours before triggering encryption:
KQL — C2 BEACON DETECTION (connections before encryption)
// Set PRE_ENCRYPTION_TIME to ~1h before FirstEncryption timestamp from Phase 1
DeviceNetworkEvents
| where DeviceName =~ "PATIENT_ZERO"
| where Timestamp between (
datetime(2026-06-14T20:00:00) .. // 2h before encryption
datetime(2026-06-14T22:00:00)) // ~start of encryption
| where ActionType == "ConnectionSuccess"
| where RemoteIPType != "Private"
| summarize
BeaconCount = count(),
RemotePorts = make_set(RemotePort),
FirstContact = min(Timestamp)
by RemoteIP, RemoteUrl, InitiatingProcessFileName
| where BeaconCount > 3 // repeated = beaconing pattern
| order by BeaconCount desc
- 2Also check DNS queries for known ransomware TOR/darknet domains or DGA-generated domains (random-looking hostnames with high beacon frequency):
KQL — DNS QUERIES FOR SUSPICIOUS DOMAINS
DeviceNetworkEvents
| where DeviceName =~ "PATIENT_ZERO"
| where Timestamp >= ago(6h)
| where ActionType == "DnsQueryResponse"
| where RemoteUrl !endswith ".microsoft.com"
and RemoteUrl !endswith ".windows.com"
and RemoteUrl !endswith ".office.com"
| summarize QueryCount = count() by RemoteUrl, RemoteIP
| where QueryCount > 5
| order by QueryCount desc
- 3Block all confirmed C2 IPs:
security.microsoft.com → Settings → Endpoints → Indicators → IP addresses → Add indicator → Action: Block and generate alert. Add each C2 IP. - 4Block all confirmed C2 domains: same path → URLs/Domains → Add indicator → Block and generate alert.
- 5If C2 comms are still active from other non-isolated hosts: emergency network-level block at the firewall/edge — push a rule to drop all traffic to C2 IPs. Coordinate with Network team.
💾
PHASE 05 — BACKUP INTEGRITY CHECK
DO NOT RESTORE YET05
Verify Last Clean Backup + Confirm Backups Are Not Encrypted
CRITICAL GATE
◈ Steps
- 1Do not restore yet. Confirm the following before touching any backup.
- 2Check VSS status on patient zero: was shadow copy deletion successful or did it fail? Review the Phase 1 KQL results — did the deletion command complete? If VSS copies still exist, file recovery may be possible without a full backup restore.
- 3Open your backup console (Veeam / Azure Backup / DPMM / Backup Exec): check the backup server health status. Is the backup server itself online and reporting healthy? If the backup server is domain-joined and was connected during the attack, the ransomware may have encrypted it too.
- 4Identify last clean backup timestamp: find the most recent backup job that completed before the FirstEncryption timestamp from Phase 1. That is your recovery point.
- 5Verify the backup files themselves: try restoring a single test file from that backup to a quarantined/air-gapped test VM. If the file opens cleanly, the backup is valid. If it's encrypted or corrupted, fall back to the next oldest backup.
- 6Check if Azure Backup / immutable storage is configured — immutable backup vaults cannot be deleted or modified by ransomware even with admin credentials. If you have this: your backups are safe regardless of the on-prem situation.
Modern ransomware groups (LockBit, BlackCat, Cl0p) specifically target backup infrastructure first — network-attached backup servers, Veeam repos on domain-joined hosts, and cloud backup sync agents are all targets. Immutable cloud backup (Azure Backup Vault with Immutability Policy) is the only reliable protection against backup encryption.
🚦
PHASE 06 — RECOVERY GATE CHECKLIST
ALL CHECKS MUST PASS BEFORE ANY RECONNECTION06
Hard Gate — Nothing Reconnects Until This Passes
RECOVERY
◈ Gate Checks — All Must Be True
- 1No new encryption activity for 30 consecutive minutes across all isolated hosts. Run the patient zero mass-rename KQL with a current time window — result count must be zero.
- 2C2 beaconing confirmed stopped: Defender network timeline on all isolated hosts shows no new outbound connections to known C2 IPs/domains since isolation.
- 3All attacker accounts disabled in Entra ID and AD. No unauthorized accounts in privileged groups.
- 4Clean backup identified and tested — restore of test file from backup snapshot confirmed successful.
- 5Root cause identified: how did the ransomware get in? Phishing email? Exposed RDP? Unpatched VPN (CVE)? Compromised credentials from a prior breach? Without knowing the entry point, reconnecting the environment recreates the same vulnerability.
◈ Recovery Steps — Execute in Order
- 6Re-image patient zero from gold image — do not restore from backup of an infected state, do not trust AV cleanup alone on a ransomware host. Rebuild from scratch.
- 7Restore user data from the verified clean backup snapshot to the rebuilt endpoint.
- 8Reconnect systems one at a time — not all at once. Monitor Defender XDR for 30 min after each reconnection before bringing the next system online.
- 9Re-enable accounts only after: endpoint rebuilt, MFA re-registered, password reset out-of-band, IR Lead sign-off.
- 10Patch the entry point before any system reconnects externally — if RDP was exposed, close it. If a CVE was exploited, patch or mitigate before internet-facing reconnection.
Closure Checklist
- Patient zero and all affected hosts isolated in Defender
- All attacker accounts disabled in Entra ID + AD
- C2 IPs and domains blocked in Defender Indicators
- No new encryption activity for 30+ min
- Root cause identified and entry point patched/mitigated
- Clean backup verified by test restore
- All affected hosts rebuilt from gold image
- User data restored from clean backup
- Accounts re-enabled with MFA, out-of-band password reset
- IR report drafted: timeline, root cause, dwell time, encrypted scope, recovery cost
If you have not identified the entry point — do not reconnect anything. The attacker will use the same vector again. This is non-negotiable.
This SOP is the most downstream in the chain — ransomware typically follows SOP-01 (Phishing initial access), SOP-03 (Malware lateral loader), or SOP-02 (Brute forced RDP/VPN credentials). Address root cause before recovery. Full SOP library at cyberhawkthreatintel.com/sops
◈ Stay Connected
Follow CyberHawk Threat Intel for threat intelligence, deployment guides and hands-on SOC tooling content.
"They can't exploit you if you are the Exploit."