Fibratus: a Windows ETW security sensor for realtime threat detection

What Fibratus solves, and for whom

Windows endpoint telemetry is abundant and mostly unread. Fibratus takes that raw stream and turns it into assertions. The README describes the project as a security sensor that "detects and eradicates advanced attacker tradecraft, malware, and emerging threats by scrutinizing and asserting a wide spectrum of system events against a behavior-driven rule engine and YARA memory scanner." The audience is the detection engineer who wants to write the rule, not buy the dashboard. The repository topics name the same crowd: blue-team, detection-engineering, endpoint-detection-response, threat-hunting, purple-team. It is a sensor, not a platform. There is no managed console in the README, no agent fleet view, no cloud signup. You run it on a host, feed it rules, and route the output somewhere you already own.

Event sources, the rule engine and the YARA scanner

The mechanism has three stages. First, collection: Fibratus observes system events, which the documentation organises under a telemetry section at docs.fibratus.io/telemetry/events. The repository topics list etw and windows-kernel, so the sensor is built on Windows tracing rather than a user-mode hooking shim. Second, assertion: each event is matched against a behavior-driven rule engine, and separately against a YARA memory scanner. The two are complementary. A rule can express sequence and context over the event stream; YARA matches byte patterns in process memory, which catches artefacts that never touch disk in a form the event stream describes. Third, routing: events go to output sinks or into capture files. The README lists both, and points at docs.fibratus.io/telemetry/outputs and docs.fibratus.io/captures. Captures matter for the forensic pillar, because they let you replay a recorded stream locally instead of re-running the sensor against live traffic. The go.mod file shows the concrete dependencies behind this: hillu/go-yara/v4 for YARA, olivere/elastic/v7 for Elasticsearch output, streadway/amqp for AMQP brokers, gomail.v2 for mail, and gozstd for compression. That list is the honest shape of the project. It is a Go binary with a small set of well-known integrations, not a sprawling data platform.

Installing Fibratus and seeing your first event

The README gives one install path and calls it the fastest: a script piped into Invoke-Expression from an elevated PowerShell terminal. Run this in a PowerShell window opened as administrator, because the sensor needs the privileges to observe kernel-level activity.

irm https://install.fibratus.io | iex

The README states that the installer downloads and sets up the latest version of Fibratus. Piping a remote script into iex means you are trusting whatever that URL serves at the moment you run it; if that bothers you, the README points to an Installation Guide at docs.fibratus.io/setup/installation for manual methods and detailed instructions. After installation, the README directs you to the Quick Start at docs.fibratus.io/setup/quick-start, described as the way to see Fibratus detect your first security event in real time. That page, not this article, is where the exact command-line flags live; the README does not reproduce them. For extending the sensor, the repository ships a filaments directory, and the README says filaments let you "extend Fibratus with your own tooling and tap into the full power of the Python ecosystem." The rules directory in the repository root holds the rule files the engine consumes, and fibratus.io/rules is the published rule collection.

Where the sensor stops being the right tool

Fibratus is Windows-only. The topics list windows, windows-kernel and etw, and the dependencies include golang.org/x/sys and Microsoft/go-winio. There is no Linux or macOS sensor in the README, and no cross-platform claim anywhere in it. If your estate is mixed, this covers one part of it. The second limitation is operational: a kernel-level sensor on every endpoint is a fleet-management problem, and the README does not describe one. Sinks are configured individually, so shipping events to a central store is your integration work, not a feature you switch on. Third, the rule engine is a language you have to learn. Rules are authored, not generated, and a rule that is syntactically valid can still be logically wrong in ways only testing against real traffic reveals. Treat rule authoring as engineering work with a review cycle, not as configuration. Finally, the licence is not stated in a form GitHub recognises: the repository reports NOASSERTION for the license field while shipping a LICENSE.MD file. Read that file before you plan a commercial deployment.

Fibratus compared with Sysmon plus a SIEM

The closest conventional alternative is Sysmon for collection with a SIEM for correlation. The difference is where the logic runs. Sysmon emits a fixed event schema that you ship to a central store; detection happens later, in queries, against data that has already left the host. Fibratus inverts that. Assertions run locally against the live event stream, and the rule engine and YARA scanner sit in the same process as the collector. That buys you memory scanning, which a log pipeline cannot do, and it means a detection can act without a round trip to a server. It costs you the central view: with Fibratus, correlation across hosts is something you build on top of the output sinks, whereas a SIEM gives it to you by default. The two are not mutually exclusive. A reasonable arrangement is Fibratus for host-local assertion and memory scanning, with its output sinks feeding the same store your Sysmon data already lands in. The RELATED SEARCHES list also surfaces Whids, another Windows event-tracing tool; the same distinction applies, in that the choice is about which rule language and output model you want to maintain.

Maintenance, releases and licence cost

The release cadence is visible and recent: v3.0.0 on 2026-04-22, v3.1.0 on 2026-08-12, and v3.1.1 on 2026-08-19. The last push to the default branch was on 2026-09-28. The repository is not archived. That is a healthy signal for a security tool, because detection content ages quickly: rules written against an older event schema need revisiting when the sensor changes. Plan for upgrade work, not just install work. A major version bump from v2 to v3 implies rule or configuration changes somewhere, though the README does not document a migration path, and the release notes are the place to check. On licence, the repository ships LICENSE.MD but GitHub classifies the project as NOASSERTION, meaning the licence could not be identified automatically. That is a signal to read the file directly. Whether you can redistribute a modified build, bundle it into a product, or run it only internally depends on terms this article cannot state. Code signing is handled by SignPath.io with a certificate from the SignPath Foundation, and the README says all releases are automatically signed, which matters if your endpoint policy blocks unsigned binaries.

Editorial conclusion

Adopt Fibratus if you run Windows endpoints and want detection logic you can read, version and extend in Python through filaments. Do not adopt it if you need cross-platform coverage or a managed console, because the repository is Windows-only and the README documents no hosted control plane. Before deploying, verify the licence terms in LICENSE.MD, since GitHub reports NOASSERTION, and confirm the rule and YARA syntax against docs.fibratus.io for the release you install.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. rabbitstack/fibratus on GitHub
4. README
5. Releases