In November 2022, DraftKings customers started watching their balances drain. Money moved out of accounts overnight, withdrawals they never authorized, deposits funding cash-outs to attacker-controlled destinations. There was no breach of DraftKings itself. No database got popped, no server got owned. The accounts were simply logged into, with the correct usernames and passwords, by someone who was not the owner. This week a 21-year-old who went by “Snoopy” was sentenced to 18 months in federal prison for his part in it, and the case is a clean, ugly lesson in the kind of cybersecurity failure that never shows up as a CVE.

The attack didn’t need a single exploit

Here’s the part that should bother you. Snoopy and his crew didn’t write malware. They didn’t find a zero-day. They ran credential stuffing, which is the least glamorous attack in the book and one of the most reliable. You take a giant list of username-and-password pairs leaked from some unrelated breach, you point an automated tool at a login page, and you see which ones still work. People reuse passwords. Enough of them reuse passwords that a list of a few million credentials will quietly unlock thousands of accounts on a completely different service.

That’s what happened here. The credentials came from somewhere else. DraftKings was just the cash-out venue. Once a login succeeded, the attackers changed the payment details, added a small deposit to validate the new method, then drained whatever was inside. The whole operation ran on other people’s password hygiene and a login endpoint that let an automated script hammer it without much resistance.

Calling this a brute-force attack isn’t quite right, and the distinction matters for defense. A classic brute-force run guesses passwords against one account until something sticks. Credential stuffing flips it: one known password tried against one matching username, then on to the next pair. Low guesses per account, enormous volume across accounts. Defenses tuned only to catch repeated failures against a single user will watch a stuffing run sail straight past.

Why this keeps printing money

The economics are brutal in the attacker’s favor. Breach dumps are cheap and abundant. Stuffing tools are off-the-shelf and route through residential proxies, so the traffic looks like it’s coming from thousands of ordinary home IP addresses instead of one suspicious server. A 1% hit rate against a list of two million credentials is twenty thousand working accounts. For anything tied to money or stored value, gambling balances, loyalty points, gift card stashes, store credit, that’s a direct payday with no malware development and almost no technical skill required.

And it scales sideways. The same list that worked against one sportsbook gets tried against banks, retailers, streaming services, and airline mileage programs. Your customers’ reused passwords are an externality you inherit whether you like it or not. You didn’t leak the credentials, but you’re the one explaining to a user why their balance is gone. That’s the uncomfortable core of consumer-facing cyber security: a meaningful share of your account-takeover risk was created by somebody else’s breach, and it still lands on your incident response team.

What actually stops a stuffing run

You can’t fix everyone’s password reuse, so stop trying. Build controls that assume valid-looking credentials will arrive at your login page and make that fact useless to the attacker. This is defense in depth applied to authentication, and most of it is configuration and process rather than new spend.

Start with the moves you can make this week:

• Make phishing-resistant MFA the default, not an opt-in. A correct password is worthless without the second factor. If you can’t mandate it everywhere, mandate it for any action that moves money or changes payment details.
• Rate-limit and throttle at the login endpoint. Per-IP limits alone won’t catch proxy-spread traffic, so add velocity controls keyed on account, device fingerprint, and failed-attempt patterns across the whole endpoint. Your firewall or WAF can blunt the crude waves; the smarter ones need application-aware logic behind it.
• Flag the takeover behaviors, not just the bad password. A login from a new device and country followed minutes later by a payment-method change and a withdrawal is the signature. Tie that sequence to step-up verification. This is where real threat detection lives, in the sequence of actions after a successful login.
• Screen credentials against known breach corpora. If a user’s password appears in a public dump, force a reset. You’re closing the exact door stuffing walks through.

Then the ongoing work, because stuffing is a campaign, not an event. Instrument your authentication stack so login success and failure rates, geographic spread, and new-device ratios are graphed and alertable; a stuffing run shows up as a statistical anomaly long before a customer complains. Bake an account-takeover scenario into your incident response plan, with a written runbook for freezing withdrawals, forcing mass resets, and notifying affected users at speed. Treat fraud signals and threat-protection telemetry as one feed, since the fraud team usually sees the cash-out pattern before security correlates the logins. Security hardening of a login page is mostly this unglamorous, continuous tuning, and it’s far cheaper than the breach headline and the regulatory letters that follow.

Frequently Asked Questions

Is credential stuffing the same as a brute-force attack?

No. Brute force guesses many passwords against one account. Credential stuffing tries known username-password pairs from other breaches, usually one attempt per account, at massive scale. Defenses built only for repeated failed logins on a single account often miss it entirely.

Does MFA fully solve this?

Phishing-resistant MFA stops the overwhelming majority of stuffing-driven takeovers, because a valid password alone gets the attacker nowhere. It isn’t a complete answer on its own, so pair it with rate limiting, behavioral detection, and breached-password screening.

Why go after a sportsbook instead of a bank?

Stored balances, weaker default authentication, and fast cash-out paths. Anywhere money or value sits behind a username and password is a target, and the same credential lists get tried everywhere at once.

Sources

• DraftKings hacker ‘Snoopy’ sentenced to 18 months in prison