AI 渗透 20 轮：5 条链打通，12 条链卡住

原创 aerfa21 2026-11-09 06:06 北京

关于AI渗透测试的体验，通用agent + 模型就能干很多事儿，半夜躺在被窝里拿手机就能渗透，并且效果很好~

一、AI 在这套流程里怎么用

起点是 shadowscan 的扫描结果。这些结果不是「疑似」，是已经跑出来的问题。AI 接到的任务不是二次判断真假，而是直接把这些点打成可利用：读前端 bundle、还原接口和签名、按「最可能缺鉴权」给端点排序、拆gRPC/protobuf、把结果整理成报告初稿。

人负责的是给目标、补经验、补资源、纠偏、换视角，以及在关键节点判断「还不够」。授权是评估前提，不在提示词里逐条写。四天大约 8 万次请求，30 条提示词，执行大部分交给模型，方向由人定。

还有一件值得单独说：AI 会写很多脚本工具。资产枚举、签名客户端、gRPC 扫描、证据解析、HTML 转 DOCX，基本都是它按需求现写的。它不只是给建议，能把重复动作固化成可重跑的脚本；但会发请求、会写文件的脚本，边界要人复核。

二、打通的链

2.1 SQL 注入到管理员：WAF 只挡了关键字，没挡语法

注入点在登录接口的 username，原样拼进 SQL。先用引号配额确认：admin 返回 3001，admin' 返回 1502，admin'' 又回到 3001。单引号报错、双引号正常，只可能是字符串拼接。

POST /nmapii/login {"username":"admin'","password":"x"}      → 1502 语法错误 {"username":"admin''","password":"x"}     → 3001 SQL 合法，仅无匹配 {"username":"admin'|1|'","password":"x"}  → 3001 位运算闭合，SQL 合法

WAF 是网络层，不是应用层。把同一个 payload 打到不存在的路径，同样被重置：

/nonexist                 → 401（应用正常响应） /nonexist?a=' or 1=1      → 000（连接重置）  ← 路径不存在也被拦

规则粒度是「引号 + 逻辑关键字 + 操作数」的子句结构。最后用四个盲区打进去：

完整链：注入 → 提 3 个 bcrypt 哈希 → 两个账号 123456 → authorization 裸值 + POST 拿会话 → 员工 token 调管理员接口 → 百余名用户。上传也打通了，filename*=utf-8''x.jsp 绕过 RFC 5987 后缀过滤，但文件落 FastDFS，返回 application/octet-stream，JSP 不解析，shell 到此为止。

2.2 gRPC-Web：WAF 没有 protobuf 的判据

统一用户中心前端走 gRPC-Web，路径前缀是 /api/。请求体是 5 字节帧头加 protobuf，字段靠位置编号标识，没有参数名、没有引号、没有 SQL 关键字。WAF 的规则库围绕文本协议建，遇到字节流没有可匹配的语法；网关又只检查「前缀是否在 /api/ 下」，整个 207 个 RPC 的命名空间都放行了。

POST /api/{service}.TokenV1/CreatePassToken Content-Type: application/grpc-web+proto  00 00 00 00 12 0a 08 6a 6f 68 6e 2e 64 6f 65 ...

对 207 个 RPC 逐个发空 protobuf，34 个返回业务级错误而不是鉴权拒绝。CheckSubjectExist 用手机号直接返回内部 staffId，无验证码、无速率限制。密码重置链走到 CreateCode → CheckCode → UpdateStaffPwdWithCode，CheckCode 4–6 位、95/s、无限速；唯一阻塞是邮件通道 send code fail。

2.3 沙箱签名：不拿 Token，直接还原签名

沙箱 pub 前缀公网可达，get-access-key 匿名返回 2048-bit RSA 公钥（443 字节），签名在客户端算。从 90 个前端 chunk 里还原出两条规则：

uploadFile : sign = RSA_PKCS1v15( filename + browserId ) analysisUrl: sign = RSA_PKCS1v15( url + browserId ) uid = browserId（Fingerprint2 x64hash128，32 位 hex）

上一轮 51 组签名全错，原因很具体：sign 放 query 而服务端从 body 读；明文少拼了文件名；uid=1 不是 32 位 hex。换到 body 后，get-times 立刻返回 {"code":"0","data":"10"}。另一个逻辑缺陷是 X-Gtw-Token：不带 Token 走签名；带任意非空值跳过签名、改走会话；空值又回到签名。服务端写成 if - else if，不是「两者都要」。

签名还原后 6 个样本入队，43 种镜像可选；analysisUrl 接受回环地址、云元数据地址、内网 10 段和 file://，是盲 SSRF。同一时期测绘 API /geoggll/api/search 无鉴权，gov.cn 可查数十万条。

2.4 数据面：四条通道，同一个根因

根因是「只校验登录，不校验权限」。四个接口分布在不同的业务里，修一条不等于修另外三条。

Hub 通道的机制错误很典型：用「报告包下载」接口做「Hub 分发」，/api/hub/skills/<id> 把内部 task_id 暴露出来，/api/reports/<task_id>/package 又只校验 task 是否存在、不校验调用者。应用分发站点则是把下载接口当静态资源，文件名直接带客户身份，解包后能看到客户内网域名。

三、没打通的链

四、可复用的技术点

• 先判 WAF 层级。

  同一个 payload 打到不存在的路径，仍被重置，就是网络层；应用层校验不会拦不存在的路径。

• 引号配额。admin

  /admin'/admin'' 三组响应，能在不触发注入的情况下确认字符串拼接。

• 换语法，不换关键字。

  位运算闭合、1e308 溢出、FIELD/STRCMP/BINARY，都是 WAF 规则没覆盖的语法。

• 换协议。

  看到 application/grpc、grpc-web+proto、x-protobuf、msgpack、cbor，先确认 WAF 认不认识，再谈 payload。

• 找「或 / 与」逻辑。

  带一个非空头就能跳过另一层校验，通常是 if - else if 写错了。

• 信封从真实请求里拿。

  扁平 JSON 全 400 时，用 CDP 抓浏览器请求，不要猜参数名。

• oracle 必做对照。

  33/32 账号「存在」用 4 个随机名推翻；314/316 用 10 个随机号确认；堡垒机 10 组 0 误报。

• 结论指回原始响应。

  指不出状态码、长度、关键字段的，标「未验证」，不写进报告。

五、本次渗透的路径全貌

把成功链、失败链、数据面、资产面放在一张脑图里。中间是结果，六条分支是这次实际走过的路：入口与注入、协议层、数据面、认证与会话、资产面、证伪与卡点。每条分支只放节点名，细节在前四节。

这张图不是攻击树，是评估路径图：哪些路走通了、哪些停在机制上、哪些只是资产或情报。下次遇到同类系统，可以先按分支定位，再决定从哪条链切。

关于AI渗透的思路，其实可以总结出来自己看看，不仅开阔视野更是丰富了思路，同样可以沉淀为知识库供后续渗透使用。

BTW，AI 绕过Waf很牛~

以上渗透基本都是半夜躺在床上，用手机做的。不得不说通用agent + 模型，在渗透测试方面就已经很强了。

跳转微信打开