1. 基本信息
| 项目 | 内容 |
|---|---|
| 名称 | red-team-alirezarezvani-claude-skills |
| 作者/维护者 | Alireza Rezvani(GitHub: alirezarezvani) |
| 来源链接 | https://github.com/alirezarezvani/claude-skills/tree/main/engineering-team/skills/red-team |
| 许可证 | MIT(数据来源:GitHub API) |
| GitHub Stars | 23,880(所属 claude-skills 合集仓库整体星数,非本技能独立星数;数据来源:GitHub API) |
| Forks | 3,352(同上,合集仓库层面;数据来源:GitHub API) |
| 最新版本 | 合集仓库标签 v2.9.0(该子技能未见独立版本号;数据来源:GitHub API) |
| 安装方式 | 复制子目录到本地 skills 目录,或经仓库自带 marketplace 配置以插件方式安装 |
2. 功能介绍与亮点
red-team 提供红队攻防演练的工程化规划方法论,配套 engagement_planner.py 工具,把散落在攻防人员经验里的攻击路径规划转成一套可复算的评分与结构化输出。
主要亮点:
- 技术评分公式:
effort_score = detection_risk × (前置条件数 + 1),对每个 MITRE ATT&CK 技术给出“多容易被防守方发现”的量化分数,辅助制定攻击路径优先级 - 11 阶段 Kill-Chain 编排:从侦察、初始访问到权限提升、横向移动、数据渗出,按 MITRE 战术顺序自动排列技术执行顺序,并内置“未建立持久化前不得横向移动”等阶段推进原则
- Choke Point(咽喉点)分析:识别多条攻击路径共用的关键技术节点(如凭据转储、Kerberoasting),提示防守方把检测资源优先投在这些节点上,一次加固覆盖多条路径
- OPSEC 风险清单:针对每种战术给出典型的“会触发检测的操作”及规避思路(如 NTLM 横向移动会产生 4624 类型 3 事件,建议改用 Kerberos),配套演练前 5 项自检清单
- 王冠资产(Crown Jewel)目标建模:以域控、数据库、支付系统、代码仓库等高价值资产为终点定义演练成功标准,而非以“发现了多少漏洞”计数
- 工具本体仅依赖 Python 标准库(argparse/json/sys),不执行任何 shell 命令、不发起网络请求;脚本在
--authorized参数缺失时直接拒绝生成任何输出
授权前置设计:SKILL.md 开篇即声明“所有红队活动均需书面授权”,要求签署 Rules of Engagement(RoE)文档并获得管理层书面批准,未获授权使用相关技术在多数司法辖区构成犯罪(明确点出 CFAA、Computer Misuse Act 等法律);工具在缺少 --authorized 标志时直接拒绝运行,而非仅在文档里口头提醒。
3. 适用场景
固定分类:安全与合规
面向已获得书面授权、需要规划或执行红队攻防演练的安全团队——尤其是需要向管理层或蓝队汇报“攻击路径为何优先测这几条”“哪些节点是检测投入的高杠杆点”的场景。它把红队负责人脑子里的攻击路径判断转成一份结构化的、可在演练前评审的书面计划,也可用于演练结束后按 Kill-Chain 阶段复盘检测覆盖缺口。不适合没有正式授权流程、只想临时“试一下”某个攻击技术的场景——工具本身会拒绝在缺少授权标志时输出结果。
4. 跨 Agent 兼容性
- Claude Code:原生支持——SKILL.md 遵循 Agent Skills 规范,仓库以 Claude Code 为首要分发目标
- Codex:未验证——仓库自述面向 Claude Code、Codex、Gemini CLI、Cursor 等多个 agent,但未抓取到 Codex 专属适配材料
- OpenClaw:未验证——内容为通用 Markdown + Python 脚本,理论上可被支持 SKILL.md 规范的 agent 加载,但未见 OpenClaw 专属说明
- Hermes Agent:未验证——未抓取到相关材料
5. 推荐理由
红队攻防演练常见的失败模式不是“技术不够硬”,而是缺少一份能让管理层、蓝队、执行人员对齐的结构化计划——什么算成功、先测哪条路径、发现了该往哪个方向深挖。red-team 把这套规划工作转成一个零依赖、可审计的评分工具,同时把授权前置这件事写进了代码逻辑而非仅仅是文档提醒,适合刚开始把红队演练从“临场发挥”转向“有据可查的工程流程”的团队。
6. 评分
| 维度 | 分数 | 说明 |
|---|---|---|
| 受欢迎程度 | 6 | 所属 claude-skills 合集仓库 23,880 星、创建约 9.5 个月,但该星数不计入单个子技能;该子技能已被至少一个第三方 Claude Code 技能目录站点收录,但未找到独立于合集仓库之外的具名第三方讨论或采用数据 |
| 可用性 | 8 | SKILL.md + 独立方法论参考文档 + 评分脚本三件齐全,脚本仅依赖 Python 标准库、无需外部服务或付费依赖,复制目录即可用;该子技能最近一次内容更新约在 3 个月前 |
| 安全性 | 9 | 见下方安全检查清单 |
安全检查清单:
| 检查项 | 结果 |
|---|---|
| ① Shell 命令及权限范围 | 不执行任何 shell 命令,engagement_planner.py 只做本地技术评分计算,不调用外部程序 |
| ② 运行时联网外发 | 无任何网络请求代码 |
| ③ API Key/凭据 | 不需要任何凭据或密钥 |
| ④ 可疑指令 | 未发现提示词注入或混淆代码迹象;相反,SKILL.md 与脚本均把“缺少书面授权即拒绝输出”作为强制前置条件,属主动的责任设计 |
| ⑤ 作者/组织信誉 | 个人开发者维护,仓库存在真实的第三方贡献者活跃记录(issue/PR),未见刷星或自我造假迹象 |
| ⑥ License | MIT,明确 |
| ⑦ 最近维护 | 所属仓库整体持续活跃维护,该子技能本体最近一次改动约在 3 个月前 |
7. 跟同类 Skills 相比的优势
| 竞品 | 定位 | 与本技能的差异 |
|---|---|---|
| security-pen-testing(同一合集内的相邻技能) | 系统性发现并利用具体漏洞 | 关注单个漏洞的发现与利用验证;red-team 关注从初始访问到王冠资产的端到端 Kill-Chain 路径规划,不聚焦具体漏洞挖掘 |
| Claude-BugHunter | 覆盖漏洞赏金全流程的 71 个技能包,内置授权范围验证与证据脱敏 | 面向个人赏金猎人对单个目标做漏洞挖掘与提交;red-team 面向企业内部授权演练,产出的是面向管理层与蓝队的攻击路径计划与检测覆盖评估,不涉及赏金提交流程 |
| recon-skills | 覆盖侦察到报告环节的结构化渗透测试技能包 | 聚焦渗透测试的侦察与报告撰写阶段;red-team 覆盖完整的 11 阶段 Kill-Chain(含权限提升、横向移动、数据渗出等侦察之后的全部阶段),并额外提供咽喉点分析与王冠资产建模 |
red-team 的差异化在于:不是漏洞发现工具,而是攻击路径的规划与优先级排序方法论——把“接下来测哪条路径最有价值”“哪个节点值得蓝队重点盯防”变成可复算的分数,同时把授权前置写进了工具的强制校验逻辑。
8. 用户评价
该技能已被至少一个第三方 Claude Code 技能目录站点收录并生成了独立的安装说明页面,但截至目前未发现来源可查的具名用户书面评价。
9. 其他补充
该技能与同目录下的 threat-detection、incident-response、cloud-security、security-pen-testing 等技能共享统一的交叉引用设计——SKILL.md 明确标注各技能的分工边界(例如红队演练触发的检测事件应交由 incident-response 处理,云环境的配置发现可作为红队攻击路径的目标输入),可视场景按需组合使用,而非互相替代。
10. 安装使用方式
渠道一:手动复制
git clone https://github.com/alirezarezvani/claude-skills
cp -r claude-skills/engineering-team/skills/red-team ~/.claude/skills/red-team
渠道二:仓库自带的插件市场
仓库根目录提供 marketplace.json 配置,可按仓库 README 中的插件安装说明接入。
安装后注意事项:无需重启客户端;在对话中提及“红队演练”“攻击路径规划”“Kill-Chain”等场景关键词即可触发技能加载。运行内置的 engagement_planner.py 前,需在命令行显式传入 --authorized 标志——这要求团队已具备真实签署的 RoE 文档,工具本身不做任何形式的授权文件核验,只做标志位检查。
11. 注意事项
- 已知限制:
engagement_planner.py只做技术评分与 Kill-Chain 编排的静态计算,不连接任何实际的攻击执行工具(如 C2 框架、漏洞利用框架),是纯规划层产物;技术库覆盖约 29 个 MITRE ATT&CK 技术,非全量技术矩阵。 - 兼容性问题:除 Claude Code 外的其他 agent 平台适配情况均未验证。
- 潜在风险:内容涉及具体的 OPSEC 规避思路(如特定检测事件的规避方式),使用者需确保始终在书面授权范围内使用;若团队本身没有正式的 RoE 签署流程,该技能的授权前置设计会直接拒绝配合。