How to detect ransomware kill chain attacks

Threat snapshot

Ransomware is not a single event. It is a sequence of attacker decisions that unfolds over hours, days, or weeks before any file gets encrypted. By the time the ransom note appears, the attacker has already established a foothold, obtained credentials, moved across the environment, disabled defenses, and positioned the encryptor on every target host. The encryption itself is the last fifteen minutes of an operation that may have started a month earlier.

That sequence is the kill chain, and it is the right unit of detection. A SIEM that alerts only on encryption activity is a smoke alarm that sounds after the fire has spread through three floors. Catching ransomware at the delivery or execution stage means the attacker has not yet obtained the access they need to do real damage. Catching it at lateral movement means they have not yet reached all their targets. Even catching the defense evasion step, the phase where they disable Defender and delete shadow copies, still leaves time to isolate affected systems before encryption completes.

Log360 covers all five stages of the ransomware kill chain: delivery, execution, defense evasion, lateral movement, and impact. Across those stages it maps 331 detection rules to ransomware-relevant behavior spanning Windows endpoints, Active Directory, network infrastructure, and cloud environments. This page walks through what Log360 monitors at each stage, what the attack sequences look like in the logs, and how a SOC team should move when any of these rules fire.

Ransomware kill chain, at a glance

How ransomware kill chain attacks work

Modern ransomware operations follow a consistent playbook across all five stages. The breakdown below covers what happens at each stage and the specific log signals each phase generates.

Stage 1: Delivery and initial access

Ransomware groups get into environments through phishing emails with malicious attachments, exploitation of public-facing applications, stolen credentials purchased from initial access brokers, or exposed remote services like RDP and VPN. The access method determines which log sources carry the earliest signals. A phishing delivery shows up in email gateway logs and endpoint process creation events when the Office document spawns PowerShell. An RDP brute-force entry appears in Windows Security Event 4625 sequences before the successful 4624 event.

Log signals: Firewall and IDS/IPS alerts for external exploitation attempts; Windows Security Event 4625 (failed logon) sequences preceding 4624 (successful logon); endpoint events showing Office applications spawning command interpreters; VPN authentication failure clusters from a single source IP.

Stage 2: Execution

Once inside, the attacker runs their tooling. Ransomware operators heavily use PowerShell for download cradles, reconnaissance scripts, and remote execution. Encoded commands, download-and-execute patterns, and AMSI bypass attempts are consistent markers at this stage.

Log signals: Windows Security Event 4688 or Sysmon Event 1 showing PowerShell with encoded command parameters (-enc, -encodedcommand); download cradle patterns using IEX, Invoke-WebRequest, or DownloadString; AMSI bypass attempts visible in PowerShell script block logging (Event 4104).

Stage 3: Defense evasion

Before spreading and before encrypting, ransomware operators systematically dismantle defenses. Disabling Windows Defender, adding exclusion paths, stopping EDR services, clearing event logs, and disabling the firewall all generate Security or System event log entries. The defense evasion phase is also when shadow copies are deleted and boot configuration is tampered with, removing the recovery options that would let a victim restore without paying.

Log signals: Windows Security Events 4719 (audit policy changed) and 1102 (audit log cleared); registry writes to Defender exclusion paths; sc stop or net stop commands targeting security services; vssadmin delete shadows or wmic shadowcopy delete in process creation logs; bcdedit /set {default} recoveryenabled no.

Stage 4: Lateral movement

Once defenses are down, the attacker spreads to as many hosts as possible before triggering encryption. PsExec, admin shares, WMI remote execution, and SMB-based file copy are the primary tools. On domain-joined networks, compromised domain administrator credentials make lateral movement trivially easy, since those credentials authenticate to every host without further exploitation.

Log signals: Windows Security Events 4624 (Type 3 logons from unusual sources), 5140 (network share access), and 4648 (explicit credential use); process creation events showing PsExec or PSEXESVC service installations on remote hosts; WMI activity events; Event 7045 (new service installed) appearing across multiple hosts in a short window.

Stage 5: Impact

The final phase covers file encryption, service stopping, and any remaining recovery sabotage. Ransomware encryptors generate distinctive file system behavior: mass file renames with new extensions, creation of identically named ransom note files across hundreds of directories, and high-velocity file modification events that deviate from any normal baseline.

Log signals: High-velocity Windows file audit events (Event 4663) for mass file modifications or renames; bulk creation of uniformly named files matching ransom note patterns; Windows System Event 7036 (service stopped) firing repeatedly for database and application services; the RstrtMgr.dll load pattern used by encryptors to close file handles before encryption.

Real-world campaigns

LockBit and the five-stage playbook

LockBit affiliates follow the kill chain with near-mechanical consistency. Initial access arrives via purchased RDP credentials or phishing. Execution is handled through PowerShell and Cobalt Strike beacons. Defense evasion includes Defender disabling, shadow copy deletion, and event log clearing. Lateral movement uses domain admin credentials obtained through credential dumping to spread via PsExec or SMB. Impact follows within hours of lateral movement completion. The entire sequence from initial access to encryption has been completed in under four hours in documented incidents, making every detection stage time-critical.

Ryuk and RagnarLocker: manual operation, prolonged dwell

Ryuk and RagnarLocker affiliates operate more slowly, with dwell times measured in days or weeks. They take time to enumerate the environment thoroughly, identify backup infrastructure, and ensure all high-value targets are reachable before deploying the encryptor. Ryuk uses a distinctive Wake-on-LAN broadcast to wake sleeping machines before encryption. RagnarLocker operators have been documented running the encryptor inside a virtual machine to evade endpoint detection, which produces an anomalous process tree from a hypervisor process rather than a standard encryptor binary.

Double extortion and data staging before encryption

Groups including BlackCat/ALPHV, Cl0p, and BlackSuit add a data exfiltration stage before encryption. Files are staged in compressed archives and exfiltrated to attacker-controlled cloud storage or file sharing services. This behavior appears in process creation logs as archive utility usage on large file sets, followed by unusual outbound traffic volumes. The exfiltration and encryption stages may be separated by hours, giving a SOC team that catches the staging activity a window to respond before encryption begins.

Business impact

• Operational shutdown across the entire environment: Because lateral movement is completed before encryption begins, ransomware typically encrypts every domain-joined host simultaneously. The operational impact is not a single server going offline; it is the entire Windows estate becoming unavailable within minutes.
• Recovery is measured in weeks, not hours: Even organizations with mature backup programs face multi-week recovery timelines when shadow copies and backup agents have been destroyed in the defense evasion phase. Rebuilding domain controllers, restoring from off-site backups, and validating data integrity is a slow process, and every day of downtime carries direct revenue and productivity costs.
• Double extortion doubles the leverage: Groups that exfiltrate data before encrypting can publish sensitive customer, patient, or financial records even if the victim rebuilds from backups without paying. The data exposure risk creates regulatory notification obligations and reputational consequences independent of whether the ransom is paid.
• Each missed kill chain stage narrows the response window: A detection at the delivery stage leaves days to respond. A detection at lateral movement leaves hours. A detection only at the impact stage, once encryption is running, leaves minutes. The financial difference between catching this at stage one versus stage five is measured in millions of dollars in recovery cost and downtime.

Detecting ransomware kill chain attacks with Log360

Log360's 331 detection rules for the ransomware kill chain are organized across all five stages. For these rules to fire correctly, Windows Security audit logging must be enabled for Process Creation, Object Access, System events, and Logon/Logoff categories. Sysmon deployment with process creation, registry, and network connection logging significantly strengthens coverage, particularly for the execution and defense evasion stages.

Stage 1: Delivery and execution rules

Stage 2: Defense evasion rules

Stage 3: Lateral movement rules

Stage 4: Impact rules

Attack chain visibility

The sequence below represents a typical human-operated ransomware deployment against a Windows/AD environment, from initial execution through to active encryption.

Sequence A: Full kill chain from PowerShell foothold to encryption

Sequence B: Double extortion variant with pre-encryption data staging

Investigation playbook

Ransomware kill chain alerts require immediate action at every stage. The time available to contain the attack shrinks dramatically with each stage. An alert at the execution stage leaves hours. An alert at the lateral movement stage leaves minutes to hours. An alert at the impact stage means encryption may already be running and containment is the only remaining action that limits damage.

Step 1: Identify which stage fired and calibrate urgency

Step 2: Identify patient zero and the lateral movement blast radius

• In Log360, use the alert timeline to identify the earliest kill chain event. The host where the first PowerShell download or C2 beacon appeared is patient zero. Every subsequent event should be traced forward from that host.
• Query Windows Security Event 4624 (Type 3) from the patient zero host's account across all hosts in the domain for the prior 24 hours. Every host where that account authenticated is a potential lateral movement target and should be treated as potentially compromised until verified clean.
• Query Event 7045 (new service installed) domain-wide for the lateral movement window. PsExec creates a temporary service on each target host; a cluster of 7045 events across many hosts in a short window confirms automated lateral movement.
• Identify which accounts were used for lateral movement. If a domain admin account was used, assume all domain-joined hosts are reachable and treat the scope as the entire Windows estate.

Step 3: Investigate using the Incident Workbench

• Open patient zero in the Incident Workbench. Use the Process Analytics tab to build the full process tree from the initial PowerShell event forward through every child process. This reconstructs the attacker's execution sequence and identifies the exact tools used at each stage.
• Use the User Analytics tab to review the account used for lateral movement. If that account shows its first-ever logon to multiple hosts within a short window, the credential was being abused at scale, not used legitimately.
• Use Advanced Threat Analytics on any external IPs involved in the C2 communication or data exfiltration to check threat feed risk scores and identify whether the infrastructure is associated with known ransomware operator infrastructure.
• Pin the Incident Workbench session to an incident record before making any remediation changes. The process tree and event timeline are the primary forensic evidence for post-incident reporting, insurance claims, and any regulatory breach notification assessment.

Step 4: Verify backup integrity before declaring the environment clean

• Query all vssadmin and wbadmin process creation events from the kill chain window. If shadow copy deletion commands ran successfully, in-host recovery is not available. Determine whether off-site backups exist and whether backup agent services on backup servers were also targeted.
• Check the Veeam Backup Database Suspicious Query and VeeamBackup Database Credentials Dump rules in the Log360 alert history. If these fired, the attacker targeted backup infrastructure directly and off-site backup integrity must be verified before assuming recovery is possible.
• Do not reconnect any host to the network until it has been verified clean by forensic review. A host that was reached during lateral movement but not yet encrypted may still be running dormant ransomware that will activate on reconnection.

Response and remediation

Immediate containment

• Network isolation first, investigation second: For any host showing active encryption (Suspicious Bulk File Modifications rule firing), remove it from the network before attempting to identify the encryptor process. Every second of network connectivity during an active ransomware deployment is additional dwell time for lateral movement to reach new hosts.
• Segment the domain controller immediately: If lateral movement is confirmed, the DC should be isolated from workstation subnets while allowing essential authentication traffic only from designated admin hosts. Ransomware operators with domain admin access can use the DC to reach every host in the domain; isolating it limits the blast radius.
• Reset all privileged credentials: Perform a double krbtgt reset, rotate all Tier-0 account passwords, and force re-authentication for all service accounts. If the attacker obtained domain admin credentials, those credentials must be treated as fully compromised regardless of whether the encryption phase was contained.
• Preserve evidence before remediation: Before wiping and rebuilding any host, take a memory image and a full disk image. The process tree visible in memory and the encryptor binary on disk are required for attribution, insurance claims, and law enforcement engagement.

Response actions by stage

Post-incident hardening

• Deploy Sysmon with a comprehensive configuration on all endpoints: Many of the highest-value kill chain signals come from Sysmon Event 1 (process creation with full command line) and Sysmon Event 13 (registry value set). Windows Security audit logging alone misses command-line parameters that are essential for detecting encoded PowerShell, download cradles, and shadow copy deletion commands.
• Enable PowerShell Script Block Logging (Event 4104) on all endpoints: This captures deobfuscated PowerShell content even when the attacker uses encoding or obfuscation. It is the single most effective additional log source for detecting the execution stage of ransomware kill chains.
• Protect backup infrastructure as a Tier-0 asset: Veeam servers, backup repositories, and off-site backup agents should be isolated in a separate network segment with no inbound access from domain-joined workstations. The documented targeting of Veeam infrastructure by ransomware groups means any backup server reachable from a compromised domain admin account should be treated as a ransomware target.
• Implement a canary file monitoring strategy: Place uniquely named files in high-value directories and configure Log360 to alert immediately on any access or modification of those files. Ransomware encryptors targeting directories alphabetically will hit canary files at predictable points, providing an additional early warning signal for active encryption.

False positive tuning