breach-patterns

Breach Patterns — 根据公开泄露事件披露进行前置加固

这是 incident-triage 的反向技能。那个技能关注的是“我们着火了，现在怎么办”。这个技能关注的是“阅读泄露事件报告，提炼出每起事件所引出的审计问题，并检查自己的技术栈”。

此处列出的泄露事件均已公开、有充分记录，并能反映某种模式。每种模式都会揭示一种控制措施或检查项，而它们往往落在 OWASP 类别之间——滥用 IMDS、供应商凭据的影响范围、CI 中的机密信息、单点登录横向移动、泄露事件发生前的日志篡改。这些都是人们首次遭遇安全事件后才会添加的控制措施；阅读他人的泄露事件，比亲自经历一次要省钱。

交叉参考：本仓库中的每项审计技能。使用此技能提出“我们是否考虑过 X？”之类的问题，然后转到相关审计技能深入检查。如果某种泄露模式涉及法规影响——健康数据暴露、支付卡数据暴露、PII 暴露——也应使用 hipaa-audit、pci-audit 或 privacy-engineering，了解这类泄露事件所涉及的法规时限和通知义务。如果这种模式始于某个人的账户（遭钓鱼攻击的创始人、SIM 卡被盗换的管理员、开发者笔记本电脑），请对持有密钥的人员运行 personal-opsec。

授权

此技能会读取公开的泄露事件报告，并据此检查用户自己的技术栈。仅以只读方式检查用户拥有或获准审查的系统和代码。这些模式描述真实攻击的运作方式，目的是帮助你弥补漏洞；不要将其转化为针对他人系统的实际攻击。如果检查发现这种模式正在发生，请立即停止并切换到 incident-triage。

如何使用此技能

针对以下每种泄露模式：

1. 阅读一段话的泄露事件摘要
2. 提出它对你的环境引出的审计问题
3. 映射到现有审计技能中的具体检查项
4. 决定处理方式——“我们已确认不会发生这种情况”、“我们存在差距，以下是计划”或“基于以下原因，我们接受风险”

输出是一份“泄露模式覆盖情况”文档——它不是固定报告，而是一份可持续使用的清单，你可以针对不断演变的技术栈反复运行检查。

模式 1 — 滥用 IMDS（Capital One，2019）

**事件经过：**配置错误的 WAF 允许 SSRF。攻击者利用 SSRF 访问 EC2 实例元数据服务（IMDSv1，无需令牌），获取临时 IAM 凭据，并利用这些凭据枚举和窃取包含超过 1 亿条记录的 S3 存储桶中的数据。

**审计问题：**是否有服务既会接收用户输入的 URL，又能通过 IMDS 访问 IAM 凭据？

检查：

• 在每个 EC2 启动模板上强制启用 IMDSv2（MetadataOptions.HttpTokens: required）——参见 cloud-audit
• 对每个接收 URL 的端点启用 SSRF 防护——参见 owasp-audit A01 SSRF 绕过矩阵（尤其是云元数据端点一行：169.254.169.254、metadata.google.internal、169.254.170.2）
• 配置 WAF 规则，记录元数据端点模式并触发告警

模式 2 — 供应商凭证的波及范围（SolarWinds，2020）

**事件经过：**攻击者入侵了 SolarWinds 的构建流水线，并在 Orion 产品中植入了后门（Sunburst）。安装了正版 Orion 更新的客户收到了含有后门的二进制文件。该后门使攻击者得以在客户网络中横向移动，包括美国联邦政府的网络。

审计问题：

• 你的环境中有哪些供应商凭证？如果供应商遭到入侵，这些凭证是否也会让攻击者以类似方式入侵你？
• 你的 CI / CD 系统是否持有可用于横向移动至生产环境的凭证？
• 软件更新是否会通过签名验证，还是仅因来源 URL 可信就予以信任？

检查：

• 将 CI/CD 密钥的权限范围降至最低（使用只读部署令牌，而非完整管理员权限）
• 在关键场景中强制要求签名提交 / 签名制品
• 将第三方 JavaScript 固定到特定版本，或通过 SRI 固定 SHA 值
• 审计供应商管理的服务，评估其波及范围 — 跨账户信任模式请参阅 iam-audit

模式 3 — 通过开发人员终端窃取保管库数据（LastPass，2022）

**事件经过：**攻击者首先通过一个存在漏洞的第三方媒体插件，入侵了一名工程师的家用电脑，从而访问了该工程师的企业保管库。几个月后，他们利用这一访问权限窃取了客户保管库数据，其中包括未加密的 URL，这些 URL 帮助攻击者对客户实施网络钓鱼。

审计问题：

• 哪些工程账户能够访问生产数据？访问需要满足什么设备安全状态要求？
• 是否对用于访问企业系统的个人设备强制执行设备安全策略？
• 加密的用户数据周围存储了哪些未加密的元数据？

检查：

• 对任何高价值访问设置设备信任要求（零信任安全状态 — 请参阅 iam-audit）
• 通过专用工作站 / 跳板机进行特权访问，而非工程师的个人笔记本电脑
• 元数据也要加密，而不只是“重要”的载荷 — URL 属于个人身份信息（PII）

模式 4 — SSO 推送通知疲劳攻击（Okta / Lapsus$，2022）

**事件经过：**攻击者获取了一名第三方支持工程师（Sitel）的凭证。他们不断向该工程师发送推送通知 MFA 请求，直到工程师出于习惯 / 厌烦而批准了一次。随后，他们利用该支持工程师的访问权限查看了部分 Okta 客户租户（但未能修改）。

审计问题：

• 管理员账户是否采用抗网络钓鱼的 MFA（FIDO2 / 硬件密钥），还是仅使用推送通知？
• 第三方支持人员 / 承包商账户是否采用与员工相同的控制措施？
• 支持 / 客户成功岗位遭到入侵会造成多大的波及范围？

检查：

• 为管理员和特权用户启用抗网络钓鱼的 MFA（FIDO2 / WebAuthn）— 请参阅 iam-audit
• 在推送 MFA 中启用“数字匹配”（如条件允许），避免用户盲目批准
• 检测推送疲劳攻击 — 短时间内反复收到推送请求时触发警报
• 每季度以与员工访问权限同等的严格程度审查第三方访问权限

模式 5 — 凭证被盗 → SaaS 横向移动（Snowflake 客户，2024）

**事件经过：**攻击者利用信息窃取恶意软件从个人设备上窃取的凭证，登录 Snowflake 客户环境（这些环境未强制启用 MFA）。他们从 Ticketmaster、AT&T、Santander 等处窃取了数据。Snowflake 本身并未遭到入侵 — 遭到入侵的是客户。

审计问题：

• 你的技术栈中是否存在用户无需 MFA 即可进行身份验证的 SaaS 服务？
• SaaS 访问是否要求通过启用 MFA 的企业 SSO 进行身份验证，还是允许使用本地账户？
• 从个人设备上窃取的凭证是否可能解锁对业务关键型 SaaS 的访问？

检查：

• 审计环境中的每项 SaaS 服务，检查是否强制启用 MFA 和 SSO 联合身份验证
• SSO 可用时，禁用本地账户访问
• 条件访问策略要求使用合规设备 — 请参阅 iam-audit
• 监控员工电子邮件凭证（HIBP、内部暗网监控）

模式 6 — 文件传输中的未修补零日漏洞（MOVEit，2023 年）

**事件经过：**Cl0p 勒索软件组织利用 Progress MOVEit Transfer 中的 SQL 注入零日漏洞（CVE-2023-34362）。他们从数百家客户处窃取数据——其中许多客户通过 MOVEit 传输敏感的人力资源、财务或健康数据。漏洞利用活动已经开始后，补丁才发布。

审计问题：

• 对于环境中面向互联网的第三方软件，出现零日漏洞时，你们的补丁 SLA 是什么？
• 你们无法控制其代码的预构建／现成软件中存储了哪些敏感数据？
• 你们是否能检测第三方系统异常的数据外传？

检查项：

• 面向互联网的第三方软件清单、负责人及补丁流程
• 对第三方系统进行网络出口监控（参见 siem-detection）
• 监控 CISA KEV——当列出的 CVE 影响你们的技术栈时自动发出警报（参见 vuln-research）
• 数据分类——尽量减少第三方平台中的敏感数据

模式 7 — CI 构建工件遭篡改（Codecov，2021 年）

**事件经过：**Codecov 的 Docker 镜像创建流程存在缺陷，攻击者因此提取了一个凭证。他们修改了 Codecov 的 Bash 上传脚本，从每个使用 Codecov 的 CI 运行中窃取环境变量。CI 环境会泄露：AWS 密钥、Stripe 密钥、npm 令牌、GitHub 令牌。

审计问题：

• 哪些第三方工具会在 CI 中运行并访问环境变量？
• CI 环境变量是否仅限每个任务所需的范围，还是所有任务都能看到所有变量？
• 如果某个 CI 步骤开始向外部服务器发送数据，你们会注意到吗？

检查项：

• CI 密钥按任务和工作流划分范围，而非全局共享——参见 secrets-audit 和 iam-audit
• 审查第三方 CI 集成（所有能够访问环境变量的上传器、扫描器和部署工具）
• 在可行的情况下监控 CI 网络出口
• 构建工件来源证明——SLSA 框架、签名构建、sigstore

模式 8 — 内部人员滥用访问权限（Twitter / X 内部工具滥用，2020 年）

**事件经过：**攻击者通过社会工程手段诱骗 Twitter 员工，获得了具有广泛客户账户权限的内部管理工具的访问权。他们利用该工具劫持了高知名度账户并实施比特币诈骗。

审计问题：

• 哪些员工有权访问功能强大的内部管理工具？
• 访问是否有日志记录并经过审查？
• 单个员工能否在没有第二人参与的情况下执行高影响操作？

检查项：

• 将内部管理工具视为高信任级别工具——采用强身份验证、即时访问（JIT）和审计日志
• 敏感操作实行双人规则（账户接管、大规模数据导出）
• 每季度审查有权访问管理工具的人员——参见 iam-audit
• 设置访问时会触发警报的蜜罐账户

模式 9 — 长期安全漏洞未被发现（Equifax，2017 年）

**事件经过：**攻击者利用了 Apache Struts 中未修补的 CVE-2017-5638（已知漏洞，补丁已发布两个月）。他们在被发现前已在系统内活动 76 天，并窃取了 1.47 亿条信用记录。补丁早已发布；漏洞扫描未能发现该漏洞，是因为扫描目标列表已经过时。

审计问题：

• 如果攻击者持有有效凭证并潜伏在你们的环境中，你们需要多久才能发现？
• 你们的补丁 SLA 在实践中是否得到落实，还是只停留在纸面上？
• 漏洞扫描清单是否与实际资产清单一致？

检查项：

• 每季度将资产清单与漏洞扫描目标进行交叉核对
• 按严重性衡量补丁 SLA，而不只是制定要求（vuln-research）
• 覆盖漏洞利用后的行为检测（横向移动、数据暂存、数据外传）——参见 siem-detection
• 针对代表性场景衡量 MTTD（平均检测时间）

模式 10 — Cookie / token 窃取 → 绕过 MFA（2022 年 Uber 泄露事件，攻击者通过承包商入侵）

**事件经过：**攻击者攻破了承包商的凭据，利用 MFA 提示疲劳攻击入侵，随后展开了探索。他们在网络共享中发现了包含特权凭据的 PowerShell 脚本，并由此访问了 AWS、GCP、Google Workspace 和 Slack。发现的资源中包括一款特权访问管理工具，攻击者可以利用它为自己授予更多访问权限。

审计问题：

• 网络共享中存放着哪些凭据？
• 如果攻击者进入网络共享，他们会发现什么？
• 承包商账户的影响范围有多大？

检查：

• 对所有内部文件共享、Wiki、工单系统进行凭据发现扫描——参见 secrets-audit
• 承包商账户接受与员工相同的 MFA 和审查
• 将特权访问管理（PAM）系统本身作为皇冠上的明珠资产进行审计

可添加的模式（由你负责）

这项技能应随着每次重大公开泄露事件不断扩展。流程：

1. 阅读事后分析（供应商报告、新闻报道、监管文件）
2. 提炼出可推广到特定供应商之外的一句话模式
3. 将其表述为一个审计问题，你的技术栈应能回答“否”
4. 将其映射到现有审计技能中的具体检查项
5. 将其添加到此技能中

优质的事后分析来源：

• 供应商安全博客（被攻击公司的自述通常最准确）
• 上市公司的 SEC 8-K 文件（法律层面的详细资料）
• “BleepingComputer”、“Risky.Biz News”、“Krebs on Security”——可靠的泄露事件报道
• Verizon DBIR（年度报告）——汇总全年各类模式
• MITRE ATT&CK 实战报告

输出格式

# Breach Pattern Coverage Assessment
## Environment: [name]
## Date: [date]

### Coverage status
| Pattern | Audit question | Status | Owner |
|---------|----------------|--------|-------|
| IMDS abuse (Capital One) | SSRF-to-metadata reachable? | Clean | sec |
| Supplier blast radius (SolarWinds) | CI/CD blast radius? | Gap — plan attached | platform |
| ... | | | |

### Gaps with plans
[For each Gap row above — what's the plan, by when]

### Patterns not yet evaluated
[Patterns where you don't yet have data to mark Clean / Gap]

这是一份每季度可重新运行的文档，不是一次性文档。行业模式会不断演变。

边界

• 此技能用于事前防范（“这种情况会发生在我们身上吗？”），而非用于攻击（“我们能否做到 Lapsus$ 做过的事？”）
• 公开的泄露事件详情属于公开信息，可以使用。不要寻找泄露的凭据转储或非公开详情
• 如果评估发现了正在发生的问题（不是“可能发生”，而是“正在发生”），请转向 incident-triage
• 不要生成攻击模式或详细的攻击者行动手册，超出评估防御覆盖范围所需的内容

参考资料

• “Cyber Incident Reporting and Analysis Methods” — DHS / CISA
• Verizon Data Breach Investigations Report（DBIR）——年度行业泄露事件分析
• MITRE ATT&CK 实战报告
• CISA 网络安全公告
• Krebs on Security（krebsonsecurity.com）
• “Risky.Biz” 新闻播客 / 新闻简报
• Project Zero — Google 的攻击性安全团队报告
• Mandiant / CrowdStrike 威胁报告
• “Tracing Stolen Bitcoin”——关于攻击者工作流的调查报告