Zircolite: Sigma rules run over your logs without a SIEM

The pipeline is flatten, compile, query

Zircolite runs Sigma rules over your logs, flattening events into SQLite, turning each rule into an SQL query and reporting what matches, offline, in one command. That last phrase is the important one, because a Sigma rule normally has to be translated into whatever query language your SIEM speaks, which is why rule packs exist per platform and why detection counts are not comparable across tools. Here the target language is always SQL, so the same rule runs the same way on Windows EVTX and on a Linux Auditd log. The README describes it as three steps: flatten each event into a row of an SQLite table, convert every Sigma rule into an SQL query over that table, and report the rows that match. The rules can be native YAML converted with pySigma, or the ready-made rulesets in the rules directory, and correlation rules are included.

Format detection is automatic, archives included

The format list is wide and, more importantly, automatic. Many log formats are detected automatically: Windows EVTX in binary, XML and JSON, Auditd, Sysmon for Linux, EVTXtract, CSV, XML and JSON, plain or inside gzip, bzip2, ZIP and 7-Zip archives. The archive support is what makes it usable in practice, since a forensic image or a log bundle arrives compressed and a tool that only reads plain files pushes the unpacking onto you. The rule side is native Sigma rules converted with pySigma, or the bundled rulesets, and the pipeline names are chosen by flag, so a Windows process creation ruleset and a Sysmon pipeline are different selections. Correlation rules are included alongside the detection rules, which is the part that distinguishes a working tool from a grep with extra steps.

Installing it three ways

The standalone binary needs nothing installed: you download the zip for your platform from the releases, with builds for Linux x64 and ARM64, macOS on Apple silicon, and Windows x64 and ARM64. The Docker route is a pull.

docker pull wagga40/zircolite:latest

From source uses PDM with Python 3.11 to 3.14.

git clone https://github.com/wagga40/Zircolite.git
cd Zircolite
pdm use -f 3.14
pdm install

The pdm use step is not incidental: it keeps PDM away from Python 3.15 and free-threaded builds, which are not supported yet, though any of 3.11 to 3.13 works as well. With uv the equivalent is uv sync with a Python version. Source installs compile a native flattening kernel and need a C compiler for it, and without one they fall back to a slower Python kernel.

Running the quick start

The commands differ mainly in the ruleset and the pipeline you choose.

# Windows logs, with the default ruleset (rules/rules_windows_merged.json)
python3 zircolite.py --events sysmon.evtx

# Linux logs: the format is detected
python3 zircolite.py --events auditd.log --ruleset rules/rules_linux.json

# Native Sigma rules, through pySigma pipelines
python3 zircolite.py --events logs/ --ruleset ./sigma/rules/windows/process_creation \
    --pipeline sysmon --pipeline windows-logsources

With a binary you run ./Zircolite instead of python3 zircolite.py. From source you prefix the command with pdm run or uv run unless the environment is already active. Detections go to detected_events.json, and for logs to try it on there is a public EVTX attack samples repository linked. The important warning sits right after the examples: the default rulesets can contain noisy or slow rules, and you are pointed to a documentation page on why you should build your own rulesets for your environment, with the update command to refresh them.

Docker needs the host user id

The Docker invocation mounts the logs and gives absolute paths.

docker run --rm --tty -v $PWD:/case/input:ro -v $PWD:/case/output \
    wagga40/zircolite:latest --events /case/input -o /case/output/detected_events.json

On a Linux host you add the user flag and a log file path, because the image runs as an unprivileged user that cannot write to a directory you own. That is the kind of detail that turns a first run into a permissions failure, and the fix is the id -u and id -g pair rather than running the container as root. The same caution applies to the output volume: the container writes the detections file and, with the log flag, a log of its own run.

The performance claim and the memory cost

The benchmark reports median wall time on a 10-core Apple M1 Max, each tool at its defaults with its own rules. For 4 Sysmon EVTX files of 478 MB, Zircolite takes 7.7 seconds, Hayabusa 4.2.0 takes 23.3 seconds and Chainsaw 2.17.1 takes 48.3 seconds. For 8 EVTX files over 11 channels and 13.3 GB, Zircolite takes 30.2 seconds, Chainsaw 183.0 seconds and Hayabusa 500.3 seconds. The README is careful about the comparison, noting that Zircolite uses more memory through its parallel workers, which the --no-parallel flag turns off, and that the rule sets differ so detection counts do not compare. The speed comes from a compiled flattening kernel, parallel workers and rule prefiltering. The benchmark document is linked for memory, setup and how to reproduce it.

The native kernel, the packaging and the licence

The build machinery explains why a source install needs a compiler. The setup.py file exists only to compile the flattening kernel, because an extension built from a staged copy of a source file cannot be declared in the project metadata. It stages the kernel source, records a SHA-256 of it inside the compiled extension, and falls back to Python when the digest does not match, so a checkout that edits the kernel without reinstalling does not run stale flattening rules. Without a C compiler the install still succeeds and the same code runs as Python, while CI, the Docker image and the release binaries set an environment variable so a missing kernel fails the build instead. The Dockerfile follows the same discipline in a two-stage build, installing with PDM into an isolated environment and setting that variable so an image cannot ship with the slow kernel. The package metadata records the licence as LGPL-3.0-or-later and the Python requirement as 3.11 or later, while the repository's own licence field carries a custom classification GitHub cannot label.

Where Zircolite is the wrong choice

Four limits apply. It is an offline triage tool, so a continuous monitoring programme still needs a collector and a SIEM, and Zircolite is the part that runs when you already have the logs. Its speed depends on rules you chose, and the README says the default rulesets can be noisy or slow, so the tuning work is yours. The SQL translation approach constrains the rules you can use, since a rule has to be expressible as a query over a flattened table, and correlation rules are a limited subset of what a full SIEM would compute. And the memory cost is real, because the parallel workers that produce the speed numbers are also what makes the tool heavy on a large case. For a laptop with sixteen gigabytes of memory and a thirteen gigabyte evidence set, that trade is worth checking before the run rather than after.

Editorial conclusion

Use Zircolite when you have logs to triage and no SIEM to put them in, because the whole detection pipeline becomes a local command that flattens events into SQLite and runs the rules as SQL. Do not treat the default rulesets as a finished detection programme, since the README warns they can contain noisy or slow rules and tells you to select rules for your environment. Verify first which rules you actually need and update them with the update flag, that you can accept the memory cost of parallel workers or turn them off, and which licence applies, because the package metadata records LGPL-3.0-or-later while the repository's own licence field carries a custom classification GitHub cannot label.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wagga40/Zircolite on GitHub