Kunai: an eBPF event monitor for Linux that reads like Sysmon for the other kernel

Sysmon for Linux, and the two stage architecture behind it

Kunai describes itself as a tool designed to bring actionable insights for tasks such as security monitoring and threat hunting on Linux systems, and the mental model it offers is the Linux counterpart to Sysmon on Windows, tailored for comprehensive and precise event monitoring.

The architecture is the interesting part. Kunai uses eBPF technology with kernel level probes that capture critical events, and those probes send data to a userland program responsible for reordering, enriching and correlating the collected events.

So the split is deliberate. The kernel side is a set of probes attached to kernel hooks, which is the only way to get the visibility a userland audit tool cannot reach, including the identity of the process that triggered an event and the parent chain behind it. The userland side is where the raw stream becomes useful, because a raw eBPF stream arrives in whatever order the kernel happened to deliver it, one event at a time, with no context.

That is where the three stated differentiators live. Events are processed and delivered in the exact order they occur, which is a property of the userland reordering stage rather than of the probes. On host correlation is described as built in capabilities for event enrichment and correlation to provide deeper context. And the tool is container aware, described as fully compatible with Linux namespaces and container technologies, enabling complete tracing of container activities.

The container claim is the one to test first in your own environment, because it changes what you see. An event that happened inside a container and an event that happened on the host look different depending on whether the namespace boundary is resolved, and the difference between seeing the container's view and the host's view is the difference between a useful trace and a confusing one.

The implementation is predominantly Rust, using the Aya library, and the design goal is a self contained standalone binary with both the eBPF probes and the userland processing logic embedded for ease of deployment.

One binary, because the probes are compiled in

The deployment story is the strongest argument for the design, and it is worth being precise about why.

Most eBPF tooling has a two artefact problem. There is a compiler and loader, and there is the tool, and they have to match, and the loader needs privileges and a compatible kernel. Kunai folds that into one binary. The probes and the userland logic are both embedded, so deploying it is copying a file and running it.

The repository structure reflects the split at the source level. The Cargo workspace has three members, kunai, kunai-common and kunai-ebpf, with default-members set to kunai and kunai-common. The eBPF crate is a separate compilation target, which is unavoidable, since eBPF programs are compiled to eBPF bytecode rather than to native instructions. The aya-ebpf and aya-ebpf-macros dependencies are pinned to a specific git revision of the Aya repository rather than to a published crate version, which is a sign that the project tracks the Aya mainline for the macros it needs.

The rest of the dependency list describes what the userland side does. clap 4.3.4 for the command line, tokio 1.43 for the async runtime, serde with the rc feature and serde_json and serde_yaml for the event encoding, env_logger and log for logging, and thiserror for error types. Then a set of libraries that name the specific work: procfs for process information from procfs, fs-walk for filesystem traversal, magic-db and pure-magic for file type detection by content, communityid for network flow hashing, ip_network for address handling, simple-dns for DNS parsing, lru-st for a cache, and yara-x at 1.20.0 for pattern matching on files.

That yara-x entry is worth pausing on. It means the collector can run a YARA style matcher over the files it observes, which is how a monitoring tool turns a file creation event into a detection. The project is not only a telemetry pipe.

The workspace also sets a large set of clippy lints as warnings, including complexity, perf, style, todo and clone_on_ref_ptr, and the dev profile sets opt-level 2 with debug line tables, which is a deliberate choice for a tool where people will be reading stack traces.

Building it, and the MUSL argument for production

The README is direct about the first step. A distribution agnostic, pre compiled version of Kunai is available on the release page, and if you simply want to try it you likely do not need to build it yourself. There is also a Docker image that includes everything needed to build the project, described as a one size fits all solution that should work on any Linux distribution.

If you do want to build it, the requirements are rustup, plus clang, libbpf-dev and bpf-linker. On Ubuntu and Debian the README gives the commands.

sudo apt update
sudo apt install -y clang libbpf-dev lld musl-tools

# assuming you have rustup and cargo installed
cargo install bpf-linker

The debug build is a plain cargo build, and the executable lands at ./target/debug/kunai.

cargo build

For production, the project recommends a static MUSL build, and gives the reason in one paragraph. MUSL produces static binaries that are more portable across different Linux distributions, avoiding dependency issues with glibc versions, and the README says this is particularly important for production deployment where you may not control the target environment.

cargo build --release --target x86_64-unknown-linux-musl

That reasoning generalises to any agent you ship to a fleet of hosts. A monitoring binary that fails to start because the glibc on the target is older than the one you built against has failed at exactly the moment you needed it, and a static binary removes that class of problem entirely.

The cross-compilation section is unusually complete for a README, and it targets aarch64, which is the architecture that matters for ARM servers and for Apple Silicon machines running Linux. The steps are to add the musl target with rustup, to install the cross toolchain including crossbuild-essential-arm64 and musl-tools:arm64, and then to build with the same release and target flags, producing the binary at ./target/aarch64-unknown-linux-musl/release/kunai.

A smaller detail that shows the project's habits: there is a memory profiling section, with a debug build using RUSTFLAGS="-g" and then heaptrack, for anyone who believes Kunai has a memory issue.

The release lines, and what the FAQ says about which to run

The FAQ in the README is short and one of its answers is the most useful thing on the page.

The first question is compatibility, and the answer is not a version list but a pointer: check the compatibility page on the documentation site. The second is about events, and the answer points to the events documentation. The third is which version to use.

That third answer is the one to read carefully. If it is just to test the tool, use the latest build, as it is always the best in terms of features and bug fixes. However, the answer warns to keep in mind that events in non stable releases are subject to change.

That warning matters more than it first appears. If your detection logic keys on an event's field names or its payload shape, and you upgrade Kunai from a release candidate to a stable, or between two release candidates, an event may arrive with a different structure. For a collector that feeds a SIEM, that is a schema change you did not ask for.

The release list in the repository metadata shows the shape of the project. The newest tag is v0.7.0-rc.1, a release candidate dated 2026-03-11. Before it, v0.6.2 from 2025-11-12 and v0.6.1 from 2025-11-11. The badges at the top of the README distinguish a stable release badge from a documentation badge for the stable line, and the commented out block shows the alternative pair for the unstable line, which is a small sign that the two tracks are maintained deliberately.

So the practical reading is that Kunai ships a moving unstable line and a stable line, and the project tells you to use the latest build for testing while warning you that event payloads are not frozen on the unstable line. The last push to the repository was on 2026-10-15, and the repository is not archived, so the code is still moving.

The workspace version in Cargo.toml is 0.7.0-rc.1, and the workspace dependency list pins aya at 0.14.0 with aya-build at 0.2.0.

Where Kunai is the wrong instrument

Three honest limits.

The first is that it is Linux only, and specifically Linux with eBPF. The compatibility page exists because kernel versions, configurations and distribution choices all matter, and the tool needs the privileges that loading eBPF programs implies. A team with a mixed estate needs something else for the non Linux hosts, and the project acknowledges that by naming Sysmon For Linux as related work rather than pretending to cover Windows.

The second is that Kunai is a collector, not a detection engine. It produces events, with some file type classification and YARA matching built in, but the correlation, the rules and the alerting live somewhere else, usually in a SIEM. If your problem is that you have no telemetry, Kunai solves it. If your problem is that you have telemetry and no detections, Kunai does not.

The third is that events in the unstable line are subject to change, which means an operational deployment has a version management problem that a packet capture tool does not. You need a way to know which event schema your rules expect, and you need to decide when to move.

There is also the ordinary matter of what an eBPF based collector costs on a host. The tool runs continuously on machines you want to watch, it needs kernel level access, and the people running it are running something with deep privileges on production systems. That is a real operational cost that has nothing to do with the quality of the code.

None of that is a criticism of the design, it is the cost of the design. The same is true of the alternative, and the alternative is worth naming.

Against Sysmon for Linux, and against writing your own probes

The related work section points at Sysmon For Linux, and the comparison is instructive because the two take opposite approaches to the same goal.

Kunai is designed as an original event model instead, and its README says the reference is the Linux counterpart to Sysmon, tailored for comprehensive and precise event monitoring. The three claimed differentiators, chronological ordering, on host correlation, and container awareness, are all things that come from the userland stage doing work after the probes fire. A schema compatible tool has to keep its events in the shape Windows defined, which constrains what it can add. Kunai can order, enrich and correlate because it is not trying to match an existing vocabulary.

The other alternative is writing your own eBPF probes, which is what a lot of teams end up doing when their detection needs an event nobody exposes. The Aya library makes that considerably less painful than it used to be, and the acknowledgements thank the people behind Aya directly. What Kunai adds over that route is the userland processing, the correlation, the container awareness and the fact that the whole thing arrives as one static binary. What it takes away is the ability to have exactly the events you want, because the event set is the project's, not yours.

The trade is between a schema you can write detections against and events that are already ordered and enriched. Most teams are better served by the second, as long as they are prepared to write their rules against Kunai's event documentation rather than against Sysmon's.

Editorial conclusion

Kunai fits a Linux defender who wants Sysmon style event coverage on servers and containers, who wants ordered events with correlation rather than a raw firehose, and who can run a binary with eBPF privileges on the hosts they monitor. It does not fit a team that needs Windows coverage, a Mac, or a detector library rather than a collector, and it does not fit a production rollout that requires a numbered stable release, because the newest numbered build in the list is a release candidate. Check three things before you commit. Check the compatibility page for your kernel and distribution, because the project points there as the first answer to whether it works on your system. Check which release line you take, since the FAQ says the latest build is best for testing while warning that events in non stable releases are subject to change. And check the container story, because the namespace compatibility claim is a headline feature and the behaviour inside your orchestration is what determines whether the traces are complete. The last push was on 2026-10-15, the newest tag is v0.7.0-rc.1 from 2026-03-11, and the license is GPL-3.0.

Frequently asked questions

Official sources

1. kunai-project/kunai on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases