Marten — Self-Correcting Memory Analysis for FIND EVIL

Marten was built entirely during the submission period. Full codebase — 4-phase agent, 14 Volatility plugins, MCP server, self-correction loop — developed from scratch for FIND EVIL 2026.191

Comment

Inspiration

Incident responders inherit massive memory dumps and a clock. Protocol SIFT gives Claude Code a memory-analysis skill that knows which Volatility plugins to run — but no agent checks its own work before writing the report. We wanted that self-correction loop.

What it does

Marten extends Protocol SIFT's memory-analysis skill with a self-correcting Gemini-driven investigation loop. Given a memory image, it runs a 4-phase pipeline — Triage → Deep Analysis → Self-Correction → Report — calling 14 Volatility 3 plugins over SSH into a SIFT Workstation. Every finding carries the tool-call IDs it was derived from, so a reviewer can replay any conclusion back to the exact Volatility output.

On the Rocba memory dump (18 GB Windows 10, SRL FOR508 lab), Marten identified process hollowing (PID 30216), lateral movement via RDP, service persistence, and USB exfiltration — catching a contradiction that signature-based tools missed and confirming it through structural anomalies across three rounds of self-correction.

How we built it

  • Gemini Flash (Vertex AI) as the reasoning engine with function calling
  • 14 Volatility 3 plugins dispatched via gcloud compute ssh into a SIFT Workstation VM — operator machine never touches the evidence file
  • Marten MCP Server exposes the same plugins for Claude Code / Claude Desktop / Gemini CLI
  • Architectural guardrails (code-enforced): read-only evidence, per-call tool budgets, output caps (3-5 KB per plugin), context compression at 80 KB, shell arguments via shlex.quote
  • Prompt-based guardrails: investigation scope, JSON output schema, self-correction convergence

Challenges we ran into

  • Context management: An 18 GB dump produces enormous tool outputs. Three-layer truncation (VM-side head, agent-side cap, context compression) keeps the LLM productive.

Inspiration

Incident responders inherit massive memory dumps and a clock. Protocol SIFT gives Claude Code a memory-analysis skill that knows which Volatility plugins to run — but no agent checks its own work before writing the report. We wanted that self-correction loop.

What it does

Marten extends Protocol SIFT's memory-analysis skill with a self-correcting Gemini-driven investigation loop. Given a memory image, it runs a 4-phase pipeline — Triage → Deep Analysis → Self-Correction → Report — calling 14 Volatility 3 plugins over SSH into a SIFT Workstation. Every finding carries the tool-call IDs it was derived from, so a reviewer can replay any conclusion back to the exact Volatility output.

On the Rocba memory dump (18 GB Windows 10, SRL FOR508 lab), Marten identified process hollowing (PID 30216), lateral movement via RDP, service persistence, and USB exfiltration — catching a contradiction that signature-based tools missed and confirming it through structural anomalies across three rounds of self-correction.

How we built it

  • Gemini Flash (Vertex AI) as the reasoning engine with function calling
  • 14 Volatility 3 plugins dispatched via gcloud compute ssh into a SIFT Workstation VM — operator machine never touches the evidence file
  • Marten MCP Server exposes the same plugins for Claude Code / Claude Desktop / Gemini CLI
  • Architectural guardrails (code-enforced): read-only evidence, per-call tool budgets, output caps (3-5 KB per plugin), context compression at 80 KB, shell arguments via shlex.quote
  • Prompt-based guardrails: investigation scope, JSON output schema, self-correction convergence

Challenges we ran into

  • Context management: An 18 GB dump produces enormous tool outputs. Three-layer truncation (VM-side head, agent-side cap, context compression) keeps the LLM productive.

Built With

  • gemini
  • google-cloud-compute-engine
  • mcp
  • python
  • sift
  • vertex-ai
  • volatility-3
Share this project:

Updates