Phone Number Fraud: Stop SMS Pumping and IRSF Draining Your Budget

Every public form that sends a text message or places a call is a way for fraudsters to spend your money. SMS pumping (also called artificially inflated traffic) and International Revenue Share Fraud (IRSF, a form of toll fraud) turn sign-up, login, password reset and "send me the app link" features into revenue for whoever controls the destination number ranges. Nothing is stolen from your database, so the attack often surfaces first as an invoice from the messaging provider. This guide explains how both schemes work, which controls stop them (geographic permissions, rate limits, line-type checks, bot friction and conversion monitoring), how to roll those controls out without locking out real users, and how to detect an attack in hours rather than at month end. It is written for product security, fraud and identity teams that own phone verification and OTP flows.

Key takeaways

• The attacker profits from your sending, not your data. Messages or calls are pushed to number ranges where a party in the termination chain shares the revenue, so every triggered OTP is a payout and a cost to you.
• Turn off what you do not serve. Country allow lists and disabled voice channels remove most of the exposure at almost no cost, and several platforms now default to sending nowhere until you opt in.
• Rate limit on the destination, not only the client. Limits per phone number, number prefix and country stop the attack shapes that per-IP limits miss.
• Watch the OTP conversion rate. Validated OTPs divided by sent OTPs, per country and per prefix, is the single most useful early warning and should alert in near real time.
• Your SMS API key is a spending credential. A leaked messaging key lets attackers send at your expense without touching your application, so treat it as a privileged non-human identity.

How SMS pumping and IRSF work

Twilio's Verify documentation describes SMS pumping as fraud that "happens when fraudsters take advantage of a phone number input field" to trigger one-time passcodes or app download links, sent to number ranges controlled by a mobile network operator, with the fraudster receiving a share of the revenue. Toll fraud, or IRSF, is the voice equivalent: the application is made to place large volumes of calls to international premium-rate numbers and the victim pays for every minute. Microsoft's Entra documentation describes IRSF in the same terms and calls the technique traffic pumping.

The economics drive the defences. International termination rates for some destinations are many times higher than domestic rates, and the attacker only needs your application to send. A bot submits a phone number, your backend asks the messaging provider to send an OTP, the message is delivered to a number the attacker's partner controls, and the termination revenue is shared. The OTP is never entered. That last fact is the signature that conversion monitoring catches.

Where the traffic comes from

• Sign-up and phone verification: the most common target because it requires no prior account. Microsoft's Azure AD B2C guidance describes attackers creating many accounts and triggering automated calls without completing MFA registration.
• Login MFA and step-up: attackers who hold a valid password, or who can register a phone number to a throwaway account, trigger repeated OTP sends.
• Password reset and "resend code": often less protected than sign-up, and resend buttons invite unlimited retries.
• Marketing and utility messages: "text me the download link", appointment reminders and contact-us callbacks are all sending endpoints.
• Direct API abuse: if the messaging provider's API key leaks, the attacker skips your application altogether. MITRE ATT&CK T1496.004 Cloud Service Hijacking describes adversaries using services such as AWS SNS and Twilio to send large volumes of SMS at the victim's cost.

Threat to control mapping

OWASP's Automated Threats to Web Applications project classifies this activity as OAT-003 Cost-Inflation Fraud: mass use of functionality to profit illegitimately from chargeable supporting services. OWASP does not name SMS pumping on that page, but the definition fits exactly, and the OAT naming helps when you brief bot management vendors or write detection requirements.

The API layer side of throttling is covered in more depth in the Rate Limiting and API Abuse Guide; this guide concentrates on the destination-side and telecoms-specific controls.

Controls that stop the traffic

1. Geographic permissions

Disable every destination country you do not serve. Twilio offers Verify Geographic Permissions for this; Firebase Authentication has an SMS region policy under Security, Authentication, Settings, and its documentation states that for new projects "the default policy allows no regions"; Microsoft Entra External ID disables SMS verification by default and requires country codes to be enabled per application, and Entra ID requires explicit opt-in for MFA telephony to certain regions. In Azure AD B2C you restrict the countryList on the multifactor page, and Microsoft notes it acts as an allow list, so enforce it in the relying party custom policy rather than only in the user interface.

• Build the list from evidence: take 90 days of successful verifications by country and start with countries that account for real users.
• Keep a separate tier: for countries with a few legitimate users, allow but apply tighter rate limits rather than blocking.
• Enforce server side: a dropdown that hides countries does not stop a bot posting directly to your API.

2. Rate limits on the destination

• Per phone number: exponential back-off between sends to the same number and a daily ceiling. Twilio's example offers a "Call me instead" option only after three time-delayed SMS attempts.
• Per number range: limit sends to numbers sharing a prefix. Pumping campaigns often walk through consecutive numbers in one allocated block.
• Per country: an hourly budget per country, set from your baseline, with an automatic pause when exceeded.
• Per client: limits by user, session, IP and device ID at the CDN, WAF or web server. Twilio notes that rate limits slow attackers rather than stop them, so combine them with the other layers.
• Provider-side limits: use the messaging platform's own service rate limits as a backstop in case your application limit has a bug.

3. Number intelligence

• Line type: look up the line type before sending and send SMS OTPs only to mobile numbers, per Twilio's Lookup guidance.
• Carrier: record the carrier per send. When inflated traffic clusters on one carrier, block it for OTP traffic.
• Number risk signals: NIST SP 800-63B-4 section 3.1.3.3 says verifiers should evaluate risk indicators such as device swap, SIM change or number porting before sending a secret over the public telephone network. The same lookups help with SIM swap; see the SIM Swap Fraud Guide.

4. Bot friction on sending endpoints

• Challenge before send: CAPTCHA or invisible bot detection before the first OTP, not after. Firebase phone auth uses reCAPTCHA by default; Azure AD B2C offers CAPTCHA on sign-up and sign-in for local accounts.
• Add a cheaper first step: Twilio suggests requiring email confirmation before 2FA enrolment, which costs a script far more effort than it costs a user.
• IP reputation: treat requests from Tor, hosting providers and anonymising proxies as higher risk, accepting that some legitimate users use VPNs.
• Bot management: for high-volume consumer services, a dedicated bot layer is worth it; see the Bot Management Guide.

5. Reduce dependence on telephony

NIST SP 800-63B-4 classes use of the public switched telephone network for out-of-band authentication as restricted and notes it is not phishing resistant. Microsoft's B2C guidance recommends authenticator app TOTP over phone MFA, and offers email OTP as an alternative. Every user you move to passkeys or an authenticator app is one fewer chargeable message. See the Authenticator Apps and OTP Guide and the Passkeys for Everyone Guide.

Choosing the right mix

Provider filter or your own controls? Provider-side fraud filters (for example Twilio's Verify SMS Fraud Guard) see traffic patterns across many customers and are cheap to switch on, but Twilio itself states that no provider-side solution is fully effective and that customer participation is essential. Treat provider filters as one layer and keep your own country, prefix and conversion controls, which reflect your user base.

Implementation roadmap

1. Inventory every sending endpoint. List each feature that triggers an SMS or call, the provider and API key it uses, whether it is reachable without authentication, and its current monthly volume and cost.
2. Set spend and usage alerts first. Configure provider usage triggers and budget alerts at a level a single bad day would breach. This is the fastest protection and needs no code change.
3. Baseline traffic. Pull 90 days of sends and successful verifications by country, prefix and carrier. Calculate conversion per segment.
4. Apply geographic permissions in monitor mode. Where the platform supports it, log what a proposed allow list would block for two weeks, review the blocked legitimate users, then enforce.
5. Disable unused channels. Turn off voice OTP if the product does not need it, or gate it behind several delayed SMS attempts.
6. Add destination rate limits. Per number, per prefix and per country limits, deployed behind a feature flag so they can be rolled back in minutes if a legitimate surge (a marketing launch, a new market) trips them.
7. Add bot friction and line-type checks. Pilot on the endpoint with the worst conversion rate first, measure user drop-off, then extend.
8. Secure the messaging credentials. Move API keys to a secrets manager, use sub-accounts or scoped keys per application, rotate, and alert on sends not matched to application events.
9. Write the response runbook. Who can pause a country or a channel at 3am, how to contact the provider's fraud team, and what evidence to keep.

Rollback should always be a configuration change, not a deployment. Keep country lists and thresholds in configuration with change logging, so a false positive in a new market can be reversed quickly and the change is auditable.

Where identity fits

Two identity issues sit inside this fraud. First, the messaging provider's API key or auth token is a non-human credential with direct spending power. If it is hard-coded in a mobile app, committed to a repository or shared across environments, an attacker can pump traffic without touching your front end, which is exactly the pattern ATT&CK T1496.004 describes. Store it in a vault, scope it to one service, and monitor its use. See the Twilio Credentials Security Guide. Second, SMS is a weak authenticator, and SMS pumping is one more cost of depending on it. The phone number is also an identity attribute that attackers manipulate, which links this topic to SIM swap and account takeover controls.

Detection and measurement

Log every send request with timestamp, endpoint, destination country, number prefix, carrier and line type (if looked up), user or session ID, IP, device ID, provider message ID and price, then join it to verification success. Microsoft's Azure AD B2C phone-based MFA workbook is a useful model: it shows failure reasons, failures by IP, phone numbers per IP and failed phone authentications over time per day, and recommends location-based and velocity-based fraud indicators.

Twilio recommends tracking conversion and alerting on drops, plus using account usage triggers. Feed these metrics into your SIEM or fraud platform with an on-call owner, because a pumping campaign can run up a large bill over a weekend.

Framework mapping

Common failure patterns

• Per-IP limits only: distributed bots stay under any sensible per-IP threshold while the per-country total explodes.
• Allow list in the user interface only: the country dropdown is restricted but the API accepts any E.164 number, so bots post directly.
• Unprotected resend and voice fallback: the first send has a CAPTCHA, the resend button and "call me" option do not.
• Monthly cost review: spend is checked when the invoice arrives, so a campaign that started on a Friday is found weeks later.
• Messaging keys in client code: provider tokens embedded in a mobile app or front-end bundle let attackers send directly at your expense.
• Treating the provider filter as complete: the provider's fraud filter is switched on and nobody owns conversion monitoring or country configuration.

Practitioner checklist

• Inventory every endpoint that sends SMS or places calls, with its provider, key and exposure.
• Set provider usage triggers and budget alerts today.
• Enforce a server-side country allow list built from real verification data.
• Disable voice OTP unless needed; gate it behind several delayed SMS attempts if kept.
• Rate limit per number, per prefix and per country, as well as per client.
• Look up line type and send SMS OTPs to mobile numbers only.
• Put bot detection in front of first send, resend and voice fallback.
• Alert on OTP conversion by country and endpoint in near real time.
• Store messaging API keys in a secrets manager, scoped per service, and alert on unmatched sends.
• Move users, starting with administrators, from SMS to authenticator apps or passkeys.

Standards and references

• OWASP: Automated Threats to Web Applications
• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• MITRE ATT&CK: Cloud Service Hijacking (T1496.004)
• Microsoft Learn: Protecting Microsoft Entra MFA against telephony fraud
• Microsoft Learn: Securing phone-based MFA in Azure AD B2C
• Twilio Docs: Preventing toll fraud and SMS pumping
• Firebase Docs: Phone authentication and SMS region policy
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Rate Limiting and API Abuse Guide · Fraud Prevention Guide for Digital Businesses · Bot Management Guide · Twilio Credentials Security Guide · SIM Swap Fraud Guide