Hayabusa: Sigma-Based Windows Event Log Forensics in Rust

The problem Hayabusa solves for DFIR teams

Windows event logs are the most common evidence source in an intrusion investigation and the least convenient to read. A single host produces an EVTX file per channel, and a mid-sized estate produces thousands. Reading them one at a time in Event Viewer does not scale, and writing a parser per investigation is wasted effort.

Hayabusa's stated job is to consolidate events from a single host or thousands of systems into one CSV, JSON or JSONL timeline. The README names the analysis targets it expects you to use afterwards: LibreOffice, Timeline Explorer, the Elastic Stack and Timesketch. It also describes running live on one system, collecting logs for offline analysis, or hunting across an enterprise with Velociraptor.

The audience is narrow and technical. This is a tool for incident responders and threat hunters who already know what an EVTX file is and have somewhere to put a timeline. It is not a SIEM and not an agent. The README makes no claim about alerting, dashboards or retention, because those are the problems of whatever you import the output into.

How the Sigma rule engine and EVTX parser fit together

Three parts of the repository tell you how the tool is built. The first is the EVTX parser: Cargo.toml depends on a fork at github.com/Yamato-Security/hayabusa-evtx, pinned to a specific revision with the fast-alloc feature enabled. The comment beside it records that revision as a 2026/09/12 update, the same day as the v4.1.0 release. Parsing is therefore a fork the project controls rather than an upstream crate.

The second is the detection layer. The README states that Hayabusa is the only open-source tool with full Sigma support, including v2 correlation rules. Correlation matters because it means detections are not evaluated one event at a time; the rule format can express relationships across events, which is what most real intrusions need.

The third is speed. The README describes the tool as multi-threaded, and the dependency list backs that up with mimalloc and libmimalloc-sys with the extended feature, dashmap, and aho-corasick for multi-pattern matching. The build targets Rust 2024 edition with a minimum toolchain of 1.97.1.

Data flow is therefore: EVTX in, parsed records matched against a Sigma rule set, matching events emitted into a timeline that is written as CSV, JSON or JSONL. The README does not describe the internal pipeline in more detail, so anything beyond this is not confirmed by the repository.

Install hayabusa and produce a first timeline

The README directs users to the Releases page for the latest signed binaries, and to the Getting Started page on the documentation site for live-response packages and building from source. It does not reproduce install commands inline, so the exact flags for a first run are not in the repository.

What the repository does give you is the build path. Cargo.toml names the package hayabusa at version 4.1.0, requires Rust 1.97.1 or newer, and includes a build.rs script that is used for Windows resource metadata. A source build therefore starts with cargo.

The result is a binary named hayabusa (hayabusa.exe on Windows, per the winresource metadata). Configuration lives in the config/ directory at the top level of the repository, and detection rules live in a rules entry that is a git submodule. Cloning without submodules leaves that directory empty, which is the most likely cause of a run that finds nothing.

For rule updates, the dependency comment in Cargo.toml explains that git2 is built with the https and vendored-openssl features specifically so that the update-rules command has a working TLS transport; an earlier wildcard version resolved to a libgit2 build with no TLS and failed with class=Ssl (16) - there is no TLS stream available. That is a useful diagnostic if rule updates fail on a minimal system. The .env.example file at the repository root lists only WEBHOOK_URL and CHANNEL, which implies an optional notification path rather than required configuration.

Where Hayabusa is the wrong tool

The documentation is thin on failure behaviour. The README does not document rollback, does not describe what happens when a Sigma rule fails to parse, and does not state how partial or corrupt EVTX files are handled. For a forensic tool this matters: an investigator needs to know whether a clean-looking timeline means no matching events or a silently skipped log file. The repository does not answer that.

The scope is also Windows-only. Everything in the README concerns Windows event logs. If your estate is predominantly Linux or macOS, or if your telemetry already lands in a SIEM with its own detection engine, Hayabusa adds a second pipeline without adding coverage.

Finally, the licence is a real constraint rather than a footnote. Hayabusa is AGPL-3.0, and the README separates that from the detection rules, which are under the Detection Rule License 1.1. If you intend to embed the engine in a product or a hosted service, the AGPL is the first thing to read, before the feature list.

Hayabusa compared with Chainsaw

The obvious alternative in the same space is Chainsaw, which also scans Windows event logs with Sigma rules and also produces a timeline. The difference in approach is the rule engine. Hayabusa's README claims full Sigma support including v2 correlation rules; a tool that evaluates Sigma rules without correlation support can only express single-event detections, which changes which behaviours you can detect at all.

The second difference is the parser. Hayabusa depends on a project-maintained fork of the evtx crate pinned by revision, which gives the maintainers control over parsing performance and bug fixes but also means parser updates arrive on the project's schedule. Chainsaw's parser choices are outside the scope of this article.

The third is ecosystem. Hayabusa's README explicitly names Velociraptor for enterprise-wide hunting and lists import paths into Elastic, Timesketch and Timeline Explorer. If you already run Velociraptor, that integration is the deciding factor, not raw scan speed.

Release cadence, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-12. The release history shows a steady cadence: v3.10.0 on 2026-07-04, v4.0.0 on 2026-08-03 and v4.1.0 on 2026-09-12. That is roughly a release every four to six weeks, with a major version in the middle of the window.

Upgrade cost is dominated by two things. First, the rules submodule: rule content changes independently of the binary, so a binary upgrade without a rule update leaves you on stale detections. Second, the pinned EVTX parser revision: because it is pinned in Cargo.lock and Cargo.toml, a source build reproduces exactly the parser the release was tested against, which is good for reproducibility and means you must rebuild to pick up parser fixes.

The licence split is worth stating plainly. The tool is AGPL-3.0, which carries network-use obligations that a permissive licence does not. The detection rules are under the Detection Rule License 1.1. This is not legal advice; if the deployment is commercial, get the licence read by someone qualified before you ship.

Editorial conclusion

Adopt Hayabusa if you do incident response or threat hunting on Windows hosts and want Sigma rule coverage without building your own EVTX pipeline; the current release is v4.1.0, pushed on 2026-09-12. Do not adopt it if you need a documented rollback path or a permissive licence for a closed-source product, because the README documents neither and the project is AGPL-3.0. Before deploying, confirm that your rules directory is populated, since the repository stores rules as a submodule, and check the pinned EVTX parser revision in Cargo.toml.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. Yamato-Security/hayabusa on GitHub