iato — AI-Driven Automated Post-Exploitation Testing Framework

Overview

iato is an AI-driven automated post-exploitation testing framework that provides a unified abstraction layer for multiple Command & Control (C2) frameworks. It exposes C2 capabilities as MCP (Model Context Protocol) tools, enabling AI agents to autonomously plan and execute post-exploitation operations.

Core Value Propositions

Dimension	Description
Unified Abstraction	Single interface adapting to Sliver, CobaltStrike, Mythic, and other主流 C2 frameworks
AI Native	Post-exploitation operations exposed as MCP Tools via mcp-go framework
Orchestratable	Visual Playbook workflow engine with DAG support, conditional branches, and loops
Crystallizable	AI exploratory executions can be automatically crystallized into reusable Playbooks
Observable	Full recording of each node's input/output/state/timing
Auditable	Complete operation chain tracking for compliance and post-incident analysis

Non-Goals

• Does not implement C2 Server functionality (Implant generation, Listener management, etc.)
• Does not replace native C2 UIs, but provides an AI enhancement layer on top
• Multi-tenant/multi-team collaboration not considered in v1.0

---

System Architecture

┌─────────────────────────────────────────────────────────────────────────┐
│ Client (Tauri Desktop App) │
│ Rust Backend + React Frontend │
│ ┌──────────┐ ┌──────────────┐ ┌──────────┐ ┌───────────────────┐ │
│ │Dashboard │ │Playbook Editor│ │Agent Mgmt│ │ Run Inspector │ │
│ └──────────┘ └──────────────┘ └──────────┘ └───────────────────┘ │
└────────────────────────────────┬────────────────────────────────────────┘
│ WebSocket (JSON-RPC 2.0)
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Server (Go) │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────────────────────┐ │
│ │ Agent Manager │ │Playbook Engine│ │ AI Orchestrator │ │
│ │ │ │ (DAG Runner) │ │ (LLM + MCP Client) │ │
│ └──────────────┘ └──────┬───────┘ └────────────┬─────────────┘ │
│ │ │ │
│ ┌──────▼────────────────────────▼──────┐ │
│ │ Execution Interceptor Layer │ │
│ │ (Record / Replay / Crystallize) │ │
│ └──────────────────┬─────────────────────┘ │
│ │ │
│ ┌───────────────┐ ┌───────────────┐ │ ┌────────────────────┐ │
│ │ Event Bus │ │ State Store │ │ │ Persistence │ │
│ │ (async event)│ │ (in-memory) │ │ │ (SQLite) │ │
│ └───────────────┘ └───────────────┘ │ └────────────────────┘ │
└────────────────────────────────────────┼─────────────────────────────────┘
│ WebSocket (JSON-RPC 2.0)
▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Bridge: Sliver │ │ Bridge: CS │ │ Bridge: Mythic │
│ (Go + mcp-go) │ │ (Go + mcp-go) │ │ (Go + mcp-go) │
│ ┌────────────┐ │ │ ┌────────────┐ │ │ ┌────────────┐ │
│ │MCP Server │ │ │ │MCP Server │ │ │ │MCP Server │ │
│ │(HTTP) │ │ │ │(HTTP) │ │ │ │(HTTP) │ │
│ └─────┬──────┘ │ │ └─────┬──────┘ │ │ └─────┬──────┘ │
│ │gRPC │ │ │Aggressor│ │ │GraphQL │
└────────┼─────────┘ └────────┼─────────┘ └────────┼─────────┘
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Sliver │ │CobaltSt │ │ Mythic │
│ Server │ │ rike │ │ Server │
└─────────┘ └─────────┘ └─────────┘

Key Components

Component	Description
Server	Core backend service handling WebSocket API, AI orchestration, Playbook execution, and Bridge management
Bridge	Adapter layer exposing C2 capabilities as MCP Tools. Currently includes Sliver Bridge by default
Client	Tauri desktop application providing UI for connection management, Playbook editing, and AI Console
Shared	Cross-module shared type definitions

---

Prerequisites

Required Development Tools

• Go 1.25.x or later
• Node.js 20.x or later
• npm package manager
• Rust toolchain
• Tauri v2 native dependencies

Note: If you only need to build and run Linux versions of server and bridge, Go is sufficient.

External Dependencies

To enable Bridge to connect to Sliver, a valid Sliver client configuration file is required:

• Example: /root/.sliver-client/configs/root_localhost.cfg

---

Quick Start

Recommended Deployment: Server-Managed Bridge

The simplest way to deploy is using Server-managed Bridge mode. This requires starting only the Server, which will automatically launch the bridge-sliver process.

1. Build the Linux bundle
2. Prepare Sliver client configuration on the target Linux machine
3. Start Server with --bridge-binary and --managed-slivers flags
4. Launch the desktop Client
5. Enter the Server WebSocket address on the Client login page

---

Building

Building Linux Bundle

From the repository root:

./scripts/build_linux_bundle.ps1 -TargetArch amd64

This generates:

• dist/bridge-sliver-linux-amd64
• dist/server-linux-amd64

For ARM64 architecture:

./scripts/build_linux_bundle.ps1 -TargetArch arm64

Building Individual Components

Server:

./scripts/build_server.ps1 -TargetOS linux -TargetArch amd64

Output: dist/server-linux-amd64

Bridge:

./scripts/build_bridge.ps1 -TargetOS linux -TargetArch amd64

Output: dist/bridge-sliver-linux-amd64

Client:

cd client
npm install
npm run build # Frontend build only
npm run tauri:build # Full desktop application

For development:

npm run tauri:dev

---

Running

1. Server-Managed Bridge Mode (Recommended)

Copy the binaries to your target Linux machine:

chmod +x server-linux-amd64 bridge-sliver-linux-amd64

Start the server:

./server-linux-amd64 \
--listen :8080 \
--ws-path /ws \
--bridge-binary ./bridge-sliver-linux-amd64 \
--managed-slivers /root/.sliver-client/configs/root_localhost.cfg

A reference script is available at scripts/run.sh:

sudo ./server-linux-amd64 -bridge-binary ./bridge-sliver-linux-amd64 -managed-slivers /root/.sliver-client/configs/root_localhost.cfg

This mode:

• Server listens on WebSocket API
• Server automatically spawns and manages bridge-sliver subprocess
• Bridge connects to specified Sliver configuration
• Server cleans up managed Bridges on shutdown

2. Manual Bridge Mode

Start Bridge first:

./bridge-sliver-linux-amd64 \
--listen :9001 \
--sliver-config /root/.sliver-client/configs/root_localhost.cfg

Then start Server with explicit Bridge address:

./server-linux-amd64 \
--listen :8080 \
--ws-path /ws \
--bridges http://127.0.0.1:9001

3. Verify Server Health

curl http://127.0.0.1:8080/healthz

Returns ok when Server is ready.

---

Client Connection

The Client login page default address:

ws://127.0.0.1:8080/ws

Connection parameters:

• Protocol: WebSocket (ws:// or wss:// for TLS)
• Host: Server machine IP or hostname
• Port: Server listening port (default: 8080)
• Path: WebSocket endpoint path (default: /ws)

Steps:

1. Start Server
2. Start Client
3. Enter Server WebSocket address on login page
4. Click Connect
5. Upon success, navigate to Dashboard

---

Configuration Reference

Server Parameters

Parameter	Description	Default
--listen	HTTP/WebSocket listener address	:8080
--ws-path	WebSocket endpoint path	/ws
--bridges	Pre-existing Bridge HTTP address	-
--managed-slivers	Sliver config file for managed Bridge	-
--bridge-binary	Bridge executable path for managed mode	-
--bridge-listen-host	Managed Bridge bind host	127.0.0.1
--bridge-base-port	Managed Bridge starting port	19001
--bridge-heartbeat-secs	Bridge event heartbeat interval (seconds)	10
--bridge-ws-client-timeout-secs	Bridge WebSocket client timeout (seconds)	30

Bridge Parameters

Parameter	Description	Default
--listen	Bridge HTTP listener address	:9001
--mcp-path	MCP endpoint path	/mcp
--ws-events-path	WebSocket events path	/ws/events
--sliver-config	Sliver client configuration file	-
--heartbeat-secs	Event heartbeat interval (seconds)	-
--ws-client-timeout-secs	WebSocket client timeout (seconds)	-

---

Data & Logs

Server stores runtime data in ~/.iato:

Path	Description
~/.iato/server-settings.json	Runtime settings persistence
~/.iato/playbooks/	Playbook library
~/.iato/runs/	Playbook execution records
~/.iato/listen-rules.json	Listen Rules persistence
~/.iato/logs/server.log	Server logs
~/.iato/logs/bridge-*.stdout.log	Managed Bridge stdout
~/.iato/logs/bridge-*.stderr.log	Managed Bridge stderr

---

Documentation

• System Design
• Bridge Design
• Server Design
• Client Design
• AI Design

---

License

This project is for authorized security testing only. Use responsibly and comply with applicable laws and regulations.