Chainsaw: a single Rust binary for triaging Windows event logs when Splunk is not an option

Built for the case where the EDR agent was never installed

The README explains the origin in a paragraph that explains the design. At WithSecure Countercept, the team ingests telemetry from endpoints through their EDR agent to run a managed detection and response service. But there are cases where forensic artefacts exist that the agent never captured, and the common one named is an incident response investigation on an estate where EDR was not installed at the time of the compromise.

That gap is the entire use case. A responder arrives with a disk image and no prior visibility, and needs to triage it fast. Chainsaw was built to give the threat hunters and incident response consultants at that firm a tool for rapid triage in those circumstances.

The second half of the rationale is about infrastructure. Windows event logs are described as a rich forensic source, but processing and searching them is slow and usually needs surrounding infrastructure such as an ELK stack or a Splunk instance to hunt efficiently. The README argues that this overhead often prevents blue teams from triaging quickly enough to give an investigation direction. It also states that few open source standalone tools offered a simple fast triage path with Sigma support, and that the tools which did exist struggled to apply detection logic efficiently across large volumes of logs.

That is a specific claim about a specific situation, and it is worth holding the tool to exactly that standard rather than to the standard of a full detection platform.

Sigma rules run against event logs through a mapping file

The detection mechanism is two parameters: `--sigma` to point at a directory of rules, and `--mapping` to tell Chainsaw which event log fields to match against. Give it a subset of Sigma rules or the entire Sigma repository and it will load, convert and run them.

The mapping file is the piece that makes this practical, because Sigma rules are written against abstract field names while Windows event logs use concrete ones. Chainsaw ships a mapping covering a wide range of event log types, and the README includes a partial table of what it handles.

|Event Type|Event ID  |
|--|--|
|Process Creation (Sysmon)| 1 |
|Network Connections (Sysmon)|3|
|Image Loads (Sysmon)|7|
|File Creation (Sysmon)|11|
|Registry Events (Sysmon)|13|
|Powershell Script Blocks|4104|
|Process Creation|4688|
|Scheduled Task Creation|4698|
|Service Creation|7045|

Sysmon covers process creation, network connections, image loads, file creation and registry events at IDs 1, 3, 7, 11 and 13. The native Windows events in the table are the ones that work even without Sysmon installed: 4104 for PowerShell script blocks, 4688 for process creation, 4698 for scheduled task creation and 7045 for service creation. On a machine with no Sysmon, that last group is what you have to hunt with, which is a real constraint on an estate that never had EDR. The README directs you to the mapping file for the full field list and invites you to extend it.

Alongside Sigma there is a custom Chainsaw rule format, and the repository's `rules/` directory ships rules that extract and parse Windows Defender, F-Secure, Sophos and Kaspersky AV alerts, detect cleared event logs or a stopped event log service, spot users created or added to sensitive groups, surface remote logins of the service, RDP and network kind to help identify lateral movement, and catch brute force against local accounts.

Analysis beyond event logs: Shimcache, SRUM and log gaps

The table of contents lists an analysis section that goes past event log searching, covering three artefacts that answer questions logs alone cannot.

Shimcache timeline creation is one. The README describes analysing Shimcache artefacts and enriching them with Amcache data to produce execution timelines. Both are artefacts of programs having run on the machine, and enriching one with the other turns a list of loaded images into something with more context. This is exactly the kind of work that is tedious by hand under time pressure.

SRUM, the System Resource Usage Monitor, gets its own entry. Chainsaw can analyse the SRUM database and provide insights about it, which is a persistent record of per-application resource usage over time and therefore useful for spotting a process that was doing something unusual. Dumping is also supported for raw forensic content including MFT entries, registry hives and ESE databases, with the `mft`, `libesedb` and `notatin` crates doing that parsing.

There is also a gaps feature for event log gap detection, which is quietly the most valuable item on that list. An attacker with administrative rights can clear a log, and a gap in the sequence tells you the record was interrupted even when the visible entries look clean. Chainsaw's custom rules separately flag cleared event logs and a stopped event log service.

Output formats are ASCII table, CSV and JSON, which covers pasting a result into a report, importing into a spreadsheet and feeding a downstream script. The design philosophy stated in the features list is clean and lightweight output without unnecessary bloat.

Building it, and the packaging change in version 2

There is a deliberate packaging decision in the quick start. With the release of Chainsaw v2, the Sigma Rules and EVTX-Attack-Samples repositories are no longer included as submodules, and the README recommends cloning them separately to keep them current.

git clone https://github.com/WithSecureLabs/chainsaw.git
cargo build --release

The README is emphatic about the release flag and says so in bold: building without it will produce significantly slower execution time. That matters here, because the whole argument is about triage speed. The binary lands in `target/release`.

You can skip the build entirely. Pre-compiled binary-only builds for various platforms and architectures are in the releases section, and there is an all-in-one package containing the binary, the Sigma rules and example event logs for people who just want to see it run. It also supports a Nix flake, since `flake.nix` and `flake.lock` are in the repository tree, and runs on MacOS, Linux and Windows.

One inconsistency is worth flagging rather than resolving. The repository you clone from and the documentation inside it name different GitHub organisations: the clone URL, the releases link and the `repository` field in `Cargo.toml` all point at `WithSecureLabs/chainsaw`, while the project as catalogued sits under `WithSecureOpenSource`. The README also refers to the project's wiki at a `WithSecureLabs` path. If you are scripting a clone, use the URL from the README and the manifest, not the owner name from a search result.

What the Rust dependency list reveals about the scope

The manifest is a compact description of what the tool actually does, and it is worth reading as a map of the capability set.

evtx = { version = "0.12", default-features = false }
libesedb = "0.2.4"
mft = "0.6"
notatin = "1.0"
tau-engine = { version = "1.0", features = ["core", "json", "sync"] }

`evtx` is the EVTX parser the README credits to @OBenamram, and it is the foundation of the whole event log path. `libesedb`, `mft` and `notatin` cover ESE databases, the MFT and registry hives respectively, which lines up with the analysis and dumping features. `tau-engine` from WithSecureLabs provides the document tagging described as detection logic matching, with core, json and sync features enabled. `aho-corasick` and `regex` are the string and pattern matching layers, `rayon` gives the parallelism, `clap` handles the command line, and `serde_yaml` alongside `serde_json` covers rule and output formats.

Two details stand out. The package declares `edition = "2024"`, which is a recent Rust edition, and the manifest carries a `[patch.crates-io]` section redirecting `libesedb`, `mft` and `notatin` to git forks in the maintainer's own namespace under a comment about handling abandoned upstreams. That is a maintenance liability and also evidence of care: the author took over three forensic parsing libraries whose upstream had gone quiet. It also means a build depends on those forks being reachable.

Licensing is GPL-3.0 in the manifest and the licence text sits in a file named `LICENCE`. GPL-3.0 matters if you intend to wrap Chainsaw inside a commercial product, since it carries copyleft obligations that a permissive licence would not.

Editorial conclusion

Chainsaw fits a specific and quite common gap: an estate where nobody installed EDR, a responder needs answers in the next twenty minutes, and standing up an ELK stack is not available. In that window a single static binary that loads Sigma rules from a directory and prints matches beats almost anything else you could unpack. Outside that window it is weaker, because output is a table, CSV or JSON file rather than a correlation pipeline, and the release history shows the work concentrated on parsing and flushing correctness rather than on detection content. Build it with `cargo build --release`, clone the Sigma rules separately as the README instructs, and start with the built-in `rules/` directory before writing anything of your own.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. WithSecureOpenSource/chainsaw on GitHub