Credential stuffing against casino cashiers

The breach is at the login; the loss is at the cashier

When a licensed casino gets hit by credential stuffing, the security team almost always looks in the wrong place. They watch the login endpoint, count failed authentications, and congratulate themselves when the block rate looks healthy. Meanwhile the actual money leaves through the cashier — hours or days later, from accounts that authenticated successfully with valid, reused passwords. The login page is where the attacker gets in. The withdrawal flow is where you lose.

We see this pattern in nearly every casino engagement that starts with "we think we have an ATO problem." The account-takeover (ATO) event and the loss event are separated in time, in log source, and usually in the org chart — the fraud team owns one and the security team owns the other. That gap is the whole game.

This post walks the full chain as we reconstruct it during an account takeover testing engagement, then gives you the defenses that actually move the loss number — not the ones that just make the login dashboard look calmer.

The attack chain, step by step

Credential stuffing against a cashier is a five-stage operation. Each stage is cheap, automatable, and individually low-signal.

Combo list acquisition. The attacker buys or assembles a "combo list" — email:password pairs leaked from unrelated breaches. Password reuse means a single-digit percentage of these will work on your platform. For a list of 2 million pairs, that is tens of thousands of valid logins.
Validation at the auth surface. Automated tooling (OpenBullet, Silverbullet, custom scripts) replays the combos against your login endpoint or, more often, a mobile or partner API endpoint that the fraud team isn't watching. The attacker isn't trying to brute-force one account; they are testing many accounts once each. Per-account failure rates stay near zero.
Session harvesting and triage. Valid sessions are sorted by value: balance, deposit history, KYC status, VIP tier. An account with a verified identity and a linked payment method is worth far more than an empty one, because it can withdraw without tripping onboarding checks.
Payment-method pivot. Inside the account, the attacker adds or modifies a withdrawal destination — a new card, a crypto wallet, an e-wallet. On many platforms this is a lighter-weight action than the original signup, protected by nothing more than the already-stolen session.
Cash-out under the radar. Withdrawals are structured to look legitimate: amounts under manual-review thresholds, timed to the account's normal activity window, sometimes preceded by a small real deposit to reset velocity counters. The money is gone before anyone correlates it with the login anomaly from three days earlier.

The reason this works is not weak passwords — you don't control your users' password hygiene. It works because each stage is defended in isolation, and no single stage looks alarming on its own.

Why your current defenses miss it

Most casinos have real controls. They just sit in the wrong places relative to this chain.

Control	What it catches	Why the cashier attack slips past
WAF rate limiting on `/login`	Volumetric brute force against one account	Stuffing is one-try-per-account, spread across a botnet — low per-IP, low per-account rate
Bot management / device fingerprinting	Naive scripted clients	Residential proxies + real mobile-app tokens defeat naive fingerprinting; the app API often has weaker checks than the web login
CAPTCHA on login	High-volume automated login	Solved via CAPTCHA-farm APIs at ~$1 per 1,000; and often absent on the mobile/partner API path
KYC at onboarding	Fake identities at signup	The stolen account is already KYC-verified — the attacker inherits it
Manual review over €X withdrawal	Large single cash-outs	Attacker structures withdrawals below the threshold

Every one of these is worth having. None of them sees the whole chain, and the attacker's entire strategy is to never present a strong enough signal to any single one.

What actually moves the loss number

The fix is not one magic control. It is instrumenting the chain end-to-end so the combination of weak signals becomes a strong one, and putting the hardest friction at the cash-out step rather than the login step. In rough order of impact:

1. Step-up authentication on the payment-method change, not just login

The single highest-leverage control. Adding or changing a withdrawal destination should require re-authentication with a factor the attacker doesn't have from the combo list — a passkey, a TOTP, or an out-of-band confirmation to a previously-verified contact. This breaks stage 4 of the chain even when stages 1–3 have already succeeded. If you do one thing from this post, do this.

2. A withdrawal cooling-off window after any account-security change

When a password, email, phone, or payment method changes, hold new withdrawal destinations for a fixed window (24–72 hours) and notify the account's original verified contact. Legitimate users almost never need to change a payment method and cash out to a brand-new destination in the same session. Attackers almost always do.

3. Cross-signal correlation between the auth surface and the cashier

This is the organizational fix disguised as a technical one. The login anomaly (successful auth from a new device/ASN) and the cashier action (new destination + withdrawal) live in different systems owned by different teams. Feeding both into one detection pipeline — the job of a 24/7 managed SOC — is what lets you say "this successful login three days ago plus this withdrawal now equals one incident." We wrote about how this correlation gets built in practice in our crypto exchange SOC runbook; the casino cashier case is the same shape with different endpoints.

4. Velocity and structuring detection at the cashier

Don't just threshold on single-withdrawal size. Detect structuring: multiple sub-threshold withdrawals, small-deposit-then-withdraw velocity resets, and cash-outs to destinations added within the trailing N days. These are the tells of stage 5, and they're only visible if you're modeling the cashier as an attack surface rather than a payments feature.

5. Credential-stuffing-specific monitoring on every auth path

The web login is usually the best-defended door. Attackers walk to the mobile API, the legacy affiliate login, the "resume session" endpoint, the password-reset flow. Inventory every path that establishes or restores a session and hold them all to the same bot-management and anomaly standard. During testing this is consistently where we find the soft entry — an undocumented or under-protected auth endpoint the security team had forgotten was live.

How we test for this

A scanner cannot find this problem, because there is no single vulnerable response to fingerprint — every individual request is well-formed and returns a normal status code. Finding it requires a human walking the full chain: enumerate every auth path, model the withdrawal state machine, and prove whether a session obtained at the login can reach a cash-out to a new destination without re-presenting a strong factor. That is exactly the kind of business-logic flaw we argue can only be found by pure-manual penetration testing — the chained-exploit narrative, not the isolated finding.

The deliverable a casino actually needs is not a CVSS list. It is a map of the withdrawal state machine with the exact transition where step-up is missing, and a reproduction that a developer can watch. That's what a real pentest report looks like for this class of attack.

The one-line summary

Stop measuring credential stuffing at the login. Measure it at the cashier, put your hardest friction on the payment-method change, and correlate the two surfaces as one incident. The attacker already treats them as one operation — your defenses need to as well.