red-team-engagement

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Red Team Engagement — Authorized Adversary Emulation

红队演练——授权对抗仿真

This skill is for planning and executing an authorized red-team engagement against systems and an organization that has explicitly contracted for it. It is distinct from a penetration test (technique-focused; see

web-pentest

) and from threat hunting (defensive; see

threat-hunting

). A red-team engagement is multi-week, objective-based, often assumed-breach, and explicitly tries to test the blue team's detect-and-respond capability — not just to find vulnerabilities.

This is the most dual-use skill in this catalog. The skill refuses to help conduct unauthorized adversary simulation, regardless of how the request is framed. The authorization check below is enforced strictly.

本技能用于针对明确签约的组织及系统，规划并执行授权的红队演练。它与渗透测试（以技术为核心；详见

web-pentest

）和威胁狩猎（防御性；详见

threat-hunting

）不同。红队演练通常持续数周，以目标为导向，常采用假设 breach 模式，旨在测试蓝队的检测与响应能力——而非仅发现漏洞。

这是本技能目录中最具双重用途的技能。无论请求如何表述，本技能均拒绝协助开展未授权的对抗仿真。以下授权检查将严格执行。

Authorization Check — required before any planning or execution

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

Before working with this skill at all, confirm:

Written authorization for this specific engagement, against this specific target, signed by an executive with authority to grant it. The "get-out-of-jail" letter — a physical / digital document the team can produce if challenged
Defined scope — what systems, what time windows, what techniques are in / out of scope
Identified target organization owns the target systems — not a third party (vendor, customer, sub-tenant) whose authorization has not been obtained
Defined success criteria — what does this engagement need to demonstrate or test
Identified deconfliction contact — a single internal person who can pause / abort the engagement and answer "is this you?" when the blue team finds activity
Legal review on file — engagement contract or internal authorization reviewed by counsel, including for any controlled-data exposure
Communication plan for unintended impact — what happens if production is affected, how is it reported, how fast

If any of the above is missing or unclear, stop. Ask the user to confirm. Do not proceed with planning, technique selection, or any execution work.

If the user describes a target that does not appear to belong to them or to a contracted client, refuse — this is not a misunderstanding to be cleared up by adding "for educational purposes" or "in a CTF." The skill refuses to help simulate an attack on systems whose authorization is not present.

在使用本技能前，需确认：

书面授权：针对本次特定演练、特定目标，由具备授权权限的高管签署。即“免责函”——团队在受到质疑时可出示的纸质/电子文档
明确范围：涵盖哪些系统、时间窗口、技术，排除哪些内容
目标组织拥有目标系统所有权：不得是未获得授权的第三方（供应商、客户、子租户）的系统
明确成功标准：本次演练需要证明或测试什么
确定冲突协调联系人：一名内部专人，可暂停/终止演练，并在蓝队发现异常活动时回答“这是你们的操作吗？”
已完成法律审查：演练合同或内部授权已由法律顾问审核，包括受控数据暴露相关内容
意外影响沟通计划：若生产环境受影响该如何处理、如何报告、响应速度如何

若上述任何一项缺失或不明确，立即停止。请用户确认。不得继续进行规划、技术选择或任何执行工作。

若用户描述的目标似乎不属于他们或签约客户，直接拒绝——即便添加“用于教育目的”或“在CTF中”也无法澄清误解。本技能拒绝协助对未获授权的系统进行攻击仿真。

What red-team engagements are for (and what they are not for)

红队演练的适用场景（及不适用场景）

Red-team engagements exist to test the security program's response capability — not just to find vulnerabilities. A good red-team engagement answers questions like:

If an attacker gets initial access, how long until the blue team notices?
When the blue team notices, how fast and how completely do they contain it?
Are the documented incident-response procedures actually used?
Do detections that exist in theory actually fire in practice?
Can a determined adversary escalate to the named crown-jewel objective?

Red-team engagements are not for:

Vulnerability discovery — pentests do that with much less overhead
Compliance check-box — engagements are designed to teach, not to pass
Performance reviews — using a red-team engagement to evaluate individual blue-team employees creates incentive problems that distort everyone's behavior

If the goal is "find vulnerabilities," use

web-pentest

or the relevant audit skill. If the goal is "test whether our detection and response actually works," this is the right skill.

红队演练旨在测试安全方案的响应能力——而非仅发现漏洞。优质的红队演练可解答以下问题：

若攻击者获得初始访问权限，蓝队需要多久才能发现？
蓝队发现后，能多快、多彻底地遏制攻击？
已记录的事件响应流程是否真的被使用？
理论上存在的检测机制在实际中是否真的会触发？
坚定的攻击者能否升级权限，达成指定的核心目标？

红队演练不适用于：

漏洞发现——渗透测试可完成此项工作，且开销低得多
合规勾选——演练旨在学习改进，而非通过合规检查
绩效评估——利用红队演练评估蓝队个人员工会引发激励问题，扭曲所有人的行为

若目标是“发现漏洞”，请使用

web-pentest

或相关审计技能。若目标是“测试我们的检测与响应是否真的有效”，本技能是正确选择。

Engagement model — three flavors

演练模式——三种类型

Model	Description	When to use
External red team	Engagement starts from outside the perimeter; no initial foothold	Mature programs testing the full attack chain end-to-end
Assumed breach	Engagement starts from a granted initial foothold (workstation, credentials, low-privilege account)	When the perimeter is well-tested already and the question is post-compromise containment
Purple team	Red and blue work side-by-side; red executes technique, blue verifies detection live	Early in detection-engineering maturity; high learning rate

Assumed-breach is the most common modern engagement model — the value-per-week is highest because almost every real breach starts with the perimeter already past. Pure external red teams are valuable but expensive in calendar time.

模式	描述	适用场景
外部红队	演练从 perimeter 外部开始；无初始立足点	成熟方案，用于端到端测试完整攻击链
假设 breach	演练从给定的初始立足点（工作站、凭据、低权限账户）开始	当 perimeter 已充分测试，需测试入侵后遏制能力时
紫队	红队与蓝队协同工作；红队执行技术操作，蓝队实时验证检测效果	检测工程成熟度初期阶段；学习效率高

假设 breach 是当前最常见的演练模式——每周价值最高，因为几乎所有真实 breach 都始于 perimeter 已被突破。纯外部红队虽有价值，但耗时较长。

Engagement lifecycle

演练生命周期

Phase 0 — Pre-engagement (4-8 weeks before kickoff)

阶段0——演练前准备（启动前4-8周）

Scoping with the client / sponsor:

Objectives — what crown-jewel access or capability does the engagement need to demonstrate? "Access customer data at rest" is concrete; "find what you can" is not
In-scope assets — specific environments, specific subnets, specific applications. List by name, not by description
Out-of-scope assets — explicitly named. Third-party SaaS, customer data of named accounts, specific production systems, executive personal accounts, regulated data the contract does not cover
Time window — engagement window with start and end dates. Tighter windows force focus; longer windows allow assumed-breach scenarios to play out
Techniques out of scope — what the team will NOT do regardless of value. Common: destructive techniques, modification of customer data, mass-exfiltration of real customer data, social engineering of named executives, physical access without separate authorization
Trusted-agent ("white cell") identification — minimum number of internal people who know the engagement is happening. Typically 2-4: executive sponsor, security leadership, deconfliction contact, legal
Reporting cadence — daily standup, weekly checkpoint, end-of-engagement debrief
Communication channels — secure out-of-band (Signal, encrypted email, dedicated bridge) so that the engagement does not leak to the blue team during execution

Documentation deliverables before kickoff:

Signed Rules of Engagement (RoE) — the contract between the red team and the sponsor
Get-out-of-jail letter (physical and digital), signed by an authorized executive
Engagement plan with objectives, scope, techniques planned (per-objective; not a complete attack list)
Communication / escalation matrix

与客户/发起方确定范围：

目标：演练需要证明或达成哪些核心资产访问权限或能力？“访问静态客户数据”是具体目标；“尽可能发现问题”则不是
范围内资产：特定环境、特定子网、特定应用。需按名称列出，而非描述
范围外资产：明确列出。第三方SaaS、指定客户账户的客户数据、特定生产系统、高管个人账户、合同未覆盖的受监管数据
时间窗口：演练的开始和结束日期。更紧凑的窗口可聚焦重点；更长的窗口可开展假设 breach 场景的完整推演
排除的技术：无论价值如何，团队都不会使用的技术。常见包括：破坏性技术、修改客户数据、大规模泄露真实客户数据、针对指定高管的社会工程、未单独授权的物理访问
可信代理（“白组”）识别：知晓本次演练的内部最少人数。通常为2-4人：执行发起方、安全负责人、冲突协调联系人、法务人员
报告频率：每日站会、每周检查点、演练结束后复盘
沟通渠道：安全的带外渠道（Signal、加密邮件、专用桥接），确保演练期间不会向蓝队泄露信息

启动前需交付的文档：

签署的参与规则（RoE）——红队与发起方之间的合同
免责函（纸质和电子版本），由授权高管签署
包含目标、范围、计划使用技术（按目标划分；并非完整攻击列表）的演练计划
沟通/升级矩阵

Phase 1 — Reconnaissance and intelligence (per the engagement type)

阶段1——侦察与情报收集（根据演练类型）

For external engagements, leverage

recon

and

osint-recon

. For assumed-breach engagements, this phase is internal recon from the granted starting position.

The output is a target map — the systems, accounts, and pivots the team will work through to reach the objective.

对于外部演练，利用

recon

和

osint-recon

技能。对于假设 breach 演练，此阶段是从给定初始立足点进行内部侦察。

输出为目标地图——团队为达成目标需攻克的系统、账户和跳转路径。

Phase 2 — Execution

阶段2——执行

Following an ATT&CK emulation plan tailored to the engagement.

Emulation plans are published playbooks of how specific threat actors operate. Use them as starting points, not scripts:

MITRE ATT&CK Emulation Plans — open-source, threat-actor-specific (APT29, FIN6, FIN7, menuPass, OilRig, Carbanak, Sandworm, etc.). Available at
```
attack.mitre.org/resources/adversary-emulation-plans/
```
CALDERA — automated adversary emulation framework from MITRE; runs ATT&CK plans against a target environment
Atomic Red Team — short, focused technique tests (one ATT&CK technique per "atomic"). Useful for purple-team exercises

The engagement progresses through the kill chain — initial access (for external) or post-foothold execution (for assumed breach), persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, exfiltration (simulated — see boundaries) — toward the named objective.

Operational notes:

Every action logged with timestamp, technique, target, and observed effect — for the eventual debrief
The deconfliction contact answers when the blue team finds the engagement — to pause if escalation risk, to confirm and continue if not
No destructive techniques unless explicitly authorized — and even then, only against systems that can be safely restored
Real data is never exfiltrated — use synthetic markers (specific filenames, specific hash values) so blue can verify what was accessed without the team actually moving customer data
Engagement pauses if the blue team's response would impact real customer service — the engagement is not worth a real outage

遵循为本次演练定制的ATT&CK仿真计划。

仿真计划是已发布的特定威胁 actor 操作手册。将其作为起点，而非脚本：

MITRE ATT&CK 仿真计划——开源，针对特定威胁 actor（APT29、FIN6、FIN7、menuPass、OilRig、Carbanak、Sandworm等）。可在
```
attack.mitre.org/resources/adversary-emulation-plans/
```
获取
CALDERA——MITRE开发的自动化对抗仿真框架；可针对目标环境运行ATT&CK计划
Atomic Red Team——简短、聚焦的技术测试（每个“原子”对应一项ATT&CK技术）。适用于紫队演练

演练按杀伤链推进——外部演练为初始访问，假设 breach 演练为立足点后执行，随后是持久化、权限提升、防御规避、凭据获取、发现、横向移动、收集、泄露（模拟——详见边界规则）——直至达成指定目标。

操作注意事项：

每一项操作都需记录时间戳、技术、目标和观察到的效果——用于最终复盘
当蓝队发现演练活动时，冲突协调联系人需回应——若存在升级风险则暂停，否则确认并继续
除非明确授权，否则不得使用破坏性技术——即便授权，也仅能针对可安全恢复的系统
不得泄露真实数据——使用合成标记（特定文件名、特定哈希值），以便蓝队无需团队实际转移客户数据即可验证访问内容
若蓝队的响应会影响真实客户服务，需暂停演练——演练不值得引发真实故障

Phase 3 — Debrief and reporting

阶段3——复盘与报告

The most under-invested phase, and the one that determines whether the engagement actually improves defenses.

Same-day debrief (within 24 hours of engagement end):

Red team walks through the timeline of actions
Blue team walks through what they saw, when they saw it, what they did
Gaps between the two are the highest-value findings (red did X, blue saw nothing)

Full written report (within 2-4 weeks):

markdown

undefined

这是投入最少但决定演练能否切实提升防御能力的阶段。

当日复盘（演练结束后24小时内）：

红队梳理操作时间线
蓝队梳理他们看到的内容、时间点及采取的行动
两者之间的差距是最有价值的发现（红队执行了X操作，蓝队未察觉）

完整书面报告（2-4周内）：

markdown

undefined

Red Team Engagement Report

红队演练报告

Engagement: [name]

演练名称：[名称]

Sponsor: [executive sponsor]

发起方：[执行发起方]

Engagement window: [start - end]

演练时间窗口：[开始-结束]

Engagement type: External / Assumed Breach / Purple

演练类型：外部/假设Breach/紫队

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]

[3-5段——是否达成目标，蓝队的检测与响应态势如何，前3-5项系统性建议]

Engagement timeline

演练时间线

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

[红队操作及时间戳、ATT&CK技术ID]

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)

ID	严重程度	类别	描述

（类别：检测缺口、响应缺口、特权访问暴露、横向移动促成因素、核心资产访问路径、补偿控制依赖）

Per-finding detail

发现项详情

[Technique used, what was achieved, what the blue team did / didn't see, recommended remediation]

[所用技术、达成的效果、蓝队的响应情况、建议的 remediation]

Recommendations

建议

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

[按优先级排序——通常为5-10项，对应具体的系统性改进，而非单点修复]

What the engagement did NOT cover

演练未覆盖内容

[Honesty about what was out of scope and where coverage gaps remain]

undefined

[坦诚说明范围外内容及仍存在的覆盖缺口]

undefined

Phase 4 — Improvement and revalidation

阶段4——改进与重新验证

Recommendations from the report become work items. The red team's value compounds when:

High-severity recommendations are tracked to closure (typically: detection rules added per
```
siem-detection
```
, response runbooks updated per
```
soc-operations
```
, control improvements per the audit skills)
Specific findings are revalidated 6-12 months later, ideally as a purple-team exercise
Lessons feed
```
breach-patterns
```
and
```
incident-triage
```
runbooks

A red team that finds the same problem twice is a budget that was wasted the second time.

报告中的建议将成为工作项。红队的价值在以下情况下会持续提升：

高优先级建议被跟踪至完成（通常：按
```
siem-detection
```
添加检测规则，按
```
soc-operations
```
更新响应手册，按审计技能改进控制措施）
6-12个月后对特定发现项重新验证，理想情况下以紫队演练形式进行
经验教训被纳入
```
breach-patterns
```
和
```
incident-triage
```
手册

若红队两次发现同一问题，第二次就是浪费预算。

Rules of Engagement (RoE) — what goes in the document

参与规则（RoE）——文档包含内容

The RoE is the contract. It must be specific.

Section	What it specifies
Authorization	Who authorized this engagement, when, with what authority
Scope — in	Specific systems, accounts, environments, applications by name
Scope — out	Explicitly excluded — third parties, regulated data, named accounts, specific production systems
Techniques in scope	Categories of technique permitted (e.g., "credential capture in named test environments")
Techniques out of scope	Categories of technique not permitted (e.g., "no destructive techniques," "no social engineering of named executives," "no exploitation of vendor systems")
Time window	Start date, end date, blackout periods (e.g., "no engagement activity during quarterly close")
Data handling	What happens to data discovered during the engagement — destruction timelines, encryption requirements, exfiltration markers
Reporting cadence	Daily / weekly / end-of-engagement
Deconfliction contact	Single named individual + backup + 24/7 contact path
Stop conditions	When the engagement pauses or aborts — production outage caused, regulatory event triggered, unintended scope crossed
Get-out-of-jail letter	Format, distribution, contact for verification

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

章节	明确内容
授权	谁授权了本次演练、时间、授权权限
范围——包含	按名称列出的特定系统、账户、环境、应用
范围——排除	明确排除的内容——第三方、受监管数据、指定账户、特定生产系统
允许的技术	允许使用的技术类别（例如：“在指定测试环境中捕获凭据”）
禁止的技术	不允许使用的技术类别（例如：“禁止破坏性技术”、“禁止针对指定高管的社会工程”、“禁止利用供应商系统”）
时间窗口	开始日期、结束日期、禁止操作时段（例如：“季度结算期间不得开展演练活动”）
数据处理	演练期间发现的数据如何处理——销毁时间线、加密要求、泄露标记
报告频率	每日/每周/演练结束后
冲突协调联系人	指定专人+备份+24/7联系方式
停止条件	演练暂停或终止的情况——引发生产故障、触发监管事件、意外超出范围
免责函	格式、分发方式、验证联系人

Boundaries

边界规则

This is the most consequential boundaries section in this catalog. Read it.

Authorization is the floor, not the ceiling. A signed authorization does not make every technique acceptable — the contract still bounds what is permitted. When the user is unsure, the answer is "ask the sponsor before proceeding"
Unauthorized targets are refused. No "hypothetical" engagements against systems the user does not own or control. No "what would you do if" against named third parties. The skill is for authorized engagements, not for adversary-thinking exercises against arbitrary targets
Destructive techniques are off by default. Even when in-scope, prefer non-destructive alternatives — simulated ransomware (file enumeration without encryption), demonstrated persistence (artifact placement without execution), proof-of-access (read-only)
Real customer data is not exfiltrated. Use synthetic markers. The blue team verifies what was accessed by what was marked; the red team does not move real data
Pause for safety. Engagement pauses when real-world impact occurs — outage, data exposure to unauthorized parties, regulatory notification trigger. Restart only after sponsor approval
Refuse to help build offensive tooling. This skill plans engagements that use existing techniques and tooling responsibly. It does not help write new malware, new C2 frameworks, or new evasion-by-default tooling. Tooling decisions are upstream of this skill
Refuse to help with social engineering against people who have not consented to be tested. Social engineering can be in-scope, but the targets must be people whose role accepts engagement testing (typically: employees broadly, with explicit exclusions). Refuse if the request is to phish a specific individual outside the consent envelope
Refuse if the request looks like an internal red team being used to surveil specific employees. Red teams test systems and processes, not people
Findings are findings, not weapons. A red-team report that produces remediation work is value-positive; one that becomes ammunition in internal politics is value-negative. Authors and reviewers carry responsibility for keeping it the former

这是本技能目录中最重要的边界规则章节，请仔细阅读。

授权是底线，而非上限：签署的授权并不意味着所有技术都可接受——合同仍会限制允许的操作。当用户不确定时，答案是“先咨询发起方再继续”
拒绝未授权目标：不得针对用户不拥有或控制的系统开展“假设”演练。不得针对指定第三方开展“如果你是攻击者会怎么做”的演练。本技能仅用于授权演练，而非针对任意目标的对抗思维练习
默认禁止破坏性技术：即便在范围内，也优先选择非破坏性替代方案——模拟勒索软件（仅枚举文件不加密）、演示持久化（放置 artifacts 不执行）、访问证明（只读）
不得泄露真实客户数据：使用合成标记。蓝队通过标记内容验证访问情况；红队不得转移真实数据
为安全暂停：当产生实际影响时暂停演练——故障、数据向未授权方暴露、触发监管通知。仅在获得发起方批准后才可重启
拒绝协助构建攻击工具：本技能负责规划负责任地使用现有技术和工具的演练。不协助编写新恶意软件、新C2框架或默认规避检测的工具。工具选择不属于本技能范畴
拒绝针对未同意测试的人员开展社会工程：社会工程可在范围内，但目标必须是其职责接受演练测试的人员（通常：全体员工，明确排除部分人员）。若请求是针对同意范围外的特定个人进行钓鱼，直接拒绝
若请求看似内部红队被用于监控特定员工，直接拒绝：红队测试的是系统和流程，而非个人
发现项是发现，而非武器：能产生 remediation 工作的红队报告是正向价值；若成为内部政治斗争的弹药则是负向价值。作者和审核者有责任确保报告保持正向价值

References

参考资料

MITRE ATT&CK Framework —
```
attack.mitre.org
```

MITRE ATT&CK Adversary Emulation Plans —

attack.mitre.org/resources/adversary-emulation-plans/

MITRE CALDERA — automated adversary emulation
Atomic Red Team —
```
github.com/redcanaryco/atomic-red-team
```
TIBER-EU (Threat Intelligence-Based Ethical Red-teaming) — European framework for financial-sector red teaming
CBEST (UK Bank of England) — UK financial-sector red-team framework
NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment)
PTES (Penetration Testing Execution Standard) — methodology source, with red-team-relevant phases
Red Team Field Manual — Ben Clark — operator-oriented reference
Adversary Tradecraft and the Importance of Cyber Threat Intelligence — MITRE / CTID writeups
CTID (Center for Threat-Informed Defense) —
```
ctid.mitre.org
```
— open-source emulation content
"Red Team Development and Operations" — Joe Vest, James Tubberville
"How to Hack Like a Ghost" — Sparc Flow (narrative-style; useful for understanding the model of an extended engagement)

MITRE ATT&CK Framework —
```
attack.mitre.org
```

MITRE ATT&CK Adversary Emulation Plans —

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（渗透测试执行标准）——方法论来源，包含红队相关阶段
Red Team Field Manual — Ben Clark — 面向操作人员的参考手册
Adversary Tradecraft and the Importance of Cyber Threat Intelligence — MITRE / CTID 文章
CTID（威胁情报防御中心） —
```
ctid.mitre.org
```
— 开源仿真内容
《Red Team Development and Operations》 — Joe Vest, James Tubberville
《How to Hack Like a Ghost》 — Sparc Flow（叙事风格；有助于理解长期演练模式）