ET Ducky's ransomware detection runs 13 behavioral rules over ETW and eBPF kernel events

A post on dev.to by the developer behind ET Ducky, a remote monitoring and management (RMM) tool, explains how the product detects ransomware behaviorally by reading the kernel event stream on each managed endpoint. Written ahead of a planned Product Hunt launch on Tuesday, September 29, the post describes a rule engine with thirteen built-in rules that every agent runs locally against its own event stream.

One event format, two kernel sources

The telemetry originates in the kernel on both supported platforms. On Windows, Event Tracing for Windows (ETW) supplies the events; on Linux, eBPF tracepoints do the job. According to the dev.to post, both streams are normalized into a common event format, so each rule has a single configurable definition that works on either operating system. That is the central design decision: instead of maintaining separate detection logic per platform, the agent translates kernel events into one shape, and rules are written against that shape.

The built-in rule set

Most of the rules are threshold counters over short time windows. The post lists these defaults:

• mass-file-rename triggers when 25 or more files are renamed to ransomware-style extensions within 60 seconds.
• file-encryption-sweep triggers when 20 or more files receive the same destination extension within 30 seconds, and a policy can adjust that window.
• mass-file-access triggers when 200 or more distinct paths across 3 user-data root directories are touched within 5 seconds.
• shadow-copy-deletion and ransom-note-pattern trigger from a single matching event, with no volume threshold required.

Correlating the kill chain

The ransomware kill-chain rule stands apart. According to the post, it is the only rule on the agent that consumes the engine's output rather than raw kernel events. It raises a Critical alert when at least two of shadow-copy-deletion, mass-file-rename, and ransom-note-pattern have fired on the same process inside a five-minute window. Its evidence list is simply the component detections, so the dashboard can show which base rules produced the alert without an additional database query.

Design trade-offs and a Linux gap

The engine operates under a hard constraint: rules execute on the same thread that delivers events, so no rule is allowed to block. The post also says the engine is deliberately biased toward false positives rather than false negatives, with noise handled downstream. Per-process cooldowns stop the same pattern from firing repeatedly, and the dashboard collapses duplicate alerts.

One rule definition has a documented limitation on Linux. ETW reports both the old and the new file name for a rename, but the current eBPF programs emit only the destination path for rename, renameat, and renameat2, so on Linux the engine has less context around rename events than on Windows.

The post is also explicit about scope: ET Ducky is not an antivirus engine and does not replace one. The full rule set, thresholds, and evidence formats are documented in a companion blog post on the project's site.

Why it matters

Signature-based antivirus struggles against ransomware variants nobody has catalogued yet, and behavioral detection over kernel telemetry is a practical answer: mass renames, encryption sweeps, and shadow-copy deletion show up in the event stream regardless of the payload's hash. The interesting part here is the cross-platform plumbing. eBPF has become the standard instrumentation surface on Linux while ETW plays the equivalent role on Windows, and normalizing both into one event format means a detection rule is written once instead of twice. The disclosed trade-offs, from non-blocking execution and a false-positive-first bias to missing rename source paths on Linux, offer a rare, concrete look at where the engineering costs of this approach actually sit.