Lattice Mind: Teaching LLMs to Hack CTFs Without Inventing Exploits

Hook

Most AI-powered hacking tools try to make LLMs write exploits from scratch. Lattice Mind does the opposite: it gives agents a curated arsenal of pre-built attacks and teaches them when to use each weapon.

Context

If you've watched an LLM try to exploit a web vulnerability, you've seen the problem. The model hallucinates SQL injection payloads that don't work, forgets to URL-encode parameters, loses track of session cookies across requests, and can't tell when it's actually succeeded. Tools like PentestGPT and HackerGPT lean into the dream of fully autonomous AI hackers—agents that discover novel exploits through pure reasoning. The reality is messier: LLMs are great at strategic thinking but terrible at the deterministic grunt work of exploitation.

Lattice Mind takes a different approach. Built by a CTF player tired of babysitting LLM agents through basic workflows, it splits the problem down the middle. A Python automation layer handles everything that should be deterministic—HTTP request permutation, payload encoding, flag pattern recognition, multi-step exploitation chains. An MCP (Model Context Protocol) server exposes 20 tools that let LLM agents orchestrate these workflows: deciding which attack trees to run, mutating requests before dispatch, injecting session tokens, and answering human questions when automated decisions fail. The agent doesn't write exploits. It conducts an orchestra of pre-written ones.

Technical Insight

The architecture centers on YAML decision trees that encode vulnerability detection and exploitation as self-contained workflows. Each tree has guard clauses that determine applicability, confidence scoring for prioritization, and multi-step action sequences with stateful capture substitution. Here's a simplified SQLi detection tree:

name: "sqli_error_based"
applies_when:
  asset_type: "web"
  http_methods_include: ["GET", "POST"]
confidence_seed: 0.7

detection:
  - action: http_request
    method: POST
    path: "/login"
    body: "username=admin'&password=test"
    match_response:
      pattern: "SQL syntax.*error"
      on_match: 
        confidence_boost: 0.2
        transition: exploitation

exploitation:
  - action: http_request
    method: POST
    path: "/login"
    body: "username=admin' OR '1'='1&password={{ captures.bypass_token }}"
    extract:
      flag_pattern: "FLAG\{[A-Za-z0-9_]+\}"

The applies_when guards run before tree selection—if recon determined the target is a web service with POST endpoints, this tree qualifies. The confidence_seed (0.7) gets boosted to 0.9 if the detection phase matches the SQL error pattern. The exploitation phase uses {{ captures.bypass_token }}—if a previous tree extracted a CSRF token or session ID, it gets substituted here automatically.

The MCP server exposes this through stdio JSON-RPC 2.0. When an agent calls start_run(target="http://ctf.example.com"), the MVPSolver pipeline begins: asset classification queries the target for technology fingerprints, recon runs nmap-style port/service detection, tree selection scores all YAML files against context, and exploitation executes the winner. The agent can intercept at key points:

# Agent receives MCP tool call request
{
  "method": "tools/call",
  "params": {
    "name": "mutate_request",
    "arguments": {
      "run_id": "abc123",
      "mutation": {
        "headers": {"X-Forwarded-For": "127.0.0.1"},
        "body": "username=admin'--&password=bypassed"
      }
    }
  }
}

This pattern—deterministic execution with selective LLM augmentation—appears throughout. The framework auto-detects flags with regex after every HTTP response, but if it's unsure (confidence < 0.5), it can call the ask_hitl_question tool to block execution and query the human operator. Session management is explicit: the agent must call set_session_cookies(run_id, cookies) when it notices auth tokens in responses, because the automation layer doesn't assume cookie jar semantics.

The FastAPI REST layer wraps this for persistence. Every run gets a SQLite record tracking state transitions (recon → tree_selection → exploitation → completed), captured values, and HITL question queues. The server enforces single-worker SQLite access—startup fails if the DB is already locked—to prevent race conditions when multiple agents try to mutate the same run's request queue.

What makes this architecture effective for CTFs is the Jinja2-style capture system. Exploitation chains often require extracting a value from response N and injecting it into request N+1—think CSRF tokens, session IDs, or leaked credentials. Instead of requiring custom Python per vulnerability class, trees use capture groups:

- action: http_request
  method: GET
  path: "/api/user/profile"
  extract:
    csrf_token: "<input name='csrf' value='([^']+)'"

- action: http_request
  method: POST
  path: "/api/user/delete"
  headers:
    X-CSRF-Token: "{{ captures.csrf_token }}"

This is Ansible-inspired but rare in offensive tooling. Metasploit modules require Ruby code for state passing. Nuclei templates are stateless by design. Lattice Mind makes multi-step attacks declarative.

The LLM's role is strategic, not creative. It doesn't generate payloads—those live in YAML. It decides which tree to prioritize when confidence scores are close, when to rotate session tokens based on 401 responses, and how to answer HITL questions about ambiguous results. This division of labor is why the system works: exploitation is too brittle for LLM hallucination, but workflow orchestration is exactly where models excel.

Gotcha

The YAML tree execution is strictly serial—one detection/exploitation path at a time per run. If you're scanning a target with 50 potential vulnerabilities, you're waiting for 50 sequential HTTP workflows. There's no parallelization, no async tree dispatch, no fan-out. Tools like Nuclei run hundreds of templates concurrently and finish in seconds. Lattice Mind prioritizes correctness over speed, which makes sense for CTF-style challenges where you're methodically solving one puzzle, but it's a non-starter for broad vulnerability assessment.

Session management is bare-bones to the point of frustration. The agent must manually call set_session_cookies when it detects auth tokens—there's no automatic cookie jar, no session persistence across tree executions, no helpers for extracting tokens from common patterns (Set-Cookie headers, JSON Web Tokens, CSRF meta tags). Modern web scanners like Burp Suite handle this transparently. Here, you're building session awareness into your agent's prompt or accepting that multi-stage authenticated exploits require human intervention. The HITL flow helps, but it's a band-aid on architectural minimalism.

Verdict

Use if: You're building AI agents for CTF competitions or security research and need them to orchestrate complex, multi-step exploitation workflows without reinventing HTTP handling, payload permutation, and flag detection. The MCP interface makes this trivially pluggable into Claude Desktop or Cline, and the YAML tree format is far cleaner than writing Metasploit modules. Perfect for scenarios where you have (or want to build) a corpus of known attack patterns and need smart sequencing, not exploit creativity. Skip if: You need high-throughput vulnerability scanning (Nuclei is orders of magnitude faster), production-grade session management (this is research-quality at best), or LLM-generated novel payloads (everything here is pre-scripted YAML). This is a framework for teaching agents to conduct pre-written exploits intelligently, not a general-purpose pentesting platform. If your workflow is 'spray 10,000 endpoints and see what breaks,' look elsewhere.