FindEvil

A locally hosted, multi-agent DFIR pipeline that turns a triage image or an M365 audit log into verified, evidence-anchored findings, a defensible customer report, and a response plan with the analyst, not the model, holding final authority.

Most incident response time is not spent finding the attacker. It is spent re-parsing the same artefacts, re-deriving the same timeline, and arguing with yourself about whether a plausible story is actually true. FindEvil is built to do the repeatable part deterministically, let models do the investigative part in parallel, and then make them prove it.

The name comes from the SANS "Find Evil" poster. The idea is the same: know what normal looks like, so what is not normal stands out.

What It Does

FindEvil takes evidence a responder already has a KAPE triage package, a mounted disk image, a memory dump, a Microsoft 365 Unified Audit Log export and runs it through three layers.

• Collect, deterministically. Parses the MFT, Amcache, Shimcache, registry hives, event logs, scheduled tasks, services, browser history, PowerShell transcripts, user sessions, IIS and Exchange logs, and UAL exports. Runs Hayabusa and Chainsaw with the full Sigma rule set, YARA and capa over flagged binaries, and Volatility over memory. No model is involved; the same input always produces the same evidence.
• Flag with a rule engine. Around eighty hand-written detection rules fire on the collected evidence: persistence, lateral movement, credential access, mailbox forwarding, OAuth consent abuse, impossible travel, LOLBin misuse and the rest. Each rule names the exact events it fired on.
• Investigate with agents. Independent agent runs, on different models, each open the raw artefacts, follow leads, query the local MITRE and Sigma intel database, and write their own findings. They never see each other's work.
• Consolidate and verify. A deterministic consolidator clusters the findings across runs and counts agreement. A verifier role tries to falsify each one. Rule hits that no run corroborated are checked by a separate model against a vendor-noise allowlist and either kept or moved to a suppressed bucket that is retained for audit.
• Report and respond. The analyst confirms or dismisses each finding in the portal, and the customer report is built only from what was confirmed, with remediation grouped as a response loop.

Nothing here reaches the internet. Evidence, models, intel and reports all stay on the network you put them on.

Pipeline Flow

Evidence (triage zip / disk image / memory / UAL export)
    -> artefact detection
    -> deterministic collection
    -> suspicion flagging + deep dives
    -> rule engine
    -> N independent agent investigations (parallel, mixed models)
    -> consensus consolidation
    -> verification + benign suppression
    -> analyst triage in the portal
    -> customer report + response playbook

Verification, Not Narration

Generating a plausible attack narrative is cheap. Verifying one costs tool calls and domain knowledge, and that is where most AI-assisted DFIR falls down.

FindEvil was shaped by its own failures. On one M365 case the agent fleet produced sixteen consensus findings and a manual verification pass dismissed fourteen of them, including both criticals: a "mailbox forwarding" finding where none of the 531 forwarding-class events actually set a forwarding address, a "persistence" finding that was a first-party Microsoft service refreshing its own grant, an "enumeration" finding that matched the tenant-wide baseline exactly.

So the pipeline now bakes the habits in:

• Consensus is counted, not asserted. A finding surfaced by four of four independent runs on two model families is a different thing from one surfaced once. The tier is on the finding.
• Confidence is labelled per claim. Every claim in the narrative is marked CONFIRMED with its source, INFERRED with its reasoning, or SPECULATIVE. Not a disclaimer at the bottom; per claim.
• Inherited labels are distrusted. A parser bucket is not evidence. Actor identity is resolved before intent is attributed, so a Microsoft service principal does not become an attacker.
• Anomalies are base-rated. Fourteen simultaneous mailbox reads mean nothing if the tenant does that 5,000 times a day.
• Everything is explained, not just the alerts. The full operation inventory is surfaced so the one human admin action in the window is not missed because no rule fired on it.
• The analyst decides. Nothing reaches a customer until a person has confirmed it.

Every finding is traceable to the tool execution, the events and the run that produced it. The audit trail is append-only.

The Analyst Portal

The portal is where an engagement lives. Customers upload evidence through it, the worker picks it up, and the analyst works the case in one place:

• Findings with evidence, confidence tier, consensus count and the analyst's confirm or dismiss decision.
• Timeline, IOCs, MITRE matrix and Entities (hosts, users, service principals) derived from confirmed evidence.
• Evidence browser with "explain this" on any artefact, answered by a local model that sees only what you send it.
• Investigations for analyst deep-dive threads, and a Console that opens an interactive, case-scoped agent session with the same typed tools.
• SIEM tab for direct queries over the event index, no model involved.
• Gaps, so the report says what was not collected rather than implying completeness.
• Playbook, below.

Customers see the overview, the conversation thread and the approved report. Everything else is analyst-only by default.

Response Playbook

FindEvil's job sits in two waypoints of the Dynamic Incident Response framework: Verify and Triage, and Scope. Its report is the input to what comes next.

So the nine DAIR step-by-step guides (Joshua Wright, CC BY 4.0) ship inside the product. Each case has a Playbook tab that shows which phase the case is at and lists its own evidence-driven actions grouped the way a responder works them: Scope, Contain, Eradicate, Recover. The customer report's remediation section uses the same grouping, so "which forwards do I kill, which app consents do I revoke, whose password do I reset" reads as a plan rather than a list.

Locally Hosted LLMs

The investigative work does not leave the building.

• Agent investigation runs on GLM 5.3 or Deepseek 4.1 across a four-node NVIDIA Spark cluster the model that tool-calls cleanly, follows the evidence-grounding methodology and corrects itself mid-run.
• Fast triage, verification and the portal's interactive answers run on Qwen 3.8 27B on an RTX 5090.
• Screenshot and image evidence goes to a 122B multimodal Qwen on its own box.

The fleet is a configuration file, not code. Point the roles at different endpoints, run everything on one box, or route to Amazon Bedrock inside your own account over a VPC endpoint. The deployment refuses the public Anthropic API, any model endpoint that is not a private address, outbound WHOIS and threat-intel lookups, and setup-time downloads; an offline bundle carries the Python wheels, the tools and the intel sources for an air-gapped install, on Linux or Windows.

Local models are not treated as oracles. Their output is parsed defensively, counted against each other, falsified where possible, and gated behind a person.

The Short Version

• Deterministic collection and an eighty-rule engine do the repeatable work, every time, the same way.
• Independent agent runs on mixed models investigate the raw evidence; a deterministic consolidator counts who agreed.
• A verifier tries to break every finding; vendor noise is suppressed and kept for audit.
• Per-claim confidence labels, an append-only audit trail, and a human confirm step before anything reaches a customer.
• A portal for the engagement, a report built only from confirmed findings, and a DAIR response playbook on every case.
• Runs entirely on local models, on-prem or air-gapped, with Bedrock as the one sanctioned cloud option.

AI-assisted, not AI-only.