breach-patterns

Breach Patterns — Preemptive Hardening from Public Breach Disclosures

The inverse of incident-triage. That skill is "we're on fire, what now." This skill is "go read the breach writeups, extract the audit question each one implies, and check your own stack."

Breaches catalogued here are public, well-documented, and pattern-bearing. Each pattern surfaces a control or check that often falls between OWASP categories — IMDS abuse, supplier credential blast radius, secrets-in-CI, single-sign-on lateral movement, log-tampering pre-breach. These are the controls people add after their first incident; reading other people's breaches is cheaper than writing your own.

Cross-references: every audit skill in this repo. Use this skill to surface "have we considered X?" questions, then pivot to the relevant audit skill for the deep dive. When a breach pattern surfaces a regulatory implication — health data exposure, payment card data exposure, PII exposure — also reach for hipaa-audit, pci-audit, or privacy-engineering to understand the regulatory clock and notification obligations that come with that breach class.

How to use this skill

For each breach pattern below:

1. Read the one-paragraph summary of the breach
2. Ask the audit question(s) it implies for your environment
3. Map to specific checks in the existing audit skills
4. Decide disposition — "we've confirmed this can't happen," "we have a gap, here's the plan," or "we accept-risk for these reasons"

The output is a "breach-pattern coverage" document — not a fixed report, an evergreen checklist you re-run against your evolving stack.

Pattern 1 — IMDS abuse (Capital One, 2019)

What happened: A misconfigured WAF allowed SSRF. An attacker used SSRF to reach the EC2 instance metadata service (IMDSv1, no token requirement), pulled temporary IAM credentials, and used them to enumerate and exfiltrate S3 buckets containing 100M+ records.

Audit question: Does any service that takes a URL from user input also have IAM credentials reachable via IMDS?