breach-patterns

Name: breach-patterns
Author: briiirussell

320stars36forks

How to install breach-patterns?

briiirussell/cybersecurity-skills/breach-patterns

$npx -y skills add briiirussell/cybersecurity-skills --skill breach-patterns

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Breach Patterns — Preemptive Hardening from Public Breach Disclosures
2
3	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."
4
5	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.
6
7	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.
8
9	## How to use this skill
10
11	For each breach pattern below:
12
13	1. Read the one-paragraph summary of the breach
14	2. Ask the audit question(s) it implies for your environment
15	3. Map to specific checks in the existing audit skills
16	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"
17
18	The output is a "breach-pattern coverage" document — not a fixed report, an evergreen checklist you re-run against your evolving stack.
19
20	## Pattern 1 — IMDS abuse (Capital One, 2019)
21
22	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.
23
24	Audit question: Does any service that takes a URL from user input also have IAM credentials reachable via IMDS?
25
26	Check:
27	- IMDSv2 enforced on every EC2 launch template (`MetadataOptions.HttpTokens: required`) — see `cloud-audit`
28	- 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`)
29	- WAF rules log + alert on metadata-endpoint patterns
30
31	## Pattern 2 — Supplier credential blast radius (SolarWinds, 2020)
32
33	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.
34
35	Audit questions:
36	- Which suppliers have credentials in your environment that could similarly compromise you if the supplier was breached?
37	- Do your CI / CD systems have credentials that could move laterally into prod?
38	- Are software updates verified against signatures, or trusted by source URL?
39
40	Check:
41	- CI/CD secrets minimized to scope (read-only deploy tokens, not full admin)
42	- Signed commit / signed artifact enforcement where critical
43	- Third-party JavaScript pinned to specific versions or SHA-pinned via SRI
44	- Vendor-managed services audited for blast radius — see `iam-audit` for cross-account trust patterns
45
46	## Pattern 3 — Vault exfiltration via developer endpoint (LastPass, 2022)
47
48	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.
49
50	Audit questions:
51	- Which engineering accounts can reach production data, and what device posture is required?
52	- Are device security policies enforced for personal devices used to access corporate systems?
53	- What metadata is stored unencrypted around encrypted user data?
54
55	Check:
56	- Device-trust requirements for any high-value access (Zero Trust posture — see `iam-audit`)
57	- Privileged access through

briiirussellPublisher · 30 listings

Preview

briiirussell/cybersecurity-skills

# 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 impli

Breaches catalogued here are public, well-documented, and pattern-bearing. Each pattern surfaces a control or check that often falls between OWASP categories —

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 de

Repobriiirussell/cybersecurity-skills

LicenseMIT

TypeSkills

CategorySecurity

UpdatedMay 2026

Repo stars320

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

breach-patterns

320stars36forks

View on GitHub

How to install breach-patterns?

briiirussell/cybersecurity-skills/breach-patterns

$npx -y skills add briiirussell/cybersecurity-skills --skill breach-patterns

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Breach Patterns — Preemptive Hardening from Public Breach Disclosures
2
3	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."
4
5	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.
6
7	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.
8
9	## How to use this skill
10
11	For each breach pattern below:
12
13	1. Read the one-paragraph summary of the breach
14	2. Ask the audit question(s) it implies for your environment
15	3. Map to specific checks in the existing audit skills
16	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"
17
18	The output is a "breach-pattern coverage" document — not a fixed report, an evergreen checklist you re-run against your evolving stack.
19
20	## Pattern 1 — IMDS abuse (Capital One, 2019)
21
22	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.
23
24	Audit question: Does any service that takes a URL from user input also have IAM credentials reachable via IMDS?
25
26	Check:
27	- IMDSv2 enforced on every EC2 launch template (`MetadataOptions.HttpTokens: required`) — see `cloud-audit`
28	- 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`)
29	- WAF rules log + alert on metadata-endpoint patterns
30
31	## Pattern 2 — Supplier credential blast radius (SolarWinds, 2020)
32
33	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.
34
35	Audit questions:
36	- Which suppliers have credentials in your environment that could similarly compromise you if the supplier was breached?
37	- Do your CI / CD systems have credentials that could move laterally into prod?
38	- Are software updates verified against signatures, or trusted by source URL?
39
40	Check:
41	- CI/CD secrets minimized to scope (read-only deploy tokens, not full admin)
42	- Signed commit / signed artifact enforcement where critical
43	- Third-party JavaScript pinned to specific versions or SHA-pinned via SRI
44	- Vendor-managed services audited for blast radius — see `iam-audit` for cross-account trust patterns
45
46	## Pattern 3 — Vault exfiltration via developer endpoint (LastPass, 2022)
47
48	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.
49
50	Audit questions:
51	- Which engineering accounts can reach production data, and what device posture is required?
52	- Are device security policies enforced for personal devices used to access corporate systems?
53	- What metadata is stored unencrypted around encrypted user data?
54
55	Check:
56	- Device-trust requirements for any high-value access (Zero Trust posture — see `iam-audit`)
57	- Privileged access through

briiirussellPublisher · 30 listings

Preview

briiirussell/cybersecurity-skills

# 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 impli

Breaches catalogued here are public, well-documented, and pattern-bearing. Each pattern surfaces a control or check that often falls between OWASP categories —

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 de

Repobriiirussell/cybersecurity-skills

LicenseMIT

TypeSkills

CategorySecurity

UpdatedMay 2026

Repo stars320

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type