Skip to content

DayJun/IATO

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

156 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

iato — AI-Driven Automated Post-Exploitation Testing Framework

Version Go React Tauri

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


License

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

About

IATO

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors