前言
之前写过一篇关于 Hermes Agent 的体验文章，当时主要是在终端里跟 AI 对话做安全分析。最近发现 GitHub 上有个
Burp_Hermes 项目，能把 Hermes 直接接入 BurpSuite——右键抓到的请求就能让 AI 分析漏洞。
试了一下，效果出乎意料地好。从 WSL 装 Hermes、到 Burp 接入、到实际测试，踩了不少坑，但最终效果确实值得。记录一下。
环境搭建
我的环境是 Windows + WSL2：
- BurpSuite Professional v2023.6.1 装在 Windows 上
- Hermes Agent 装在 WSL2 Ubuntu 里
- Jython 2.7.3 配置在 Burp 的 Python Environment 里
关键点：Burp 和 Hermes 不在同一台机器上（一个在 Windows，一个在 WSL），所以扩展需要通过
wsl hermes -q 跨系统调用。
踩坑记录
搭建过程中遇到了几个问题，顺便记一下：
- 中文路径问题——Jython 不支持路径里的中文字符，Burp 必须放在纯英文路径下（比如
C:ToolsBurpSuite）
- hermes CLI 参数问题——手动安装的 hermes wrapper 缺少
fire.Fire(main)，导致所有 CLI 参数被忽略。修复后 hermes -q "prompt" 才能正常使用
- WSL 非登录模式——
wsl hermes -q 在非登录 shell 下不加载 .bashrc，找不到 hermes 命令。需要在脚本里手动 source ~/.bashrc
- 编码问题——Java FileWriter 写出的文件在 WSL bash 中产生 null byte，改用 base64 编码传输解决
这些坑花了点时间，但解决后整个链路就通了。
Burp_Hermes 是什么
一个 BurpSuite 的 Jython 扩展，核心功能就四个：
- 🔍 安全分析——右键任意请求，AI 分析可能存在的漏洞
- 🎯 生成 Payload——根据请求参数自动生成 SQL注入/XSS/SSRF 测试 Payload
- 🧪 SQLMap 优化——给出最优的 sqlmap 命令，包括技术选择和 WAF 绕过建议
- 📋 批量审计——多选请求，按风险排序，给出优先测试顺序
原理不复杂：从 Burp 里提取 HTTP 请求内容，拼成 prompt，调 Hermes CLI 分析，结果弹窗显示。
实际测试
我在自己的 WordPress 站点（www.redspear.cn）上抓了一个请求来测试。
测试请求
GET /wp-content/themes/prime-cyber-security/webfonts/fa-solid-900.woff2 HTTP/1.1
Host: www.redspear.cn
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0
Origin: http://123.207.45.199
Referer: http://www.redspear.cn/wp-content/themes/prime-cyber-security/css/all.min.css?ver=7.0
这是一个静态字体文件的请求，没有参数。说实话，我本来没抱太大期望——一个 .woff2 文件能分析出什么？
Hermes 的分析结果
结果让我有点意外。从一个”看起来没什么攻击面”的静态资源请求里，Hermes 分析出了这些：
SQL 注入（4个注入点）
- URI 追加参数——在 .woff2 后追加
?ver=7.0' AND (SELECT 9064 FROM (SELECT(SLEEP(5)))a)，利用主题版本参数做时间盲注
- Referer 头——如果访问统计插件把 Referer 写入数据库，可以 UNION SELECT 探测
- User-Agent 头——MSSQL 时间盲注变体，探测 UA 字段是否入库
- X-Forwarded-For 头——经典 XFF 注入，IP 字段常为数据库记录点
XSS（4个注入点）
- Referer——反射型 XSS，针对后台 Referer 显示或日志分析页面
- Origin——探测 CORS 白名单配置错误
- X-Forwarded-Host——缓存投毒或反向代理错误回显
- Accept 头——针对非标准 Accept 解析的反射探测
SSRF / 路径遍历（5个注入点）
- Origin: 127.0.0.1——探测本地开放端口与管理后台
- Origin: 169.254.169.254——云厂商元数据接口探测（AWS/阿里云/腾讯云兼容）
- Host 头——Host 头 SSRF，探测虚拟主机配置
- URI 路径遍历——
../../../wp-config.php 读取 WordPress 数据库配置
- 空字节截断——
.woff2%00.txt 绕过扩展名限制
WAF 绕过思路（6条）
- 静态资源信任——WAF 通常对 .woff2 等静态资源放宽检查，把 Payload 放在 Header 或尾部参数中
- 双重编码——
%2527（双重 URL 编码），部分 WAF 只做一次解码
- HTTP 参数污染——
?ver=7.0&id=1&id=1' UNION SELECT...，后端取数组最后一个值而 WAF 只检查第一个
- Header 名大小写混淆——
oRiGiN、ReFeReR 绕过正则规则
- SQL 注释填充——
/!50000UNION/ /!50000SELECT/ 伪装 MySQL 版本特性
- Origin 域名混淆——
http://123.207.45.199@evil.com 利用 URL 解析差异绕过白名单
追问功能
分析完之后，Hermes 会自动进入交互模式，可以继续追问。比如我问”接下来优先测什么”，它会基于刚才的分析上下文给出建议，还会自动搜索历史记忆关联之前的事件。
这个功能很实用——不用重新描述上下文，直接在分析结果的基础上深入。
真实感受
优点
- 攻击面发现能力强——从一个静态资源请求里找到了 13 个潜在注入点和 6 条 WAF 绕过思路。人工分析很难这么全面
- 上下文关联——AI 会把请求的 Origin、Referer、Cookie 等所有上下文都纳入分析，不会遗漏
- 可以直接追问——分析完进入交互模式，不用重复描述上下文
- 集成到 Burp 工作流——不用切终端，右键就能用，效率高
槽点
- 环境配置麻烦——需要 Burp + Jython + Hermes CLI 三件套，跨 Windows/WSL 调用有不少坑
- 分析质量取决于请求——有参数的请求（如
?id=1、登录接口、搜索接口）分析效果好，静态资源请求只能猜攻击面
- 响应慢——一次分析要 1-3 分钟，取决于 AI 模型响应速度
- 不能替代人工测试——AI 给的是”可能存在的漏洞”和”建议的 Payload”，实际能不能打穿还得人工验证
适合谁
如果你是
渗透测试新手，这个工具能帮你快速建立攻击面思维——看 AI 怎么分析一个请求，学到很多思路。
如果你是
有经验的安全工程师，可以用它做”初筛”——批量审计大量请求，快速标记高风险目标，然后人工深入。
总结
Burp + Hermes 的组合比我预期的好用。核心价值不是”AI 替你挖洞”，而是
AI 帮你看到你可能忽略的攻击面。一个看起来无害的静态资源请求，AI 能从 Header 的每个字段里找到潜在的注入点。
当然，AI 分析的结果需要人工验证。但作为渗透测试的”第一遍扫描”，效率提升很明显。
参考资料
