AllBlue

• 

  AllBlue starts with 15 MCP tools — 3 new Splunk tools (✦) alongside original 12 DFIR tools, webhook live on :8718

• 

  Splunk HEC responding healthy — code 17 confirms the HTTP Event Collector is active and ready to receive AllBlue IOC events

• 

  Splunk alert fires → AllBlue webhook accepts on :8718 → 202 Accepted → autonomous triage session launched in background

• 

  Real SRL-2018 APT findings pushed to Splunk — DKOM rootkit, C2 IP, code injection, hidden service, lateral movement — all confirmed

• 

  HEC healthy + inputs.conf shows allblue-token configured — full Splunk integration verified end-to-end without requiring Splunk ui

• 

  Full autonomous triage on SRL-2018 APT image — Claude runs 4 iterations, 9-step memory agent, findings auto-pushed to Splunk HEC

• 

  SRL-2018 benchmark — 100% precision, 0 false positives, 0 hallucinations. 10 of 14 documented IOCs confirmed autonomously

What is AllBlue?

AllBlue is an autonomous DFIR (Digital Forensics and Incident Response) triage system that connects Claude AI to the toolchain through a custom MCP Server written in Go — now fully integrated with Splunk as both a trigger source and findings destination.

The Splunk integration loop:

1. Splunk alert fires → POST webhook to AllBlue on port 8718
2. AllBlue launches autonomous multi-agent forensic triage
3. Agents query Splunk MCP Server for historical enrichment
4. All findings pushed to Splunk HEC as structured logposesift:ioc events
5. Splunk dashboard shows live IOCs, threat scores, and session logs

What Inspired This

Memory forensics is one of the hardest problems in incident response. A skilled analyst needs hours to triage a single memory image — and even then, rootkits like DKOM actively hide from standard tools. I wanted to build something that could do that work autonomously, with the same rigor a senior analyst would bring, but in minutes instead of hours.

When the Splunk hackathon came up, the integration was natural — Splunk is where alerts come from and where findings need to land. AllBlue becomes the autonomous analyst sitting between Splunk detection and Splunk investigation.

How I Built It

Core architecture — security boundary first:

The LLM cannot run shell commands. It can only call typed Go functions. The MCP server (cmd/sift-mcp/main.go) is the security boundary — architectural enforcement, not prompt-based rules.

New Splunk components added:

• internal/splunk/hec.go — pushes findings to Splunk HEC
• internal/splunk/alert_handler.go — webhook receiver on :8718
• internal/splunk/mcp_client.go — queries Splunk MCP Server for enrichment
• 3 new MCP tools: push_findings_to_splunk, query_splunk_alerts, get_splunk_context

Self-correction: When standard memory plugins return empty output (a rootkit indicator), the agent detects this as an anomaly and runs DKOM-bypass tools automatically — without being told to.

Results — Validated on Real APT Data

Tested on the SRL-2018 Compromised Enterprise Network dataset (DFIR Summit):

Confirmed findings include: external C2 IP (108.79.235.64:33000), DKOM rootkit, 3 malicious processes, SMB lateral movement to 2 hosts, and Active Directory targeting.

Challenges

Splunk auth on a fresh install — Splunk 10.4's --seed-passwd flag didn't write the passwd file correctly on the SIFT VM. Solved by writing the HEC config directly via inputs.conf, bypassing the UI entirely. HEC works perfectly without needing Splunk login.

Rootkit evasion of forensic tools — the DKOM rootkit hides processes from pslist, malfind, cmdline, dlllist — all return empty. The self-correction system detects "empty output on a running system = rootkit" and switches to pool-tag scanning (psscan) which bypasses the linked list manipulation.

LLM hallucinations — solved architecturally. Every finding must pass through internal/validator which tags it CONFIRMED, INFERRED, or UNVERIFIED based on actual tool output. The LLM cannot claim a finding is confirmed unless the Go layer verified it.

What I Learned

Building the Splunk integration showed me how naturally agentic AI fits into the SOC workflow — Splunk is already the detection layer, AllBlue becomes the investigation layer. The findings flowing back into Splunk as structured events means analysts can search, alert on, and dashboard everything AllBlue discovers automatically.

Built With

• anthropic-api
• claude-sonnet-4.6
• gemini-2.5-flash
• go
• log2timeline
• mcp
• sans-sift-workstation
• splunk
• splunk-hec
• splunk-mcp-server
• the-sleuth-kit
• volatility-3
• yara