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?

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-fatigue detection — repeated push prompts in a short window trigger an alert
• Third-party access reviewed quarterly with same rigor as employee access

Pattern 5 — Stolen credentials → SaaS lateral movement (Snowflake customers, 2024)

What happened: Attackers used credentials stolen from infostealer malware on personal devices to log into Snowflake customer environments (which had no MFA enforced). They exfiltrated data from Ticketmaster, AT&T, Santander, and others. Snowflake itself wasn't breached — customers were.

Audit questions:

• Are there SaaS services in your stack where users can authenticate without MFA?
• Is access to SaaS gated on enterprise SSO with MFA enforcement, or are local accounts allowed?
• Could credentials stolen from a personal device unlock your business-critical SaaS?

Check:

• Every SaaS in your environment audited for MFA enforcement and SSO federation
• Local-account access disabled where SSO is available
• Conditional Access policies require compliant device — see iam-audit
• Credential monitoring (HIBP, internal dark-web monitoring) for employee emails

Pattern 6 — Unpatched zero-day in file transfer (MOVEit, 2023)

What happened: Cl0p ransomware group exploited an SQL injection zero-day (CVE-2023-34362) in Progress MOVEit Transfer. They exfiltrated data from hundreds of customers — many of whom were transferring sensitive HR / financial / health data via MOVEit. Patches arrived after the exploitation campaign was already running.

Audit questions:

• For internet-facing third-party software in your environment, what's your patch SLA when a zero-day surfaces?
• What sensitive data sits in pre-built / off-the-shelf software you don't control the code of?
• Do you have detection for unusual data egress from third-party systems?

Check:

• Inventory of internet-facing third-party software, owners, patch process
• Network egress monitoring on third-party systems (see siem-detection)
• CISA KEV monitoring — automatic alerting when listed CVEs apply to your stack (see vuln-research)
• Data classification — sensitive data minimized in third-party platforms