What happened

In 2019, Capital One suffered a breach exposing over 100 million customer records — names, addresses, credit scores, bank account numbers. No password was stolen. No employee got phished. The attacker exploited a misconfigured web application firewall sitting in front of Capital One's AWS infrastructure, using a technique called SSRF (server-side request forgery) to trick that server into fetching temporary security credentials from AWS's internal metadata service.

Those credentials belonged to an IAM role that had far more permission than the firewall ever needed — including read access to a large number of S3 storage buckets. The attacker used the borrowed credentials to list and download the contents of those buckets directly. Capital One was later fined $80 million by regulators, on top of the breach itself.

Why this matters for you

Two things went wrong here, and both are extremely common in startups running on AWS, GCP, or Azure:

1. Over-permissioned roles. It's fast and easy to attach a broad policy ("just give it S3 read access to everything") when you're moving quickly. Almost nobody goes back later to narrow it down once things are working.

2. A single misconfigured public-facing component became a bridge to everything else. The firewall itself wasn't the valuable target — it was a stepping stone to credentials that unlocked the real target.

Most startups have at least one over-permissioned role sitting quietly in their cloud account right now, created in a rush during setup and never revisited.

What to actually do about it

1. Apply least-privilege by default. Every IAM role/service account should have exactly the permissions it needs — nothing broader "just in case." This is a policy decision, not a technical limitation; most cloud providers support scoping this tightly.

2. Audit your existing roles today. Look for any role with wildcard (*) resource access or broad read/write to storage. You will likely find at least one.

3. Disable or restrict metadata service access (IMDSv2 on AWS) on any server that doesn't need to reach it — this specific technique relied on an older, weaker version of that service.

4. Treat your WAF/firewall/proxy layer as a high-value target itself, not just a defense — it's often the single most exposed component with the most invisible internal access.

5. Set up storage bucket alerts for unusual access patterns (large downloads, access from new IPs) — this breach went undetected for months.

No security team required — this is a settings review you can do this afternoon in your own cloud console.

---

Want a breakdown like this every week, delivered to a members-only space where you can ask about your own setup? That's ThreatWire Insider ($19/mo) — new subscribers get 25% off their first month with code LAUNCH.

Know a founder who'd find this useful? The affiliate program pays 30% recurring commission on every referral — link's on the product page.

What happens

Business Email Compromise (BEC) is consistently the single largest category of reported cybercrime losses tracked by the FBI's Internet Crime Complaint Center — bigger than ransomware, bigger than card fraud, running into the billions annually. And it usually doesn't involve any "hacking" at all.

The classic version: someone on your team gets an email that looks exactly like it's from a real vendor, contractor, or even your own CEO. It says something routine — "quick update, we changed banks, please send this month's payment to the new account" — and includes a legitimate-looking invoice. Whoever's paying bills wires the money. It's gone in minutes, and by the time the real vendor asks where their payment is, there's nothing to claw back.

Sometimes the attacker spoofs the sender address. Sometimes they've actually compromised a real vendor's email account and are watching an existing invoice thread, then jumping in with the "bank changed" message at exactly the right moment.

Why this matters for you

Startups are disproportionately easy targets for this specific scam:

• Usually one person (often the founder) approves and sends payments, with no second set of eyes.

• Finance processes are informal — email is the approval mechanism, not a dedicated system with verification steps.

• Founders are visible online (LinkedIn, Twitter, your own product marketing), making it trivial for an attacker to know your name, your vendors, and your writing style.

This attack costs an attacker nothing but time and a convincing email. No malware, no exploit, no technical skill required — just patience and a well-timed message.

What to actually do about it

1. Never change payment details based on an email alone. Any request to change a bank account or payment method gets a phone call to a number you already have on file (not one provided in the email) before you send anything.

2. Require a second person to approve any wire or bank-detail change over a set dollar threshold — even if that second person is a co-founder, not a finance team.

3. Set up DMARC, SPF, and DKIM on your own domain so it's harder for attackers to spoof your company's emails to your vendors and customers.

4. Watch for urgency and secrecy language — "this is time-sensitive," "don't loop anyone else in yet" — these are the two biggest tells in a BEC attempt.

5. Tell your vendors and clients directly that you will never change payment instructions over email alone, so they know to double-check if they ever get a request like that appearing to come from you.

None of this costs money. It costs one conversation with whoever pays your bills, today.

---

If you want a weekly breakdown like this delivered straight to a members-only space — plus somewhere to ask about your own setup — that's ThreatWire Insider ($19/mo). New subscribers get 25% off their first month with code LAUNCH.

Know a founder who'd get value from this? The affiliate program pays 30% recurring commission on every referral — link's on the product page.

What happened

In 2022, Uber got breached end-to-end — internal Slack, AWS, GCP, code repos, financial dashboards, the works. The entry point wasn't a zero-day. It was a contractor whose credentials had leaked, and an attacker who simply spammed their phone with MFA push notifications until, exhausted, they approved one ("MFA fatigue"). That got the attacker onto the internal network.

From there, the attacker found a PowerShell script sitting on a shared network drive. Inside it: hardcoded admin credentials for the company's privileged access management tool. That one file was the master key — it unlocked everything else.

Why this matters for you

Two failures, both extremely common at startups:

1. Single-factor-equivalent MFA. Push-based MFA that just asks "approve or deny" is beatable by volume — spam someone at 2am enough times and they'll tap approve just to make it stop. This works on real employees at real companies constantly.

2. Hardcoded credentials in scripts, configs, or notes. Every startup has at least one script, README, or internal doc with a real API key or password typed directly into it "temporarily." Those never get cleaned up. They're often the single point of failure the entire rest of your security stack has been quietly assuming doesn't exist.

Neither of these requires a sophisticated attacker. They require patience and someone forgetting to clean up after themselves — which is normal, not negligent. That's exactly why it's worth checking for.

What to actually do about it

1. Switch to number-matching or phishing-resistant MFA (not simple push-approve) on anything that gates real access — VPN, SSO, cloud consoles.

2. Grep your own repos and shared drives for hardcoded secrets. Tools like gitleaks or trufflehog take minutes to run against your whole codebase and will surface exactly this problem before an attacker finds it.

3. Never let credentials live in scripts. Use a secrets manager (even a basic one) — a script should fetch a credential at runtime, never contain it.

4. Rate-limit and alert on repeated MFA prompts. If someone is getting hit with push requests at 2am they didn't trigger, that's a signal, not noise.

None of this needs a security hire. It needs about an afternoon and the discipline to actually go looking.

---

If you want this kind of practical breakdown delivered every week — plus a private space to ask specific questions about your own stack — that's what ThreatWire Insider ($19/mo) is for. New subscribers can use code LAUNCH for 25% off the first month.

And if you know other founders who'd find this useful: the affiliate program pays 30% recurring commission on every referral, for as long as they stay subscribed. Link's on the product page.

ThreatWire Insider just launched — a $19/mo cybersecurity newsletter for startup founders and CTOs without a security team (weekly threat briefs, breach breakdowns, no-fluff defense tactics).

We're opening up our affiliate program: 30% recurring commission on every referral, for as long as they stay subscribed. Grab your affiliate link from the product page and share it with any founder who needs to sleep better at night.

Bonus: new subscribers can use code LAUNCH for 25% off their first month, which makes it an easy recommend.

Drop a comment if you have questions about the program.

Ran engineering at two startups before this. Both times, security was "we'll deal with it after we raise the next round." Both times, we got hit with something avoidable before that round closed.

Here's the pattern I keep seeing with founders who don't have a security hire yet:

1. Everyone shares one AWS root account. No MFA, no audit trail. When something breaks at 2am, you don't know who touched what. Fix: IAM users per person, root account locked in a vault, MFA everywhere. Takes an afternoon.

2. Customer data lives in a Notion doc "temporarily." It's still there 8 months later. Attackers don't need to breach your infra if your support team pastes API keys into a shared doc. Fix: a real secrets manager (even a free one) from day one.

3. Nobody owns "what happens if we get breached." Not because anyone's careless — there's just no one whose job it is to ask. Fix: even as a solo founder, write a 1-page incident response plan. Who do you call, what do you shut off first, who do you notify.

None of this requires a security hire or a budget. It requires 2-3 hours and someone deciding it matters before it's on fire.

I started writing these breakdowns up properly (real breaches, what triggered them, the exact fix) because I got tired of re-explaining the same three things to every founder I advise. If that's useful to you, it's free to browse what I've got going.