How a card testing ring made 120,000 fake accounts without opening the signup page

Every week I take one real fraud or abuse case, walk through what the actor actually did, and list the rules you can add to your own trust engine because of it. This is edition #002.

This week: 120,000 fake accounts, built to test stolen credit cards.

We hold full forensics on 40,266 of them, created inside four days on a subscription platform we protect. A normal day on that platform is 300 to 390 signups. The peak day did 20,065, which is 51 times normal.

The detail that stuck with me is that they never opened the signup page.

How they did it

1. Testing the waters

They created twelve accounts using disposable infrastructure, a VPN and disposable email, to get a sense of what the platform was checking. This happened twelve days before the burst, by hand, on throwaway domains that never came back.

That was the rehearsal. They were measuring what would get stopped.

2. Decoding the API parameters

They watched the network calls in the browser console to see what the API actually required, then confirmed a request would go through on its own. From that point the front end was irrelevant to them.

3. Bypassing 2FA

They used a well known disposable email provider whose inboxes are readable over an open JSON API. No key, no cookie, no proof of ownership. The bot script queried the inbox, pulled the verification code, and submitted it.

No browser was ever open. Signup, email verification and checkout ran as raw HTTP in seconds.

4. Bypassing IP blocking

They bought IP blocks from Vultr, Hostroyale Technologies Private Limited and others, and rotated constantly. Within a single email domain, 4,461 accounts arrived on 4,087 addresses, and 91% of those addresses were used exactly once.

Across the whole population we profiled 17,260 IP addresses. 99.7% were anonymized in some way. Thirteen were clean.

5. Bypassing domain blocking

They kept rotating disposable domain providers, so blocking turned into whack-a-mole. 1,634 disposable domains have hit this platform in total. Every round of blocking kept the customer's team busy and away from working on their actual product, which is its own kind of damage.

What did not work

Each of these was already in place before the attack.

Domain blocking. They rotated faster than anyone could maintain a list.

IP blocking. Almost every address was used once and discarded. Rented hosting is cheap enough that this isn't a constraint.

Email 2FA. This is the one that should worry you. An emailed code proves someone controls a mailbox. When the mailbox is served over a public API, the bot controls it too.

What did work

The device

The customer checks on the checkout page that Rupt sees a real, valid, active device attached to the account. If you're running headless, you cannot fake that part.

Automations lie

Real browsers come loaded with things a script has to remember to inject, and scripts forget. Timezones and user agents disagreed with each other. Those mismatches are detectable.

The signals were too lazy

The forged fingerprints weren't randomized in any convincing way. They were close to uniform, which is nothing like a real user population:

Every screen they sent was transposed: 1080x1920, 2160x3840. No desktop is 3,840 pixels tall.

Forging a fingerprint is easy. Forging a distribution of fingerprints that looks like a real user base is much harder, and nobody bothers.

Rules worth adding to your engine

1. Check velocity per email domain and per IP block, at signup.
2. Send an AI agent at every new email domain the first time you see it.
3. Score datacenter, VPN and anonymizer traffic into your risk score.
4. Score fingerprint consistency and impossible values.
5. Score bot, headless-browser and automation detection.
6. Serve your challenge on its own bot-resistant page. This is the critical one.
7. Make the API prove the earlier steps actually happened.
8. Tighten everything automatically while volume is spiking.

Rule 6 and rule 7 are the pair that matters. A challenge a script can finish end to end is a speed bump, and an API that accepts a checkout without evidence that the earlier steps were real is an open door.

The takeaway

An emailed code proves someone controls a mailbox. A texted code proves someone controls a number. Neither one proves there's a person.

If a script can finish your challenge on its own, the challenge is checking the wrong thing. Agents have their own inboxes now.

More Trust Booster cases

• One device, 400 fake accounts: the six signals that gave the ring away
• Thousands of fake leads, made by hand, with no bot signals at all
• One seat, 41 people: how account sharing hid a scraping and resale ring