# Fibratus — Full Technical Context

> Runtime threat detection, protection, and eradication for Windows.
> This file provides extended context for AI models and large language models.

## Identity

- Name: Fibratus
- Type: Open-source runtime security engine
- License: Apache 2.0
- Language: Go
- Platform: Windows 10, Windows 11, Windows Server
- Creator: Nedim Šabić (GitHub: @rabbitstack, Twitter: @introsec)
- Organization: Fibratus (https://fibratus.io)
- GitHub Repository: https://github.com/rabbitstack/fibratus
- LinkedIn: https://www.linkedin.com/company/fibratusio/
- Twitter/X: https://x.com/Fibratusio

## What Is Fibratus?

Fibratus is a runtime security engine for Windows that detects, protects, and eradicates advanced adversary tradecraft. It captures kernel-level telemetry via ETW (Event Tracing for Windows) and analyzes it using behavior-driven detection rules and YARA memory scanning.

Unlike traditional antivirus that relies on file signatures, Fibratus observes what processes do at the kernel level — registry modifications, network connections, memory operations, handle manipulation — and triggers alerts or blocks threats when behaviors match known attack techniques mapped to MITRE ATT&CK.

## How It Works

1. **Telemetry Collection**: Fibratus subscribes to ETW providers to capture kernel events (process, thread, file, registry, network, memory, handle, driver, image load).
2. **Context Enrichment**: Each event is enriched with process ancestry, loaded modules, handles, and metadata from a live process tree maintained in memory.
3. **Rule Evaluation**: Events are evaluated against YAML-based detection rules with filter expressions, macros, and sequence correlation for multi-stage attacks.
4. **YARA Scanning**: Process memory is scanned using YARA rules for in-memory indicators like shellcode, implants, and packed payloads.
5. **Response**: Detected threats can trigger alerts, process termination, or custom actions via filament plugins.
6. **Output**: Events and alerts are routed to Elasticsearch, AMQP/RabbitMQ, HTTP webhooks, or Windows Event Log for SIEM integration.

## Architecture

Fibratus operates entirely in user-space — no kernel driver is required. This eliminates driver signing requirements, reduces system stability risks, and simplifies deployment. ETW is a native Windows facility optimized for high-throughput event delivery with minimal performance overhead.

The processing pipeline uses Go's goroutine-based concurrency model to handle high event volumes efficiently. Events flow through collection → enrichment → rule evaluation → response/output stages operating concurrently.

## Detection Rules

Detection rules are YAML files with human-readable filter expressions. They support:
- **Macros**: Reusable pattern fragments
- **Sequences**: Multi-event correlation with temporal ordering
- **MITRE ATT&CK mapping**: Each rule links to relevant techniques and tactics
- **Severity and tags**: For alert prioritization and categorization

Example rule structure:
```yaml
- group: Credential Access
  rules:
    - name: LSASS memory access from suspicious process
      condition: >
        evt.name = 'OpenProcess'
          and ps.name = 'lsass.exe'
          and not ps.ancestor[ps.name] in ('svchost.exe', 'csrss.exe')
      action: kill
      severity: critical
      tags: [T1003.001]
```

## Filaments (Python Plugins)

Filaments are Python-based plugins that extend Fibratus with custom logic:
- Custom detection algorithms
- Alert enrichment and formatting
- Automated response actions
- Third-party integrations (Slack, email, ticketing systems)
- Custom output formats

## Key Differentiators

1. **Kernel-native telemetry**: Direct ETW access provides visibility into behaviors invisible to user-mode tools.
2. **No kernel driver**: User-space operation eliminates driver signing requirements and stability risks.
3. **Transparent rules**: YAML-based rules are human-readable, auditable, and version-controllable.
4. **Open source**: 100% Apache 2.0 licensed, no vendor lock-in, no black boxes.
5. **YARA memory scanning**: Detects in-memory threats like shellcode, implants, and packed payloads.
6. **Behavioral detection**: Identifies attack techniques regardless of the specific tool used.
7. **European origin**: Built in Europe with a focus on digital sovereignty and data transparency.

## Core Concepts

### Execution Truth
Execution truth refers to the actual, deterministic state transitions that the operating system kernel must perform when software executes — process creation, memory allocation, handle manipulation, thread scheduling. These transitions are the ground truth of what happened on a system. Detection models anchored to execution truth cannot be evaded by changing tooling, reordering API calls, or swapping user-mode techniques.

### Detection as Code
Detection as Code is the practice of treating detection rules and logic as software: version-controlled in Git, tested against simulated attack scenarios, reviewed through pull requests, and deployed through CI/CD pipelines. Fibratus detection rules are YAML files that live alongside application code, enabling a true Detection as Code workflow.

### Invariants
An invariant is a condition that must always hold true for legitimate execution across a security boundary. For example: "a thread start address must map to a backed image section." When an invariant is violated, it indicates malicious activity regardless of the specific tool or technique used. Invariant-based detection is structurally resistant to evasion.

### Detection Pipeline
A detection pipeline is the end-to-end system from telemetry capture through normalization, enrichment, state modeling, invariant validation, alerting, and response. Fibratus implements this as an engineered pipeline where each stage is measurable and testable.

## Content Architecture — Hub & Spoke Cluster

Fibratus organizes its technical content around three pillar pages (hubs) supported by satellite blog posts:

### Pillar 1: Kernel Runtime Security
Hub: https://fibratus.io/kernel-runtime-security
Topic: Why execution truth lives in the kernel and why detection models must observe kernel-level execution mechanics.

Satellite posts:
- Process Injection Detection at Kernel Level: https://fibratus.io/blog/detecting-process-injection-kernel-level-windows
- Userland Hooks vs Kernel Telemetry: https://fibratus.io/blog/userland-hooks-vs-kernel-telemetry
- Windows Kernel Event Monitoring Explained: https://fibratus.io/blog/windows-kernel-event-monitoring-explained
- Memory Scanning at Runtime: https://fibratus.io/blog/memory-scanning-at-runtime
- What Is an EDR?: https://fibratus.io/blog/what-is-an-edr-crowdstrike-telemetry

### Pillar 2: Behavioral Detection
Hub: https://fibratus.io/behavioral-detection
Topic: Invariant-based behavioral detection vs pattern-based detection. Why "behavior" only matters when it validates execution semantics.

Satellite posts:
- Why Signature Detection Keeps Losing: https://fibratus.io/blog/why-signature-detection-keeps-losing
- Adversarial Mimicry and Behavioral Model Evasion: https://fibratus.io/blog/adversarial-mimicry-behavioral-model-evasion
- Technique-First Detection with Attack Invariants: https://fibratus.io/blog/technique-first-detection-attack-invariants
- Valid Accounts and Living-off-the-Land Detection: https://fibratus.io/blog/valid-accounts-living-off-the-land-detection
- How to Write Behavioral Detection Rules: https://fibratus.io/blog/how-to-write-behavioral-detection-rules

### Pillar 3: Detection Engineering
Hub: https://fibratus.io/detection-engineering
Topic: Detection engineering as a pipeline discipline — telemetry, state, invariants, validation, and response.

Satellite posts:
- Detection Engineering Is Not Writing Rules: https://fibratus.io/blog/detection-engineering-not-writing-rules
- State Modeling: The Missing Layer: https://fibratus.io/blog/state-modeling-missing-layer
- Attack to Primitives Mapping: https://fibratus.io/blog/attack-to-primitives-mapping
- The Telemetry Ceiling: https://fibratus.io/blog/telemetry-ceiling-hard-limit

### Additional Technical Blog Posts
- NTLM Hash Leak via MS Photos URI: https://fibratus.io/blog/ntlm-hash-leak-ms-photos-uri-behavioral-detection
- Thread Pool Telemetry and Sleeping Beacon Detection: https://fibratus.io/blog/thread-pool-telemetry-sleeping-beacon-detection
- Detecting Object Symbolic Link Abuse: https://fibratus.io/blog/detect-object-symbolic-link-abuse-windows

## Frequently Asked Questions

### What is Fibratus?
Fibratus is a runtime security engine that detects, and eradicates advanced adversary tradecraft. It captures kernel-level telemetry via ETW and analyzes it using behavior-driven detection rules and YARA memory scanning.

### How does Fibratus differ from antivirus software?
While antivirus relies on file signatures to detect known malware, Fibratus uses behavior-based detection to identify attack techniques. This means it can detect fileless attacks, living-off-the-land techniques, and novel threats that evade signature-based detection.

### Does Fibratus require a kernel driver?
No. Fibratus operates entirely in user-space using ETW for kernel telemetry. This eliminates driver signing requirements, reduces system stability risks, and simplifies deployment compared to driver-based solutions.

### What is kernel runtime security?
Kernel runtime security is the practice of detecting and responding to threats by observing system behavior directly at the OS kernel level. Unlike userland monitoring, kernel telemetry provides execution truth — the actual system state changes that attacks must produce to succeed.

### What is execution truth?
Execution truth refers to the actual, verifiable state changes that occur at the kernel level when software executes. This includes process creation, memory allocation, handle manipulation, and thread scheduling — the deterministic events that attacks cannot avoid producing.

### What is behavioral detection?
Behavioral detection identifies malicious activity by observing system state transitions and validating them against invariants tied to security boundaries — not against historical byte patterns. It evaluates whether a state transition should exist across a trust boundary, regardless of how the attacker achieved it.

### What is detection engineering?
Detection engineering is the practice of designing, implementing, validating, and iterating detection logic as an engineered system: data collection → normalization → state modeling → invariant validation → alerting/response, with measurable quality attributes (coverage, precision, latency, and robustness to evasion).

### What is Detection as Code?
Detection as Code is treating detection rules as software: version-controlled, tested, reviewed, and deployed through CI/CD. Fibratus supports this natively with YAML-based rules that can be managed alongside application code.

### What operating systems does Fibratus support?
Fibratus is designed specifically for Windows operating systems, supporting Windows 10, Windows 11, and Windows Server editions. It uses native Windows ETW (Event Tracing for Windows) for kernel-level telemetry.

### Is Fibratus open source?
Yes. Fibratus is 100% open source under the Apache 2.0 License. The entire codebase is publicly auditable on GitHub with no vendor lock-in, no black boxes, and complete transparency.

### Can Fibratus integrate with my SIEM?
Yes. Fibratus supports multiple output sinks including Elasticsearch, AMQP/RabbitMQ, HTTP webhooks, and Windows Event Log. Events and alerts can be routed to your existing SIEM for aggregation and analysis.

### How do I install Fibratus?
Fibratus can be installed via the Windows installer, Chocolatey package manager, or by downloading the binary directly from GitHub releases. The installation takes minutes and requires minimal configuration to start detecting threats.

### What is the performance overhead of running Fibratus?
Fibratus is designed for minimal overhead. ETW is a native Windows facility optimized for high-throughput event delivery, and Fibratus uses concurrent processing to handle event volumes efficiently without impacting system performance.

### Can Fibratus detect multi-stage attacks?
Yes. By correlating events over time and tracking process ancestry, Fibratus can detect attack chains where reconnaissance, privilege escalation, and lateral movement occur across separate processes.

### What are filaments in Fibratus?
Filaments are Python-based plugins that extend Fibratus with custom logic, alerting, and integrations. They allow you to build custom detection tools, automate response workflows, and integrate with third-party systems.

### How are detection rules mapped to MITRE ATT&CK?
Each detection rule includes MITRE ATT&CK technique IDs linking the rule to relevant tactics and techniques. This enables coverage analysis, gap identification, and alignment with industry frameworks.

### Can I use Fibratus alongside my existing EDR?
Yes. Fibratus complements existing EDR solutions by providing transparent, user-controlled detection rules and kernel-level visibility. It integrates with SIEMs via Elasticsearch, AMQP, HTTP webhooks, and Windows Event Log outputs.

## Key Concepts (Glossary)

- **ETW (Event Tracing for Windows)**: A high-performance kernel-level tracing mechanism built into Windows, used by Fibratus to capture system events with minimal overhead.
- **Behavioral Detection**: Identifying threats by analyzing runtime behavior patterns rather than matching file signatures.
- **Detection Engineering**: The discipline of designing, building, testing, and maintaining threat detection logic.
- **Kernel Telemetry**: Low-level system event data captured from the OS kernel, providing deep visibility into process, thread, file, and network activity.
- **Execution Truth**: The actual, deterministic state transitions that the OS kernel must perform when software executes — the ground truth of system activity.
- **Detection as Code**: Treating detection rules as version-controlled, testable software artifacts deployed through CI/CD pipelines.
- **Invariant**: A condition that must always hold true for legitimate execution across a security boundary. Violations indicate malicious activity regardless of tooling.
- **Detection Pipeline**: The end-to-end system from telemetry capture through normalization, enrichment, state modeling, invariant validation, alerting, and response.
- **YARA**: A pattern-matching tool for identifying and classifying malware based on textual or binary patterns in files or memory.
- **Process Injection**: A technique where malicious code is inserted into the address space of another process to evade detection or escalate privileges.
- **Living-off-the-Land (LotL)**: Attack technique using legitimate system tools and binaries to carry out malicious actions, avoiding detection by blending with normal activity.
- **MITRE ATT&CK**: A knowledge base of adversary tactics, techniques, and procedures used to categorize and map cyber threats.
- **Filament**: A Python-based plugin in Fibratus that extends the engine with custom detection logic, alerting, and integrations.
- **Process Tree**: A hierarchical representation of running processes and their parent-child relationships, used by Fibratus for execution context and ancestry tracking.
- **Endpoint Detection and Response (EDR)**: Security solutions that monitor endpoint activities, detect threats, and provide investigation and response capabilities.
- **Threat Hunting**: Proactive searching through endpoint telemetry to identify threats that evade automated detection.

## Links

- Website: https://fibratus.io
- Documentation: https://fibratus.io/docs/setup/installation
- Detection Rules: https://fibratus.io/rules
- Blog: https://fibratus.io/blog
- Glossary: https://fibratus.io/glossary
- Downloads: https://fibratus.io/downloads
- GitHub: https://github.com/rabbitstack/fibratus
- How It Works: https://fibratus.io/how-it-works
- Kernel Runtime Security: https://fibratus.io/kernel-runtime-security
- Behavioral Detection: https://fibratus.io/behavioral-detection
- Detection Engineering: https://fibratus.io/detection-engineering