Back to Details

thinking-red-team

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Red Team

红队

Adversarial security review of systems you are authorized to assess. Attack before an outsider does, but report only what you can actually break: every finding needs a concrete exploit path and a check that the proposed fix closes it.
针对你获授权评估的系统进行对抗性安全审查。在外部攻击者行动前发起模拟攻击，但仅报告你实际能够攻破的内容：每一项发现都需要具备具体的利用路径，且需验证提议的修复方案能够阻断该路径。

When to Use

适用场景

  • Security review of code, authentication, authorization, APIs, data handling, or infrastructure you control and are permitted to probe.
  • Pre-launch hardening of systems that handle auth, money, personal data, or privileged actions.
  • Checking whether a specific vulnerability class (injection, XSS, IDOR, auth bypass, SSRF, secret exposure, etc.) is present with a real path.
  • Validating that a claimed control actually blocks the attack, not only that a scanner is quiet.
  • 针对你控制且获许可探查的代码、认证（auth）、授权（authorization）、API、数据处理流程或基础设施进行安全审查。
  • 针对处理认证、资金、个人数据或特权操作的系统进行上线前加固。
  • 检查特定漏洞类别（注入、XSS、IDOR、认证绕过、SSRF、密钥泄露等）是否存在真实利用路径。
  • 验证声称的控制措施是否真能阻断攻击，而非仅依赖扫描工具无告警的结果。

When NOT to Use

不适用场景

  • No authorization to attack the target — stop; do not probe systems you do not own or have written leave to test.
  • Speculative "best practice" notes without a reproducible exploit path — drop them; they are not findings.
  • Plan, strategy, or decision stress-testing — use pre-mortem (how the plan fails) or steel-manning (strongest case against the decision).
  • Architecture resilience without a security objective — use systems or pre-mortem.
  • Scanner output alone as a report — patterns are leads; red-team requires an exploit path.
  • Non-security root-cause or hypothesis localization — use scientific-method or five-whys-plus.
  • 未获攻击目标的授权——立即停止；不得探查你不拥有或未获明确测试许可的系统。
  • 无复现利用路径的推测性「最佳实践」建议——直接舍弃；这些不属于有效发现。
  • 计划、策略或决策的压力测试——采用事前验尸法（分析计划如何失败）或强化反驳法（构建针对决策的最强反对论据）。
  • 无安全目标的架构韧性评估——采用系统分析或事前验尸法。
  • 仅以扫描工具输出作为报告——扫描结果仅为线索；红队审查要求具备实际利用路径。
  • 非安全相关的根本原因或假设定位——采用科学方法或五问法升级版。

Procedure

流程步骤

  1. Confirm authorization and objective. State target, allowed scope, out-of-scope assets, success condition (e.g., unauthorized data read, privilege escalation), and stop rules. Refuse or narrow if authorization is unclear.
  2. Build the threat model. Name adversary profiles (anonymous external, authenticated user, privileged insider) and their goals under realistic access. Attacks without an actor and goal are noise.
  3. Map the attack surface. Enumerate entry points and trust boundaries: public endpoints, auth flows, APIs, uploads, admin surfaces, jobs, webhooks, secrets, and data stores. Note exposure and required privileges.
  4. Trace exploit paths. For each high-value surface, attempt concrete abuse: input manipulation, authz gaps, token/session misuse, injection, SSRF, IDOR, mass assignment, rate-limit bypass, secret leakage. Record exact steps and observed behavior.
  5. Apply the anti-fabrication gate. Keep a finding only if you can complete: entry point → ordered steps → realized impact on this code/config. Incomplete paths are dropped, not listed as "informational."
  6. Score severity and attempt defense bypass. Rate impact and exploitability. For each relevant control (rate limit, validation, session check), try a realistic bypass and record held vs broken.
  7. Prescribe and verify mitigations. For each kept finding, give a minimal concrete fix and state how to re-test that the path is closed. Prefer fixes that remove the exploit precondition. Stop when in-scope surfaces are covered or authorization/budget ends; zero findings is valid.
  1. 确认授权与目标。明确目标对象、允许范围、超出范围的资产、成功条件（如未授权数据读取、权限提升）以及停止规则。若授权不明确，应拒绝或缩小审查范围。
  2. 构建威胁模型。定义攻击者画像（匿名外部人员、已认证用户、特权内部人员）及其在真实访问权限下的目标。无明确攻击者和目标的攻击属于无效噪声。
  3. 梳理攻击面。枚举入口点与信任边界：公共端点、认证流程、API、上传功能、管理界面、定时任务、Webhook、密钥及数据存储。记录暴露程度与所需权限。
  4. 追踪利用路径。针对每个高价值攻击面，尝试具体滥用操作：输入篡改、授权（authz）漏洞、令牌/会话误用、注入、SSRF、IDOR、批量赋值、速率限制绕过、密钥泄露。记录精确步骤与观察到的行为。
  5. 应用防伪造校验。仅保留能够完整复现的发现：入口点 → 有序步骤 → 对当前代码/配置造成的实际影响。未完成的路径需舍弃，不得列为「信息性提示」。
  6. 评估严重程度并尝试绕过防御。评估影响程度与可利用性。针对每项相关控制措施（速率限制、验证、会话检查），尝试真实可行的绕过方法，并记录控制措施有效或被攻破的结果。
  7. 提出并验证缓解方案。针对每项保留的发现，给出最小化的具体修复方案，并说明如何重新验证该利用路径已被阻断。优先选择消除利用前提条件的修复方案。当覆盖完范围内的攻击面，或授权/预算耗尽时停止；无发现的结果同样有效。

Output

输出格式

text
Target/scope: <in | out | goal | authorization>
Threat model: <actors, access, goals>
Attack surface: <entry points + trust boundaries>
Findings (only complete paths):
  - Title | Severity
    Entry: <endpoint/param/file>
    Steps: <1..n>
    Impact: <realized effect>
    Bypass attempts: <control → result>
    Mitigation: <minimal fix>
    Re-test: <how to confirm closed>
Summary: <kept count; dropped speculative count>
text
Target/scope: <in | out | goal | authorization>
Threat model: <actors, access, goals>
Attack surface: <entry points + trust boundaries>
Findings (only complete paths):
  - Title | Severity
    Entry: <endpoint/param/file>
    Steps: <1..n>
    Impact: <realized effect>
    Bypass attempts: <control → result>
    Mitigation: <minimal fix>
    Re-test: <how to confirm closed>
Summary: <kept count; dropped speculative count>

Verification

验证要求

  • Falsify any finding missing entry, steps, or realized impact; treat "could be vulnerable" as non-finding.
  • Stop when in-scope attack surfaces are exhausted under authorization, or when re-test shows mitigations close the paths.
  • Over-application guard: do not pad with best-practice laundry lists; do not use this skill for non-security plan critique; do not attack without authorization.
  • 若发现缺少入口点、步骤或实际影响，则判定为无效；将「可能存在漏洞」视为非有效发现。
  • 当在授权范围内遍历完所有攻击面，或重新测试显示缓解方案已阻断所有路径时停止。
  • 过度应用防护：不得堆砌最佳实践清单；不得将此技能用于非安全相关的计划批评；不得在未获授权的情况下发起攻击。