At 02:14 a local hospital’s help desk logged a spike in “file access denied” tickets from radiology. By 02:41 the shared imaging drive returned locked extensions. The SOC later pulled three days of Windows Security, Sysmon, and VPN logs and found the encryption wave had clear precursors: a dormant service account logged on from a jump host, PowerShell spawned under that account with encoded arguments, then volume shadow copy deletions on two file servers. The encryption tools arrived late. The staging sequence sat in the logs for hours.
Ransomware volume keeps climbing across enterprise and industrial environments. Microsoft’s recent waves of patched flaws raise the odds that opportunistic crews will probe freshly disclosed paths. Your advantage is still chronological: attackers leave ordered footprints in authentication, process, and file telemetry long before payload delivery. This article walks through how to turn those footprints into detections your analysts can run the same day.
Start from the question logs can answer
Threat detection from logs works when you ask a concrete operational question. For ransomware staging the useful question is: which identity gained unusual execution rights on a high-value host within a short window?
That question forces three log planes into one timeline:
- Identity and session logs — interactive, remote, and service logons; MFA outcomes; conditional access failures
- Host execution logs — process creation, parent-child trees, script interpreters, living-off-the-land binaries
- Change and recovery logs — shadow copy deletion, backup agent stops, scheduled task creation, service installs
Keep network flow and firewall data as enrichment. The primary signal for this hunt lives on the host and in the identity provider.
Build a minimal correlation spine
Most SIEM noise comes from single-field alerts. Staging detection needs a short join key and a hard time bound.
Join keys that survive rotation
Prefer keys attackers struggle to randomize every hop:
- Normalized username (domain\user or UPN)
- Host name or asset ID for the target system
- Logon ID / session ID where Windows Security events expose it
- Parent process GUID when Sysmon or equivalent EDR telemetry is present
IP addresses help for VPN and RDP context. Treat them as secondary joins because cloud exits and carrier NAT rotate them.
A practical 90-minute window
Use a rolling 90-minute correlation window for the core chain: unusual logon → interpreter or LOLBin → recovery sabotage. Extend to 24 hours only after the chain fires, when you need dwell-time reconstruction. Shorter windows cut false positives from routine admin work; longer replay windows support incident scoping.
Detection sequence worth encoding
Below is a sequence many extortion crews still follow on Windows estates. Map each step to concrete fields your collectors already store.
Step 1 — Spot the odd logon
Watch for service or admin accounts authenticating from unexpected sources:
- Windows Security Event ID 4624 with Logon Type 3, 10, or 2 for privileged accounts outside change windows
- Event ID 4648 (explicit credentials) when a user launches a process as another account
- Entra ID or Okta sign-in logs showing impossible travel, new ASN, or disabled MFA for break-glass accounts
Example triage rule: privileged account + first-seen source host in 30 days + logon outside approved jump hosts.
Step 2 — Attach process creation to that session
Within the same Logon ID or within five minutes on the same host, require process creation evidence:
- Sysmon Event ID 1 or Windows 4688 for powershell.exe, pwsh.exe, cmd.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe
- Parent process outside expected management tools (for example, winword.exe or outlook.exe spawning interpreters)
- Command lines containing -enc, FromBase64String, IEX, Invoke-WebRequest, or remote share paths under admin$ or C$
Cloud identity research keeps pushing behavioral clustering for accounts. Apply the same idea on-prem: cluster each service account’s normal parent-child process pairs for two weeks, then alert on first-seen pairs with high privilege.
Step 3 — Flag recovery sabotage as the confirmation beat
Encryption often follows attempts to remove restore options. Elevate severity when the same identity or host shows:
- vssadmin, wmic, or PowerShell commands deleting shadow copies
- Stop or uninstall events for backup agents
- New scheduled tasks (Event ID 4698) that run encryption helpers or rename scripts
- Sudden mass file renames or ACL changes on file servers in security or file audit logs
One hospital case reconstructed the order as 4624 → Sysmon 1 (encoded PowerShell) → shadow copy wipe → share encryption. The SIEM already held every event. No rule joined them until after downtime started.
Real-world scenarios to rehearse
Ransomware staging on a file server
Actors land on a user workstation, dump or reuse a service account, then RDP or WinRM to the file server. Logs that matter: workstation process creation for credential tools, domain controller 4624/4769 for the service account, file server 4624 Logon Type 10, then vssadmin on the file server. Response starts at the service account disable and file server isolation, not at the first encrypted extension.
ICS-adjacent Windows jump hosts
Industrial automation threat reports for mid-2026 keep highlighting IT/OT bridging systems. Jump hosts that reach PLCs and historians often have thin logging. Require process creation and privileged logon auditing on those jump boxes even when OT networks themselves stay quiet. A successful staging sequence on the jump host is your early warning that production assets are next.
When malware analysis gets derailed
Techniques that confuse AI-assisted malware reverse engineering still leave host telemetry. If static analysis stalls on obfuscation tricks, lean on your execution trail: who launched the sample, which child processes appeared, which network destinations followed within the session. Log analysis remains the operational path when lab tooling gets noisy.
Implementation details that keep detections honest
- Normalize account names once. Collapse MACHINE$ vs domain forms and strip UPN suffixes inconsistently applied by VPN brokers. Broken joins are the top reason staging chains miss.
- Preserve command lines. Process creation without command-line auditing blinds you to encoded PowerShell. Enable it on Tier 0 and Tier 1 assets first.
- Clock-sync every collector. Correlate with NTP-disciplined timestamps. A five-minute skew between domain controllers and endpoints shatters session joins.
- Retain raw events for 30 days hot. Ransomware investigations routinely rewind two weeks. Hot search beats cold restore when encryption is active.
- Tag crown-jewel hosts. File servers, backup servers, domain controllers, and OT jump hosts should carry asset tags so the same sequence scores higher there than on a lab PC.
- Tune with change calendars. Suppress known admin automation during approved windows. Keep the rule firing elsewhere.
Response actions when the sequence fires
Treat a full three-step chain as an active intrusion, even before encryption alerts.
- Contain identity first. Disable or reset the implicated account, revoke refresh tokens, and invalidate VPN sessions tied to that identity.
- Isolate the host pair. Quarantine both the source of the odd logon and the target where interpreters ran.
- Freeze recovery systems. Verify backup consoles and repositories for the same identity activity before you trust restores.
- Expand the hunt on the join keys. Replay the username and parent process GUID across the estate for 72 hours. Look for scheduled tasks and new services created under that identity.
- Preserve evidence. Export the correlated event set, memory if policy allows, and EDR timeline before reimaging.
- Brief operations with a timeline. Give IT a minute-by-minute sequence of logon → process → sabotage so they stop treating tickets as isolated outages.
Actionable takeaways for this week
- Write one correlation rule that requires privileged logon + interpreter process + recovery sabotage within 90 minutes on tagged servers.
- Confirm command-line process auditing is on for domain controllers, file servers, and OT jump hosts.
- Build a saved hunt that pivots from username and Logon ID, then practice it on last month’s true-positive incident.
- Add a dashboard tile for shadow copy deletion commands grouped by account. Review it at the start of every shift.
- Align log retention so identity, endpoint, and file server events stay hot for at least 30 days.
Log analysis for threat detection pays off when analysts chase ordered behavior instead of isolated alerts. Ransomware crews still stage through accounts and processes you already record. Wire those records into one sequence, rehearse the response, and you catch the intrusion while shares still open.
