Kavra LabPOST /otp/sendBlockedScripted OTP request to a high-cost range
- HTTP client posing as a browser
- Same actor, 40 numbers in 10 min
- Datacenter IP, phone abroad
Risk93
Solution
SMS pumping fraud prevention that stops the text before it is sent
SMS pumping, also called artificially inflated traffic (AIT), is toll fraud where bots request one-time passcodes or signup texts to phone numbers a rogue carrier or intermediary controls. You pay for each message and they keep a share of the fee. Kavra assesses the request first, so your backend never sends the SMS.
- Who it hits
- Any app that sends OTP, signup or login texts
- What it costs
- SMS fees, surprise carrier bills, blocked routes
- Tools used
- Scripts, HTTP clients, proxies, number lists
- Where to stop it
- Before your backend calls the SMS provider
What is SMS pumping?
SMS pumping is a form of telecom toll fraud aimed at any form that sends a text message on demand: phone verification at signup, login one-time passcodes, password resets, "send me the app link" boxes and two-factor setup. The attacker does not want your account or your data. They want your SMS spend.
The money comes from how text messages are billed. When you send an SMS, your provider pays the mobile network that delivers it a termination fee. In some routes, a dishonest carrier, reseller or aggregator agrees to split that fee with whoever generates the traffic. The fraudster then uses bots to request as many messages as possible to phone numbers on that route. Nobody ever reads the codes. The messages exist only to be billed.
The industry name is artificially inflated traffic, or AIT. It is also called SMS toll fraud or SMS pumping in short. It is a close cousin of international revenue share fraud on voice calls, moved to the channel that every modern signup flow now depends on.
How an SMS pumping attack works
The attack is cheap to run and usually hits outside business hours, when nobody is watching the SMS dashboard.
- 01
Find a form that sends texts
The operator scans for public endpoints that trigger an SMS without much proof of a real user: signup verification, login OTP, resend buttons, or a marketing form that texts a download link.
- 02
Get a number range
A rogue carrier or intermediary provides blocks of numbers, often sequential, in countries where termination fees are high. Many of the numbers are not even assigned to real subscribers.
- 03
Automate the requests
A script or HTTP client calls your send endpoint directly, or a headless browser walks the form. Each request uses a new number from the list and often a new IP address.
- 04
Spread and repeat
Requests are rotated across proxies and user agents to stay under per-IP limits. Resend buttons are pressed again and again to multiply the volume per number.
- 05
Collect the share
Your SMS provider bills you for every message. The carrier at the end of the route is paid for terminating them and passes part of that fee back to the operator. The bill arrives weeks later.
Who it hits and what it costs
Every product with phone verification is a target, but the damage is highest where texts are sent before the user has proven anything. Fintech apps verify phones at onboarding. Marketplaces and delivery apps use passwordless login by SMS. SaaS and AI products verify phones to slow down free-tier abuse, which ironically hands attackers a new endpoint to pump.
- Direct cost: every pumped message is billed at the destination rate, and the most expensive routes are exactly the ones fraudsters pick.
- Budget shocks: a quiet weekend attack can burn through a month of SMS budget before anyone notices.
- Delivery problems: providers may throttle or suspend your sender when traffic to one country spikes, so real customers stop getting their codes.
- Blunt workarounds: teams in a hurry switch off whole countries, which also locks out real users who travel or live there.
- Noisy metrics: phone verification requests look like growth until you compare them with completed verifications.
Warning signs of SMS pumping
The clearest signal is a gap between codes sent and codes entered. The rest tell you who is behind it.
Verification rate collapses
SMS sent climbs while completed verifications stay flat. Pumped codes are never typed back into your app.
Unusual destinations
A sudden share of texts going to countries or carriers where you have few or no real customers, usually on premium routes.
Sequential numbers
Phone numbers in the same prefix, often counting up or down one digit at a time, requested minutes apart.
Resend hammering
The same number asks for a new code over and over, faster than any person waiting for a message would.
No real page visit
Send requests arrive with no page load, no typing and no scrolling before them, or from a client that only claims to be a browser.
Off-hours bursts
Volume spikes at night or on weekends in your main market, spread across many IP addresses to dodge simple rate limits.
Why common defenses fall short
Most SMS pumping controls look at the phone number or the IP address. Operators rotate both.
| Defense | What it does | Where it breaks |
|---|---|---|
| Per-IP rate limits | Caps requests from one address | Residential proxies give every request a fresh home IP |
| Per-number limits | Caps codes to one phone | Attackers use thousands of numbers, one or two texts each |
| Country blocklists | Stops texts to risky regions | Blocks real customers too, and routes shift to new countries |
| CAPTCHA before send | Asks for proof of a human | Solving services pass it, and the send endpoint is often called directly |
| Provider fraud filters | Flags odd traffic on the SMS side | Acts after your backend has already decided to send, and cannot see the visitor |
| Number type lookups | Rejects landlines and some virtual numbers | Pumping ranges are often valid mobile numbers on paper |
How to prevent SMS pumping
The cheapest SMS is the one you never send. That means judging the visitor who asks for the code, not only the number the code goes to, and making the decision in your backend before it calls the SMS provider.
- Put a risk check in front of every endpoint that sends a text, including resend and "text me a link" forms.
- Require a real session: the send request should come from a page or app screen the same visitor actually loaded, with a signed token bound to that action.
- Track the actor, not the IP. One device asking for codes to many numbers is the pattern, even when the IP changes each time.
- Watch the ratio of codes sent to codes verified per country, per route and per hour, and alert on drops.
- Only allow destinations you actually serve, and add stricter checks for high-cost routes instead of blanket bans.
- Offer alternatives such as email or authenticator apps, so SMS is not the only path for honest users.
- When evidence is mixed, step up with an invisible challenge first, and send the text only if it passes.
A real phone verification vs a pumped one
Real user
- Loads the signup page, types the number, waits
- Phone country fits the device, language and network
- Asks for one code, maybe one resend
- Enters the code within a minute or two
SMS pumping bot
- Calls the send endpoint with no real page visit
- Phone in a high-cost country, visitor elsewhere
- Walks through a list of numbers in one prefix
- Never enters a single code
Sources
- USENIX Security 2025: Preventing Artificially Inflated SMS Attacks through Large-Scale Traffic Inspection
- Ericsson white paper: AIT, the root cause, the solution and the implication on RCS and network APIs
- OWASP API Security Top 10: API4:2023 Unrestricted Resource Consumption
- NIST SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management
How Kavra helps
How Kavra stops SMS pumping
Kavra assesses the visitor who asks for a code, with 3,000+ data points, and returns a recommendation your backend reads before calling the SMS provider.
Decide before the send
One server call on your OTP endpoint returns allow, verify or block, so a pumped request never reaches your SMS provider.
Signed single-use tokens
Each send is tied to a signed, short-lived token bound to that action. Direct calls without a real session and replayed tokens are refused and reported.
Scripts and fake browsers exposed
HTTP clients that claim to be a browser, automation frameworks and headless Chrome are caught by contradictions between layers.
One actor, many numbers
Devices are recognized across visits and fingerprint rotations, so one actor requesting codes for dozens of numbers shows up as one actor.
Network context
Own measurements of residential and mobile proxy exits, datacenter ranges and 30+ reputation feeds show where the request really comes from.
Campaign alerts
Surges of new devices, shared infrastructure and velocity anomalies on your send endpoint are flagged as a coordinated campaign.
FAQ
Frequently asked questions
Something else? Talk to our team.
What is the difference between SMS pumping and SMS spam?
SMS spam is unwanted messages sent to people. SMS pumping is the reverse: attackers make your app send messages, usually to numbers nobody reads, so a carrier on the route earns termination fees and shares them. The victim is the business paying the SMS bill, not the phone owner.
How do I know if my app is being hit by SMS pumping?
Compare OTP messages sent with codes actually entered, broken down by destination country and hour. A falling verification rate, a spike to countries where you have few users, and sequential numbers in one prefix are the classic signs. Your SMS provider's per-country cost report usually confirms it.
Can I get a refund for SMS pumping charges?
Sometimes, but do not count on it. Carriers and providers billed real deliveries, and refunds depend on your provider's terms and any fraud protection you bought. Contact them quickly with evidence of the attack. The dependable fix is stopping pumped requests before your backend sends them.
Does blocking countries stop SMS pumping?
It stops the countries you block for a while. Fraudsters move to other routes, and you also lock out real customers who live or travel there. Geographic rules work best as one input alongside an assessment of the visitor, not as the only line of defense.
Is a CAPTCHA enough to prevent SMS toll fraud?
Usually not. Many attacks call the send endpoint directly and never render the form, and solving services pass puzzles cheaply. A CAPTCHA also adds friction to every honest signup. Checking the visitor invisibly and binding each send to a signed, single-use token closes the direct-call route without a puzzle.
Who profits from SMS pumping?
The operator running the bots and one or more parties on the delivery route, typically a dishonest carrier, reseller or aggregator that receives termination fees for the messages. They split that revenue. Your business, and sometimes your SMS provider, carry the cost.
See who is really on your site.
Run Kavra on your own traffic in observe-only mode. No risk to your customers, and a clear report of the fraud it finds.