Skip to content

Fake-account creation at scale: SMS farms, email churn, and the defenses

· 22 min read
Copyright: MIT
fraud anti-bot bot-detection
The phrase fake accounts in monospace above a row of phone icons feeding one server node, one icon orange

A signup form asks for almost nothing. An email, a password, maybe a phone number to prove you are real. The cost to a legitimate user is thirty seconds. The cost to an attacker who wants ten thousand accounts is whatever it takes to clear that same form ten thousand times, and the entire economy of fake-account creation is the work of driving that per-account cost down to fractions of a cent. The question every platform faces is not whether someone will try to mass-register accounts. It is how cheaply they can do it, and whether your defenses raise that cost faster than the attacker’s tooling lowers it.

The phone-number check was supposed to be the hard part. A human has one phone; a number costs money and ties to a real identity; SMS is out-of-band. All of that turned out to be wrong at scale. There is a global market that rents you a working mobile number for a single verification code for under a cent, and some of those numbers belong to people who have no idea their phone is part of it. This post walks the supply side first: how SMS-verification farms work, where the numbers come from, the disposable-email layer underneath, and the per-account math that makes it all viable. Then it turns to the defense: velocity and account-graph analysis, device fingerprinting, phone-number reputation, and the proof-of-work tax that tries to make automation pay. We close on why SMS verification is being quietly demoted from a trust anchor to just another weak signal.

What a fake account is worth

Nobody mass-creates accounts for the accounts themselves. The account is inventory. It gets spun up to send spam, post reviews, claim a signup bonus, farm a referral, scalp limited inventory, launder the proceeds of a carding run, or sit dormant until it is aged enough to look trustworthy and then sold. The value per account is small, often a few cents to a few dollars, so the whole operation only works if creation is cheaper than that value by a comfortable margin. That margin is the battlefield.

The attacker’s costs break into a few line items. There is the IP address, because a platform that sees a thousand signups from one IP will block it, so the attacker rents residential or mobile proxies to spread the requests. There is the email, because most signups want one. There is the phone number, when the form demands SMS verification. And there is the CAPTCHA, when one stands in the way. Each of these has a spot price on an open market, and the sum of those prices is roughly the floor on what one account costs to create. Defense is the art of pushing that sum up.

The per-account cost stack (open-market spot prices) order-of-magnitude, varies by target platform and country Residential / mobile proxy (per request share) ~$0.001 Disposable email address ~$0.000 SMS OTP number (single use, common platform) ~$0.01 CAPTCHA solve (simple, human-farmed) ~$0.001 Floor cost of one account ~$0.01 to $0.10 *The cost of one fake account is the sum of its inputs. Each line is a market with a published spot price; the phone OTP is usually the largest single item and the main thing defenses try to inflate.*

The numbers in that stack are not invented. The SMS OTP line comes straight off public price lists. On 5sim, a number for a one-time verification on a common social platform sits around a cent, with the absolute minimum near $0.008; pricier targets cost more, with WhatsApp around $0.06 and Telegram up to $0.10, because those platforms are harder to verify and the success rate is lower. CAPTCHA solving runs $0.50 to $1.00 per thousand for simple challenges on 2Captcha, climbing to $1 to $3 per thousand for reCAPTCHA v2 and far higher, $30 to $50 per thousand, for an Arkose FunCaptcha, where solver scarcity sets the price. Put together, a determined operator working a poorly-defended target can land accounts for pennies each. That is the number the defense has to move.

The SMS-verification farm

When a signup form demands a phone number and texts a code to it, the platform is making a bet. The bet is that a real person controls a real phone, that the phone costs money, and that the person will not burn it on disposable signups. SMS-verification farms exist to win that bet for the attacker by supplying a working number that receives the code, on demand, for a fraction of what the platform assumes a phone is worth.

The clean version of the supply chain is a SIM bank. An operator buys hundreds or thousands of physical SIM cards, slots them into a multi-SIM gateway (a “SIM box,” a rack of GSM modems), and exposes an API that lets a customer request a number, trigger a signup elsewhere, and read back the verification code. This is the model behind the public “receive SMS online” sites and their paid tiers. It is industrial but legal-adjacent, and it has a weakness from the attacker’s view: SIMs cost money, get flagged, and run out. The numbers churn, and platforms learn to recognize the ranges.

The dirtier version solves the cost problem by not paying for the phones at all. In early 2022 Trend Micro published a study of SMS PVA (“phone-verified account”) services that documented at least one operator running its service on top of a botnet of infected Android devices rather than a SIM bank. The malware family, Guerrilla, deployed by an actor Trend Micro named the Lemon Group, ships in a component the researchers identified as plug.dex. It sits on the victim’s phone, watches incoming SMS, matches messages against regular-expression patterns pushed from a control server, and quietly forwards any matching code, an OTP for an account being registered somewhere, back to the operator. The phone’s owner never sees it. They are an unwitting verification endpoint for someone else’s signup. Trend Micro detected over 490,000 mobile numbers used for OTP requests across the Lemon SMS and later Durian SMS services, and the Lemon Group later claimed a base of nearly 9 million Guerrilla-infected devices its customers could draw on.

SMS PVA on a malware botnet (Trend Micro, 2022) Attacker (PVA customer) PVA service number pool + API Victim phone Guerrilla / plug.dex 1. get number Target platform 2. register w/ number 3. SMS OTP to victim 4. regex-matched code forwarded 5. code -> attacker *The malware-botnet variant of an SMS PVA service. The victim's phone receives the verification code in step 3 and silently forwards it in step 4; the owner never sees the message. The regex patterns that decide which messages to steal are pushed from a control server.*

The regex detail is the part worth sitting with. The malware does not exfiltrate every text, which would be noisy and obvious. It pulls only messages matching patterns the operator pushes down, so it can be tuned to grab verification codes from a specific list of target services and ignore the victim’s personal messages. Trend Micro noted the same mechanism could be retargeted to harvest banking OTPs or used as a surveillance tool, since a regex that matches “your verification code is” is one edit away from a regex that matches anything. The accounts these services produce go on to seed messaging-app scams: recruitment fraud, fake parcel-delivery texts, investment and romance scams, all of which need a fresh, phone-verified account that is not tied back to the operator.

The phone-number economy

Step back from any one operator and there is a layered market. At the bottom are the numbers themselves, sourced from SIM banks, from MVNO bulk purchases, from VoIP allocations, and from compromised phones. In the middle are the PVA services that wholesale access to those numbers through an API, abstracting away where the number came from. At the top are the customers, the people running the actual account-creation campaigns, who neither know nor care whether their cent-per-code number is a SIM in a rack in one country or a stranger’s Android phone in another.

What makes the market efficient, from the attacker’s side, is specialization and pricing by difficulty. The public price lists read like a difficulty ranking of the platforms. A number for a service with weak verification is cheap because almost any number works and the success rate is high. A number that will pass WhatsApp or Telegram costs five to ten times more, because those platforms aggressively block known VoIP and recycled ranges, so the supply of numbers that actually work is smaller and the failure rate eats into the operator’s margin. The price is a live signal of how good each platform’s phone defenses are. When a platform tightens its checks, the spot price of a working number for it goes up, and you can watch that happen on the price lists.

There is a second, nastier way to monetize the same plumbing, and it does not even require keeping the accounts. SMS toll fraud, also called artificially inflated traffic or SMS pumping, turns the verification SMS itself into the product. The attacker controls, or colludes with, a premium-rate number range, then triggers a flood of verification texts toward those numbers through a legitimate platform’s signup or 2FA flow. Every message the platform sends costs the platform money and pays out, through the carrier chain, to whoever controls the destination range. The accounts are incidental; the SMS sends are the revenue. The best-known public airing of this came in late 2022, when Elon Musk claimed on a Twitter Spaces call that the company had been “scammed to the tune of 60 million dollars a year for SMS texts, not counting North America,” attributing it to telcos “gaming the system” by running 2FA texts “over and over again” through bot accounts. His stated fix was blunt: cut off any telco where fraud ran above ten percent, which he said “turned out to be 390 telcos.” The figure is unaudited and the mechanism is debated, but the category is real and large, and it explains why a platform might pay to send millions of texts it never wanted to send.

SMS pumping: the text is the product, not the account Attacker spams signup form Platform pays per SMS sent Carrier chain takes a cut Premium range payout margin flows back to attacker *In SMS pumping the attacker does not want the accounts at all. The money is the carrier payout on each verification text, so the goal is to make a legitimate platform send as many texts as possible toward numbers the attacker profits from.*

The disposable-email layer underneath

Below the phone problem sits an older and cheaper one. Most signups still want an email, and an email that the attacker controls and can read costs effectively nothing. Disposable email services hand out an inbox with no signup, no payment, and no identity attached. Some are ephemeral, a single-use address that exists for ten minutes and then evaporates. Others are forwarding aliases that relay to a real inbox while hiding it. Either way the attacker gets an address that receives the confirmation link, clicks it, and is never seen again.

The reason these are hard to block with a simple list is that the providers fight back. They rotate domains constantly, so a blocklist of disposable domains is stale the day after you build it. Castle, a fraud-detection vendor, runs a public repository tracking disposable phone numbers and has written about the email side as well, and its position is that a blocklist is a starting point, not an answer. Disposable signals work best as one input among many, “contextual, probabilistic, and often predictive,” correlated with device fingerprints, IP reputation, and behavioral velocity rather than treated as a binary verdict. The detection logic that catches a disposable address is closer to the logic that catches a disposable phone number than it looks: both are about recognizing an identity that is cheap, fresh, and structurally throwaway.

There is also a subtler version that does not use a disposable provider at all. Subaddressing lets one real Gmail inbox spawn unlimited distinct-looking addresses: [email protected] all deliver to [email protected], and Gmail ignores dots, so [email protected] is the same mailbox too. A naive signup that treats the raw string as the unique key sees a thousand different users; a signup that normalizes first, stripping the plus-suffix and the dots, sees one. The fix is canonicalization before deduplication, the same move you would make to dedupe URLs. The attacker who knows this just moves to a provider that does not normalize, which is why email alone was never going to carry the weight.

Defense, part one: velocity and the account graph

The first defense is also the oldest, and it works because mass creation is, by definition, not a single account. It is many accounts that share something. The signal is in the sharing.

Velocity analysis watches for rate and repetition that no human pattern explains. One device fingerprint registering five accounts in ten minutes. One IP firing hundreds of signup requests a minute. A burst of accounts all created within seconds of each other, all from the same ASN, all with sequential or templated usernames. None of these is provably fraudulent on its own, a NAT gateway or a university network really does put many real users behind one IP, but the conjunction is damning, and the more dimensions you measure velocity across, the harder it is to spread thin enough to look natural. The attacker’s counter is to slow down and spread out across more IPs and more devices, which is exactly the point: every dimension you force them to spread across raises their cost.

Account-graph analysis is the deeper version of the same idea. Instead of scoring each signup in isolation, you build a graph where accounts are nodes and shared attributes are edges: same device fingerprint, same payment instrument, same recovery email, same phone number, same residential proxy subnet, same behavioral signature. Fraudulent accounts are rarely independent. They were made by the same operator with a finite pool of resources, so they cluster, and a tight cluster of accounts that each look fine individually is a strong collective tell. This is the structure that catches the operator who is careful enough to defeat per-account checks but cannot avoid reusing a device or a proxy across the batch. The related machinery for the login side is covered in account-takeover detection; on the creation side the same graph logic looks for birth-time collusion instead of takeover.

Defense, part two: device fingerprinting

Velocity tells you that many accounts share a signal. Device fingerprinting is how you produce one of the strongest such signals, by identifying the machine behind a signup even when the attacker rotates IPs, emails, and user agents to look like distinct users.

The technique combines dozens to hundreds of attributes the browser or device exposes, canvas and WebGL rendering quirks, installed fonts, screen and color-depth entropy, audio-stack signatures, the navigator object, timezone and locale, into an identifier stable enough to recognize a returning device but high-entropy enough to distinguish it from others. Commercial device-intelligence products advertise combining on the order of a hundred signals into a single visitor identifier. The value for fake-account defense is reuse detection. An operator scripting account creation tends to run from a small number of machines or a small set of browser profiles, and even when they rotate everything at the network layer, the rendering stack and hardware leak consistency. A single fingerprint appearing across dozens of new accounts is the tell.

This is why serious operators reach for anti-detect browsers that spoof the fingerprint surface per profile, and why fingerprinting vendors invest so heavily in catching the spoof rather than the bot. The deeper mechanics of turning device signals into a risk verdict are in fingerprint-based fraud scoring; for account creation the question is narrower. Have I seen this machine before, and how many accounts has it touched? An honest new user is a fingerprint with no history. A farm is a fingerprint with too much.

Defense, part three: phone-number reputation

If the phone check is going to mean anything, the platform has to stop treating “received the code” as proof and start asking what kind of number received it. This is phone-number intelligence, and it is the direct counter to the SMS-farm supply chain.

The core move is line-type lookup before the code is ever sent. Carrier-data APIs return what a number actually is. Twilio’s Lookup v2 Line Type Intelligence, for example, classifies a number into one of a fixed set of types, with mobile, landline, fixedVoip, nonFixedVoip, tollFree, premium, voicemail, and others in the list, alongside the carrier_name, mobile_country_code, and mobile_network_code. A signup that demands a “mobile phone” and gets a nonFixedVoip number is showing one of the clearest farm tells there is, because non-fixed VoIP is exactly the cheap, programmatically-allocated supply that PVA services lean on. Filtering or step-up-challenging those numbers before sending the OTP cuts off a large slice of the farm economy and, as a bonus, blocks the premium-rate destinations used in SMS pumping.

Line type is the cheap first pass. Beyond it sits reputation: whether a number has been seen across many accounts, whether it was recently ported or had a recent SIM change (a tell for both fraud and account-takeover risk), whether it sits in a range associated with known SIM banks, and whether it is reachable at all. None of the deeper internals here are fully public, the vendors do not publish their range blocklists or their exact scoring, and what a given API flags is inferred from its documentation and observed behavior rather than from a spec. The honest summary is that phone reputation has shifted the question from “did a code arrive” to “is this the kind of number a real returning customer would use,” which is a much harder bar for a cent-per-code rented number to clear.

Defense, part four: the proof-of-work tax

The defenses so far are all detection: spot the farm, refuse it. Proof-of-work attacks the economics from the other side. Instead of trying to tell humans from bots, it makes every request, human or not, pay a small computational toll, sized so that one real signup is imperceptible but ten thousand scripted ones are not.

The idea is old. Adam Back proposed Hashcash in 1997 to tax email spam: before sending, the sender must find an input whose hash has a required number of leading zero bits, which costs CPU time, and the recipient can verify the answer instantly. The asymmetry is the whole point. Finding the answer is expensive; checking it is free. Modern proof-of-work CAPTCHAs carry the same shape to the signup form. Systems like mCaptcha and Friendly Captcha hand the client a SHA-256 puzzle whose difficulty the server controls, and that difficulty can scale with load. Under normal conditions the puzzle is trivial and the user waits a fraction of a second; under attack the difficulty rises, so a flood of automated signups suddenly has to burn real CPU per request while a single legitimate user barely notices.

Proof-of-work: expensive to make, cheap to check Client (per signup) n = 0 while sha256(c, n) has < D zero bits: n += 1 # millions of tries submit(n) Server (per signup) h = sha256(c, n) accept if h has D zero bits # one hash. done. n Difficulty D rises with load: one user shrugs, ten thousand scripted signups pay in CPU. *The proof-of-work bargain. The client spends real CPU searching for a hash with enough leading zero bits; the server confirms the answer with a single hash. Raising the difficulty under attack taxes volume without taxing the individual.*

Proof-of-work is not a silver bullet and nobody serious claims it is. An attacker with cheap or stolen compute can pay the toll, and the difficulty that meaningfully taxes a botnet may also annoy a legitimate user on a weak phone. It does not identify anyone. What it does is change the slope of the attacker’s cost curve, so that scaling up stops being free, and it pairs naturally with the detection layers, which decide who has to do how much work. The broader case for and against it is in the proof-of-work renaissance. On a signup form it is best understood as a way to make the cheapest part of the cost stack, the raw HTTP request, no longer free.

Why the layers beat any single check

No one of these defenses holds alone, and the attack economy proves it by routing around each in turn. Block an IP and they rotate proxies. Blocklist a disposable email domain and they spin up a new one or move to subaddressing. Demand a phone number and the farm rents one for a cent. Add a CAPTCHA and a solver farm clears it for a dollar per thousand. Each defense, taken alone, is a tax the market has already priced.

The reason platforms still win often enough is that the defenses compound. The attacker has to defeat all of them on the same request, with the same finite pool of devices, IPs, numbers, and emails, and the correlations between those resources are exactly what the account graph reads. A rented VoIP number is cheap, but it fails line-type lookup. A fresh device fingerprint is easy to fake once, but faking a thousand distinct, consistent, history-bearing ones is not. Proof-of-work makes the volume hurt. Each layer is weak; the conjunction is strong, because the attacker’s economy is built on doing the same cheap thing many times, and every layer that ties those many things back together collapses the batch into one detectable cluster. The art is stacking the layers so the combined cost of clearing them rises past the value of the account on the other side.

Where this leaves SMS

The quiet conclusion of the last decade is that the phone number lost its status as a trust anchor, and the standards bodies have caught up to what the fraud market already knew. NIST’s Digital Identity Guidelines, in the SP 800-63B-4 revision, formally classify out-of-band authentication over the public switched telephone network, which is to say SMS and voice OTP, as a restricted authenticator. The document is explicit. Use of the PSTN for out-of-band verification “is restricted as described in this section,” verifiers “SHALL ensure that alternative authenticator types are available to all subscribers,” and they “SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN.” Setting or changing the registered number is treated as binding a new authenticator, not a casual update. Email is barred from out-of-band use entirely. Restricted does not mean banned; it means second-class, allowed only with extra conditions because its weaknesses are now assumed rather than debated.

That is the right way to read the whole subject. A code arriving at a phone number proves almost nothing on its own, because there is a global, liquid, cent-per-code market in numbers that receive codes, and some of those numbers are stolen from people who will never know. The defenses that work do not trust any single proof. They price the attacker’s whole operation, line by line, and try to make the sum of those prices exceed what a fake account is worth. The interesting number is not the cost of one account. It is the gap between that cost and the account’s value, and every defense in this post is a move to close it, while every service on those price lists is a move to keep it open.

Sources & further reading

Further reading