mcpField
R
red-team-engagement

red-team-engagement

github.com/briiirussell安全478349 次安装1 天前更新
代码仓库

关于 red-team-engagement

面向经明确授权的红队团队,指导规划并执行以目标为导向的对抗模拟,重点评估蓝队的检测与响应能力。流程涵盖授权核验、范围界定、执行、复盘及改进,并严格拒绝未授权测试。

主要功能

  1. 01强制核验书面授权与范围
  2. 02规划外部、假定失陷和紫队演练
  3. 03按 ATT&CK 方案组织模拟
  4. 04记录行动并管理暂停条件
  5. 05提供复盘、报告与验证流程

适用场景

  1. 01规划企业红队演练
  2. 02测试蓝队检测和遏制能力
  3. 03安排假定失陷后的响应评估
  4. 04根据演练结果跟踪防御改进

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/briiirussell/cybersecurity-skills --skill red-team-engagement

安装后在 Claude Code 中输入/red-team-engagement确认已加载。

详细介绍

红队演练 — 经授权的对手模拟

此技能用于规划并执行针对明确签约授权的系统和组织开展的红队演练。它不同于渗透测试(侧重技术;参见 web-pentest),也不同于威胁狩猎(侧重防御;参见 threat-hunting)。红队演练通常持续数周,以目标为导向,常采用假定已被入侵的场景,并明确旨在测试蓝队的检测与响应能力,而不仅仅是发现漏洞。

这是本目录中双重用途最明显的技能。无论请求如何措辞,此技能都拒绝协助开展未经授权的对手模拟。下方的授权检查会严格执行。

授权检查 — 规划或执行前必须完成

在使用此技能开展任何工作之前,请确认:

  1. 针对本次具体演练和具体目标的书面授权,且由有权授予授权的高管签署。这是一封“免责信”——团队受到质疑时可出示的纸质或电子文件
  2. 明确的范围——涉及哪些系统、哪些时间段、哪些技术属于范围内或范围外
  3. 已确认目标系统归目标组织所有——而非未取得授权的第三方(供应商、客户、子租户)所有
  4. 明确的成功标准——本次演练需要展示或测试什么
  5. 已确定的冲突协调联系人——一位能够暂停或中止演练,并在蓝队发现活动时回答“这是你们在操作吗?”的内部人员
  6. 已存档的法律审查记录——由法律顾问审查的演练合同或内部授权,包括可能涉及受控数据暴露的情况
  7. 意外影响沟通计划——生产环境受到影响时如何处理、如何报告以及报告时限

如果以上任何一项缺失或不明确,请停止。要求用户确认。在确认之前,不要继续规划、选择技术或开展任何执行工作。

如果用户描述的目标似乎不属于他们或其签约客户,请拒绝——这并非可以通过补充“仅用于教育目的”或“在 CTF 中进行”来澄清的误解。对于未经授权的系统,此技能拒绝协助模拟攻击。

红队演练的目的(以及非其目的)

红队演练旨在测试安全计划的响应能力,而不仅仅是发现漏洞。一次出色的红队演练会回答以下问题:

  • 如果攻击者获得初始访问权限,蓝队需要多久才能发现?
  • 蓝队发现后,需要多快、多彻底才能遏制威胁?
  • 是否实际使用了记录在案的事件响应流程?
  • 理论上存在的检测机制在实际中是否真的会触发?
  • 坚定的对手能否升级权限并达成指定的核心资产目标?

红队演练并非用于:

  • 发现漏洞——渗透测试可以用更低的成本完成这项工作
  • 勾选合规清单——演练旨在帮助改进,而非通过检查
  • 绩效评估——用红队演练评估蓝队个别员工会导致激励机制出现问题,扭曲所有人的行为

如果目标是“发现漏洞”,请使用 web-pentest 或相关审计技能。如果目标是“测试我们的检测和响应是否真正有效”,那么此技能正合适。

交战模式——三种类型

模式描述适用场景
外部红队从边界外开始交战;没有初始立足点成熟的项目,用于端到端测试完整攻击链
假定已入侵从已获准的初始立足点开始交战(工作站、凭据、低权限账户)边界已充分测试,需要了解入侵后遏制能力时
紫队红队与蓝队并肩工作;红队执行技术,蓝队实时验证检测效果检测工程成熟度尚处早期、学习效率较高时

假定已入侵是现代交战中最常见的模式——其每周价值最高,因为几乎所有真实入侵发生时,攻击者早已突破边界。纯外部红队很有价值,但耗时较长。

交战生命周期

阶段 0——交战前准备(启动前 4-8 周)

与客户 / 赞助方确定范围:

  • 目标——交战需要展示对哪些皇冠级资产的访问能力或何种能力?“访问静态客户数据”是具体的;“能找到什么就找什么”则不是
  • 范围内资产——明确具体环境、子网和应用。按名称列出,而不是按描述列出
  • 范围外资产——明确列出。第三方 SaaS、指定账户的客户数据、特定生产系统、高管个人账户,以及合同未涵盖的受监管数据
  • 时间窗口——设定交战的开始和结束日期。窗口越短,越能促使团队专注;窗口越长,越有利于假定已入侵场景的展开
  • 范围外技术——明确团队无论价值多大都不会使用的技术。常见情况包括:破坏性技术、修改客户数据、大规模外传真实客户数据、对指定高管实施社会工程,以及未经单独授权获取物理访问权限
  • 可信联络人(“白组”)确认——了解交战正在进行的内部人员最低数量。通常为 2-4 人:高管赞助方、安全负责人、协调联系人和法务人员
  • 报告频率——每日站会、每周检查点、交战结束后的复盘
  • 沟通渠道——使用安全的带外渠道(Signal、加密邮件、专用会议桥),避免交战执行期间泄露给蓝队

启动前的文档交付物:

  • 已签署的《交战规则》(RoE)——红队与赞助方之间的合同
  • 免责信(实体和数字形式),由获授权的高管签署
  • 交战计划,包含目标、范围和计划使用的技术(按目标列出,不要求提供完整攻击清单)
  • 沟通 / 升级处理矩阵
阶段 1——侦察与情报收集(按交战类型进行)

对于外部交战,使用 recon 和 osint-recon。对于假定已入侵的交战,此阶段是从获准的起始位置进行内部侦察。

输出是一份目标地图——团队为实现目标而逐步访问的系统、账户和跳转路径。

阶段 2 — 执行

遵循根据此次演练量身定制的 ATT&CK 仿真计划。

仿真计划是公开发布的、介绍特定威胁行为者如何运作的剧本。请将其用作起点,而非照本宣科:

  • MITRE ATT&CK 仿真计划 — 开源,针对特定威胁行为者(APT29、FIN6、FIN7、menuPass、OilRig、Carbanak、Sandworm 等)。可在 attack.mitre.org/resources/adversary-emulation-plans/ 获取
  • CALDERA — MITRE 提供的自动化对手仿真框架;可针对目标环境运行 ATT&CK 计划
  • Atomic Red Team — 简短、专注的技术测试(每个“atomic”对应一种 ATT&CK 技术)。适用于紫队演练

演练沿着攻击链推进——初始访问(外部演练)或立足点后的执行(假定已被入侵),继而是持久化、权限提升、防御规避、凭证访问、侦察、横向移动、收集、数据外泄(模拟——参见边界)——最终达成指定目标。

操作说明:

  • 记录每项操作的时间戳、技术、目标和观察到的效果,以便事后复盘
  • 蓝队发现此次演练时,冲突协调联系人应及时回应——若存在升级风险,则暂停;若无风险,则确认并继续
  • 除非明确授权,否则不得使用破坏性技术;即使获得授权,也只能针对能够安全恢复的系统
  • 绝不外传真实数据——使用合成标记(特定文件名、特定哈希值),让蓝队能够验证访问了哪些内容,而无需团队实际传输客户数据
  • 如果蓝队的响应会影响真实客户服务,则暂停演练——演练不值得造成真实服务中断
阶段 3 — 复盘与报告

这是投入最少的阶段,也是决定演练是否真正提升防御能力的关键。

当日复盘(演练结束后 24 小时内):

  • 红队按时间线回顾操作
  • 蓝队回顾他们看到了什么、何时看到以及采取了什么行动
  • 双方认知之间的差距是价值最高的发现(红队执行了 X,蓝队却毫无察觉)

完整书面报告(2-4 周内):

# Red Team Engagement Report
## Engagement: [name]
## Sponsor: [executive sponsor]
## Engagement window: [start - end]
## Engagement type: External / Assumed Breach / Purple
## Authors: [red team leads]

### Executive summary
[3-5 paragraphs — were objectives achieved, what the blue team's detection-and-response posture looks like, top 3-5 systemic recommendations]

### Engagement timeline
[Red-team actions with timestamps and ATT&CK technique IDs]

### Blue-team observations
[For each red-team action, what the blue team saw, when, and how they responded — or did not]

### Detection coverage analysis
[Map of techniques used vs detections that did / should have fired]

### Findings
| ID | Severity | Category | Description |
|----|----------|----------|-------------|

(Categories: Detection gap, Response gap, Privileged-access exposure, Lateral-movement enabler, Crown-jewel access path, Compensating control reliance)

### Per-finding detail
[Technique used, what was achieved, what the blue team did / didn't see, recommended remediation]

### Recommendations
[Prioritized — usually 5-10 items mapping to specific systemic improvements, not point fixes]

### What the engagement did NOT cover
[Honesty about what was out of scope and where coverage gaps remain]
阶段 4 — 改进与重新验证

报告中的建议将转化为工作事项。红队的价值会在以下情况下不断累积:

  • 跟踪高严重性建议,直至完成(通常包括:按 siem-detection 添加检测规则、按 soc-operations 更新响应运行手册、按审计技能改进控制措施)
  • 6-12 个月后重新验证具体发现,最好通过紫队演练进行
  • 将经验教训纳入 breach-patterns 和 incident-triage 运行手册

如果红队两次发现同一个问题,那么第二次投入的预算就浪费了。

交战规则(RoE)——文档应包含的内容

RoE 是合同,必须具体明确。

部分规定内容
授权谁授权了此次活动、授权时间以及授权依据
范围 — 包含按名称列出具体系统、账户、环境和应用程序
范围 — 排除明确排除的内容——第三方、受监管数据、指定账户、特定生产系统
范围内的技术允许使用的技术类别(例如,“在指定测试环境中捕获凭据”)
范围外的技术不允许使用的技术类别(例如,“不得使用破坏性技术”“不得对指定高管进行社会工程”“不得利用供应商系统”)
时间窗口开始日期、结束日期、禁测时段(例如,“季度结算期间不得开展活动”)
数据处理如何处理活动期间发现的数据——销毁时限、加密要求、数据外传标记
报告频率每日/每周/活动结束时
冲突协调联系人指定的一名联系人、备用联系人以及全天候联系方式
停止条件何时暂停或中止活动——造成生产中断、触发监管事件、意外超出范围
免责证明信格式、分发对象、核验联系人

边界

这是本目录中影响最重大的边界部分,请仔细阅读。

  • 授权是底线,不是上限。 签署授权并不意味着所有技术都可以接受——合同仍然界定了允许的范围。用户不确定时,回答应是“继续之前先咨询发起方”
  • 拒绝针对未经授权的目标。 不得对用户不拥有或不控制的系统开展“假设性”活动。不得针对具名第三方讨论“如果你会怎么做”。此技能用于已获授权的活动,不用于针对任意目标进行对手思维演练
  • 默认禁用破坏性技术。 即使属于授权范围,也应优先采用非破坏性替代方案——模拟勒索软件(枚举文件但不加密)、展示持久化(放置痕迹但不执行)、访问证明(只读)
  • 不得外传真实客户数据。 使用合成标记。蓝队通过已标记的内容核实访问范围;红队不得转移真实数据
  • 为安全起见暂停活动。 发生现实影响时暂停活动——服务中断、数据暴露给未授权方、触发监管通报。只有获得发起方批准后才能重新开始
  • 拒绝协助构建进攻性工具。 此技能用于规划以负责任的方式使用现有技术和工具开展的活动,不协助编写新恶意软件、新 C2 框架或默认规避检测的新工具。工具选择不属于此技能的职责范围
  • 拒绝协助对未同意接受测试的人员实施社会工程。 社会工程可以属于活动范围,但目标必须是其职责允许接受活动测试的人员(通常是广泛的员工群体,并明确排除特定人员)。如果请求是要钓鱼某个不在同意范围内的特定个人,则应拒绝
  • 如果请求看起来是在利用内部红队监视特定员工,则应拒绝。 红队测试的是系统和流程,而不是人员
  • 发现是发现,不是武器。 能推动修复工作的红队报告具有正面价值;沦为内部政治弹药的报告则具有负面价值。作者和审阅者都有责任确保报告发挥前一种作用

参考资料

  • MITRE ATT&CK 框架 — attack.mitre.org
  • MITRE ATT&CK 对手模拟计划 — attack.mitre.org/resources/adversary-emulation-plans/
  • MITRE CALDERA — 自动化对手模拟
  • Atomic Red Team — github.com/redcanaryco/atomic-red-team
  • TIBER-EU(基于威胁情报的道德红队测试)— 面向金融行业红队测试的欧洲框架
  • CBEST(英国英格兰银行)— 英国金融行业红队框架
  • NIST SP 800-115(信息安全测试与评估技术指南)
  • PTES(渗透测试执行标准)— 方法论来源,包含与红队相关的阶段
  • 红队现场手册 — Ben Clark — 面向操作人员的参考资料
  • 对手技艺与网络威胁情报的重要性 — MITRE / CTID 撰写的文章
  • CTID(威胁知情防御中心) — ctid.mitre.org — 开源模拟内容
  • 《红队开发与运营》 — Joe Vest、James Tubberville
  • 《如何像幽灵一样黑客攻击》 — Sparc Flow(叙事风格;有助于理解长期交战的模式)

评论

支持 Markdown