Ransomware Response

The first 72 hours — by scenario, with the reason for every step

Preparing, not responding? Readiness, detection and hardening are on Ransomware Resilience. This page is for when it is happening.
Keeps the timed steps and triage table; hides platform queries, scenarios and extortion guidance.
T+0 — T+1 h  •  CONTAIN

Respond: The First Hour

The loops below are how you get ready. This is what you do when it happens. The flow is the same for every ransomware incident; By Scenario lists what changes when the incident is shaped differently. Goal in this phase: stop the spread, protect the way back, and keep the evidence.
Isolate, don't power off. Pulling the plug destroys memory (running processes, sometimes the encryption key) and on ESXi wipes logs that live on a ramdisk. Cut the network instead: EDR host isolation, switch port, or the Kill Internet playbook.
Contain at least as wide as the attacker could be. Containment wider than their footprint cuts every path at once and buys time. Containment narrower than it — one host isolated, one beacon killed, while other footholds stay live — tells the operator they're found while they still have a way in, and many encrypt early. Until the scope is known, go broad: the segment, the tier, estate-wide egress, all sessions. Go surgical only once the scope is known.
T+0–15 minDeclare, name one incident lead, move to out-of-band comms
Why: corporate email and Teams may be encrypted, down, or read by the attacker. One decision owner stops two people containing in conflicting ways. Use the Signal group and printed contact sheet from Ransomware Resilience, Loop 1.
T+0–15 minClassify the scenario before acting
Is anything encrypted yet? Which planes are touched: endpoints, hypervisors/NAS, backups, identity, cloud storage? Is there a note, a leak-site post, or a phone call? Why: the first hour differs per scenario. Piecemeal, host-by-host containment of an attacker who has not encrypted yet can make them encrypt early — the scenario tells you how wide to cut. Answer the questions in How Far Has It Got?, then pick the matching card in By Scenario.
T+15–30 minIsolate affected systems and segments
EDR network containment for hosts, switch-port or VLAN shutdown for segments, Kill Internet (Loop 1, Playbook 1) when spread is unclear. Cut at the widest level the attacker could have reached, not host by host. Why: encryption and exfiltration both need the network; isolation stops both and keeps memory and disk intact for forensics. Stop execution, don't clean: the kill and quarantine actions under Hunt & Act stop a running payload and preserve it as evidence. Compromised hosts are rebuilt from known-good images later, never cleaned in place.
T+30–45 minSever and verify the backups
Disconnect the backup infrastructure from production, change the backup console credentials (separate MFA), and confirm an immutable or offline copy exists and when its last clean point is. Why: 94% of organisations hit by ransomware saw the attacker try to compromise their backups (Sophos, State of Ransomware 2024). An attacker who sees the response starting deletes them next, and the date of the last clean copy sets the recovery plan and the ransom question. The stage 6 hunts under Hunt & Act (Veeam event ids, ESXi audit VOBs, backup-console logons) tell you whether they already have.
# S3 / Wasabi / B2: is Object Lock on, and in which mode?
aws s3api get-object-lock-configuration --bucket <backup-bucket>
# restic: newest snapshots (read-only)
restic -r <repo> snapshots --latest 3
T+45–60 minCut the deployment channel
Disable the accounts seen deploying, and look for mass-deployment staging: recently changed GPOs, new scheduled tasks and services, PsExec or RMM pushes. Why: operators push the payload domain-wide through GPO or remote execution. Removing the channel stops the next wave even before every host is isolated.
Get-GPO -All | Sort-Object ModificationTime -Descending |
  Select-Object -First 10 DisplayName, ModificationTime
Get-ScheduledTask | Where-Object { $_.Date -and [datetime]$_.Date -gt (Get-Date).AddDays(-3) } |
  Select-Object TaskName, TaskPath, Date, Author
T+0–60 minCall the insurer and legal counsel
Why: many policies only cover IR firms and negotiators the insurer has approved, and require notice before you engage them. Counsel directing the investigation keeps the findings privileged. Claim number is on the emergency contact sheet.
Hour 1 — 24  •  EVICT & SCOPE

Hour 1–24: Evict, Scope, Preserve

Kill Authentication, Tier 0 first
Loop 1, Playbook 2: disable the accounts seen, then revoke, then reset, then revoke again. Rotate domain and enterprise admin first, then every non-AD credential (hypervisors, vCenter SSO, NAS, network devices, backup console, service accounts). Reset krbtgt twice, with the second reset after replication and the maximum ticket lifetime (10 h by default). Why: one reset leaves forged Kerberos tickets valid; two back-to-back breaks legitimate authentication across the domain.
The resets that are usually missed — each one survives a password reset on every user and admin account:
  • Entra Connect sync accounts. The AD DS connector account (MSOL_<hex>) has replication rights, so it is a DCSync credential; the Entra connector account (Sync_<server>_<hex>) holds Directory Synchronization Accounts. Reset the AD account in AD and update it in Synchronization Service Manager; reset the cloud one with Add-ADSyncAADServiceAccount on the Connect server.
  • AD CS. A certificate issued through a misconfigured template (ESC1) authenticates as that user until it expires, and a stolen CA key signs new ones forever (a "golden certificate"). List and revoke everything issued in the dwell window; if the CA key may have been exported (CA server reached, or 4876/4877 backup events), the CA is reissued, not reset.
  • DSRM. The Directory Services Restore Mode password on every DC; with DsrmAdminLogonBehavior set to 2 it is a working domain-controller logon over the network.
  • AdminSDHolder and SIDHistory. An extra ACE on AdminSDHolder is re-applied to every protected group hourly; a SIDHistory value equal to a privileged SID is domain admin on a plain user. Both persist through any reset.
  • gMSA. The password rotates on the KDS schedule, but anyone in PrincipalsAllowedToRetrieveManagedPassword can read the current one; remove what the attacker added. If a DC was fully compromised, the KDS root key is theirs too (GoldenGMSA) and the domain is rebuilt, not cleaned.
  • Entra tokens and PRTs. Revoke-MgUserSignInSession invalidates refresh tokens and browser sessions; access tokens already issued stay valid until they expire (about 1 h; CAE-capable clients enforce the revoke within minutes). The Primary Refresh Token on an attacker-held device dies when that device object is disabled (Update-MgDevice -AccountEnabled:$false), so disable the device records of every host the stage 2–5 hunts returned. Disable the account before revoking; revoking first leaves the still-valid password usable for a new sign-in.
# AD CS: everything issued in the dwell window, then revoke by serial (reason 1 = key compromise)
certutil -view -restrict "NotBefore>=<dd/mm/yyyy>,Disposition=20" -out "RequestID,RequesterName,CommonName,SerialNumber,CertificateTemplate"
certutil -revoke <SerialNumber> 1
# DSRM behaviour and reset, on every DC
reg query "HKLM\System\CurrentControlSet\Control\Lsa" /v DsrmAdminLogonBehavior
ntdsutil "set dsrm password" "reset password on server null" q q
# AdminSDHolder ACL and SIDHistory
(Get-Acl "AD:\CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)").Access | Where-Object { $_.IdentityReference -notmatch 'Domain Admins|Enterprise Admins|Administrators|SYSTEM|Enterprise Key Admins|Key Admins|Pre-Windows 2000' }
Get-ADObject -LDAPFilter "(sIDHistory=*)" -Properties sIDHistory | Select-Object Name, sIDHistory
# gMSA readers
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword | Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword
# Entra: disable, revoke, disable the attacker's device records
Update-MgUser -UserId <upn> -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId <upn>
Get-MgDevice -Filter "displayName eq '<host>'" | ForEach-Object { Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false }
Find the entry point and the dwell time
VPN and firewall authentication logs, edge-device versions against the CISA KEV list, first appearance of attacker tools and accounts. Why: median dwell time in ransomware cases is 3–4 days (Sophos, Active Adversary Report 2025), and the stage 1 hunts under Hunt & Act are how you find the first external logon. Restoring before the door is closed means being encrypted again from the same entry point.
Scope what left the network
Egress volume per host for the dwell window from the firewall or Zeek (the stage 7 bytes-out queries in the Splunk and Elastic tabs; the EDR tables have no byte counts), staging and transfer tools (rclone, MEGAcmd, WinSCP, FileZilla), 7-Zip or WinRAR archives created in bulk on file servers, and the cloud-storage destinations the stage 7 hunts list. Why: exfiltration decides whether this is a notifiable data breach and whether a leak-site threat is real — and it can be true even when nothing was encrypted. The rclone config names the destination account, which is what the takedown request and the notification need.
Get-ChildItem C:\Users\*\AppData\Roaming\rclone\rclone.conf -ErrorAction SilentlyContinue
Identify the variant, check for a decryptor
Ransom note text, file extension and a sample encrypted file against No More Ransom and ID Ransomware; ask law enforcement whether keys are held. Why: free decryptors exist for some families, and the variant tells you the group's usual TTPs and leak-site behaviour.
Export first: the logs that expire on a clock
Before any hunt or clean-up, export the sources whose retention is shorter than the case will run, and record a SHA256 for each export. Why: every one of these rotates on its own schedule regardless of the incident; the insurer, police, regulator and any later claim need evidence that no longer exists once the window closes. Retention is as of the product tier named; check yours.
  • Windows Security, System and Sysmon logs on DCs, file servers and the hosts in scope: default 20 MB sizes overwrite in hours on a busy DC. wevtutil epl each channel, or Live Response Collect investigation package / RTR eventlog export.
  • Defender advanced hunting: 30 days. Sentinel: the workspace retention (90 days interactive by default). Export the stage queries' results as CSV while they still return rows.
  • Entra sign-in and audit logs: 30 days on P1/P2, 7 days free, unless streamed to Log Analytics. Get-MgAuditLogSignIn -All and Get-MgAuditLogDirectoryAudit -All.
  • Unified Audit Log: 180 days on Audit Standard, 1 year on Audit Premium. Search-UnifiedAuditLog -StartDate <dwell start> -EndDate (Get-Date) -SessionCommand ReturnLargeSet, paged until empty; -ResultSize 5000 alone truncates.
  • ESXi and vCenter: ESXi logs sit on a ramdisk and are gone at reboot; vm-support on each host, and the VCSA support bundle. Veeam: the Veeam Backup event log and C:\ProgramData\Veeam\Backup.
  • Firewall, VPN and proxy logs for the dwell window, with the bytes-out per host, and DHCP lease logs so that addresses in every other log resolve to hosts.
wevtutil epl Security C:\IR\%COMPUTERNAME%-Security.evtx
wevtutil epl Microsoft-Windows-Sysmon/Operational C:\IR\%COMPUTERNAME%-Sysmon.evtx
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) -SessionId "IR-<n>" -SessionCommand ReturnLargeSet -ResultSize 5000 | Export-Csv ual-page.csv -Append
Get-MgAuditLogSignIn -All -Filter "createdDateTime ge <yyyy-mm-dd>T00:00:00Z" | Export-Csv signins.csv
Get-ChildItem C:\IR | Get-FileHash -Algorithm SHA256 | Export-Csv C:\IR\manifest.csv
Preserve evidence before it rotates
Memory from patient zero and a sample of affected hosts, ESXi and NAS logs, the ransom note, the encryptor binary, and hashes of a sample encrypted file. Three collectors are published here; check the SHA256 before you run any of them, and push them with your EDR's file transfer (Live Response putfile/run, RTR put/run, a RemoteOps script, Velociraptor Windows.System.PowerShell, the Elastic response console upload/execute) — the exact commands per tool are in each tab's Collect step under Hunt & Act.
  • Magnet RESPONSE 1.7.2 d315c63d1ad4b89e03c7688b29169e977c2abc4559c23b9f6b2282f3c91a6c7d — Windows volatile data: RAM, pagefile, running processes and triage files, in one package. Run it elevated from removable media or push it with the EDR; the /unattended /captureram /capturepagefile switches avoid the prompt. Velociraptor users can take RAM natively with Windows.Memory.Acquisition.
  • Get-PersistenceSnapshot.ps1 a9534865f9e8e7b1f5077b4e1cfd8c29e7e32f6e9e49a4918ce4f8fb713e64df — Windows persistence, read-only: run keys, services, scheduled tasks, WMI subscriptions, startup folders and more, with file hashes and signatures. -Zip for chain of custody; run it on a clean host of the same build and pass that snapshot to -CompareTo to see only what the attacker added.
  • get-persistence-snapshot.sh 8fe386a7d6ebd50225b04ad83581ee3e5d504a10a4263253b5a11b8a61eeca67 — the Linux counterpart for servers and x86 NAS: cron, systemd units and timers, SSH keys, PAM, ld.so.preload, SUID files, with package-manager verification of every referenced binary. --zip and --compare-to as above. ESXi has no bash; the Linux / ESXi tab lists the equivalent checks by hand.
Why: default log sizes overwrite in hours, memory is gone at the first reboot, and the encryptor often deletes itself; the insurer, police and any later claim need evidence you can no longer collect once systems are rebuilt.
Day 1 — 7  •  NOTIFY & RECOVER

Day 1–7: Notify, Decide, Recover

Run the notification clocks from awareness, not from close
GDPR: supervisory authority within 72 h of becoming aware of a personal-data breach, data subjects without undue delay if the risk is high. NIS2: early warning within 24 h, notification within 72 h, final report within one month. DORA (financial entities): initial notification within 4 h of classifying the incident as major, and no later than 24 h after becoming aware. File a police report — most insurers require one. Why: the clocks start before scoping ends; notify with what you know and update.
Put the pay / don't-pay question to the board with facts
The board decides, with counsel. It needs: date of the last clean backup and the restore estimate, what data left, the sanctions screening result (OFAC, EU consolidated list), the insurer's position, and proof that a decryptor works on a sample file. Add three more: how long the attacker was in before detection (dwell time sets how far back backups may carry their tools), what the family is known for (decryptor reliability, exfil-first, re-extortion), and whether the organisation will accept affected systems being destroyed and rebuilt rather than decrypted. Why: almost 80% of organisations that paid were hit a second time (Cybereason, Ransomware: The True Cost to Business 2024), and paying never guarantees stolen data is deleted. See Extortion.
Restore in tier order, into a clean network
Tier 0 identity first, then Tier 1 (payroll, ERP) — the order from Loop 5. Compromised hosts are rebuilt from known-good images, not cleaned; data comes back from backup. Restore into an isolated recovery network and scan restored systems for the attacker's persistence — backups from inside the dwell window can carry their tools back in. Gate: reconnect only after the incident lead declares eradication complete. Identity being reset is not enough on its own. Why: IT recovering before the response team has finished eradicating is one of the fastest ways to lose a response; restoring onto a compromised identity plane, or restoring the attacker's scheduled task along with the server, reinfects the estate.
Eradication gate — all of these, in writing, before the first host reconnects:
  • The entry point is named and closed (stage 1 hunt answered; edge device patched or replaced; the VPN account disabled), and every account seen in stages 1, 4 and 5 is in the Kill Authentication list.
  • Kill Authentication is complete, including the second krbtgt reset and the resets listed above (Entra Connect, AD CS, DSRM, AdminSDHolder, SIDHistory, gMSA, device objects).
  • Every host the stage 2 and 5 hunts returned is rebuilt from a known-good image or still isolated; none has been cleaned in place.
  • The hypervisors in scope are reinstalled, SSH and the shell are off, lockdown is on, and the backup console credentials are new (stage 6 hunts, re-run, return nothing after the eviction time).
  • Verification hunt: the stage 2 (RMM, tunnels, beacon indicators), stage 4 (LSASS, DCSync, Kerberoasting), stage 5 (fan-out, remote execution), stage 6 (ESXi audit, backup console) and stage 8 (shadow copies, security services, GPO) hunts, re-run over the window from the eviction time to now, all return nothing new. Run them in every tab you have and in Velociraptor across the rebuilt hosts; a hit on any of them reopens scoping and resets the window.
  • Persistence snapshots from the rebuilt hosts (Get-PersistenceSnapshot.ps1 -CompareTo, get-persistence-snapshot.sh --compare-to) diff clean against the gold image.
  • The restored data was taken from a point before the dwell start, or scanned for the attacker's tools and persistence if it had to come from inside the window.
After Day 7  •  LEARN

After Day 7: Feed the Slow Loops

The incident doesn't close at recovery. It is the most expensive data the program will collect — spend it. Machines collect, humans curate.
  • Entry route → vulnerability management and posture: the edge device, credential or exposure that let them in, and every other place it exists.
  • What detection missed → the detection backlog: each stage they reached without an alert (staging, credential dumping, backup tampering) becomes a tested detection with an owner.
  • Visibility and process gaps → structural improvement: missing logs, slow decisions, backups that were reachable, handovers that stalled.
  • Indicators become intelligence only after an analyst checks them and gives each one a date, a source, an expiry and a confidence level. Attacker IPs and hashes rotate; an unexpired block list becomes noise.
  • Re-run the tabletop against what actually happened, and update this playbook where the response was slow.

How Far Has It Got?

Ask these at triage, top to bottom, and again at every update. The furthest stage you can show evidence for is how far the incident has got — write it in the case's status line. A stage you cannot answer yet is a scoping gap: say when it will be known. Why: the stage reached decides which scenario card applies, how hard to contain, and whether the notification clocks are already running.

Ransomware attack chain (Scenarios 1, 2 and 5)

#StageATT&CKQuestionWhere to look
1Initial accessT1133 T1190How did they get in, and when was the earliest malicious activity?VPN, firewall and edge-device auth logs; edge-device versions against CISA KEV; EDR first-seen times
2FootholdT1219 T1055Do they have C2 beacons or remote-access tools on hosts, and on how many?EDR alerts; Velociraptor hunt for RMM and beacon artifacts; named pipes; new services and scheduled tasks
3DiscoveryT1087.002 T1482Have they mapped Active Directory and the network?BloodHound/SharpHound, AdFind or network-scanner execution; LDAP query spikes
4PrivilegeT1003.001 T1003.006Do they hold domain admin or other Tier 0 credentials?Admin logons (4624/4672) from unusual hosts; LSASS access; NTDS.dit copies; DCSync (4662 with replication GUIDs) on domain controllers; Kerberoasting (4769 RC4)
5Lateral movementT1021.002 T1569.002How many hosts have they reached?Logon type 3/10 from foothold hosts; RDP, SMB, WMI and WinRM; service installs (7045), remote tasks (4698), admin-share writes (5145)
6Recovery planesT1021.004 T1490Have they touched hypervisors, vCenter or the backup console?vCenter and ESXi auth logs; esx.audit.ssh.enabled in vobd.log; Veeam event ids 10050/23090/28200/40201; backup console logons
7ExfiltrationT1567.002 T1560.001Has data left, how much, and from where?Firewall/proxy egress volume per host; rclone, MEGAcmd, WinSCP; 7-Zip/WinRAR archives on file servers; cloud-storage destinations
8Impact preparationT1490 T1562.001Are they disabling defences or recovery?Security agents stopped; shadow copies deleted (vssadmin, wmic); backup jobs or retention changed; new or changed GPOs
9EncryptionT1486Has encryption started, and how widely?Ransom notes; mass renames; canary tokens; EDR mass-file-modification alerts
10ExtortionT1657Have they made contact or listed us on a leak site?Ransom note contact details; emails or calls to staff; leak-site monitoring

Data theft without encryption (Scenario 3)

#StageATT&CKQuestionWhere to look
1First contactT1566.004How did the attacker first reach us: call or email, which users, when?Phone-system logs; helpdesk tickets; user interviews; email gateway
2Other targetsT1566.004Were other staff contacted with the same pretext?Phone-system logs; email gateway search; ask staff
3Remote accessT1219Was a remote-access tool installed or a session granted, on which hosts?EDR software inventory; AnyDesk, Zoho Assist, ScreenConnect installs; browser download history
4Session activityT1083How long did the access last, and what did they do?The tool's own session logs; EDR process tree
5Data accessedT1039 T1530Which shares, mailboxes and applications were read?File-server audit; SharePoint/OneDrive and Unified Audit Log; document-management audit
6ExfiltrationT1567.002How much left, and to where?Egress volume from the host; cloud-storage uploads; rclone
7PersistenceT1078 T1219Do they still have access: other tools, accounts, tokens?Sign-ins after the session; a second remote-access tool; new accounts
8DemandT1657Has a demand arrived, with samples and a deadline?The message itself; samples validated against our systems
9PublicationT1657Are we listed on a leak site, or is data already published?Leak-site monitoring; threat-intel feeds
10Third partiesT1657Has the extortionist contacted our clients or partners?Client and partner reports; account managers

Hypervisor / NAS (Scenario 4)

#StageATT&CKQuestionWhere to look
1Network entryT1133How did they reach our network?VPN and firewall logs; EDR on Windows hosts
2Management planeT1021.004Did they reach ESXi, vCenter or NAS management interfaces, and from which host?Firewall logs into the management VLAN; vCenter logins; ESXi auth.log "Accepted" lines by source
3CredentialsT1078Which account did they use: vCenter SSO, root, the AD "ESX Admins" group?ESXi auth.log and hostd.log; vCenter events; AD group changes (4728/4732/4756)
4Shell accessT1059.004Was SSH or the ESXi Shell enabled, when, and by whom?vobd.log esx.audit.ssh.enabled / esx.audit.shell.enabled; hostd.log; shell.log (interactive commands only)
5Defence changesT1562.001Was lockdown disabled, VIB acceptance lowered or execInstalledOnly turned off?esxcli software acceptance get; esxcli system settings kernel list -o execInstalledOnly; esx.audit.lockdownmode.disabled in vobd.log
6RecoveryT1490Were snapshots deleted, or the backup appliance reached?hostd.log RemoveSnapshot tasks; vCenter tasks; backup console audit log
7ExfiltrationT1048Did data leave from VMs or NAS before encryption?Egress from the management network and NAS; NAS access logs; rclone configs on the NAS
8VMs stoppedT1489Which VMs were powered off?vCenter events; esxcli vm process list; vim-cmd vmsvc/getallvms
9EncryptionT1486Which datastores and NAS volumes are encrypted, on how many hosts?Listing of /vmfs/volumes; ransom notes; NAS share contents
10ExtortionT1657Have they made contact or listed us on a leak site?Ransom note; emails to staff; leak-site monitoring

Hunt & Act by Platform

What to look for in your EDR or SIEM for each stage of the ransomware attack chain, and the response actions in each tool. Pick your platform.
Test these before you need them. The queries follow each vendor's documented schema, but field names depend on your data sources, versions and ingestion. Run each one in your own tenant during peacetime and fix it there — not during an incident.
KQL, advanced hunting. The same Device* tables in Sentinel when the Defender XDR connector streams them; SecurityEvent, Syslog, Event and CommonSecurityLog are Sentinel-only. Advanced hunting keeps 30 days; anything older is in the Sentinel workspace or nowhere.

Hunt

Stage 1 · Initial accessInbound RDP, SMB and WinRM from public addresses; VPN logons by country

Why: Most ransomware cases start with a VPN or RDP logon on a valid account, or an unpatched edge device. The first external logon on the account later seen moving laterally dates the intrusion.

DeviceNetworkEvents sees the endpoint side only. VPN and firewall authentication arrives in Sentinel as CommonSecurityLog (CEF) or a vendor table; the second query assumes CEF. Check edge-device versions against CISA KEV by hand.

DeviceNetworkEvents
| where Timestamp > ago(30d) and ActionType == "InboundConnectionAccepted"
| where LocalPort in (3389, 445, 5985, 5986)
| where not(ipv4_is_private(RemoteIP)) and RemoteIP != "127.0.0.1"
| summarize FirstSeen=min(Timestamp), Connections=count() by DeviceName, RemoteIP, LocalPort
| order by FirstSeen asc
// Sentinel: VPN logons per user, how many source countries (CEF-based appliances)
CommonSecurityLog
| where TimeGenerated > ago(30d) and DeviceProduct has_any ("VPN", "Firewall", "FortiGate", "PAN-OS", "ASA")
| where Activity has_any ("vpn", "tunnel", "login", "logon") and DeviceAction !has "fail"
| extend Country = tostring(geo_info_from_ip_address(SourceIP).country)
| summarize Countries=make_set(Country), Sources=dcount(SourceIP), First=min(TimeGenerated) by DestinationUserName
| where Sources > 1 | order by First asc
T1133 T1078 Tuning: Published RDP or SMB on a jump host and VPN concentrators that NAT every user to one address fire this. Exclude the known public-facing hosts by name, not by port. Travelling staff give two countries; three or a hosting-provider ASN is the lead.

Stage 2 · FootholdRemote-access and tunnelling tools, first seen per tool

Why: Operators install legitimate RMM tools for persistent access and tunnel through them when the EDR blocks their C2. A tool first seen in the last days, on few hosts, is the lead.
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName has_any ("anydesk","screenconnect","atera","splashtop","teamviewer","rustdesk","meshagent","client32","simplehelp","syncro","level.exe","tacticalrmm",
                          "ngrok","chisel","plink","ligolo","cloudflared","gost","frpc","rsocx")
     or ProcessCommandLine has_any ("--reverse", "-R 0.0.0.0", "tunnel run", "client -connect")
| summarize FirstSeen=min(Timestamp), Hosts=dcount(DeviceName), Example=any(ProcessCommandLine) by FileName
| order by FirstSeen asc
T1219 T1572 Tuning: Helpdesk RMM is legitimate on every host; the lead is a second RMM product, or the house product on servers where helpdesk never connects. Filter on the signer and install path your deployment uses.

Stage 2 · FootholdBeacon indicators — known named pipes, rundll32 with no arguments, remote thread injection

Why: Cobalt Strike, Brute Ratel and Sliver leave default pipe names and a hollow rundll32.exe parent; a process creating a thread in another process is the loader. These date the foothold when the RMM hunt is empty.
DeviceEvents
| where Timestamp > ago(14d) and ActionType == "NamedPipeEvent"
| extend PipeName = tostring(parse_json(AdditionalFields).PipeName)
| where PipeName matches regex @"(?i)\\(msagent_[a-f0-9]{2}|postex_[a-f0-9]{4}|MSSE-\d+-server|status_\d+|mojo\.5688\.8052\.|wkssvc_|ntsvcs_|DserNamePipe|SearchTextHarvester|mypipe-[fh])"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, PipeName
// rundll32 with no arguments, or a remote thread from an unsigned/odd parent
DeviceProcessEvents
| where Timestamp > ago(14d) and FileName =~ "rundll32.exe"
| where ProcessCommandLine matches regex @"(?i)rundll32(\.exe)?""?\s*$"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine
DeviceEvents
| where Timestamp > ago(14d) and ActionType == "CreateRemoteThreadApiCall"
| where InitiatingProcessFolderPath !startswith @"c:\windows\system32" and InitiatingProcessFolderPath !startswith @"c:\program files"
| summarize Count=count(), Targets=make_set(FileName, 10) by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath
T1055 T1218.011 T1071.001 Tuning: AV, DLP and performance agents create remote threads from Program Files and are excluded above; anything from Users, ProgramData or Temp is the lead. Pipe names are the defaults; operators who change the malleable profile will not hit this.

Stage 3 · DiscoveryAD and network reconnaissance tools; LDAP enumeration from workstations

Why: AdFind, SharpHound and network scanners run days before encryption; they date the dwell time. The LDAP hunt catches the same reconnaissance when the tool is renamed or run in memory.
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("adfind.exe","sharphound.exe","netscan.exe","nltest.exe","dsquery.exe")
     or FileName startswith "advanced_ip_scanner"
     or ProcessCommandLine has_any ("trustdmp","domain_trusts","-collectionmethod","objectcategory=computer","samaccounttype=805306368","/domain_trusts","Get-DomainComputer","Get-NetSession")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine
// Workstations issuing broad LDAP searches (MDE LdapSearch telemetry)
DeviceEvents
| where Timestamp > ago(14d) and ActionType == "LdapSearch"
| extend Filter = tostring(parse_json(AdditionalFields).SearchFilter)
| where Filter has_any ("objectClass=trustedDomain", "samAccountType=805306368", "objectCategory=computer", "adminCount=1", "servicePrincipalName=*")
| summarize Searches=count(), Filters=make_set(Filter, 5) by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName
| where InitiatingProcessFileName !in~ ("lsass.exe","svchost.exe","Microsoft.Tri.Sensor.exe") | order by Searches desc
T1087.002 T1482 T1046 T1018 Tuning: Vulnerability scanners, Entra Connect, MDI sensors and admin tooling (RSAT, PowerShell AD module on jump hosts) issue the same filters; exclude those hosts by name. A user workstation running them is the finding.

Stage 4 · PrivilegeLSASS credential dumping — handle access and known tools

Why: A LSASS dump means every credential cached on that host is the attacker's; Kill Authentication has to cover them. Command-line patterns miss nanodump and renamed tools; the OpenProcessApiCall event sees the handle itself.
DeviceEvents
| where Timestamp > ago(14d) and ActionType == "OpenProcessApiCall" and FileName =~ "lsass.exe"
| where InitiatingProcessFolderPath !startswith @"c:\windows\system32" and InitiatingProcessFolderPath !startswith @"c:\program files"
| summarize Count=count(), First=min(Timestamp) by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessSHA256
| order by First asc
// Known tools and techniques by command line
DeviceProcessEvents
| where Timestamp > ago(14d)
| where (ProcessCommandLine has "comsvcs" and ProcessCommandLine has "MiniDump")
     or (FileName startswith "procdump" and ProcessCommandLine has "lsass")
     or ProcessCommandLine has_any ("sekurlsa", "nanodump", "lsassy", "pypykatz", "dumpert", "handlekatz", "mimikatz")
     or (FileName =~ "taskmgr.exe" and ProcessCommandLine has "lsass")
     or (FileName =~ "rundll32.exe" and ProcessCommandLine has "lsass")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine
T1003.001 Tuning: AV engines, EDR agents, Sysmon and crash-dump tooling open LSASS from Program Files or System32 and are excluded above. Anything else opening LSASS from a user-writable path is a finding; investigate rather than tune.

Stage 4 · PrivilegeNTDS.dit theft from a domain controller

Why: One copy of ntds.dit plus the SYSTEM hive is every password hash in the domain. It is the reason the krbtgt reset has to happen twice and why every service account is rotated.
DeviceProcessEvents
| where Timestamp > ago(30d)
| where (FileName =~ "ntdsutil.exe" and ProcessCommandLine has_any ("ifm", "create full"))
     or (FileName =~ "vssadmin.exe" and ProcessCommandLine has_all ("create", "shadow"))
     or (FileName in~ ("esentutl.exe","copy.exe","xcopy.exe","robocopy.exe") and ProcessCommandLine has "ntds.dit")
     or (FileName =~ "diskshadow.exe")
     or ProcessCommandLine has_all ("reg", "save", "hklm\\system")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine
DeviceFileEvents
| where Timestamp > ago(30d) and FileName =~ "ntds.dit" and FolderPath !startswith @"c:\windows\ntds"
| project Timestamp, DeviceName, FolderPath, InitiatingProcessFileName, InitiatingProcessAccountName
T1003.003 Tuning: Backup agents and IFM media for new DCs create shadow copies and IFM sets on a schedule; match the account and time against the backup job. A copy of ntds.dit under a user profile, Temp or a share has no legitimate reason.

Stage 4 · PrivilegeDCSync and Kerberoasting

Why: DCSync pulls hashes over the replication protocol with no process on the DC; Kerberoasting cracks service-account passwords offline. Both show up only in directory and ticket telemetry, not on the endpoint. Defender for Identity records replication as IdentityDirectoryEvents; without MDI, SecurityEvent 4662 and 4769 in Sentinel are the source.
// Defender for Identity: replication from anything that is not a DC or Entra Connect
IdentityDirectoryEvents
| where Timestamp > ago(30d) and Application == "Active Directory" and ActionType == "Directory Services replication"
| where DeviceName !in~ ("<dc01>", "<dc02>", "<entra-connect>")
| project Timestamp, AccountName, DeviceName, DestinationDeviceName
// Sentinel, Security log on DCs: 4662 with the replication GUIDs from a non-machine account
SecurityEvent
| where TimeGenerated > ago(30d) and EventID == 4662 and ObjectServer == "DS"
| where Properties has_any ("1131f6aa-9c07-11d1-f79f-00c04fc2dcd2", "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2", "89e95b76-444d-4c62-991a-0facbeda640c")
| where SubjectUserName !endswith "$" and SubjectUserName !startswith "MSOL_"
| project TimeGenerated, Computer, SubjectUserName, SubjectDomainName
// Kerberoasting: RC4 service tickets for many SPNs from one source
SecurityEvent
| where TimeGenerated > ago(14d) and EventID == 4769 and TicketEncryptionType == "0x17" and Status == "0x0"
| where ServiceName !endswith "$" and ServiceName != "krbtgt"
| summarize Services=dcount(ServiceName), Names=make_set(ServiceName, 20) by TargetUserName, IpAddress, bin(TimeGenerated, 1h)
| where Services > 5 | order by Services desc
T1003.006 T1558.003 Tuning: Entra Connect (MSOL_ or the AD DS connector account) and some backup or identity products replicate legitimately; name them. Legacy applications still request RC4 tickets, but one user requesting five or more distinct SPNs in an hour is Rubeus, not an application.

Stage 5 · Lateral movementOne account or source reaching many hosts

Why: Fan-out from one source is how the payload is staged; the source host and account are what to contain first.
DeviceLogonEvents
| where Timestamp > ago(7d) and ActionType == "LogonSuccess"
| where LogonType in ("Network","RemoteInteractive") and isnotempty(RemoteIP)
| summarize Targets=dcount(DeviceName), First=min(Timestamp), Last=max(Timestamp) by AccountName, RemoteIP
| where Targets > 10 | order by Targets desc
T1021.001 T1021.002 Tuning: Domain controllers, vulnerability scanners, backup servers, SCCM/Intune distribution points, monitoring pollers and admin jump hosts all reach dozens of targets. Exclude those source IPs and service accounts, then look at the remainder; a user account or workstation IP above the threshold is the finding.

Stage 5 · Lateral movementRemote execution — services, tasks, WMI, WinRM and Impacket

Why: PsExec is the minority. Most tooling installs a service with a random name, registers a task, or runs through WMI or WinRM; Impacket's wmiexec/smbexec leave a fixed cmd.exe /Q /c … \\127.0.0.1\ADMIN$ shape. Each hit is a target host for the isolation list.
DeviceEvents
| where Timestamp > ago(7d) and ActionType in ("ServiceInstalled", "ScheduledTaskCreated")
| extend F = parse_json(AdditionalFields)
| extend Name = coalesce(tostring(F.ServiceName), tostring(F.TaskName)), Path = coalesce(tostring(F.ServiceFilePath), tostring(F.TaskContent))
| where InitiatingProcessFileName in~ ("services.exe", "svchost.exe")
| summarize Hosts=dcount(DeviceName), Example=any(Path) by ActionType, Name
| where Hosts > 3 or Name matches regex @"^[A-Za-z]{8}$|^[0-9a-f]{8,}$|PSEXESVC|csexec|paexec|RemCom"
| order by Hosts desc
// WMI, WinRM and Impacket signatures
DeviceProcessEvents
| where Timestamp > ago(7d)
| where (InitiatingProcessFileName in~ ("wmiprvse.exe", "wsmprovhost.exe") and FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "rundll32.exe", "mshta.exe"))
     or (FileName =~ "cmd.exe" and ProcessCommandLine has "/Q /c" and ProcessCommandLine has_any ("ADMIN$", "\\127.0.0.1\\", "2>&1"))
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine
T1569.002 T1053.005 T1047 T1021.006 Tuning: SCCM, Intune, GPO software installs and monitoring agents install the same service on every host; the random eight-letter name or hex name is the PsExec-clone signature. wmiprvse.exe spawning powershell.exe is also how SCCM and some RMMs run scripts; match the script path.

Stage 6 · Recovery planesESXi and vCenter audit events from syslog

Why: Enabling SSH or the ESXi Shell, leaving lockdown mode and logging in as root on a host that is normally managed only through vCenter is the attacker lining up the hypervisor encryptor. ESXi writes these as VOB audit records; vCenter writes SSO logins. Both reach Sentinel only if syslog forwarding is configured — if this query is empty, confirm the forwarder before concluding nothing happened.
Syslog
| where TimeGenerated > ago(14d)
| where ProcessName in~ ("vobd", "hostd", "Hostd", "vpxd", "sso", "vmware-sso")
| where SyslogMessage has_any ("esx.audit.ssh.enabled", "esx.audit.shell.enabled", "esx.audit.lockdownmode.disabled",
                               "esx.audit.account.loginfailures", "esx.audit.account.locked", "User root@", "logged in as", "esx.audit.dcui.enabled")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated asc
// AD "ESX Admins" group membership changes (CVE-2024-37085 path)
SecurityEvent
| where TimeGenerated > ago(30d) and EventID in (4728, 4732, 4756)
| where TargetUserName =~ "ESX Admins"
| project TimeGenerated, Computer, SubjectUserName, MemberName, TargetUserName
T1021.004 T1562.001 Tuning: Patch windows and vendor support sessions enable SSH legitimately; match each enable event to a change record. Any enable outside a change, or from an account that is not the virtualisation team, is the finding.

Stage 6 · Recovery planesBackup console logons, backup deletion and retention changes

Why: Backups are the first thing a ransomware operator destroys once they have the hypervisor (94% of victims saw their backups attacked — Sophos, State of Ransomware 2024). Veeam writes an event for every restore point deleted, job changed, repository removed and MFA toggled; the Backup & Replication server's Security log shows who logged on to do it.

Veeam Backup & Replication writes to the Windows event log Veeam Backup (collect it with AMA into Event) and, from 12.1, to syslog with the same ids as instanceId. Ids below are from the Veeam Backup & Replication Event Reference.

// Veeam audit events: 10050 restore point deleted, 23050 job settings updated, 23090 job deleted,
// 28200 repository deleted, 30200 scale-out repository deleted, 31400 user/group deleted,
// 40201 MFA disabled, 40204 MFA for user disabled, 42401 four-eyes authorisation disabled, 41800 attempt to delete backup failed
Event
| where TimeGenerated > ago(30d) and EventLog == "Veeam Backup"
| where EventID in (10050, 23050, 23090, 28200, 30200, 31400, 40201, 40204, 42401, 41800)
| project TimeGenerated, Computer, EventID, RenderedDescription
Syslog
| where TimeGenerated > ago(30d) and SyslogMessage has "enterpriseId=\"31023\""
| where SyslogMessage matches regex @"instanceId=(10050|23050|23090|28200|30200|31400|40201|40204|42401|41800)\b"
| project TimeGenerated, Computer, SyslogMessage
// Interactive and RDP logons to the backup servers, and backup-admin logons anywhere else
SecurityEvent
| where TimeGenerated > ago(30d) and EventID == 4624 and LogonType in (2, 10)
| where Computer in~ ("<vbr01>", "<vbr-proxy01>") or TargetUserName in~ ("<svc-veeam>", "<backup-admin>")
| summarize Logons=count(), First=min(TimeGenerated) by Computer, TargetUserName, IpAddress, LogonType
| order by First asc
T1078 T1490 Tuning: Retention policy runs delete restore points on every job cycle; the finding is a deletion outside the job schedule, or by an interactive user rather than the Veeam service account. Backup admins log on to the console daily; a new source IP or a non-backup account is the lead.

Stage 7 · ExfiltrationTransfer tools, cloud-storage destinations and archive staging

Why: rclone to MEGA is still the most common path, but Dropbox, pCloud, Backblaze B2, Gofile and temp.sh are the alternates, and the data is usually archived with 7-Zip or WinRAR first. A hit makes this a data breach and the leak-site threat real.

DeviceNetworkEvents has no byte counts. Egress volume per host comes from the firewall or proxy: in Sentinel, CommonSecurityLog | summarize sum(SentBytes) by SourceIP, DestinationIP over the dwell window.

DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("rclone.exe","megasync.exe","megacmd.exe","winscp.exe","filezilla.exe","restic.exe","curl.exe")
     or ProcessCommandLine has_any ("rclone", "mega-put", "--transfers", "b2 upload", "ftp://")
     or (FileName in~ ("7z.exe","7za.exe","rar.exe","winrar.exe") and ProcessCommandLine has " a " and ProcessCommandLine has_any ("-p", "-hp", "-mhe", "-r", "-v"))
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemoteUrl has_any ("mega.nz","mega.io","mega.co.nz","dropbox.com","dropboxapi.com","pcloud.com","backblazeb2.com","backblaze.com","gofile.io","temp.sh","file.io","ufile.io","filetransfer.io","anonfiles.com","transfer.sh","put.io","storj.io","wasabisys.com")
| summarize Connections=count(), First=min(Timestamp) by DeviceName, InitiatingProcessFileName, RemoteUrl
| order by Connections desc
// Archives created in bulk on file servers
DeviceFileEvents
| where Timestamp > ago(14d) and ActionType == "FileCreated" and (FileName endswith ".7z" or FileName endswith ".rar" or FileName endswith ".zip" or FileName endswith ".001")
| summarize Archives=count(), Size=sum(FileSize) by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, bin(Timestamp, 1h)
| where Archives > 20 or Size > 5000000000
T1567.002 T1560.001 T1048 Tuning: Corporate Dropbox, Backblaze or Wasabi backup agents hit the same domains from every host; filter on the initiating process and account. Users zipping a project folder trip the archive count; the attacker's archives are on file servers, by an admin account, often at night, and split into volumes.

Stage 8 · Impact preparationShadow-copy, boot-recovery and backup-catalog deletion

Why: These run minutes before encryption. A hit with no encryption yet means contain now.
DeviceProcessEvents
| where Timestamp > ago(3d)
| where (FileName =~ "vssadmin.exe" and ProcessCommandLine has_all ("delete","shadows"))
     or (FileName =~ "vssadmin.exe" and ProcessCommandLine has_all ("resize","shadowstorage"))
     or (FileName =~ "wmic.exe" and ProcessCommandLine has_all ("shadowcopy","delete"))
     or (FileName =~ "bcdedit.exe" and ProcessCommandLine has_any ("recoveryenabled", "bootstatuspolicy"))
     or (FileName =~ "wbadmin.exe" and ProcessCommandLine has_all ("delete","catalog"))
     or (FileName =~ "powershell.exe" and ProcessCommandLine has "Win32_ShadowCopy" and ProcessCommandLine has "Delete")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
T1490 Tuning: Some backup products resize shadow storage as part of a job; delete shadows /all from an interactive account has no legitimate use.

Stage 8 · Impact preparationSecurity tooling stopped and GPO changes

Why: Defender exclusions, real-time protection off and services stopped precede the payload; a new or modified GPO is how it is pushed estate-wide. A GPO change is evidence of the deployment channel from the T+45–60 step.
DeviceProcessEvents
| where Timestamp > ago(3d)
| where ProcessCommandLine has_any ("Set-MpPreference", "DisableRealtimeMonitoring", "Add-MpPreference -ExclusionPath")
     or (FileName in~ ("net.exe","net1.exe","sc.exe") and ProcessCommandLine has_any ("stop", "config", "delete") and ProcessCommandLine has_any ("WinDefend", "Sense", "MsMpSvc", "SepMasterService", "CSFalconService", "SentinelAgent", "veeam", "sql", "vss", "backup"))
     or (FileName =~ "taskkill.exe" and ProcessCommandLine has_any ("sql", "veeam", "backup", "/im"))
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
DeviceRegistryEvents
| where Timestamp > ago(3d) and RegistryKey has @"Windows Defender" and RegistryValueName in~ ("DisableAntiSpyware", "DisableRealtimeMonitoring", "TamperProtection")
| project Timestamp, DeviceName, InitiatingProcessAccountName, RegistryKey, RegistryValueName, RegistryValueData
// Sentinel: GPO objects created or modified (needs Directory Service Changes auditing on DCs)
SecurityEvent
| where TimeGenerated > ago(7d) and EventID in (5136, 5137) and ObjectClass == "groupPolicyContainer"
| project TimeGenerated, Computer, SubjectUserName, ObjectDN, AttributeLDAPDisplayName, AttributeValue
T1562.001 T1484.001 T1489 Tuning: Patch cycles and DBAs stop SQL and backup services; GPO edits happen daily in a large estate. Match each hit to a change ticket; the finding is a stop command across many hosts from one account, or a GPO edit by an account that does not administer GPOs.

Stage 9 · EncryptionMass file changes by one process; ransom notes

Why: The process doing the writing is patient zero's payload; the note name identifies the variant.
DeviceFileEvents
| where Timestamp > ago(1d) and ActionType in ("FileRenamed","FileModified")
| summarize Files=count(), Extensions=dcount(FileName) by DeviceName, InitiatingProcessFileName, InitiatingProcessSHA256, bin(Timestamp, 5m)
| where Files > 500 | order by Files desc
DeviceFileEvents
| where Timestamp > ago(1d) and ActionType == "FileCreated"
| where FileName matches regex @"(?i)^(readme|restore|recover|decrypt|how_to|how-to|!!!|_readme|unlock).*\.(txt|html?|hta)$"
| summarize Hosts=dcount(DeviceName), Notes=count(), Example=any(FolderPath) by FileName, InitiatingProcessFileName
T1486 Tuning: Backup agents, DCs (SYSVOL replication), build servers, compilers, Outlook and OneDrive sync exceed 500 file writes in five minutes on their own. Exclude by InitiatingProcessSHA256 of your known software, not by host; the payload is an unsigned binary with no history in DeviceFileCertificateInfo.

Stage 10 · ExtortionRansom contact by mail and the note's contact details

Why: The first contact usually arrives by email to executives or the generic mailbox, from a privacy mail provider, within hours of encryption; leak-site posts follow days later. Finding every message tells counsel who has been contacted and gives the negotiator the case id and channel from the note.

Leak-site listing is not visible in any Microsoft table; threat intel or the IR firm monitors the group's site. The note itself: getfile in Live Response, then grep the .onion URL, Tox id and case id.

EmailEvents
| where Timestamp > ago(7d) and EmailDirection == "Inbound"
| where SenderFromDomain in~ ("onionmail.org","proton.me","protonmail.com","tutanota.com","tuta.io","cock.li","mail2tor.com","skiff.com")
     or Subject has_any ("your network", "your files", "encrypted", "decrypt", "negotiat", "data leak", "stolen", "ransom", "your company")
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction, NetworkMessageId
EmailUrlInfo
| where Timestamp > ago(7d) and (Url has ".onion" or Url has "tox.chat")
| join kind=inner (EmailEvents | project NetworkMessageId, SenderFromAddress, RecipientEmailAddress, Subject) on NetworkMessageId
T1657 Tuning: Legitimate mail from Proton or Tuta users exists; the subject filter and a .onion link are what separate the contact from ordinary mail. Expect phishing that imitates the extortionist once the incident is public.

Act

Broad first, surgical once the scope is known. Collect before you stop anything; compromised hosts are rebuilt, not cleaned.

T+15–30 · IsolateIsolate every host the attacker could have reached

Why: isolating only the alerting host tells the operator they are found while the rest of their footholds stay reachable. The API isolates one device per call: run it for every device the hunts above returned, not one per hour.

Console: device page › Isolate device (Full). Live Response keeps working on an isolated device.

POST https://api.security.microsoft.com/api/machines/{id}/isolate
{"Comment": "IR case #<n>", "IsolationType": "Full"}
T1489

T+15–30 · IsolateContain the accounts the attacker holds, and let attack disruption run

Why: Contain user blocks the account on every onboarded device (SMB, RDP, service logons) within seconds, without waiting for AD replication or a password reset to propagate; it also covers the window before Kill Authentication is complete. Automatic attack disruption does the same on its own when Defender XDR correlates a human-operated ransomware incident — it isolates devices and contains users and will have started before you open the console. Do not undo its actions during triage; read them in the incident's action centre.

Incident page › the user entity › Contain user (needs Defender for Identity and the MDE sensor at version 10.8470 or later; AD accounts are disabled on the DC by the MDI sensor and in Entra if synced). Attack disruption: Settings › Microsoft Defender XDR › Identity automated response; leave it on. Under Hunt & Act, every account the stage 4–5 hunts returned is contained here, then reset in Kill Authentication.

T1078.002

T+15–30 · IsolateBlock the payload tenant-wide

Why: a custom indicator stops the same payload on hosts you have not found yet. For C2, use IpAddress or DomainName with action Block (needs network protection in block mode). Set an expiry: attacker infrastructure rotates.
POST https://api.security.microsoft.com/api/indicators
{"indicatorValue": "<sha256>", "indicatorType": "FileSha256",
 "action": "AlertAndBlock", "title": "IR case #<n>",
 "description": "Ransomware payload", "expirationTime": "<yyyy-mm-dd>T00:00:00Z"}
T1486

T+15–30 · CollectCollect before you stop anything

Why: killing the payload or rebuilding the host destroys the memory and persistence you need to scope the rest of the estate. Memory comes from Magnet RESPONSE 1.7.2 d315c63d1ad4b89e03c7688b29169e977c2abc4559c23b9f6b2282f3c91a6c7d; persistence from Get-PersistenceSnapshot.ps1 a9534865f9e8e7b1f5077b4e1cfd8c29e7e32f6e9e49a4918ce4f8fb713e64df. Both are pushed through the Live Response library; putfile needs the file uploaded to the library first (Settings › Endpoints › Response actions). Allow unsigned script execution in Advanced features for the duration of the case, then turn it off.

Console: device page › Collect investigation package. Then in Live Response (library files uploaded first):

processes
connections
persistence
scheduledtasks
services
getfile "C:\path\to\ransom-note.txt"
putfile MagnetRESPONSEv172_Self_Extracting_Archive.exe
run MagnetRESPONSEv172_Self_Extracting_Archive.exe -parameters "/accepteula /unattended /output:C:\IR\magnet /capturesystemfiles /captureram /capturepagefile"
run Get-PersistenceSnapshot.ps1 -parameters "-Zip -OutputPath C:\IR\persistence"
getfile "C:\IR\persistence\<host>_<timestamp>.zip"

T+15–30 · StopStop the running payload

Why: this stops execution and keeps the file as evidence. It is not the fix: the host is rebuilt from a known-good image.
remediate process <pid>
T1486

Day 1–7 · ScopedRelease hosts one at a time, after the eradication gate

Why: releasing isolation reconnects the host. Do it per host, once it is rebuilt and the restore gate is met — never in bulk while the scope is still open.

Console: device page › Release from isolation.

POST https://api.security.microsoft.com/api/machines/{id}/unisolate
{"Comment": "IR case #<n>: rebuilt, gate met"}

By Scenario: What Changes

The first-72-hours flow above is the universal path. These are the deltas — what you do differently, and first, when the incident is shaped like this. Each has its own TheHive case template.

1. Encryption in Progress

Indicators: ransom notes appearing, mass file renames, canary-token hits, file servers at full disk and CPU, users reporting files that will not open.

Variation: Speed beats precision. Run Kill Internet and isolate segments now and accept the business outage — every minute is more encrypted data. Scope after the spread stops. Template: ransomware-resilience.

2. Discovered Before Encryption

Indicators: C2 beacons or unexpected RMM tools, AD reconnaissance (BloodHound, AdFind), new admin accounts, attempts to delete shadow copies, backup-console logins — and nothing encrypted yet.

Variation: Don't tip them off one host at a time. Killing a single beacon tells the operator they are found while their other footholds stay live, and many then encrypt early. Contain at least as wide as they could be, in one move: cut estate or segment egress, revoke all sessions and disable the accounts seen, then map every foothold, account and persistence mechanism behind that cut — minutes to hours, not days. Go surgical only once the scope is known. Exception: anything destructive in progress — encryption starting, backup deletion, payload staging (GPO changes, PsExec copies to many hosts) — means contain immediately, at the widest level, scoped or not. Template: ransomware-pre-encryption.

3. Data Theft Without Encryption

Indicators: an extortion email or call with sample files, a leak-site listing, nothing encrypted. Vishing variant (Silent Ransom / Luna Moth): a user was called by "IT support" and installed a legitimate remote-access tool — no malware anywhere.

Variation: Backups do not help: this is a confidentiality incident. First validate the claim — do the samples come from us, and from which system? Then scope what left and whose data it is; the notification clocks started when you became aware. Cut the remote-access tool's path and every other foothold in one pass: block its egress, revoke the user's sessions (a reset alone leaves tokens valid), reset the credentials, and rebuild the hosts it ran on rather than uninstalling it. Nobody talks to the extortionist except through counsel or an insurer-approved negotiator. Template: ransomware-data-extortion.

4. Hypervisor / NAS Encryption

Indicators: VMs powered off at once, .vmdk files renamed or unreadable, SSH enabled on ESXi outside a change, lockdown mode disabled, VIB acceptance level changed, NAS shares encrypted.

Variation: No EDR runs here, so the host logs are the evidence — collect them before anything else, and do not reboot: without persistent scratch or remote syslog, ESXi logs are gone after a restart. vm-support bundles every log with a manifest; a VM snapshot with memory preserves each guest's running state. Note that commands run as ssh host cmd never reach shell.log, so an empty shell log does not mean nothing ran — auth.log and the VOB audit records in vobd.log are the authoritative trail. Work out how they got in (vCenter credentials, the AD "ESX Admins" group — CVE-2024-37085), then freeze the encryptor, rotate root and vCenter SSO, disable SSH and the shell and re-enter lockdown. The full command set, stage by stage, is the Linux / ESXi tab under Hunt & Act; on Linux servers and x86 NAS run get-persistence-snapshot.sh 8fe386a7d6ebd50225b04ad83581ee3e5d504a10a4263253b5a11b8a61eeca67 and the Velociraptor Linux.Sys.Crontab, Linux.Sys.Services, Linux.Ssh.AuthorizedKeys, Linux.Syslog.SSHLogin and Linux.Search.FileFinder artifacts; ESXi has no client, so it is shell only. Template: ransomware-hypervisor.

# copy before anything else
vm-support -w /vmfs/volumes/<clean-datastore>/ir
tar czf /vmfs/volumes/<clean-datastore>/ir/logs.tgz /var/run/log /etc/rc.local.d /etc/ssh
# then triage
esxcli system account list
esxcli software acceptance get
esxcli software vib list
esxcli system settings kernel list -o execInstalledOnly
grep -hE "esx.audit.(ssh|shell).enabled|lockdownmode" /var/run/log/vobd.log*
# then close the door
vim-cmd hostsvc/disable_ssh ; vim-cmd hostsvc/disable_esx_shell ; vim-cmd vimsvc/auth/lockdown_mode_enter

5. Backups Destroyed or Tampered

Indicators: deleted restore points, shortened retention, disabled backup jobs, immutability errors, backup-console logins from unexpected accounts — with or without encryption elsewhere.

Variation: Treat it as the pre-encryption signal it usually is: encryption tends to follow. Sever backup admin from production and change its credentials now, then run Scenario 2's scoping. If no clean copy survives, tell the board the same day — it changes the recovery estimate and the ransom question. Handled with the ransomware-pre-encryption template, or the ransomware-resilience template if encryption has already started.

6. Cloud / SaaS Data Held Hostage

Indicators: mass modification or deletion in OneDrive or SharePoint, S3 objects re-encrypted with a customer-provided key (SSE-C) or deleted, a ransom note in a bucket.

Variation: Containment is identity, not network: revoke the compromised user's or app's sessions and keys (Identity Breach Response for Microsoft 365, Cloud Incident Response for AWS, Azure and GCP storage). Recovery comes from versioning: OneDrive and SharePoint restore to an earlier point in time (up to 30 days), S3 from object versions or Object Lock. Handled with the identity-breach-response template plus a Recovery task for the restore.

aws iam update-access-key --user-name <user> --access-key-id <key> --status Inactive
aws s3api list-object-versions --bucket <bucket> --prefix <path> --max-items 20

Extortion: Negotiation and the Leak Site

Applies to every scenario with a ransom demand or a leak threat.
Nobody replies to the attacker directly
Contact goes through counsel or an insurer-approved negotiator. Why: an early reply reveals urgency, what you know and whether backups survived, and can start a deadline you did not choose.
Screen for sanctions before any payment is discussed
Check the group and the wallet against OFAC and the EU consolidated sanctions list. Why: paying a sanctioned party is illegal regardless of the business pressure, and insurers will not cover it.
Proof of life and test decryption before any number is discussed
The negotiator asks for two things before price: proof that the attacker holds what they claim, and proof that their decryptor works. For data: a file listing or tree of what was taken, then two or three specific files you choose (not their sample), checked against the originating system and its file-server audit. For encryption: two or three encrypted files you choose from different hosts and extensions, decrypted and returned; compare hashes against the pre-incident backup copy where one exists. Why: some groups bluff on exfiltration, some decryptors do not work on every file type or large files, and the samples the attacker picks are the ones they know will decrypt. The result goes into the board paper as a fact, not a hope.
Treat a decryptor as untrusted software
If a key or decryptor is obtained — paid, from law enforcement or from No More Ransom — it runs only on copies. Snapshot or image every encrypted volume first; keep the encrypted originals until the restore is verified. Run the decryptor on an isolated test host against copies of a few hundred files of each type, hash the results against known-good versions where available, and check the binary itself (hash, signature, sandbox detonation) before it touches production. Expect it to be slow, single-threaded and to fail on some files; plan for backup restore to remain the primary path and the decryptor to fill gaps. Why: attacker-supplied decryptors have shipped with bugs that corrupt files and, in some cases, with malware; the originals and the snapshot are the only way back if it goes wrong.
# copies only, never the originals
robocopy \\fs01\share\encrypted D:\decrypt-test /E /COPY:DAT /R:1 /W:1
Get-FileHash D:\decrypt-test\sample\* | Export-Csv before.csv
# run the decryptor on D:\decrypt-test only, then
Get-FileHash D:\decrypt-test\sample\* | Export-Csv after.csv
Compare-Object (Import-Csv known-good.csv) (Import-Csv after.csv) -Property Hash
Watch the leak site and prepare for publication
Threat intel monitors the group's leak site for your name and countdown. Prepare customer, staff and press statements for the day the data appears. Why: paying does not guarantee deletion — plan as if the data will be published.