Fibratus Setup

Fibratus Setup

Full walkthrough for kind: fibratus profiles. Pull-from-event-log model, no remote backend needed — Fibratus runs locally on the EDR VM, writes alerts to the Windows Application event log, and Whiskers wevtutil-queries them on demand.

This is the same shape DetonatorAgent's FibratusEdrPlugin.cs uses. If you don't want to stand up an Elastic stack, this is the lighter-weight option.

---

What is Fibratus?

Fibratus is an open-source ETW-based behavioral detection engine for Windows. Think Sysmon + Sigma rules + a YARA pipeline in one Go binary. Free, no vendor backend, runs entirely on the host.

LitterBox uses Fibratus's eventlog alert sender — rule matches land in the Windows Application event log under Provider=Fibratus, and Whiskers reads them via wevtutil. Fibratus does the ETW collection and rule matching; LitterBox does the dispatch and correlation.

---

1. Install Fibratus

Download the latest installer from github.com/rabbitstack/fibratus/releases and run it on the EDR VM. Default install path: C:\Program Files\Fibratus\.

Whiskers detects Fibratus's presence by checking for C:\Program Files\Fibratus\Bin\fibratus.exe. After install, verify:

curl http://<vm>:8080/api/info
# {
#   "hostname": "...",
#   "telemetry_sources": ["fibratus"]    ← this confirms Whiskers found it
# }

If telemetry_sources doesn't include "fibratus", the binary isn't where Whiskers expects it. Reinstall to the default path.

---

2. Configure Fibratus to write JSON alerts

This is the critical step. The default Fibratus config writes alerts in a human-readable "pretty" format that LitterBox can't parse — you need to flip it to JSON.

Edit %PROGRAMFILES%\Fibratus\Config\fibratus.yml:

alertsenders:
  eventlog:
    enabled: true
    format: json    # ← CRITICAL — analyzer parses the <Data> field as JSON

Make sure the rule engine is enabled and points at the rule pack you want active:

filters:
  rules:
    enabled: true
    from-paths:
      - C:\Program Files\Fibratus\Rules\*.yml

Fibratus ships a useful default rule pack. If you want to start with everything Fibratus's authors enable, the default fibratus.yml is fine to leave untouched apart from the alertsenders.eventlog block above.

Restart the Fibratus service:

net stop fibratus
net start fibratus

---

3. Smoke-test rule matches reach the event log

Trigger a benign-but-flagged behavior to confirm the wire. Mshta-launching-a-URL is a common rule:

mshta.exe "javascript:close()"

Then check Event Viewer → Windows Logs → Application — filter Source = Fibratus. You should see a record with a JSON <Data> blob.

From LitterBox you can query the same path through Whiskers without dispatching a payload:

python GrumpyCats/grumpycat.py fibratus-alerts \
    --profile fibratus \
    --from 2026-04-30T00:00:00Z

If this returns alerts with parseable JSON data strings, the wire is good. If it returns prose strings instead, your format: pretty config didn't take effect — re-check step 2.

---

4. Configure the LitterBox profile

Copy the example and fill in the agent URL:

cp Config/edr_profiles/fibratus.yml.example Config/edr_profiles/fibratus.yml

Edit fibratus.yml:

name: "fibratus"
display_name: "Fibratus"
kind: "fibratus"

agent_url: "http://<edr-vm-ip>:8080"

wait_seconds_for_alerts: 30    # Fibratus pushes in real-time → shorter than Elastic's 90s
av_block_wait_seconds: 30      # Fibratus is detect-only; this is for parity, rarely fires
exec_timeout_seconds: 60       # hard cap on payload runtime

No Elastic fields — there's no remote backend. Restart LitterBox; the upload page gains a Fibratus button.

---

How alert correlation works

FibratusEdrAnalyzer._poll_alerts calls AgentClient.get_fibratus_alerts(since, until). Whiskers shells out to:

wevtutil qe Application "/q:*[System[Provider[@Name='Fibratus'] and TimeCreated[@SystemTime >= '<from>' and @SystemTime <= '<until>']]]" /f:xml /e:Events

(matches DetonatorAgent's exact XPath shape, including the rounded-down from timestamp). Whiskers parses the XML out of band and returns the raw JSON <Data> strings; LitterBox parses them and filters by filename match against:

• events[].proc.name
• events[].proc.exe
• events[].proc.cmdline
• events[].proc.parent_name
• events[].proc.parent_cmdline

Same idea as the Elastic filename match — only alerts that mention the payload's filename are counted toward the run.

---

Profile schema

Fibratus profiles are intentionally minimal:

name: "fibratus"             # used in URLs
display_name: "Fibratus"     # shown on the button
kind: "fibratus"             # required — discriminates from kind: elastic

agent_url: "http://<vm>:8080"

wait_seconds_for_alerts: 30
av_block_wait_seconds: 30
exec_timeout_seconds: 60

# drop_path: "C:\\Users\\Public\\sample.exe"   # optional override

No elastic_url, no elastic_apikey, no index pattern. The Whiskers agent + a properly-configured Fibratus on the same VM is everything you need.

---

Status flow + correctness fixes

killed_by_edr requires alert evidence to fire — Fibratus is detect-only and can never legitimately kill a process, so a non-zero exit alone (e.g. payload crashed on its own) won't cause LitterBox to claim the EDR killed it. The DETECTED badge on the EDR row is gated on total_alerts > 0 after the run reaches a terminal status.

---

Troubleshooting

/api/info doesn't list fibratus in telemetry_sources Whiskers checks C:\Program Files\Fibratus\Bin\fibratus.exe. Reinstall Fibratus to the default path.

fibratus-alerts returns supported: false Same as above — Fibratus isn't installed or isn't at the default path.

fibratus-alerts returns events but data is plain prose, not JSON You're still in format: pretty. Re-edit fibratus.yml, set format: json, restart the Fibratus service.

Dispatch finishes but total_alerts: 0

• Was Fibratus actually running during the dispatch window? Get-Service fibratus.
• Did the rule pack include something that should have fired for your payload? Try a known-flagged sample first (mimikatz.exe triggers a dozen rules out of the box).
• Hostname mismatch — Fibratus emits host.name; LitterBox filters case-insensitively. Run curl <vm>:8080/api/info and wevtutil qe Application /q:*[System[Provider[@Name='Fibratus']]]/c:1 and confirm the host strings match.

format: json is set but events still parse as prose Restart of the Fibratus service didn't take effect. Get-Service fibratus | Restart-Service. Confirm via Get-WinEvent -ProviderName Fibratus -MaxEvents 1 — the message should look like JSON.

Performance — Fibratus eating CPU Tune eventsource.blacklist.events in fibratus.yml to drop noisy event types your rules don't need. The default blacklist already excludes CloseFile and RegCloseKey (very high-volume, low-detection-value).

---

Recommended fibratus.yml for max detection

If you want every detection vector enabled (CPU cost is acceptable in a sandbox VM), see the operator-friendly config in the LitterBox README "Max-detection Fibratus config" section. Highlights:

• filters.match-all: true — one event can fire multiple rules
• evasion.enabled: true + both syscall detectors
• event.serialize-pe: true + event.serialize-modules: true — richer alert context
• pe.enabled: true + read-resources / read-symbols / read-sections: true — full PE metadata in alerts
• symbolize-kernel-addresses: true + symbol-paths pointing at MS symbol server — readable kernel call stacks
• yara.enabled: true (with rules under Rules\Yara\) — third detection vector on top of rules + evasion

---

See also

• EDR Integration — overview of both kinds
• Whiskers Agent — agent install / endpoints
• Elastic Defend Setup — kind: elastic walkthrough
• Fibratus docs — full configuration reference