如何让 Hermes Agent 用上 BurpSuite MCP？

一、先说两句

现在 AI Agent 越来越火，搞安全的肯定想的是——能不能让 AI 帮我操作 Burp Suite？

Freebuf 上已经有一篇文章讲 OpenClaw 接 Burp MCP 了，但我自己照着配的时候发现几个问题：一是那篇文章主要针对 Linux 环境，我平时用 WSL；二是中间隔了一层 MCPorter，架构有点绕；三是踩坑基本没写——实际配起来根本不是三分钟搞定的事。

所以我换了个方案：用 Hermes Agent。这玩意儿原生就支持 MCP 协议，不用额外装中间件。但坦白说，从零到真正跑通，我花了一整个下午。这篇文章就是把那些坑记下来，给后来人省点时间。

二、两个方案，差在哪

先简单对比一下两个方案的区别。

Freebuf 那篇用的是 OpenClaw + MCPorter 的组合。MCPorter 是个 npm 包，相当于在 OpenClaw 和 Burp MCP 之间加了一层翻译官。架构上是：

OpenClaw → MCPorter → Burp AI Agent → Burp Suite

Hermes 的方案就简单了：

Hermes Agent → Burp AI Agent → Burp Suite

核心结论：Hermes 的架构更干净，但这不代表你没坑踩。

三、开搞之前，先把东西备齐

3.1 你需要什么

我这边环境是这样的：

• 宿主机: Windows 11
• WSL: Ubuntu 22.04
• Burp Suite: 2026.3.x 版本（专业版社区版都行）
• JDK: 必须 21+（后面会讲为什么这是个坑）
• Burp AI Agent 插件: v0.9.0
• Hermes Agent: v0.13+
• Python: 3.11+

3.2 装 Burp 和加载插件

Burp 的安装就不细说了，网上教程一堆。只说一点——JDK 版本一定要 21 以上。我第一次拿 JDK 17 跑最新版 Burp，直接报 UnsupportedClassVersionError，class file version 65.0 啥的。查了半天才发现是 Java 版本太老。

插件下载地址在 GitHub 上：https://github.com/six2dez/burp-ai-agent/releases，下载 v0.9.0 的 jar 包。

加载方式：Burp Suite → Extensions → Add → Extension type 选 Java → 选中下载的 jar 文件。

加载成功之后，Burp 界面会多出一个叫 Custom AI Agent 的标签页。点进去，找到 MCP Server 设置，Host 填 127.0.0.1，Port 填 9876。一定要勾上 Unsafe mode，不然 Agent 只能读不能写，发不了请求。

还有，记得去 Settings → Privacy & Logging，

把 Privacy mode 从 BALANCED 改成 OFF。不然你查到的 Cookie 和 Authorization 全是 [REDACTED]，啥也看不出来。

3.3 装 Hermes

装 Hermes 倒是简单，一行命令：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

但装完之后有两个坑等着你。

坑 1：hermes 命令找不到。
官方装到了 ~/.hermes/hermes-agent/hermes，但没加 PATH。你得手动加：

echo 'export PATH="$HOME/.hermes/hermes-agent:$PATH"' >> ~/.profile

注意是 .profile 不是 .bashrc，WSL 启动时读的是 .profile。我一开始写 .bashrc 里了，source 了三次都没用，郁闷了半天。

坑 2：装完跑 hermes 报缺少模块。

ModuleNotFoundError: No module named 'prompt_toolkit'

补齐一下就好：

pip install --break-system-packages fire prompt_toolkit rich openai requests pyyaml

3.4 网络拓扑

先搞清楚 WSL 和 Windows 之间是怎么通信的：

Burp AI Agent (127.0.0.1:9876)  ← Burp 绑定在本机环回地址
    ↕ netsh portproxy (0.0.0.0:9876 → 127.0.0.1:9876)
WSL → Windows 网关 IP (172.18.x.1:9876)

关键点：WSL 里的 Windows 宿主机 IP 不是 192.168.x.x，而是 vEthernet (WSL) 那个虚拟网卡的地址。在 Windows 上跑 ipconfig 可以看到，一般是 172.18.x.1 这种。

四、踩坑记录——全文最有价值的部分

说实话，前面那些安装配置半小时就搞完了。真正花时间的，是下面这五个坑。

4.1 WSL 网络桥接的两难选择

Burp AI Agent 默认只监听 127.0.0.1——也就是只有 Windows 本机能访问。但我的 Hermes 跑在 WSL 里，WSL 的 127.0.0.1 和 Windows 的 127.0.0.1 不是一回事，它们是各自独立的。

所以我需要让 Burp 监听 0.0.0.0，这样 WSL 才能通过 Windows 的 IP 连上来。

但问题来了——Burp AI Agent v0.9.0 不支持绑 0.0.0.0。你改成 0.0.0.0，MCP Server 直接变 Error，完全起不来。

没办法，只能绑回 127.0.0.1，然后用 Windows 的 netsh portproxy 做端口转发。这条命令把 Windows 的 0.0.0.0:9876 转发到 127.0.0.1:9876：

netsh interface portproxy add v4tov4 listenport=9876 listenaddress=0.0.0.0 connectport=9876 connectaddress=127.0.0.1

然后你遇到了第二个问题："Port in use"。因为你先加了 portproxy，portproxy 把 9876 占了，Burp MCP 再启的时候发现端口被占用，就报错了。

解决方案的顺序很重要：先删 portproxy → 启动 MCP → 再加 portproxy。

一步都不能错。

:: 第一步：删掉旧的转发
netsh interface portproxy delete v4tov4 listenport=9876 listenaddress=0.0.0.0

:: 第二步：在 Burp AI Agent 里勾上 MCP Server Enabled，等它变 Running

:: 第三步：重新加转发
netsh interface portproxy add v4tov4 listenport=9876 listenaddress=0.0.0.0 connectport=9876 connectaddress=127.0.0.1

验证方法：在 Windows CMD 跑 netstat -ano | findstr 9876。看到 127.0.0.1:9876 对应的 PID 是 javaw.exe（不是 svchost.exe），就说明 Burp AI Agent 的 MCP 端口在工作。

这个坑说大不大，说小不小，但新人容易在这卡半小时。

我的 Burp Suite 是 2026 版，java -jar burpsuite_pro.jar 一跑就报错：

java.lang.UnsupportedClassVersionError: burp/StartBurp has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0

翻译成人话：你的 Java 太老了。2026 版的 Burp 编译需要 JDK 21，我装的还是 JDK 17。

解决方案：装 Eclipse Temurin 21 JDK。装完之后用全路径启动：

"C:\Program Files\Eclipse Adoptium\jdk-21.0.11.10-hotspot\bin\java.exe" -jar burpsuite_pro.jar

还有个坑——就算装好了，java -version 可能还是显示 17。因为系统 PATH 还指着的旧 JDK。要么重启终端，要么跟我一样直接写全路径省事。

然后把 Java 版本信息加到 PATH 里，以后启动就不用每次敲那么长一串了。

4.3 Windows 防火墙拦了 WSL

删掉 portproxy 重来，终于 Burp MCP 起来了。但 WSL 里 curl 还是超时：

$ curl --max-time 5 http://172.18.64.1:9876/
curl: (28) Operation timed out

查了半天——Windows Defender Firewall 默认会拦截从 vEthernet 网卡进来的连接。也就是说 WSL 访问 Windows 的 9876 端口被防火墙挡了。

测试环境里最简单的办法是关掉防火墙：

netsh advfirewall set allprofiles state off

当然在生产环境你得加一条放行规则：

netsh advfirewall firewall add rule name="Burp MCP 9876" dir=in action=allow protocol=TCP localport=9876

4.4 CORS/Origin 检查导致 403

端口通了，curl 也能连了。我满心期待地配置好了 Hermes 的 config.yaml：

mcp_servers:
  burpsuite:
    url: "http://172.18.64.1:9876/sse"
    timeout: 300
    connect_timeout: 60

重启 Hermes，连接测试——403 Forbidden。

但我拿 curl 手动测明明是 200 OK 啊？后来发现是 Origin 头的问题。Hermes 的 MCP 客户端用 httpx 发请求时会自动带一个 Origin 头，Burp AI Agent v0.9.0 有 CORS 检查，发现 Origin 不在白名单里就直接拒绝了。

解决办法：在 Hermes 的 config.yaml 里给这个 MCP 服务加上 headers 字段，把 Origin 设为空字符串，这样 Hermes 的 HTTP 客户端就不会发送 Origin 头了。

改了之后重启 Hermes，连接成功。

4.5 所有 tools/call 都是异步的

终于连上了，我兴冲冲地调第一个工具——status，想着看看 Burp 状态。

发出去之后等了半天，返回了一个 202 Accepted。然后就没下文了。结果呢？数据去哪了？

后来看了 Burp AI Agent 的源码才知道，所有 tools/call 调用都是异步的——你提交请求后服务端返回 202，实际结果通过 SSE 连接推回来。如果你只连了一次 POST 就断开，那结果就丢了。

解决方案是写一个封装脚本，自动保持 SSE 连接，等待异步结果。脚本的核心逻辑大概是这样的：

# 1. 开 SSE 连接拿 sessionId
sse = connect_sse("http://172.18.64.1:9876/sse")
session_id = get_session_id(sse)

# 2. 发 POST 请求调工具
post_response = post_message(session_id, "tools/call", {"name": "status", "arguments": {}})

# 3. 从 SSE 连接读异步结果
result = read_sse_result(sse)

我把这个封装成了 burp_mcp.py，一行命令就能调任何工具：

python3 burp_mcp.py tools/call status '{}'
python3 burp_mcp.py tools/call http1_request '{"content":"GET / HTTP/1.1...","targetHostname":"example.com","targetPort":443,"usesHttps":true}'

4.6 隐私脱敏藏了关键数据

又搞定一个问题。我调 proxy_http_history_regex 查 Burp 历史，终于拿到数据了，但看着一脸懵：

Cookie: uuid=...; vulbox_token=[REDACTED]; authorization=[STRIPPED]

Cookie 里的 token 和 Authorization 头全被替换成了 [REDACTED] 和 [STRIPPED]。这哪行啊，我还指望着拿 Cookie 直接发请求呢。

解决方法在 Burp AI Agent 的 Settings → Privacy & Logging 里，把 Privacy mode 从 BALANCED 改成 OFF。改完再查，完整的 Cookie 和 JWT 就出来了。

五、把反复要做的事情写成脚本

踩完坑之后，有两件事每次都要做，太烦了。

一个是调工具。每次都要先连 SSE 拿 sessionId、发 POST、等异步结果，至少五六行代码。我写了个 burp_mcp.py 脚本，把这些全封装了。

另一个是修 portproxy。关了 WSL 再开，有时候 portproxy 就掉了。但加 portproxy 需要管理员权限，WSL 没有。我写了个 fix_burp_portproxy.py，通过 UAC 弹窗来提权，运行时会弹出 Windows 的 UAC 确认框，点确认就行：

python3 fix_burp_portproxy.py fix

两个脚本暂未开源，但核心逻辑在前面已经讲了，照着写就能用。

六、拿 SRC 练个手

工具都调通了，总得找个目标试试吧。我选了一个车企的 SRC，授权范围内的子域有十几个。

流程是这样的：

1. 浏览器设 Burp 代理（127.0.0.1:8080），登录 SRC 平台
2. 浏览器访问目标域名，Burp 自动抓包
3. 我在 WSL 里用 burp_mcp.py 查 Burp 历史

先看看代理抓到什么流量了：

python3 burp_mcp.py tools/call proxy_http_history_regex '{"regex":"target"}' | head -20

返回了登录接口、API 端点、静态资源等请求记录。

然后我逐个测各个子域名能不能访问：

# 对每个目标域名发 GET 请求
python3 burp_mcp.py tools/call http1_request '{"content":"GET / HTTP/1.1\\r\\nHost: example.com\\r\\nConnection: close\\r\\n\\r\\n","targetHostname":"example.com","targetPort":443,"usesHttps":true}'

结果大部分域名返回了 200 或 301，但有三个尤其值得注意——它们返回了 JSON 数据：

countly.example-ev.com: 返回 {"replica_id":"..."}
v-api.countly.example-ev.com: 返回 {"replica_id":"..."}

这是 Countly 分析平台，而且 /i 端点无鉴权就可以写入数据：

curl -s -X POST "https://countly.example-ev.com/i" -H "Content-Type: application/json" -d '{}'
# 返回: {"result":"Success"}

这个点是一个数据污染风险，可以报到 SRC。

另外在登录页的 HTML 里，发现登录组件暴露了一堆内部 API 域名：

• customer-appointment-api.example-ev.com（预约 API）
• service-center-customer-api.example-ev.com（服务中心 API）
• leadscenter-api.example-ev.com（线索中心 API）

这些域名虽然都在授权范围内，但暴露在前端 JS 里算信息泄露，也是一个可报的点。

七、总结

折腾了一下午，总结几点感受：

Hermes + Burp MCP 这套方案确实能用。 架构比 OpenClaw + MCPorter 清爽，不用中间层，原生支持 MCP。51 个工具全量注册，HTTP 请求、历史查询、Repeater、Intruder、Collaborator 都能调。

但也不是完美的。 Burp 社区版的 AI 功能不可用（ai_analyze、ai_passive_scan 这些工具会报错），只能靠 Hermes 自己的 LLM 能力做分析。另外 WAF 是个大问题——Burp 直接发的请求会被 Cloudflare 拦截，必须配合浏览器代理才能拿到真实流量。

下一步的想法是接入浏览器的 MCP 工具，让 Hermes 自己控制浏览器访问目标、Burp 自动抓包、AI 自动分析，实现真正的全自动化。