把漏洞利用链钉死在真实流量帧上:深入 AntiFox 双图状态机、MITM 证据链绑定与多智能体自愈架构

把漏洞利用链钉死在真实流量帧上:深入 AntiFox 双图状态机、MITM 证据链绑定与多智能体自愈架构

在过去参与的数十次企业级红蓝对抗与安全众测中,我常常陷入同一种痛苦的割裂:面对庞大的攻击面,传统漏扫工具只会机械地堆砌端口和疑似 CVE 的版本比对结果,充斥着海量假阳性;而早期涌现的各类“AI 黑客 Agent”,虽然能够在命令行里天马行空地执行各种渗透指令,但一旦跑出成果,后续复盘往往令人崩溃——它们要么把中间真实的 HTTP 交互数据包随手丢弃,要么在生成报告时严重幻觉,凭空捏造根本无法复现的 PoC 步骤。

开源项目 AntiFox(二次开发自 ARTEX v0.1.1 并全面演进至 v2.0)的出现,彻底切中了这处行业长期忽视的死穴。它没有盲目追求“让大模型通晓所有黑客工具”的虚无跑分,而是把工程重心狠狠砸向了 “证据驱动的交付” 。通过设计全局资产图与单任务探索图并行的“双图架构”、引入 MITM 流量全量录制与 SQLite Trigram FTS5 报文反查机制,AntiFox 让多智能体在执行漏洞利用的瞬间,将攻击链上的每一个输入输出与底层的真实流量帧死锁在一起。在本文中,我将以第一视角深入拆解 AntiFox 的核心状态机设计、多智能体协同机制与交付级证据链落地细节。


一、 架构选型与攻防定位:从“盲目探测”到“证据闭环”

在评估任何自动化渗透测试系统时,我们核心关注两个维度的交点:利用链闭环深度(Exploitation Depth) 与 交付证据可信度(Evidence-Driven Trust)。

长久以来,自动化安全工具的生态分布呈现出明显的极端化:

自动化渗透测试架构选型定位矩阵

如上图的四象限矩阵所示,业界的工具方案往往难以两全:

  1. 第二象限:静态合规与传统漏扫(Nessus、OpenVAS 等)
    • 依赖固化的特征签名与单点盲扫。它们虽然能够给出触发告警时的特定回显片段,但完全缺乏跨接口的业务上下文感知,无法处理“先注册账号、绕过前端校验、提权修改配置、最终触发反序列化”的多步链式利用;
  2. 第三象限:轻量侦察与资产测绘(Nmap、Amass、ScopeSentry 等)
    • 能够高精度绘制域名、IP、端口与服务指纹的静态拓扑,但职责止步于资产梳理,无法进一步探测深层逻辑漏洞;
  3. 第四象限:狂野探索型自主 Agent(早期 ARTEX v0.1、AutoGPT 类脚本)
    • 尝试利用 LLM 的通用规划能力在目标系统内四处打洞。然而这类系统最大的致命伤在于 “挖得到却交不出” :Agent 内部经过数十轮交互确实拿到了回显,但会话上下文一旦溢出压缩,关键的 Payload 与数据包便荡然无存;在最后输出报告时,LLM 只能凭借模糊的短期记忆“脑补”复现过程,造成报告复现步骤失真、甚至全盘造假;
  4. 第一象限:证据闭环型多智能体渗透(AntiFox v2.0)
    • 确立了 “证据即报文、复现即事实” 的工程范式。它将利用链分步结构化就地落库,并将每一步无缝锚定到 MITM 代理抓取的原始流量包上,最终由内嵌渲染引擎直接输出面向客户的高质量三语工业级 .docx 交付报告。

二、 纵深分层架构全景:单二进制内的微内核宇宙

从工程实现上看,AntiFox 采用了极具实战考量的现代化 Go 单体架构(Go 1.24+)。整个平台的前端基于 Next.js 构建,在发布时通过 go:embed 直接内嵌编译进 Go 单一可执行文件中;底层状态存储依托 PostgreSQL(关系拓扑与向量),流量抓取与报文检索则由纯 Go 实现的 SQLite(modernc.org/sqlite)独立支撑。

我将整个系统的架构逻辑自顶向下梳理为四大层级:

AntiFox 分层系统架构全景

整个系统自顶向下紧密咬合:

  • Layer 1: 交互呈现与接入控制(Presentation & Ingress)
    内嵌的 Next.js 前端提供了全栈可观测控制台,涵盖目标资产看板、任务探索拓扑树、漏洞利用链可视化展示、报文级流量探针与三语国际化支持。所有 API 接口均受多用户 RBAC 矩阵与 JWT 会话机制的严格约束;
  • Layer 2: 任务编排与动态治理(Orchestration & Governance)
    驻留在 Go 后端的事件引擎负责监听双图状态演进。特别关键的是内置的 HITL(Human-in-the-Loop)人机拦截门禁,它能够根据安全工程师预设的正则规则,在 Agent 触发危险指令(如针对生产数据库的写操作或敏感目录删除)时强制挂起等待人工审批;同时,针对上游 LLM 调用,内置了带有熔断自愈(Circuit Breaker)与故障转移能力的连接池;
  • Layer 3: 多智能体协同中枢(Multi-Agent Triad)
    系统彻底摒弃了“单 Agent 包打天下”的脆弱循环,将职责严苛拆分为 MainAgent(人机交互薄代理)、Planner(唯一意图生成器) 与 Worker(沙盒单意图执行器) 三元组;
  • Layer 4: 双图状态机与持久化引擎(Dual-Graph & Hybrid Storage)
    底层的双图状态机是整套框架的大脑中枢。PostgreSQL 承载了跨任务复用的全局资产图与任务专属的探索血缘图;内嵌的 SQLite 配合 Trigram FTS5 引擎实现超大报文的毫秒级检索;而基于 Python 脚本的嵌入式报告生成器则随时待命,负责把结构化证据转译为精美报告。

三、 双图状态机内核:物理资产与认知血缘的锚定解耦

在传统的自主渗透工具中,最容易出现的逻辑混乱就是“资产数据”与“推理逻辑”的混杂。一个系统一旦既要记录“这个 IP 开了哪些端口”,又要追踪“我为什么要去试这个注入点”,上下文极易被大量无序的信息冲垮。

AntiFox 在 db/schema.sql 中通过清晰的解耦方案解决了这个难题:全局共享资产图(Global Asset Graph) 与 每任务独立探索图(Task Exploration Graph)。

3.1 全局资产图:跨任务沉淀的客观真值

全局资产图充当企业的攻击面事实库,存储在 assets 表中。它独立于任何特定渗透任务而存在,记录了包括根域名、子域名、IP 地址、C 段网络、开放端口、Web 服务类型、favicon_mmh3 指纹以及技术栈标签(technologies)等结构化实体:

CREATE TABLE IF NOT EXISTS assets (
    id              BIGSERIAL PRIMARY KEY,
    type            TEXT NOT NULL CHECK (type IN (
                        'root_domain','ip','subdomain','app','service','endpoint'
                    )),
    company_id      BIGINT REFERENCES companies(id) ON DELETE SET NULL,
    task_ids        BIGINT[] NOT NULL DEFAULT '{}',
    domain          TEXT,
    ip              TEXT,
    c_segment       CIDR,
    port            INTEGER CHECK (port BETWEEN 1 AND 65535),
    url             TEXT,
    service_type    TEXT CHECK (service_type IN ('http','other')),
    technologies    TEXT[]  NOT NULL DEFAULT '{}',
    extra           JSONB   NOT NULL DEFAULT '{}',
    ...
);

当多个渗透任务并行或按周期推进时,新的资产发现通过 insert_assets 工具统一沉淀入库。这保证了哪怕某个任务因超时中止,已经打标识别出的物理资产绝不会丢失。

3.2 探索血缘图:可解释的认知推理链

与静态的物理资产不同,一次渗透测试本质上是一场有目标、有分支、有取舍的假设检验过程。AntiFox 在 exploration_nodes 和 exploration_edges 中抽象出一套严格的状态转移模型:

CREATE TABLE IF NOT EXISTS exploration_nodes (
    id             BIGSERIAL PRIMARY KEY,
    exploration_id BIGINT NOT NULL REFERENCES explorations(id) ON DELETE CASCADE,
    kind           TEXT NOT NULL,
    payload        JSONB NOT NULL DEFAULT '{}',
    priority       INT  NOT NULL DEFAULT 0,
    state          TEXT NOT NULL DEFAULT 'open',
    CONSTRAINT ck_node_kind CHECK (kind IN ('begin','goal','intent','fact','finding','hint')),
    CONSTRAINT ck_node_state CHECK (
        (kind='begin'   AND state IN ('open')) OR
        (kind='intent'  AND state IN ('open','running','done','blocked','exhausted','stopped')) OR
        (kind='goal'    AND state IN ('open','met','abandoned')) OR
        (kind='fact'    AND state IN ('confirmed','dismissed','origin')) OR
        (kind='finding' AND state IN ('confirmed','dismissed')) OR
        (kind='hint'    AND state IN ('active','consumed'))
    )
);

节点之间的因果血缘由 exploration_edges 严格串联,支持四类语义关系:

  • spawns:上一轮推理衍生出新的探索意图;
  • derived_from:某个事实基于上一级节点的证据推导而出;
  • yields:一次意图的执行结出了具体的事实或漏洞成果;
  • proves:确凿的漏洞节点(finding)最终证明了宏观任务目标(goal)的达成。

3.3 锚点互联:让虚拟推理扎根在物理世界

探索图中的推理节点是如何与具体的网络资产挂钩的?答案是 exploration_anchors 关联表:

CREATE TABLE IF NOT EXISTS exploration_anchors (
    node_id   BIGINT NOT NULL REFERENCES exploration_nodes(id) ON DELETE CASCADE,
    asset_id  BIGINT NOT NULL REFERENCES assets(id) ON DELETE CASCADE,
    PRIMARY KEY (node_id, asset_id)
);

通过这一轻量锚点设计,系统实现了完美的双向感知:当 Planner 决定对某一 Web 端点展开 SQL 注入测试时,生成的 Intent 节点通过 Anchor 绑定到该 endpoint 资产上;当该端点在后续扫描中被确认为存在漏洞,该漏洞(Finding)所挂载的资产拓扑一目了然。


四、 多智能体三元组编排:职能强解耦与自愈生命周期

在很多开源智能体项目中,开发者容易陷入“Agent 越多越好”的误区,导致智能体之间消息漫天飞舞、执行陷入死锁。AntiFox 在代码架构上展现出了极高的工程克制力:全流程只保留三大角色,且各自的权限边界被物理锁死。

整个协同运转的端到端时序与数据流转,如下图的跨职能泳道图所示:

AntiFox 跨职能端到端渗透与证据链交付泳道图

4.1 Planner:全系统唯一的意图发生器

在 agent/planner.go 中,Planner 的定义极其纯粹:

Planner 是由事件驱动的 LLM 规划器。每当底层资产图或探索图发生变更(经过防抖防雪崩处理),它就会被唤醒,读取当前探索路径,评估任务目标是否达成,并向 Frontier 队列分发 0 到 N 条探索意图。它是全系统唯一的意图生成源。

更为精妙的是其跨唤醒状态维持机制。很多 Agent 每次被唤醒都是一次无状态的会话,容易导致反复生成重复的探测意图。在 AntiFox 中,每个任务持有一个独立的 TodoStore:

type Planner struct {
    ...
    // todos keeps ONE plan-scratchpad per task (keyed by exploration id)
    // so the planner's multi-step plan survives across wake-ups.
    todoMu sync.Mutex
    todos  map[int64]*actool.TodoStore
}

通过这套跨会话的草稿本,Planner 能够制定长跨度的串行利用链,并在每次被唤醒时按步释放下一步意图,而无需把所有并发探测盲目压向目标。此外,Planner 还掌握了 kill_work 与 steer_work 两个强控工具,一旦发现某个 Worker 探测进入死胡同或目标服务发生异常,可随时在运行中动态纠偏或直接强行掐断。

4.2 Worker:单意图沙盒与强制结算门禁

与 Planner 的高瞻远瞩相反,agent/worker.go 里的 Worker 被刻意设计得极其“狭隘”:

  • 单意图约束:一次运行只认领一条处于 open 状态的 Intent,将状态置为 running,执行完成后立即退出。它严禁自主衍生新方向,确保并发动作永远收敛在规划器的射程之内;
  • 软硬双重超时门禁:在真实的渗透测试中,网络工具(如 sqlmap、ffuf 或自主编写的 Python 爆破脚本)极易因连接挂起或防火墙黑洞而无限期卡死。Worker 设置了 runTimeout(软超时)以及在此基础上的 settleHardGrace = 90 * time.Second(硬超时宽限)。

最打动我的,是当 Worker 触碰超时阈值时的强制结算机制(Settlement Round):

const settleWrapUpPrompt = "你即将因预算耗尽被终止。不要再运行任何命令/探测。请依次:" +
    "(1) 把你上面已识别但还没写回的内容逐条写回——新资产用 insert_assets、" +
    "探索结论/事实用 record_fact、确认漏洞用 report_finding;" +
    "(2) **最后单独用一句话纯文本**总结你做了什么、得到哪些关键结论。"

以往的 Agent 在遇到超时或者上下文耗尽时,直接进程退出或报错,前 10 分钟辛苦探测出的端点和密码哈希全随内存灰飞烟灭。而 AntiFox 的强制结算轮会截断一切新的探测行为,强行留出最后一次上下文机会,逼迫大模型把已经到手的战果完整写回 PostgreSQL 数据库。这种对工程细节的严谨把控,保证了系统在恶劣网络环境下的极高鲁棒性。

4.3 MainAgent:操作员的专属操舵接口

在 agent/mainagent.go 中,MainAgent 是人类渗透工程师与底层系统沟通的薄接口。它不直接参与资产扫描,也不自主生成意图,而是扮演着全知观察者与最高仲裁者:

  • 可解释性问答:工程师随时提问“当前发现了什么”、“系统利用到了哪一步”,MainAgent 通过 graph_overview、list_findings 等只读工具快速总结汇报;
  • 意图注入与操舵:当工程师发现某处逻辑有可疑漏洞需要重点深入时,可以通过 MainAgent 调用 add_hint 向 Planner 施加规划偏好,甚至直接调用 add_intent 强行插入一条最高优先级的指令让 Worker 立即执行;
  • 漏洞终核落库:当任务结束或暂停时,MainAgent 会遍历探索图中的有效事实,查漏补缺,确保所有经实机验证的风险项均被规范地调用 report_finding 固化。

五、 证据驱动的交付内核:MITM 流量绑定与报文级反查

如果说双图和多智能体是 AntiFox 的骨架,那么 v2.0 引入的证据驱动交付引擎 则是它最具杀伤力的灵魂。

在安全工程实践中,很多甲方安全工程师拿到第三方给出的渗透报告时,最头疼的就是“只给结论不给报文”:报告写着“某接口存在水平越权”,但到底发了什么 Header、Cookie 结构如何、响应返回了哪些关键字段,一概语焉不详。工程师想去复现,往往还要自己重新抓包配参数。

AntiFox 从根本上推翻了这一落后流程。

5.1 全链路透明录制与 SQLite Trigram 检索

在 traffic/traffic.go 中,AntiFox 启动了一个基于 github.com/lqqyt2423/go-mitmproxy 的内嵌 MITM 代理。所有 Worker 在调用 Kali 工具链、执行 HTTP 请求时,流量必须强制通过该代理出口。

每一笔进出目标的 HTTP Exchange(请求行、全部 Header、完整的明文 Body、响应状态码与响应体)均被分门别类归档在磁盘目录中,并在纯 Go 实现的 SQLite 中构建极速元数据索引:

const indexSchema = `
CREATE TABLE IF NOT EXISTS exchanges (
  id           TEXT PRIMARY KEY,
  ts           INTEGER,
  host         TEXT,
  method       TEXT,
  url_template TEXT,
  url          TEXT,
  status       INTEGER,
  content_type TEXT,
  req_len      INTEGER,
  resp_len     INTEGER,
  path         TEXT
);
`

为了解决安全分析师在海量流量中定位特定敏感特征(如反序列化特征头、特定环境变量泄露、报错回显等)的性能难题,AntiFox 创新性地引入了 SQLite Trigram FTS5 全文索引:

CREATE VIRTUAL TABLE IF NOT EXISTS bodies 
USING fts5(req, resp, id UNINDEXED, tokenize='trigram');

Trigram(三元语法分词)是处理非自然语言、混杂代码与二进制报文最有效的算法。借由这一底层设计,分析师哪怕只记得响应报文里的某半截 Hash 或关键字,也能在数万条数据包中毫秒级检索定位。

5.2 步骤与报文的就地死锁:trafficResolver

漏洞的复现过程绝不是事后大模型大篇幅凭空生成的,而是在 Worker 发现漏洞的一瞬间,由 trafficResolver 钩子就地落库:

{
  "entry_point": "POST /api/v1/auth/reset-password",
  "prerequisites": "注册普通权限测试账号 user_test",
  "steps": [
    {
      "step_index": 1,
      "description": "构造恶意 Host 头部触发密码重置邮件投毒",
      "request": "POST /api/v1/auth/reset-password HTTP/1.1\nHost: evil.attacker.com\n...",
      "expected": "HTTP/1.1 200 OK 且邮件内容重置链接指向 evil 域名",
      "proves": "确认存在未校验 Host 头的凭据接管漏洞"
    }
  ],
  "provenance": "worker_03_run_18"
}

在调用 pg.LinkFindingTraffic 时,系统将该 Finding 节点与底层 SQLite 库中捕获的唯一 exchange_id 深度绑定(存储在 finding_traffic 表中)。

在前端界面中,工程师点击漏洞复现链的任意步骤,界面右侧立刻呼出该步骤对应的真实流量报文。报文本身就是无可辩驳的证据,彻底告别了“靠截屏拼报告”的石器时代。

5.3 工业级三语 DOCX 渲染流水线

在完成测试后,报告的导出无需人工排版。report/docx.go 和 report/pybuilder/report_builder.py 构筑了一条确定性的渲染流水线:

  • Go 后端从 PostgreSQL 中抽取经过 AI 富化(CVSS 评分、风险影响分析、修复加固建议)并关联了报文证据的结构化 JSON;
  • 调用内嵌的 Python 独立渲染器,借助 python-docx 库生成排版严谨的 .docx 文档;
  • 包含标准报告封面、自动目录、合规测试方法论、按高危/中危分级的漏洞汇总表,以及图文并茂、代码带高亮底色的详细复现步骤;
  • 原生支持简体中文(zh-CN)、繁体中文(zh-TW)以及英文(en-US)三种输出格式,真正实现了测试结束即交付。

六、 人机协同防御红线:HITL 拦截与双刃剑反思

作为一个兼具自主推理与实际攻击能力的框架,“如何防止 AI 彻底失控” 是任何负责任的安全研发必须直面的硬红线。

在网络攻防史上,任何自动化渗透利器都具有天然的“双刃剑”属性。甚至包括 Arctic Wolf 等国际威胁情报机构在内的安全团队,也曾在野外观察到恶意黑客尝试将开源渗透框架改造为自动化凭据窃取与云环境横向移动脚本的案例。

正因如此,AntiFox 在底层 intercept/intercept.go 中内置了强制的 HITL(Human-in-the-Loop)规则化拦截系统:

type InterceptRule struct {
    MatchTarget string `json:"match_target"` // tool_name | tool_input
    MatchType   string `json:"match_type"`   // string | regex
    Pattern     string `json:"pattern"`
    Action      string `json:"action"`       // allow | deny | ask
    TimeoutSec  int    `json:"timeout_seconds"`
}

针对高危敏感场景,系统提供了三重防护网:

  1. 立即放行(allow):对于常见的只读侦察工具(如 whois、静态目录检索),策略引擎直接放行,避免过度打扰操作员;
  2. 绝对阻断(deny):凡是命中诸如 rm -rf、格式化磁盘、直接向非授权内网网段发送探测等不可逆的高危正则,拦截引擎在本地直接扼杀,并向大模型返回阻断原因;
  3. 人工审批(ask):当涉及利用溢出、写入 WebShell 或尝试敏感数据库 Dump 时,Worker 触发挂起状态,前端弹出高危操作审批卡片。如果操作员在预设窗口(如 60 秒)内未做确认,系统自动按超时策略(默认 Deny)降级拦截,确保无人值守时绝不发生越权破坏。

[!CAUTION] 合规责任红线:仅限受控验证
AntiFox 是一套面向授权渗透测试与代码安全研究的学术与工程工具,严禁对任何未经明确书面授权的线上系统发起攻击探测。合规的防御红线是安全工具唯一的生命线。


七、 总结与工程反思

纵观整个 AntiFox 的架构演进,它给所有致力于构建落地级 AI Agent 的工程师上了一堂极具说服力的架构设计课:

  1. 大模型的智能边界不在 Prompt,而在状态机
    很多团队在 Agent 开发上耗费了几个月去雕琢复杂的长篇 System Prompt,却依然无法根除 Agent 迷路和死循环的问题。AntiFox 证明了,将复杂目标拆解为“Planner 唯一规划 + Worker 单意图执行 + 双图血缘约束”的状态机,比让大模型单体去“自由发挥”要可靠上百倍;
  2. “挖得到”是算法能力,“交得出”才是工程壁垒
    在商业级交付场景中,无法稳定复现、没有报文证据支持的漏洞发现,在企业法务和工程审计层面几乎毫无价值。把 MITM 流量录制、Trigram 报文索引与结构化复现链作为第一公民进行建设,才是一个专业安全产品的立足之本;
  3. 软硬超时的双门禁是物理世界与 LLM 的桥梁
    网络环境的复杂性决定了远程探测必然遭遇不可预知的延迟与挂起。强制结算轮(Settlement Round)的设计巧妙地为不可控的网络调用兜底,确保每一轮算力投入都能沉淀为确定性的资产与事实。

AntiFox 让我们看到,当 AI 真正走出空中楼阁式的“Demo 跑分”,走向深水区与真实世界的网络流量、业务状态和交付规范深度咬合时,它所爆发出的那种工业级生产力,才是 Agentic AI 最迷人的未来。


原文链接与参考资料