fibratus is a Windows security sensor that combines kernel-level telemetry, a behavior-driven rule engine, and YARA memory scanning for real-time detection and forensics in authorized environments.
| Tool | rabbitstack/fibratus — security sensor for realtime threat detection and protection on Windows |
| Category | endpoint detection and response / kernel telemetry |
| Primary Use | Detecting attacker tradecraft and malware on Windows hosts by asserting system events against behavior rules and YARA memory scans, with forensic captures |
| Safe Use | Deployed defensively on hosts you own or are authorized to monitor — SOC detection engineering, purple-team validation, lab research, and incident response |
| Telemetry Note | As a defensive sensor, fibratus consumes ETW-style kernel events rather than generating attack traffic; defenders see its footprint in the kernel driver load, service installation, and its signed binaries (SignPath certificate) |
fibratus positions itself as a security sensor for real-time threat detection and protection, and the phrase is deliberate: this is not a passive logger but an endpoint detection and response component that can both observe and act. Written in Go and hosted at rabbitstack/fibratus with roughly 2,500 stars, the project targets the Windows ecosystem, leaning on kernel-level visibility that the repo's topics — windows-kernel, etw, endpoint-detection-response, blue-team — make explicit. The README frames its mission as detecting and eradicating advanced attacker tradecraft, malware, and emerging threats by scrutinizing a wide spectrum of system events against a behavior-driven rule engine and a YARA memory scanner. That combination places it squarely in the detection engineering toolbox rather than in offensive arsenals, despite the red-team and purple-team tags, which reflect its usefulness for validating detections against simulated tradecraft.
The project's architecture is summarized in the README as three pillars: real-time behavior detection, memory scanning, and forensics. Each pillar maps to a concrete subsystem. Behavior detection is handled by the rule engine, documented separately at the project's docs site, where events streamed from the kernel are matched against expressive predicates that describe malicious behavior patterns rather than static indicators. Memory scanning is delegated to an integrated YARA engine, meaning the same binary can sweep process memory for signatures that file-based scanning would miss — a common blind spot for droppers that never touch disk. Forensics closes the loop with capture files that record the event stream for local inspection and post-incident analysis.
Under the hood, fibratus taps into the Windows kernel's event tracing infrastructure to harvest system activity across processes, threads, file system operations, registry mutations, and network traffic. The README links to an events reference in its documentation that enumerates the telemetry surface, and the breadth matters: behavior-driven rules are only as good as the events feeding them. By instrumenting at the kernel level, the sensor sees activity regardless of user-mode obfuscation, which is the same telemetry class that commercial EDR products depend on. The mitre-attack topic tag signals that the rule vocabulary is intended to express adversary techniques in ATT&CK terms rather than only atomic IOCs, which is the correct abstraction for detecting tradecraft that mutates between campaigns.
The rule engine deserves particular attention from detection engineers. Rather than shipping a closed signature corpus, fibratus treats rules as first-class, editable artifacts hosted at fibratus.io/rules, letting teams write detections against the event stream with the semantics of the underlying telemetry. This is the model popularized by tools like Sigma — separating detection logic from the telemetry transport — and it enables a purple-team workflow where offensive activity is executed in an authorized lab and rules are iterated until they fire reliably with low noise. The README's contribution guidelines and active discussions forum suggest the project expects community involvement in expanding that rule surface, which is a healthy signal for long-term detection coverage.
Extensibility is handled through what the project calls filaments, a mechanism the README describes as letting you extend fibratus with your own tooling and tap into the full power of the Python ecosystem. This is a meaningful design choice: instead of forcing analysts to learn a bespoke scripting language or wait on upstream features, filaments expose the event stream to Python, where enrichment, custom analytics, and integration with existing tooling can be layered on top. For a SOC that already invests in Python automation, this dramatically lowers the cost of adopting the sensor, and it makes fibratus a plausible telemetry backbone for custom detection pipelines rather than an all-or-nothing product decision.
Event routing is another practical strength. The README notes that events can be routed to a wide range of output sinks or written to capture files for local inspection and forensic analysis. That flexibility matters operationally: a small lab might log to local files for capture-and-replay debugging, while a production deployment can forward telemetry to a SIEM or data lake for fleet-wide correlation. The capture format is particularly interesting for detection engineering, because recorded event streams allow rules to be replayed against historical data — test detections against real telemetry without re-running the activity that generated it. This replay capability is exactly what makes the tool valuable for both forensic reconstruction and rule regression testing.
Installation is refreshingly minimal for a kernel-touching sensor. The README's recommended path is a single line from an elevated PowerShell terminal: irm https://install.fibratus.io | iex, which downloads and sets up the latest release. A manual installation guide with alternative methods exists in the documentation for environments where scripted installers are disallowed — a sensible precaution, since piping a remote script into iex is exactly the pattern defenders teach users to avoid, and hardened hosts will want the explicit route. Note that elevation is required, as expected for anything loading kernel components.
Supply-chain posture is addressed directly: the README states that free code signing is provided by SignPath.io with a certificate from the SignPath Foundation, and that all releases are automatically signed. For a tool that must load a kernel driver on Windows, signed binaries are not a nicety — unsigned or tampered builds would fail on systems enforcing driver signature verification, and the signing policy gives defenders a verifiable provenance chain for deployed binaries. Teams should still pin versions and validate signatures against the expected certificate, but the policy removes the most common friction in deploying open-source endpoint tooling.
The developer context is worth noting: the project is developed by Nedim Šabić Šabić and contributors, with structured documentation living at docs.fibratus.io covering setup, quick start, telemetry outputs, and the rule and YARA subsystems. The depth of that documentation ecosystem — separate references for events, rules, filaments, captures, and outputs — indicates a mature project rather than a weekend experiment. The topic tags also reveal the intended audience split: blue-team, detection-engineering, threat-hunting, and forensics on the defensive side, with red-team and purple-team implying offensive testers use it as an adversary-emulation measurement target or to verify their activity is visible.
Where does fibratus fit in an authorized workflow? For defenders, it is a lightweight, scriptable EDR-telemetry layer on hosts you control: build rules mapped to ATT&CK techniques, run purple-team exercises in a lab, and iterate detections against captured streams. For threat hunters, the capture files and Python filaments provide a programmable interface for hypothesizing over raw kernel events. For incident responders, the forensic captures preserve the timeline evidence needed for reconstruction. The malware-detection topic rounds out the picture, with YARA memory scanning catching injected or fileless payloads that evade disk-based controls — provided scans run on memory the host is authorized to inspect.
Caveats are the usual ones for kernel instrumentation. Any sensor that hooks deep Windows internals carries a stability and performance surface that must be evaluated on representative hardware before fleet deployment, and the license is marked NOASSERTION on GitHub, which legal and procurement teams will want to clarify before commercial adoption despite the signed releases. Detection quality ultimately depends on the rule corpus you maintain, so budget for rule engineering rather than expecting turnkey coverage. Still, for teams wanting transparent, extensible, kernel-depth visibility into Windows without a commercial EDR's opacity, fibratus is one of the strongest open-source options in its class, and its documentation depth makes it approachable enough to evaluate quickly in a lab.
rabbitstack/fibratus.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.