eBPF and Rust tutorial builds ransomware detector that kills on file-open spikes

A behavioural tripwire in the kernel

A tutorial published on dev.to by Bartosz Osiej walks through a working ransomware detector built with eBPF and Rust, drawn from his MIT-licensed talus-process-monitor project on GitHub. The core observation is straightforward: a legitimate program opens a handful of files per second, while ransomware sweeping a filesystem to encrypt it opens hundreds or thousands. Instead of matching signatures or running a model, the detector tracks a single number per process — how many openat calls a PID makes within one second — and reacts when that number spikes.

Because the counting happens in eBPF programs attached to kernel tracepoints, the detector sees activity while encryption is still in progress, and according to the tutorial the overhead is close to zero since only events are counted, not file contents copied. No kernel module is involved.

Kernel side: tracepoints and per-CPU buffers

The kernel-side code uses the aya-ebpf crate. A shared ProcessEvent struct carries the event type, PID, UID, a 16-byte command name and a 64-byte filename. Events are pushed through a PerfEventArray, which the tutorial notes provides one buffer per CPU so concurrent processes do not stall each other.

Two tracepoints do the work: sys_enter_execve and sys_enter_openat. The handler reads the current PID and UID with BPF helpers, extracts the filename pointer from the tracepoint arguments, copies the string with a probe-read helper and emits the event into the buffer.

One eBPF constraint shapes the code: there is no Rust standard library on the kernel side. With no memcpy and no string formatting available, the tutorial writes a manual byte-by-byte copy loop to avoid LLVM builtins that would not verify.

Userspace: a sliding window and a kill switch

The userspace half, built on the aya library, drains the perf buffer into a per-PID queue of timestamps. Anything older than one second is dropped, and the remaining queue length is the current open rate. When that count reaches the threshold — 50 by default — the monitor raises an alert and, if the auto-kill flag is set, sends SIGKILL to the offending process, a signal the target cannot catch or intercept.

Requirements are modest: Linux kernel 5.8 or newer, root, Rust nightly and clang. The tutorial includes a quick self-test — run the monitor with a threshold of three and auto-kill enabled, then create a hundred files in a loop from another terminal, and the loop is terminated after a few opens.

Known limits and next signals

The author is upfront about false positives: a backup job also touches many files quickly, and a pure rate heuristic will flag it. The wider project layers additional signals on top: Shannon entropy scoring of filenames, since encrypted or randomised names score high; tracking of mass extension changes such as .enc or .locked; and tracing connect and sendto calls to spot data leaving the machine alongside the encryption. The project also ships an online-trained MLP model that maps ten behavioural features to a benign, suspicious or ransomware verdict, implemented in a few kilobytes of Rust with no external machine learning dependencies.

Why it matters

Signature-based tooling is structurally behind novel ransomware strains, and this tutorial demonstrates the alternative that modern endpoint detection relies on: behavioural signals observed inside the kernel, where the malicious work is actually happening. The eBPF approach avoids loadable kernel modules, which reduces crash and compatibility risk, and doing it in Rust with aya keeps the whole pipeline type-checked on both sides of the kernel boundary.

The open-rate heuristic alone is too coarse for production, as the author concedes — backup software will trip it. But the architecture generalises: swapping in entropy scoring, extension tracking or network tracing fits the same observe, count and respond pipeline, and a few dozen lines turn a passive monitor into an active agent. For engineering teams weighing host security options, it is also a compact illustration of how far eBPF observability now reaches beyond metrics and tracing.