[{"data":1,"prerenderedAt":331},["ShallowReactive",2],{"\u002Fblog\u002Fcard-testing-ring-120000-fake-accounts":3},{"id":4,"title":5,"accomplishment1":6,"accomplishment2":6,"accomplishment3":6,"author":7,"body":8,"category":315,"createdAt":316,"description":317,"executiveSummary":6,"extension":318,"founded":6,"headquarters":6,"img":319,"meta":320,"navigation":322,"og-img":319,"path":323,"rawbody":324,"seo":325,"sitemap":326,"size":6,"status":327,"stem":328,"tags":329,"updatedAt":6,"website":6,"__hash__":330},"blog\u002F4.blog\u002F55.Card testing ring 120000 fake accounts.md","How a card testing ring made 120,000 fake accounts without opening the signup page",null,"Ahmed Saleh",{"type":9,"value":10,"toc":294},"minimark",[11,15,19,22,25,28,35,40,45,48,51,55,58,62,65,68,72,75,78,82,85,89,92,99,105,111,115,119,122,126,129,133,136,214,217,220,224,252,255,259,262,265,268,272],[12,13,5],"h1",{"id":14},"how-a-card-testing-ring-made-120000-fake-accounts-without-opening-the-signup-page",[16,17,18],"p",{},"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.",[16,20,21],{},"This week: 120,000 fake accounts, built to test stolen credit cards.",[16,23,24],{},"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.",[16,26,27],{},"The detail that stuck with me is that they never opened the signup page.",[16,29,30],{},[31,32],"img",{"alt":33,"src":34},"Trust Booster #002: 120,000 fake accounts to test stolen credit cards","\u002Fimg\u002Fblog\u002Ftrust-booster-card-testing.png",[36,37,39],"h2",{"id":38},"how-they-did-it","How they did it",[41,42,44],"h3",{"id":43},"_1-testing-the-waters","1. Testing the waters",[16,46,47],{},"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.",[16,49,50],{},"That was the rehearsal. They were measuring what would get stopped.",[41,52,54],{"id":53},"_2-decoding-the-api-parameters","2. Decoding the API parameters",[16,56,57],{},"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.",[41,59,61],{"id":60},"_3-bypassing-2fa","3. Bypassing 2FA",[16,63,64],{},"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.",[16,66,67],{},"No browser was ever open. Signup, email verification and checkout ran as raw HTTP in seconds.",[41,69,71],{"id":70},"_4-bypassing-ip-blocking","4. Bypassing IP blocking",[16,73,74],{},"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.",[16,76,77],{},"Across the whole population we profiled 17,260 IP addresses. 99.7% were anonymized in some way. Thirteen were clean.",[41,79,81],{"id":80},"_5-bypassing-domain-blocking","5. Bypassing domain blocking",[16,83,84],{},"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.",[36,86,88],{"id":87},"what-did-not-work","What did not work",[16,90,91],{},"Each of these was already in place before the attack.",[16,93,94,98],{},[95,96,97],"strong",{},"Domain blocking."," They rotated faster than anyone could maintain a list.",[16,100,101,104],{},[95,102,103],{},"IP blocking."," Almost every address was used once and discarded. Rented hosting is cheap enough that this isn't a constraint.",[16,106,107,110],{},[95,108,109],{},"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.",[36,112,114],{"id":113},"what-did-work","What did work",[41,116,118],{"id":117},"the-device","The device",[16,120,121],{},"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.",[41,123,125],{"id":124},"automations-lie","Automations lie",[16,127,128],{},"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.",[41,130,132],{"id":131},"the-signals-were-too-lazy","The signals were too lazy",[16,134,135],{},"The forged fingerprints weren't randomized in any convincing way. They were close to uniform, which is nothing like a real user population:",[137,138,139,155],"table",{},[140,141,142],"thead",{},[143,144,145,149,152],"tr",{},[146,147,148],"th",{},"Device signal",[146,150,151],{},"Bot",[146,153,154],{},"Real users",[156,157,158,170,180,194,204],"tbody",{},[143,159,160,164,167],{},[161,162,163],"td",{},"high-entropy fields empty",[161,165,166],{},"100%",[161,168,169],{},"0.3%",[143,171,172,175,177],{},[161,173,174],{},"Windows 10 \u002F Win32",[161,176,166],{},[161,178,179],{},"22%",[143,181,182,189,191],{},[161,183,184,185],{},"languages = ",[186,187,188],"span",{},"en-US",[161,190,166],{},[161,192,193],{},"44.6%",[143,195,196,199,201],{},[161,197,198],{},"maxTouchPoints = 0",[161,200,166],{},[161,202,203],{},"48.7%",[143,205,206,209,211],{},[161,207,208],{},"screen height > width",[161,210,166],{},[161,212,213],{},"1 device",[16,215,216],{},"Every screen they sent was transposed: 1080x1920, 2160x3840. No desktop is 3,840 pixels tall.",[16,218,219],{},"Forging a fingerprint is easy. Forging a distribution of fingerprints that looks like a real user base is much harder, and nobody bothers.",[36,221,223],{"id":222},"rules-worth-adding-to-your-engine","Rules worth adding to your engine",[225,226,227,231,234,237,240,243,246,249],"ol",{},[228,229,230],"li",{},"Check velocity per email domain and per IP block, at signup.",[228,232,233],{},"Send an AI agent at every new email domain the first time you see it.",[228,235,236],{},"Score datacenter, VPN and anonymizer traffic into your risk score.",[228,238,239],{},"Score fingerprint consistency and impossible values.",[228,241,242],{},"Score bot, headless-browser and automation detection.",[228,244,245],{},"Serve your challenge on its own bot-resistant page. This is the critical one.",[228,247,248],{},"Make the API prove the earlier steps actually happened.",[228,250,251],{},"Tighten everything automatically while volume is spiking.",[16,253,254],{},"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.",[36,256,258],{"id":257},"the-takeaway","The takeaway",[16,260,261],{},"An emailed code proves someone controls a mailbox. A texted code proves someone controls a number. Neither one proves there's a person.",[16,263,264],{},"If a script can finish your challenge on its own, the challenge is checking the wrong thing. Agents have their own inboxes now.",[266,267],"trust-booster-callout",{},[36,269,271],{"id":270},"more-trust-booster-cases","More Trust Booster cases",[273,274,275,282,288],"ul",{},[228,276,277],{},[278,279,281],"a",{"href":280},"\u002Fblog\u002Fone-device-400-fake-accounts","One device, 400 fake accounts: the six signals that gave the ring away",[228,283,284],{},[278,285,287],{"href":286},"\u002Fblog\u002Fthousands-of-fake-leads-made-by-hand","Thousands of fake leads, made by hand, with no bot signals at all",[228,289,290],{},[278,291,293],{"href":292},"\u002Fblog\u002Fone-seat-41-people","One seat, 41 people: how account sharing hid a scraping and resale ring",{"title":295,"searchDepth":296,"depth":296,"links":297},"",2,[298,306,307,312,313,314],{"id":38,"depth":296,"text":39,"children":299},[300,302,303,304,305],{"id":43,"depth":301,"text":44},3,{"id":53,"depth":301,"text":54},{"id":60,"depth":301,"text":61},{"id":70,"depth":301,"text":71},{"id":80,"depth":301,"text":81},{"id":87,"depth":296,"text":88},{"id":113,"depth":296,"text":114,"children":308},[309,310,311],{"id":117,"depth":301,"text":118},{"id":124,"depth":301,"text":125},{"id":131,"depth":301,"text":132},{"id":222,"depth":296,"text":223},{"id":257,"depth":296,"text":258},{"id":270,"depth":296,"text":271},"Research","2026-08-06","Trust Booster #002. A card testing operation created 120,000 fake accounts on a subscription platform by calling the APIs directly. Domain blocking, IP blocking and email 2FA were all already running. Here is what stopped it.","md","\u002Fimg\u002Fblog\u002Ftrust-booster-card-testing-cover.png",{"head":321},{"title":5},true,"\u002Fblog\u002Fcard-testing-ring-120000-fake-accounts","---\ntitle: How a card testing ring made 120,000 fake accounts without opening the signup page\nhead:\n  title: How a card testing ring made 120,000 fake accounts without opening the signup page\ndescription: \"Trust Booster #002. A card testing operation created 120,000 fake accounts on a subscription platform by calling the APIs directly. Domain blocking, IP blocking and email 2FA were all already running. Here is what stopped it.\"\nauthor: Ahmed Saleh\ncreatedAt: 2026-08-06\nimg: \u002Fimg\u002Fblog\u002Ftrust-booster-card-testing-cover.png\nog-img: \u002Fimg\u002Fblog\u002Ftrust-booster-card-testing-cover.png\ncategory: Research\ntags: trust booster, card testing, fake account prevention, bot detection, 2FA bypass, device fingerprinting, payment fraud\nstatus: published\n---\n\n# How a card testing ring made 120,000 fake accounts without opening the signup page\n\nEvery 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.\n\nThis week: 120,000 fake accounts, built to test stolen credit cards.\n\nWe 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.\n\nThe detail that stuck with me is that they never opened the signup page.\n\n![Trust Booster #002: 120,000 fake accounts to test stolen credit cards](\u002Fimg\u002Fblog\u002Ftrust-booster-card-testing.png)\n\n## How they did it\n\n### 1. Testing the waters\n\nThey 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.\n\nThat was the rehearsal. They were measuring what would get stopped.\n\n### 2. Decoding the API parameters\n\nThey 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.\n\n### 3. Bypassing 2FA\n\nThey 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.\n\nNo browser was ever open. Signup, email verification and checkout ran as raw HTTP in seconds.\n\n### 4. Bypassing IP blocking\n\nThey 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.\n\nAcross the whole population we profiled 17,260 IP addresses. 99.7% were anonymized in some way. Thirteen were clean.\n\n### 5. Bypassing domain blocking\n\nThey 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.\n\n## What did not work\n\nEach of these was already in place before the attack.\n\n**Domain blocking.** They rotated faster than anyone could maintain a list.\n\n**IP blocking.** Almost every address was used once and discarded. Rented hosting is cheap enough that this isn't a constraint.\n\n**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.\n\n## What did work\n\n### The device\n\nThe 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.\n\n### Automations lie\n\nReal 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.\n\n### The signals were too lazy\n\nThe forged fingerprints weren't randomized in any convincing way. They were close to uniform, which is nothing like a real user population:\n\n| Device signal             | Bot  | Real users |\n| ------------------------- | ---- | ---------- |\n| high-entropy fields empty | 100% | 0.3%       |\n| Windows 10 \u002F Win32        | 100% | 22%        |\n| languages = [en-US]       | 100% | 44.6%      |\n| maxTouchPoints = 0        | 100% | 48.7%      |\n| screen height > width     | 100% | 1 device   |\n\nEvery screen they sent was transposed: 1080x1920, 2160x3840. No desktop is 3,840 pixels tall.\n\nForging a fingerprint is easy. Forging a distribution of fingerprints that looks like a real user base is much harder, and nobody bothers.\n\n## Rules worth adding to your engine\n\n1. Check velocity per email domain and per IP block, at signup.\n2. Send an AI agent at every new email domain the first time you see it.\n3. Score datacenter, VPN and anonymizer traffic into your risk score.\n4. Score fingerprint consistency and impossible values.\n5. Score bot, headless-browser and automation detection.\n6. Serve your challenge on its own bot-resistant page. This is the critical one.\n7. Make the API prove the earlier steps actually happened.\n8. Tighten everything automatically while volume is spiking.\n\nRule 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.\n\n## The takeaway\n\nAn emailed code proves someone controls a mailbox. A texted code proves someone controls a number. Neither one proves there's a person.\n\nIf a script can finish your challenge on its own, the challenge is checking the wrong thing. Agents have their own inboxes now.\n\n::TrustBoosterCallout\n::\n\n## More Trust Booster cases\n\n- [One device, 400 fake accounts: the six signals that gave the ring away](\u002Fblog\u002Fone-device-400-fake-accounts)\n- [Thousands of fake leads, made by hand, with no bot signals at all](\u002Fblog\u002Fthousands-of-fake-leads-made-by-hand)\n- [One seat, 41 people: how account sharing hid a scraping and resale ring](\u002Fblog\u002Fone-seat-41-people)\n",{"title":5,"description":317},{"loc":323},"published","4.blog\u002F55.Card testing ring 120000 fake accounts","trust booster, card testing, fake account prevention, bot detection, 2FA bypass, device fingerprinting, payment fraud","UaIOIs5mYtIrUv_tcaDfie5YdmydFACB4edM0pTaknQ",1787249130687]