Verdict Dfir

VERDICT is DFIR (digital forensics & incident response) for agents — a typed, read-only, audit-chained forensic tool surface any AI agent can plug into and drive. Point an agent at a Windows-host investigation (memory images, EVTX logs, disk artifacts, network captures) and it works through 45 narrow, schema-validated, read-only MCP (Model Context Protocol) tools, so every Finding cites the exact tool call that produced it. The result is an evidence-bound verdict backed by a cryptographic chain of custody any third party can verify offline. The three verdict words are scoped tightly: SUSPICIOUS means reportable evidence was found, INDETERMINATE means coverage was too limited to scope a clearance, and NO_EVIL means no reportable finding in the artifacts actually examined. NO_EVIL is never a whole-environment clean bill of health: coverage is bounded, and what was not examined is not the same as absent.

The two tool servers are standard MCP — any MCP-capable agent can connect to them. VERDICT runs in three modes, and it matters which one you're in:

1. Default — deterministic engine. scripts/verdict <evidence> runs a headless detection engine (curated DFIR signature logic + ACH scoring) over the same typed tools and custody spine — zero LLM calls (token_usage: llm_api_calls 0 in the committed trace). This is the proven, benchmarked path.
2. Interactive analyst. Run claude in this repo and type /verdict <evidence>: that Claude Code session becomes the analyst — it opens the Case, drives the tools, runs the verifier, and signs the verdict, with no separate application server.
3. Agent mode (opt-in, experimental). scripts/verdict --agent swaps the pools for a provider-agnostic LLM tool-use loop (Claude, OpenAI-compatible, or local endpoints). Currently live-verified on single-artifact evidence (e.g. one EVTX); not yet proven at disk/memory scale.

None of these is an autonomous responder: the verdict, custody, and verification guarantees are enforced by deterministic code either way — before any Finding reaches the report the verifier re-runs every cited tool to confirm its output reproduces. Replay reproduces the operation; it does not validate the interpretation.

The tools give any agent a read-only forensic surface; the verdict, custody, and verification guarantees come from VERDICT's orchestration layer (the verifier, the ≥2-artifact-class gate, the dual-pool ACH (Analysis of Competing Hypotheses), and the signed manifest) — included here, driven by the reference agent today. "DFIR for agents" means forensic tools that agents operate — not forensics of what an agent did.

• Plug it into your agent — two standard MCP stdio servers (34 Rust + 14 Python tools); point your agent at memory/disk/EVTX/PCAP and it has a forensic verb set in seconds.
• Stay read-only by design — no execute_shell; every tool is a narrow, schema-validated read-only verb, and evidence is hashed first and never mutated.
• Verify it offline — runs seal into a hash-chained audit log → Merkle root → signed manifest; manifest_verify confirms the whole chain offline.

VERDICT ecosystem — what is what

VERDICT is a local-first DFIR (digital forensics & incident response) agent platform, split into three repos:

Runtime flow: caseforge (controls + guards) → verdict binary (runs the agent) → this repo's findevil MCP tools (do the forensics) → hash-chained custody → caseforge verify.

Two rules everything obeys: the LLM is not the forensic source of truth (findings must cite a tool_call_id + output_sha256 + verified manifest); real evidence stays local by default.

Install and run

One-liner — clones the repo and runs setup:

curl -fsSL https://raw.githubusercontent.com/TimothyVang/verdict-dfir-beta/main/install.sh | bash

This is a convenience wrapper around the steps below, not a standalone binary download. VERDICT is a real forensics toolchain, so the wrapper still needs git and a Claude Code credential present (the preflight requires one; see below); on a bare machine it relies on the official Rust/uv/Node installers (driven by setup's --bootstrap). It will not run a Case by itself — it gets you to a green scripts/setup. Prefer to see every step? Run them yourself:

git clone --depth 1 https://github.com/TimothyVang/verdict-dfir-beta.git verdict
cd verdict
bash scripts/setup            # toolchain + DFIR binaries + both MCP servers + preflight doctor
scripts/verdict <path-to-evidence>

Before your first Case you also need a Claude Code credential: a logged-in claude, CLAUDE_CODE_OAUTH_TOKEN, or ANTHROPIC_API_KEY. The preflight doctor checks for one before any run, so scripts/verdict will not start a Case without it — even though the default deterministic engine itself makes zero LLM calls (the credential is exercised only by the interactive analyst path and agent mode's default claude_cli backend). scripts/setup will go green without it; a Case will not.

Point it at supported evidence — a memory image, EVTX log, disk image (.E01 / .dd), packet capture, Velociraptor collection, or a whole multi-host case folder. Output lands in tmp/auto-runs/<case-id>/. Unsupported formats degrade to custody/limitation records rather than a broad clearance claim.

Prefer Claude Code interactively? Run claude in the repo and type /verdict <evidence> or investigate <evidence>.

Get test evidence

The repo's evidence/ directory ships empty — real forensic images are far too large to host on GitHub. Drop your own evidence into evidence/ (or point $FINDEVIL_EVIDENCE_ROOT at wherever you keep it) and run scripts/verdict <image>.

An operator-hosted, view-only Google Drive folder also carries an organized DFIR artifact set used for local VERDICT testing:

https://drive.google.com/drive/folders/1j4nPm3vjAcRwVdKOauIVc8yurxoADhOv?usp=drive_link

The folder is organized by artifact class (disk-images/, memory-images/, network-captures/, windows-event-logs/, mixed-cases/, security-datasets/, and derived-artifacts/). Browser downloads work from the Drive link. For CLI downloads, rclone still needs the downloader to configure their own Google Drive remote, even though the folder is view-only:

rclone config create gdrive drive scope drive
rclone copy --drive-root-folder-id 1j4nPm3vjAcRwVdKOauIVc8yurxoADhOv gdrive: ./verdict-dfir-artifacts --progress
scripts/verdict ./verdict-dfir-artifacts/network-captures/nitroba/nitroba.pcap

The Drive folder is a convenience artifact mirror, not a GitHub release asset. Honor upstream dataset licenses and prefer the canonical public sources below when redistribution terms require using the original host.

Public datasets you can download to try VERDICT, mapped to the path each exercises:

SANS DFIR. The SANS SIFT Workstation — VERDICT's recommended disk-image parity path — is a free download from the SANS DFIR community page. Note: the enterprise multi-host scenario in our own showcase (a domain controller + file server, the kind used in SANS FOR508-style labs) is course lab material and is not publicly redistributable — use the public datasets above to reproduce that class of investigation.

What you get

Every run writes a self-contained case directory:

Reproduce a finding

Don't trust the model. Reproduce the finding. Every Finding cites a tool_call_id; the verifier re-runs that exact tool call, compares the output hash, and re-extracts the value the Finding claims, so a third party can replay the chain offline.

Worked example, committed for spot-checks: Finding f-A-evtx-audit-log-cleared cites evtx_query tool call tc-002. Its cited output, SHA-256, verifier replay, and coverage state are in docs/release-evidence/; the offline-verification recipe is in docs/cryptographic-attestation.md. After any run, confirm tmp/auto-runs/<case-id>/manifest_verify.json reports overall: true.

A match proves the cited operation reproduces and the custody chain holds. It does not validate the interpretation; that stays the examiner's call.

See it run

Every capture below is from a real VERDICT run, not a mockup — except the fact-fidelity clip, which replays a recorded tool output to isolate the real decision logic (flagged at that clip). Full gallery: docs/showcase/.

Videos

Short, narrated walkthroughs on YouTube (@ImTimothyVang), built from the same Remotion pipeline (scripts/make-demo-video/, see CAPTURE.md). Hosted, not committed.

Building or re-voicing them: bash scripts/make-demo-video.sh --all (local Piper voice by default; TTS_ENGINE=elevenlabs for the cloud voice).

How it works

Every Case runs the same nine-stage pipeline, each stage landing live on the dashboard as it completes:

1. Evidence locked — case_open SHA-256s the evidence and opens a read-only Case.
2. Persistence pool — the first analysis pool forks as a subagent and hunts persistence with the typed DFIR tools; every Finding cites the tool_call_id that produced it.
3. Exfiltration pool — a second pool works the same evidence in parallel with an exfil-biased prior, so competing hypotheses surface instead of hiding in consensus.
4. Cross-check — detect_contradictions flags disagreeing Findings before anything merges.
5. Verify — the verifier re-runs each cited tool, compares output hashes, and re-extracts the value the Finding asserts from that output; a Finding whose output drifted, or whose asserted value isn't actually in the evidence, is rejected (fact-fidelity).
6. Weigh — judge_findings merges by claim with credibility weighting; execution claims need ≥2 artifact classes or stay HYPOTHESIS.
7. Correlate — correlate_findings stitches the survivors into one attack story.
8. Sign — manifest_finalize seals the run into a hash-chained, Merkle-rooted, signed manifest.
9. Report — the analyst report and the verdict.

Three design choices carry the weight:

1. A typed MCP tool surface — no execute_shell. 45 narrow, schema-validated product tools: 32 Rust DFIR tools (case_open, vol_pslist/psscan/psxview, mft_timeline, evtx_query, hayabusa_scan, yara_scan, registry_query, prefetch_parse, pcap_triage, and allow-listed long-tail wrappers) plus 14 Python crypto/analysis tools. Copyleft and source-available engines (Hayabusa, pandoc, tshark, Volatility 3, Velociraptor) are invoked as subprocesses only, keeping the Apache-2.0 tree license-clean.
2. A cryptographic chain of custody. Hash-chained audit log → Merkle root over canonical-JSON tool outputs (computed by the Python manifest builder, mirroring rs_merkle semantics) → a signed manifest. The default signer is a local Ed25519 key that verifies offline; Sigstore/Rekor is the identity and transparency-log tier. manifest_verify checks the chain and root offline, and customer-release candidates carry an expert-signoff packet. This is about integrity and offline replayability, not admissibility; the courtroom framing (FRE 902(14)) and its caveats live in docs/cryptographic-attestation.md.
3. Analysis of Competing Hypotheses as agent topology. Two pools investigate the same evidence with opposing priors. Their disagreements are emitted as first-class kind=contradiction records before a credibility-weighted judge merges them — surfaced, not hidden. Two pools do not prove truth; the replayable tool-output chain does.

How the agent teams actually solve a case — a supervisor forks the persistence-biased Pool A and exfiltration-biased Pool B in parallel over the typed read-only tool surface (with cross-case memory for recall), their disagreements surface before a verifier → judge → correlator reconcile them, and every step lands in the hash-chained custody record:

Findings follow a strict epistemic hierarchy — CONFIRMED (≥2 corroborating artifact classes, verifier-passed) > INFERRED (derived from confirmed facts) > HYPOTHESIS — and execution claims require at least two artifact classes.

Maturity note. The long-tail verbs (vol_run, ez_parse, plaso_parse, mac_triage, cloud_audit, journalctl_query, login_accounting, ausearch, nfdump_query, suricata_eve, indx_parse) are typed, allow-listed, and unit-tested against fixtures, but not yet exercised on real evidence in a committed run. Committed sample runs exercise the core disk / registry / EVTX / MFT / Prefetch / Hayabusa / USN / PCAP and vol_* memory paths (each with a real tool call in a committed audit.jsonl; see Results). yara_scan, sysmon_network_query, zeek_summary, vel_collect, and browser_history are typed and fixture-tested but not yet in a committed real-evidence run.

Architecture

The whole workflow as one picture — every boundary is crossed only through a typed, read-only tool whose output is hash-chained into custody: the read-only evidence vault → SIFT tool subprocesses → two typed MCP servers → the Claude Code agent loop → cryptographic custody → the presentation layer, with trust boundaries marked.

The same pipeline mapped to the repository — entrypoints (scripts/), the agent loop governed by agent-config/, the .mcp.json surface (product servers findevil-mcp + findevil-agent-mcp = 48 audit-chained tools, plus the n8n / playwright / puppeteer / qmd convenience servers that never emit findings), the SIFT DFIR tools, the read-only evidence vault, the custody chain (audit.jsonl → manifest_finalize → manifest_verify), and the outputs:

Trust-boundary detail and the agent topology are in docs/architecture.md.

Fact-fidelity — a finding can't assert a value that isn't in the evidence

A valid tool_call_id proves a finding points at real, unchanged evidence — not that the model read it right. So a CONFIRMED finding declares the structured value(s) it claims, and after the cited output reproduces, a pure, LLM-free check re-extracts each value from that output: a misread (a value not in the evidence) is rejected before it can reach the Verdict, and the recorded fact is the value the parser read, not the model's transcription. This is structured-value fidelity — registry / EVTX / prefetch / MFT / USN fields — not "hallucination solved": interpretation has no deterministic oracle and stays HYPOTHESIS, human-owned. See it catch a misread on purpose with FIND_EVIL_FAULT_INJECT=entailment_misread_once, or run python3 scripts/entailment-demo.py. Details: docs/fact-fidelity.md.

Capabilities

• Disk and memory in one Case. With local Sleuth Kit/libewf support or in SIFT mode, it opens raw/E01 images read-only and extracts $MFT, registry hives, EVTX, and Prefetch (disk_mount / disk_extract_artifacts / disk_unmount), then analyzes memory in the same Case. Raw disk with no supported mounted/extracted content stays custody-only and honestly INDETERMINATE. Supported disk images can be parsed locally through Sleuth Kit direct-read when prerequisites are present; case_open alone remains custody-only, and unsupported artifact classes stay as named limitations. (tool inventory)
• Self-verifying Findings. verify_finding re-runs each cited tool call and confirms the output SHA-256 still matches; detect_contradictions raises pool conflicts as first-class records before the judge merges — so a third party can independently replay the chain. (tools)
• Fleet scale. Run a whole estate, not one box: the investigate → correlate → render pipeline produces a single cross-host FLEET_REPORT surfacing signals that only appear across machines — the same uncommon process on many hosts, near-simultaneous process-creation waves, MITRE-technique spread. (On a 22-host SANS estate it correlated the same uncommon image across 20 of 22 hosts; per-host custody still required.) Runs in the SANS SIFT VM (fleet analysis) or per-host locally with no VM (whole-case local run).
• Optional post-verdict action. When the operator deploys an n8n workflow, a verdict can drive a notification, ticket, or containment step. Out of the box no workflow is deployed, so the step records as skipped. Either way it sits outside the audit chain — never evidence, never a Finding.

Accuracy and scope

If no parser or tool extracts an artifact class, VERDICT cannot reason over it — that is the trust boundary, not a footnote. Every run writes a coverage_manifest.json sidecar (and embeds the same object in verdict.json) with one row per artifact class. The strongest claim is not "the AI reviewed the whole image"; it is that the cited artifacts were examined through replayable tools. Disputed or unsupported leads stay visible as contradictions, HYPOTHESIS, or analysis_limitations.

Accuracy is measured against published answer keys, not asserted. The repo ships small answer keys under goldens/; large fixtures are staged with scripts/fetch-fixtures.sh, then scored with scripts/score-recall.py tmp/auto-runs/<case-id> --golden goldens/<case-id>. Method, corpus shape, false-positive controls, and honest limits are in docs/accuracy-report.md; local evidence/ drop-zone cases that have committed score keys are mapped in docs/evidence-answer-keys.md; and the adversarial "break VERDICT" challenge is in docs/red-team-challenge.md. A compact committed execution trace for reviewer spot-checks lives in docs/release-evidence/: Finding f-A-evtx-audit-log-cleared maps to evtx_query tool call tc-002, with verifier replay and token usage recorded.

Results: what's reproducible

VERDICT is scored on two axes against published answer keys: does it surface known activity, and does it refuse to overclaim when coverage is thin. The scored rows below have committed receipts and are reproducible with scripts/score-recall.py; full method and caveats are in docs/accuracy-report.md.

On the local-runnable corpus, 9 of 9 cases pass (aggregate recall 23/27 = 85%; measured 2026-07-01, docs/benchmark/RESULTS.md; manifest_verify overall:true on every run) — Nitroba, NIST, and seven EVTX / control cases. NIST now passes at its 71% floor. The larger gated disk/memory goldens (19 cases) are fixture-staged and not yet run, with no number fabricated. A staged control is alihadi-09-encrypt (dual-use crypto should not become an overconfident SUSPICIOUS).

Artifact classes proven on committed runs

Each is backed by a real tool call in a committed audit.jsonl:

• Disk: raw/.E01 mount + extract, $MFT (mft_timeline), registry hives (registry_query), Prefetch (prefetch_parse)
• Windows event logs: evtx_query, plus a Hayabusa/Sigma sweep at lead-tier (hayabusa_scan)
• NTFS USN journal: usnjrnl_query
• Network: PCAP triage (pcap_triage)
• Memory: Volatility 3 active list, pool scan, cross-view, injection (vol_pslist, vol_psscan, vol_psxview, vol_malfind)
• Custody intake: case_open SHA-256 over the evidence

The long-tail verbs (vol_run, ez_parse, plaso_parse, mac_triage, cloud_audit, journalctl_query, login_accounting, ausearch, nfdump_query, suricata_eve, indx_parse) plus yara_scan, sysmon_network_query, zeek_summary, vel_collect, and browser_history are typed and fixture-tested, not yet exercised on real evidence in a committed run.

Wins, with the receipt

Suspicious log clearing caught with full custody, zero LLM calls. A fresh deterministic run on the public EID 1102 Security-log-clear fixture, signed and offline-verifiable:

seq  1  tool_call_start   case_open    tc-001
seq  2  tool_call_output  tc-001   output_sha256 a0615707…   (= the evidence SHA-256)
seq  3  tool_call_start   evtx_query   tc-002
seq  4  tool_call_output  tc-002   output_sha256 3d3dd694…
seq 17  finding_approved  f-A-evtx-audit-log-cleared  cites tc-002  (T1070.001)
verifier replay matched : true
manifest_verify          : overall true · ed25519 signature_verified · merkle c7f9a8bf…
token_usage              : llm_api_calls 0 · total_tokens 0   (deterministic headless path)
coverage                 : parsed [custody, evtx] · not_supplied [disk, memory, network, velociraptor] · 7 ATT&CK blind spots kept visible

That output_sha256 3d3dd694… and finding ID reproduce in the committed trace (docs/release-evidence/evtx-security-log-clear-trace-summary.json). Run it and compare.

Custody you can verify offline. Every run seals into a hash-chained audit.jsonl, a Merkle root over canonical tool outputs, and an ed25519-signed manifest:

manifest_verify : overall true · audit_chain_ok · leaf_count_ok · merkle_root_ok · entailment_ok · ed25519 signature_verified

→ docs/release-evidence/sample-run/manifest_verify.json

Self-correction under real failure (organic, not injected).

organic     : fault_injection_present false  ("the string fault_injection never appears in the audit chain")
trigger     : registry_query failed on truncated RegBack hives (SAM / SECURITY / SOFTWARE)
adjustment  : course_correction = "narrow (skip this key; continue remaining hive triage)"   x6
escalation  : heartbeat_failure = "escalate" -> honest partial INDETERMINATE over what was examined   x5
audit chain : 311 hash-chained records (excerpt seq 169-183)

→ docs/release-evidence/natural-self-correction-summary.json

Self-correction in code, first-pass. The textbook DKOM signature (vol_pslist=0 vs vol_psscan=124) was refused as a rootkit: OS singletons recovered only by psscan, plus a duplicate System PID, point to acquisition smear, which a rootkit cannot produce. The engine re-sequenced to vol_psxview and scoped to INDETERMINATE, with no post-run patch (docs/accuracy-report.md).

Don't trust the model. Reproduce any row: scripts/verdict <evidence> then scripts/score-recall.py tmp/auto-runs/<case-id> --golden goldens/<case-id>.

Built from practitioner feedback

When VERDICT launched we posted it to r/computerforensics, r/digitalforensics, and r/rust and asked, directly, "where does this break?" Practitioners pushed back hard. They flagged hallucination (a valid tool_call_id proves a finding points at real output, not that the model read it right), two same-model pools converging on a shared blind spot, and court-defensibility. We shipped against that feedback. The headline response is the deterministic, LLM-free **fact-fidelity gate described above, no