Back to Blog

Ransomware Kill-Chain Detection

Christopher 6 min read
securityransomwarebehavioral-detectioncross-platform

The ET Ducky agent now has four additional cross-platform behavioral rules covering the canonical commodity-ransomware kill chain, plus a meta-rule that fires when two or more chain stages happen on the same process within five minutes. The four base rules each emit their own detection. The meta-rule synthesizes a separate critical alert from those component detections.

The kill chain

Commodity ransomware (the kind that encrypts files and demands payment, distinct from nation-state intrusions) follows a recognizable sequence:

  1. Disable rollback. The strain typically starts by deleting shadow copies on Windows or filesystem snapshots on Linux. Without this step the victim can restore encrypted files from a system snapshot and the ransom payment is unnecessary.
  2. Encrypt files. Each target file is read, encrypted, written, and renamed with a strain-specific extension (.locked, .encrypted, .conti, .lockbit, and roughly 35 others).
  3. Drop a ransom note. The strain creates a file in each affected directory or in the user's home directory with a name like HOW_TO_DECRYPT.txt or _RESTORE_FILES_README.html. The note explains how to pay.

The four base rules cover stages 1, 2, and 3 of that sequence. A separate fourth rule covers cryptominers, which are an adjacent post-compromise threat but not part of the ransomware kill chain.

Rule: shadow-copy-deletion

Severity: Critical. Fires on a single match. Per-process 60-second cooldown after firing.

The rule subscribes to process exec events and matches the command line against a per-OS regex set.

Windows patterns: vssadmin delete shadows, vssadmin resize shadowstorage, wbadmin delete catalog, wbadmin delete systemstatebackup, bcdedit /set bootstatuspolicy ignoreallfailures, bcdedit /set recoveryenabled no, wmic shadowcopy delete, and PowerShell calls of the form Get-WmiObject Win32_ShadowCopy ... .Delete() or Get-CimInstance Win32_ShadowCopy ... Remove-CimInstance.

Linux patterns: btrfs subvolume delete, zfs destroy commands targeting snapshots (the @ pattern in the dataset name is the snapshot indicator), snapper delete, timeshift --delete-all, and rm -rf invocations against /.snapshots, /var/lib/btrfs/snapshots, or /var/snap.

Legitimate maintenance work occasionally runs these commands. The rule does not distinguish a sysadmin clearing space from a ransomware sweep. Severity is set to Critical because the cost of missing a real ransomware deletion is high; an operator can acknowledge a legitimate maintenance event in one click.

Rule: mass-file-rename

Severity: High. Fires when 25 or more rename operations from a single process touch destinations with known ransomware extensions in a 60-second window. Per-process 60-second cooldown after firing.

The extension list contains roughly 40 entries. Generic indicators: .locked, .encrypted, .crypted, .crypt, .crypto, .enc. Pay and ransom indicators: .pay, .payransom, .ransom, .bitcoin. Strain-specific extensions: .wnry (WannaCry), .conti, .lockbit, .ryuk, .dharma, .sodinokibi, .revil, .maze, .doppelpaymer, .egregor, .darkside, .blackmatter, .hive, .cuba, .babuk, .play, .royal, .phobos, .mamba, and others.

The list is curated rather than feed-driven. New strains add new extensions but old ones keep working, so the maintenance overhead is low. Sources blended for the list: the ID Ransomware extension catalog, the NoMoreRansom decryptor index, and public ransomware-family writeups from CrowdStrike and Sophos.

The rule keeps a per-process sliding window of recent renames. When 25 entries in the window all match the extension list, the rule fires once and then suppresses re-fires for 60 seconds.

This rule complements the existing mass-file-access rule. That rule fires on raw file-touch volume regardless of extension; some stealthy strains throttle below its 200-files-in-5-seconds threshold and slip past. The mass-file-rename rule is shape-aware: a process that renames 25 files in 60 seconds where every rename adds an extension from the curated list matches a strong ransomware signature even at low volume. The listed extensions have no documented non-ransomware use on managed endpoints.

Rule: ransom-note-pattern

Severity: Critical. Fires on a single match. Per-process 5-minute cooldown to suppress duplicates when one strain drops the same note across many directories.

The rule subscribes to file create events and matches the basename against a compiled regex of ransom-note name patterns. The regex covers around 20 patterns: HOW_TO_DECRYPT*, HOW_TO_RESTORE*, DECRYPT_INSTRUCTIONS*, README_FOR_DECRYPT*, _RESTORE_FILES_*, RECOVER_MY_FILES*, !INSTRUCTIONS!, RANSOM*.txt, @WanaDecryptor@*, and strain-specific names like LOCKBIT_README, CONTI_README, RYUK_README, REVIL_README.

Security awareness training exercises that drop files named HOW_TO_DECRYPT.txt will fire this rule. The alert can be acknowledged without action when the source is known.

Rule: crypto-miner-heuristic

Severity: High. Per-process 5-minute cooldown after firing.

This rule covers a different threat than ransomware. Cryptocurrency miners run continuously and silently rather than encrypting files; the threat model overlap is that both are post-compromise monetization paths. The rule is included with the H.2 release because the detection vector (command-line shape matching) is identical.

The patterns target argument shapes that have no non-mining use:

Severity is High rather than Critical because legitimate mining workloads exist on some endpoints: a developer testing a miner binary, a homelab Monero rig, security research. The High severity routes the alert through operator review rather than any automated containment path.

The kill-chain meta-rule

Severity: Critical. Fires when two or more of {shadow-copy-deletion, mass-file-rename, ransom-note-pattern} fire on the same process within five minutes. Per-process 10-minute cooldown after firing.

The meta-rule is implemented differently from the four base rules. The base rules subscribe directly to the kernel-event stream (eBPF on Linux, ETW on Windows). The meta-rule subscribes to the rule engine's DetectionEmitted event, which fires after another rule has already emitted a detection. It does not see raw kernel events; it only sees the output of other rules.

When the meta-rule fires it emits a synthetic detection at Critical severity. The detection includes references to the underlying base detections in its evidence list, so the dashboard can show "this kill-chain alert was triggered by these specific component detections" without re-querying the database.

The crypto-miner-heuristic rule is deliberately not part of the kill chain. Miners are an adjacent threat but they do not precede or follow ransomware in any meaningful sequence. Including them would dilute the meta-rule's signal.

The meta-rule produces a single alert that aggregates the underlying component detections rather than three separate toasts. The synthetic detection's evidence list contains references to each contributing base detection, so the dashboard can surface the full chain in one panel.

Cross-platform implementation

All five rules live in ETDucky.Agent.Shared/Services/Rules and share a base class (BehavioralRuleBase). They consume SystemEvent objects, which the eBPF capture engine on Linux and the ETW capture engine on Windows both produce. The only OS-specific code in the rules themselves is in the regex patterns; the shadow-copy-deletion rule has Windows and Linux patterns concatenated into one combined regex with an alternation between the two.

Both platforms register the rules identically in their DI container. The kill-chain meta-rule is registered as a singleton with constructor side effects (its constructor subscribes to the engine event); the host service takes it as a constructor dependency to force eager DI construction so the subscription is in place before the engine starts emitting events.

Where detections appear

Every detection writes a row to AgentBehavioralDetections, the same table the other behavioral rules use. Row-level security applies at the database layer. After the row is persisted, an SSE event named behavioral.detection is pushed to every dashboard tab open in the organization. A toast appears in the top right within seconds of the agent observing the pattern.

The Smart Reports system prompt has been extended with the new rule IDs. Questions like "show me ransomware activity in the last 24 hours" produce a query against AgentBehavioralDetections filtered by RuleId in (mass-file-rename, ransom-note-pattern, shadow-copy-deletion, ransomware-kill-chain). Questions like "any active ransomware right now?" map to a 15-minute window on the ransomware-kill-chain rule specifically.

What is and is not in this release

In: four base rules covering stages 1 through 3 of the ransomware kill chain plus cryptominer execution, the meta-rule that synthesizes a kill-chain alert from base detections, and Smart Reports schema integration.

Not in: file-write entropy analysis. Encrypted output has high entropy (around 7.99 bits per byte versus typical office documents at 4 to 6). Detecting that requires file-content sampling on write, which the current eBPF and ETW capture engines do not do. A small extension that hashes the first 4 KB of a post-write file would close that gap.

Not in: a persistence-tampering rule that would diff the inventory snapshots over time and fire when a new file appears in /etc/sudoers.d, a new registry Run key is added, or an existing one changes hash. The inventory data is captured today; the diffing is not implemented yet.

Not in: cross-agent lateral-movement detection. Patterns like "one host SSHing to N internal hosts in 60 seconds" require correlating events across agents. The per-agent rule engine cannot see those patterns; that work belongs in a backend correlation engine.

Behavioral detection rules in the agent

The five ransomware kill-chain rules ship active by default. Detections are persisted to the per-organization AgentBehavioralDetections table and surfaced in the dashboard within the heartbeat following a match.

Plans and Pricing