Fibratus Backend

Fibratus Backend

Added in v0.15.0

The fibratus backend converts Sigma rules into Fibratus rule YAML, the rule format consumed by Fibratus’s open-source kernel-event detection and EDR engine. It is the first conversion target aimed at an endpoint sensor rather than a centralized log store; the produced rules drop directly into a Fibratus installation’s Rules/ directory and are accepted by the same loader that ships with the upstream rules library.

For the workflow walkthrough see Rule Conversion. For Fibratus-side operational topics (rule installation, alerting sinks, the filter language, the macro library) see the Fibratus documentation.

How it differs from PostgreSQL and LynxDB

Fibratus is a runtime detection engine, not a log store. Three differences drive the backend design:

• Case-insensitive matching needs an operator switch, not a wrapper. Fibratus’s plain operators (=, contains, startswith, endswith, matches, in, intersects) are case-sensitive; the i-prefixed cousins (icontains, istartswith, …) and the ~= string-equality operator are not. Sigma defaults to case-insensitive matching, so the backend emits the case-insensitive forms by default and flips to the bare forms only when Sigma’s |cased modifier is present (or when -O case_sensitive=true is set globally). Plain literal equality (no */? wildcards) uses the dedicated string-equality operators (~= default, = cased) instead of a wildcard match because they evaluate more efficiently and read the way the upstream rules library writes literal equality; imatches/matches are reserved for values that actually carry wildcards. The evt.name event discriminator always uses the exact = operator, matching the macro and rules libraries.
• Regex is a function call, not an operator. Fibratus has no =~-style regex operator; instead it exposes the regex(field, 'pat1', 'pat2', ...) = true filter function. Sigma |re lowers to that call; the negated form uses a leading not. The underlying RE2 engine rejects PCRE-only constructs (lookarounds, backreferences); patterns that use those return a structured UnsupportedModifier rather than emitting something Fibratus would reject at load time.
• YAML envelope, not query string. Every rule emits as a complete YAML document with name, id, version, description, labels, condition, min-engine-version, and optional action. The version field is the rule content version, required by the loader. Multi-rule output is ----separated so the entire stream loads as a valid YAML stream.

Fibratus has a native not operator and no parser envelope, so the backend ships no De Morgan negation push-down (unlike Loki) and no stream-selector machinery.

Backend options

Pass with -O key=value (repeatable). Unknown keys are silently ignored so forward-compatible flags can be added without breaking existing invocations.

Modifier mapping

Verified against the Fibratus backend’s unit tests at crates/rsigma-convert/src/backends/fibratus.

Integer, float, and boolean values keep their literal form (evt.pid = 4, ps.is_protected = true). Strings are single-quoted; \ and ' are backslash-escaped, and a line break is written as \n, the only escapes the Fibratus lexer accepts. Added in v0.24.0

Field naming

Fibratus identifiers are lowercase dotted paths (ps.exe, ps.cmdline, file.path, registry.path, net.dip, thread.callstack.symbols). Sigma rules use PascalCase Windows-event field names (Image, CommandLine, TargetFilename, TargetObject, DestinationIp). The backend does not invent field renames on its own; the bundled fibratus_windows builtin pipeline does the translation per logsource category.

Always pair the backend with -p fibratus_windows when converting upstream SigmaHQ Windows rules:

rsigma backend convert rules/windows/process_creation/ -t fibratus -p fibratus_windows

The pipeline maps logsource categories to evt.name discriminators and renames fields:

Field names target the Fibratus 3.0.0 registry. The legacy image.* namespace is deprecated in favor of module.* for loaded executables/DLLs, and DNS fields live under dns.* (not net.dns.*). Sigma fields with no 3.0.0 equivalent (SignatureStatus, Hashes, Imphash under image_load/driver_load; DestinationHostname, Initiated under network_connection) are intentionally not mapped, so a rule that depends on one fails conversion rather than emitting a field the loader rejects.

The pipeline injects the evt.name discriminator as the first condition (via add_condition’s prepend: true), so the emitted rule leads with the cheapest, most selective predicate (spawn_process and ...) and Fibratus short-circuits before evaluating the rest of the rule body.

A final change_logsource transformation tags every matched rule with product: windows, service: fibratus so downstream tooling can re-route by service.

ATT&CK tags

Sigma tags: entries are flattened into the labels: block Fibratus expects. The mapping mirrors how the upstream Fibratus rules library names ATT&CK labels:

• attack.<tactic_short_name> becomes tactic.id + tactic.name + tactic.ref via a static MITRE ATT&CK lookup.
• attack.t<NNNN> (a base technique) becomes technique.id + technique.ref.
• attack.t<NNNN>.<sub> (a sub-technique) becomes subtechnique.id + subtechnique.ref. The parent technique.* keys are only emitted if the rule also carries the base-technique tag; the backend does not invent a parent technique because doing so would diverge from the rule author’s stated tags.
• Anything else passes through as tag.<original>: <original> so the YAML loader sees a string value rather than a typed bool.

tags:
  - attack.defense_evasion
  - attack.t1055
  - attack.t1055.001

becomes

labels:
  tactic.id: TA0005
  tactic.name: Defense Evasion
  tactic.ref: 'https://attack.mitre.org/tactics/TA0005/'
  technique.id: T1055
  technique.ref: 'https://attack.mitre.org/techniques/T1055/'
  subtechnique.id: T1055.001
  subtechnique.ref: 'https://attack.mitre.org/techniques/T1055/001/'

Output formats

Pick with -f <format>. Four formats; default, yaml, and rule are aliases for the same YAML envelope:

default (alias yaml, rule)

One YAML rule document per Sigma rule, separated by ---:

name: Suspicious cmd via Explorer
id: 11111111-2222-3333-4444-555555555555
version: 1.0.0
description: |
  Detect cmd.exe spawned by explorer.exe with whoami in args.
labels:
  tactic.id: TA0002
  tactic.name: Execution
  tactic.ref: 'https://attack.mitre.org/tactics/TA0002/'
condition: >
  spawn_process and ps.exe iendswith '\\cmd.exe'
  and ps.parent.exe iendswith '\\explorer.exe' and ps.cmdline icontains 'whoami'
min-engine-version: 3.0.0

The leading spawn_process is the macro recognizer rewriting the raw evt.name = 'CreateProcess' clause the pipeline injects first; set -O use_macros=false to keep the raw evt.name = 'CreateProcess' form.

expr

Filter expression only, no YAML envelope. Useful for piping into ad-hoc Fibratus run commands:

spawn_process and ps.exe iendswith '\\cmd.exe' and ps.parent.exe iendswith '\\explorer.exe' and ps.cmdline icontains 'whoami'

One file per rule

Fibratus loads one YAML rule per file from its Rules/ directory, so the backend can write a separate file per converted rule instead of a single ----separated stream. This happens automatically when --output points at a directory: an existing directory, or a path with a trailing separator (which is created on demand). Each rule lands in <title-slug>.yml, ready to drop straight into the sensor:

rsigma backend convert rules/windows/ -t fibratus -p fibratus_windows -o ./Rules/

File stems are a snake_case slug of the rule title (Detect Whoami becomes detect_whoami.yml), matching the upstream rules-library naming style; the rule id and then a rule literal are fallbacks when a title slugifies to nothing, and colliding names get a numeric suffix (same.yml, same_2.yml) so no rule overwrites another. A rule that converts to several documents (a temporal correlation expanded with -O temporal_permute=true, for example) keeps them together in its one file. Without a directory --output, the behavior is unchanged: the whole stream goes to stdout or to the single file you name.

Correlation rules

Fibratus 1.10+ uses an inline DSL inside condition: for stateful sequences; the backend lowers Sigma correlation rules to that DSL. Coverage matrix:

The group-by fields are shared by every referenced rule, so the join is emitted once as a sequence-level by field1, field2, ... clause (after maxspan, before the stages), matching the upstream rules-library style. No inline $1.<field> = <field> bindings are needed for multi-field group-by.

Example: 3 failed authentications from the same source IP within 5 minutes lowers to

name: Brute force from single source
id: 22222222-aaaa-bbbb-cccc-000000000002
version: 1.0.0
description: |
  3 failed logins from the same source within 5 minutes.
labels:
  tactic.id: TA0006
  tactic.name: Credential Access
  tactic.ref: 'https://attack.mitre.org/tactics/TA0006/'
  technique.id: T1110.001
  technique.ref: 'https://attack.mitre.org/techniques/T1110/001/'
condition: >
  sequence
  maxspan 5m
  by net.sip
    |evt.name = 'AuthFail'|
    |evt.name = 'AuthFail'|
    |evt.name = 'AuthFail'|
min-engine-version: 3.0.0

Caveats and follow-ups

• create_remote_thread cross-process guards. The Sigma logsource lowers to the create_remote_thread macro, which is create_thread plus evt.pid != 4 (exclude the System process) and evt.pid != thread.pid (the target thread lives in another process). The pipeline injects both guards as negated equalities the recognizer folds back into the macro. TargetImage maps to the evt.arg[exe] event argument and TargetProcessId to thread.pid (the cross-process pointer the macro itself uses).
• |all multi-value lists. A Fibratus list right-hand side (field in (...), field icontains (...), …) carries OR (“any of”) semantics, so the AND semantics of Sigma’s |all modifier cannot collapse into a single list clause; those values stay AND-joined as separate clauses.
• Named pipes (pipe_created). Fibratus has no visibility into named-pipe events without a dedicated kernel driver, so the pipe_created logsource is intentionally not mapped; such rules fall through unmapped (and fail conversion) rather than aliasing to an unrelated event.

Related material

• Fibratus documentation: runtime, rule language, alerting.
• Fibratus rules library: upstream-hand-authored detection corpus the converter mimics stylistically.
• Rule Conversion guide: broader workflow including pipeline composition, output handling, and multi-backend strategies.