/breach-patterns

name: breach-patterns
description: "Learn from public breach disclosures — extract the audit question each one implies and check your own stack. Capital One IMDS abuse, LastPass vault exfiltration, Okta Lapsus$, Snowflake credential reuse, MOVEit, SolarWinds, Equifax, Target POS, Codecov, Uber, Twilio — what would you check now if your boss said 'could that happen to us?' Use when the user mentions 'breach analysis,' 'lessons learned,' 'security postmortem,' 'breach patterns,' 'breach lessons,' 'has this happened to us,' 'apply breach lessons,' 'preempt breaches,' 'security retrospective,' 'real-world security incidents,' or wants to harden against known attacker playbooks."
allowed-tools: Read, Grep, Glob, Bash, WebSearch, WebFetch

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?

**Check:**

• IMDSv2 enforced on every EC2 launch template (`MetadataOptions.HttpTokens: required`) — see `cloud-audit`
• SSRF defences on every URL-taking endpoint — see `owasp-audit` A10 bypass matrix (especially the cloud metadata endpoints row: `169.254.169.254`, `metadata.google.internal`, `169.254.170.2`)
• WAF rules log + alert on metadata-endpoint patterns

Pattern 2 — Supplier credential blast radius (SolarWinds, 2020)

**What happened:** Attackers compromised SolarWinds' build pipeline and inserted a backdoor (Sunburst) into the Orion product. Customers who installed legitimate Orion updates received the backdoored binary. The backdoor enabled lateral movement into customer networks, including the US federal government.

**Audit questions:**

• Which suppliers have credentials in your environment that could similarly compromise you if the supplier was breached?
• Do your CI / CD systems have credentials that could move laterally into prod?
• Are software updates verified against signatures, or trusted by source URL?

**Check:**

• CI/CD secrets minimized to scope (read-only deploy tokens, not full admin)
• Signed commit / signed artifact enforcement where critical
• Third-party JavaScript pinned to specific versions or SHA-pinned via SRI
• Vendor-managed services audited for blast radius — see `iam-audit` for cross-account trust patterns

Pattern 3 — Vault exfiltration via developer endpoint (LastPass, 2022)

**What happened:** Attackers initially compromised an engineer's home computer via a vulnerable third-party media plugin. That gave them access to the engineer's corporate vault. Months later, they used that access to exfiltrate customer vault data — including unencrypted URLs that helped target customers for phishing.

**Audit questions:**

• Which engineering accounts can reach production data, and what device posture is required?
• Are device security policies enforced for personal devices used to access corporate systems?
• What metadata is stored unencrypted around encrypted user data?

**Check:**

• Device-trust requirements for any high-value access (Zero Trust posture — see `iam-audit`)
• Privileged access through dedicated workstations / jump hosts, not engineer personal laptops
• Encrypt the metadata too, not just the "important" payload — URLs are PII

Pattern 4 — SSO push fatigue (Okta / Lapsus$, 2022)

**What happened:** Attackers obtained credentials for a third-party support engineer (Sitel). They spammed the engineer with push-notification MFA prompts until the engineer approved one out of habit / annoyance. They then used the support engineer's access to view (but not modify) some Okta customer tenants.

**Audit questions:**

• Is MFA on your admin accounts phishing-resistant (FIDO2 / hardware key), or just push?
• Are third-party support / contractor accounts treated with the same controls as employees?
• What's the blast radius of a support / customer-success role being compromised?

**Check:**

• Phishing-resistant MFA (FIDO2 / WebAuthn) for admins and privileged users — see `iam-audit`
• "Number matching" enabled on push MFA (where allowed) so users can't approve blindly
• Push-fat