文章总结： Pentest-Lyan是一套AI渗透测试增强包，通过三阶段串行流程(Discovery、Attack、Audit)将AI对话扩展为完整测试。它强调功能建模而非漏洞清单，要求对每个功能从12个维度建模并验证业务影响。项目通过结构化状态文件实现断点续测和跨角色验证，要求证据充分才能确认漏洞。它是一套可审查的方法框架，适合内部靶场先验证。 综合评分： 85 文章分类： 渗透测试,红队,实战经验

Pentest-Lyan：AI 渗透测试增强包

攻防录

2026年7月19日 06:00 北京

在小说阅读器读本章

去阅读

Pentest-Lyan 把威胁建模、前端 JS 深读、跨角色验证、断点续测和双格式报告打包成一套 Skill。它让 AI 不只会发请求，还能按功能建立威胁模型、验证业务影响，并留下可复查的证据。

项目地址：

https://github.com/HeaSec/Pentest-Lyan

简介

Pentest-Lyan 是一组写给 Claude Code 或 Kimi Code 的工作指令，相当于为现有模型补上渗透测试方法、状态记忆和交付流程。

整个仓库主要是 Markdown、JSON Schema 和一个 Word 报告渲染脚本。真正的测试能力来自 Agent 已有的浏览器自动化或 curl。

项目的核心句子是：

模型负责思考，文件负责记忆。

模型可以临场判断攻击面，但不能只靠对话记住测过什么。Pentest-Lyan 把接口、会话、权限矩阵、模块队列、验证结果和盲区分别写入结构化文件，为断点续测和最终审计留下依据。

技术原理

三阶段串行，把一次对话扩展成完整流程

Pentest-Lyan 将测试拆成 Discovery、Attack 和 Audit 三个阶段。它们严格串行，每个阶段都有独立输入和退出条件。

| 阶段 | 主要动作 | 核心产物 | 不允许省略的点 | | — | — | — | — | | Discovery | 读前端 JS、找接口、建会话池、生成权限矩阵 | js_analysis.json 、api_inventory.json、permission_matrix.json | 独立 JS、内联脚本、引用资产、页面链接、路径推断、响应体六个渠道 | | Attack | 按功能建模，逐条验证，对业务影响做二次确认 | modules/{id}.json 、持续更新的接口与权限矩阵 | 威胁项必须对应验证结果，跨角色测试不能硬编码 victim ID | | Audit | 查缺口、做系统级审计、生成 Markdown 和 Word 报告 | coverage.json 、summary.json、交付报告 | 队列清空、页面功能有结论、漏洞证据齐全后才能出报告 |

Discovery 阶段不只用正则抓 API 路径。指令要求 Agent 完整阅读所有前端 JS，关注签名逻辑、前端校验、localStorage、客户端可控金额与角色字段，还会扫描配置资产中的密钥模式。

项目对“发现”的定义也是动态的。创建订单后响应体出现新回调地址，或上传文件后返回新访问路径，都会追加到“活文件”里，然后立即补做各角色权限比较。

不套漏洞清单，而是对每个功能建模

Attack 阶段以 Feature 为单位。对每个功能，Agent 要从 12 个维度展开自问：

| 类别 | 维度 | | — | — | | 输入与处理 | 数据流、客户端可控值、注入面、文件操作 | | 身份与边界 | 权限边界、资源归属、认证与会话 | | 流程与状态 | 状态变更、并发场景、业务逻辑 | | 输出与外部交互 | 输出展示、SSRF |

这里的重点不是把 12 项都打勾，而是结合功能真正生成 threat_model。每条威胁要有自由命名、推理依据、目标接口和参数，并在 validation_results.tests[] 中找到对应结果。

例如“编辑用户”不会只记一个笼统的 IDOR，而是拆成“编辑他人用户”、“普通用户访问管理接口”、“通过未暴露的 role 字段批量赋权”等具体威胁。这是仓库 Schema 文档里的示意数据，不是真实目标漏洞。

200 只是响应，不是漏洞结论

Pentest-Lyan 对证据的要求很明确：可疑请求成功后，还要查看业务状态是否真的改变。

• 读越权要在响应中看到对方的私有数据。
• 写越权要再次查询资源，确认值已改变。
• 交易篡改要对账余额、账单或数据库结果。
• 竞态要检查最终状态，不能只数多少请求返回 success。

一条 confirmed 漏洞还必须有完整 URL、请求包、响应包和功能访问路径。越权问题要同时保留 baseline 与 attack 两组请求。证据不足时，状态只能是 suspicious。

用“未排除面”防止过早判安全

渗透测试中常见的另一个问题，是一个 PoC 失败就把功能判为安全。Pentest-Lyan 要求每条 not_vulnerable 都必须填写 unruled_out，列出尚未排除的参数变体、时序、角色组合或其他验证方式。

每个 Feature 收口时还要写 coverage_note，回答三个问题：

1. 外部可控输入是否都有结论？
2. 接口、状态变更、并发点和角色组合是否都触及？
3. 安全结论是来自多个合理变体，还是只试了一种姿势？

这个设计没有假装“已经穷尽一切”，而是把仍然存在的不确定性写进结果。

状态文件和 GATE 如何串起来

每个目标使用独立的 pentest-data/{project-id}/ 目录。关键数据流如下：

Discovery
  ├── state.json
  ├── module_queue.json
  ├── sessions/pool.json
  ├── js_analysis.json
  ├── api_inventory.json
  └── permission_matrix.json

Attack
  └── modules/{module_id}.json
        ├── features
        ├── threat_model
        ├── validation_results
        └── cross_role_verification

Audit
  ├── coverage.json
  ├── summary.json
  └── Markdown / DOCX 报告

module_queue.json 使得 Agent 可以中断后用 --resume 续测，多个项目也不会把 Cookie、模块和漏洞结果混在一起。

仓库一共定义了 9 条最终退出条件，并在 gates.md 中将关键门禁归纳为 G1—G7。模块队列没清空、威胁项没对应结果、页面功能没触达且没写 BLOCKED，都不允许生成最终报告。

需要注意，这些 GATE 主要由模型按清单自检，最后仍由用户 Review。仓库提供的 JSON Schema 能约束字段结构，但 schema.md 明确说明当前是“模型写字段时参考，不做机器校验”。它不是一套确定性工作流引擎。

与常见 Agent 渗透对话的差别

| 对比项 | 普通对话式测试 | Pentest-Lyan | | — | — | — | | 测试入口 | 用户点名 SQLi、XSS 等项目 | 先理解功能，再从 12 维度自主建模 | | 进度记忆 | 依赖当前对话 | 写入项目级 JSON 状态文件 | | 越权检查 | 临时换 Cookie 试请求 | 先建权限矩阵，再用真实 victim 资源做跨角色对比 | | 漏洞确认 | 容易把 200 或异常响应当结论 | 要求二次查询或基线对比，验证业务影响 | | 安全结论 | 一个 PoC 无效就收口 | not_vulnerable 必须记录 unruled_out | | 报告 | 对话末尾直接总结 | 9 条退出条件满足后再生成 Markdown 和 DOCX |

快速上手

Pentest-Lyan 的个人级 Claude Code Skill 可放在 ~/.claude/skills/ 下。官方说明也支持放进项目级 .claude/skills/。

1. 将仓库安装到个人 Skill 目录。

mkdir -p ~/.claude/skills
git clone https://github.com/HeaSec/Pentest-Lyan.git ~/.claude/skills/pentest-lyan

2. 配置浏览器自动化。

Pentest-Lyan 依赖 Playwright MCP 完成页面导航、登录、会话池和浏览器内请求。在 Claude Code 中可以按 Playwright 官方方式添加：

claude mcp add playwright npx @playwright/mcp@latest

如果没有浏览器工具，Skill 会退化到 curl，但纯 JS 渲染页面会形成盲区。

3. 准备目标和测试账号。

/pentest-lyan https://target.example.com --project target-test

账号：
  - admin/Admin@123   (role_level: high_privilege)
  - user1/User@123    (role_level: standard)
  - user2/User@123    (role_level: standard)

role_level 需要显式填写，Skill 不会从用户名猜权限。有两个及以上账号时，才能更完整地做横向和纵向权限交叉。0 或 1 个账号不会阻断测试，但报告会记录会话池限制。

4. 中断后恢复或查看项目。

/pentest-lyan --resume target-test
/pentest-lyan --list

使用场景

1. 业务系统的黑盒测试

任务示例： 测试订单、支付、积分或审核系统，确认状态跳转、客户端可控金额和并发重复处理等风险。

技术要点： 这类目标需要准备专用测试数据。支付、退款、通知和批量操作在执行前仍要人工确认，竞态测试不能变成压测。

2. 多角色权限专项

任务示例： 使用管理员、普通用户和商户账号，检查页面级、接口级和对象级的权限差异。

技术要点： 权限矩阵中的 200 只是高优先线索。验证对象越权时，要从 victim 账号的真实列表取资源 ID，再用 attacker 自己的会话访问，不能硬编码一个猜测 ID。

3. 长周期、分段执行的评估

任务示例： 一个业务系统包含数十个模块，无法在一次对话里完成，需要跨会话恢复进度。

技术要点： 为每个目标指定稳定的 project-id。续测时先读 state.json 和 module_queue.json，Cookie 过期后要重新登录并同步更新会话文件。

4. 内部报告与客户交付分层

任务示例： 内部团队保留按功能列出的威胁建模、覆盖率和盲区，对外只交付聚焦漏洞复现的 Word 文档。

技术要点： Markdown 报告是全量技术底稿，DOCX 交付件只保留封面、漏洞概要、影响、复现和修复建议。项目自带 render_docx.py，依赖 python-docx。

注意点

• pentest-data/ 会保存明文 Cookie、Token 和账号，交付后应清理或加密，不要进 Git，也不要同步到普通网盘。
• DOCX 报告按项目默认要求保留完整请求、响应和凭据，只适合加密或内网传输。对外交付前还应按组织规范做脱敏复核。
• 仓库的 test-results.md 中，触发测试和功能测试的“实际”栏仍是“待测”。项目也没有提供真实目标 Benchmark 或公开测试报告。因此，目前更适合把它看成一套可审查的方法框架，不要直接把“高覆盖率”或“低误报”当成已被数据证明的结论。

结尾

Pentest-Lyan 把模型原有的推理和工具调用能力，扩展成一套能持续推进、跨角色验证、保留证据并交付报告的渗透测试能力。

如果团队已经在用 AI 辅助 Web 安全评估，可以先拿内部靶场或低风险测试环境跑一轮。重点不是看它找到多少漏洞，而是审查状态文件是否真实、GATE 是否被严格执行，以及第三方能否按报告重现结果。

往期推荐 📚

Tutti：让多个 Agent 共用一个工作台

AntiDebug MCP：AI 前端逆向助手

BurpAPIFinder：接口与敏感信息发现

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：攻防录 《Pentest-Lyan：AI 渗透测试增强包》