BlackSnufkin
fb52b1432e
Fibratus EDR profile (kind: fibratus). Pull-from-event-log model, same
shape DetonatorAgent's FibratusEdrPlugin.cs uses: operator configures
Fibratus on the EDR VM with alertsenders.eventlog: {enabled: true,
format: json}; rule matches land in the Application log. Whiskers gains
GET /api/alerts/fibratus/since which wevtutil-queries the log,
extracts <TimeCreated SystemTime> + <EventID> + <Data>, ships the raw
JSON blobs back. The new FibratusEdrAnalyzer mirrors Elastic's
two-phase shape — Phase 1 exec, Phase 2 polls Whiskers — and normalizes
Fibratus's actual schema (events[].proc.{name,exe,cmdline,parent_name,
parent_cmdline,ancestors} + bare tactic.id/technique.id/subtechnique.id
labels) into the saved-view renderer's dict.
Whiskers /api/info now reports telemetry_sources: ['fibratus'] when
fibratus.exe is at C:\Program Files\Fibratus\Bin\, so the
orchestrator can preflight before dispatching. wevtutil's single-quoted
attribute output is parsed correctly.
Dashboard reachability cache (services.edr_health). 30s TTL +
background poller every 15s. Per-probe timeouts dropped 4s/5s -> 2s.
First load post-boot waits at most one probe cycle; every subsequent
load <5ms (cache hit).
GrumpyCats package split: 1085-line monolith into:
grumpycat.py — orchestrator (14 lines)
cli/ — parser, handlers, runner
litterbox_client/ — base + per-domain mixins (files, analysis,
doppelganger, results, edr, reports, system)
composed into LitterBoxClient.
LitterBoxMCP.py rewires its one import. New CLI subcommand
fibratus-alerts and matching MCP tool fibratus_alerts_since pull
Fibratus alerts via a LitterBox passthrough endpoint
(/api/edr/fibratus/<profile>/alerts/since) for wire-checking the agent
without dispatching a payload.
CHANGELOG updated.
39 lines
1.1 KiB
Python
39 lines
1.1 KiB
Python
"""Final `LitterBoxClient` — composes the per-domain mixins onto
|
|
`_BaseClient`. Public callers import this name from `litterbox_client`
|
|
(re-exported in __init__) and treat it as a single class.
|
|
"""
|
|
|
|
from .analysis import AnalysisMixin
|
|
from .base import _BaseClient
|
|
from .doppelganger import DoppelgangerMixin
|
|
from .edr import EdrMixin
|
|
from .files import FilesMixin
|
|
from .reports import ReportsMixin
|
|
from .results import ResultsMixin
|
|
from .system import SystemMixin
|
|
|
|
|
|
class LitterBoxClient(
|
|
FilesMixin,
|
|
AnalysisMixin,
|
|
DoppelgangerMixin,
|
|
ResultsMixin,
|
|
EdrMixin,
|
|
ReportsMixin,
|
|
SystemMixin,
|
|
_BaseClient,
|
|
):
|
|
"""Python client for the LitterBox payload-analysis sandbox API.
|
|
|
|
The class itself is a thin composition: each domain (files,
|
|
analysis, doppelganger, results, EDR, reports, system) lives in its
|
|
own mixin module under `litterbox_client/`, and they all share the
|
|
`_BaseClient`'s requests Session + `_make_request` helpers.
|
|
|
|
Usage stays the same as the pre-split single-file client:
|
|
|
|
with LitterBoxClient("http://localhost:1337") as c:
|
|
result = c.upload_file("malware.exe")
|
|
...
|
|
"""
|