Twilio’s toll fraud problem

If a threshold of Twilio customers dispute charges, Twilio loses the ability to process credit cards at a lower risk rate, then with all but high risk processors, then may lose the ability to process them at all.

If enough of their customers are getting burned, and enough dispute, Twilio would no longer be able to accept credit cards. They are terrified of that, so begging you not to dispute charges for their lack of fraud prevention.

You accepting anything less than full refund of all fraudulent use they're cascading back on you is a gift to them. You accepting less than a full refund, while not dinging them at all with a chargeback is also a gift to them. If they don't want to give you the full refund for misuse they should be preventing, dispute it, as is your right.

The correct course for Twilio is for Twilio to refund these charges no questions asked while fixing the problem.

How it works:

  1.  Attacker leases 1 or more premium rate numbers in an international country.
      - Attacker can lease a premium rate number for as little as $10/month
      - Typically, the attacker gets to keep 70% of the money generated by the premium rate number.

  2. Attacker then finds companies with OTP (One-Time Passcodes) or 2FA (Two-Factor Authentication) endpoints that require no validation and writes a script to automate the webpage or call the API endpoint
     - Attacker will typically obtain a new IP address per API call using a VPN or a rented botnet from the dark web.

  3. If the premium rate number costs 10 cents, then each successful text message they can send to the number generates 7 cents for them.

  4. The attacker then just needs to send 150 SMS to the premium rate number to break-even on their $10 investment, not counting the cost of the VPN or rented botnet.

1. Your balance is running low at -65 USD

2. (30 seconds later) your account is suspended, I checked the account an hour later when I saw this email and the balance was -4,000 USD

I asked support why they continued charging our account even with auto recharge disabled, but they just ignore the question.

Support says it's our fault, asks us not to dispute the charge (although there has been no charge yet as we disabled auto recharge), and said it will take 10 days for finance to issue a partial refund (that was 24 days ago).

At the least, there should be a list of phone numbers known to not result in surprise charges so you can block all others.

If you want to read the tweet on how it works.

They retain the right to any/all the upside of any risk/scale, and you retain the obligation in any downside. No questions.

It's despicable.

In our case, Twilio reached out to us to tell us they were detecting toll fraud. Before that, we actually had no idea what toll fraud was.

We quickly tried to address it with distributed rate limiting and that worked, for all of a couple of hours. The fraudsters quickly figured out the rate limit and worked around it by spacing out the calls and using more IPs.

Eventually, we had to disable a set of countries known for toll fraud and change our product to not connect calls in a variety of scenarios.

At the time I wondered if I was overengineering or gold plating but apparently not.

I do seem to recall that Twilio writes about this issue quite alot and includes strategies in its best practices for avoiding the issue.

We tried to mitigate as cleanly as possible for our users, adding one-time nounces to signup requests, adding rate-limiting rules, locking down regions, but we still faced an onslaught of tens of thousands of fraudulent signups per day. On our tier we don't have the ability to set block rules ourselves - it requires a support request that takes 2-3 days to get a response on. Our choices are to eat thousands of dollars per day in toll fraud, or disable sign-ups until we can add more fraud prevention on top of what Twilio enables. The problem is the fraudsters are using real browsers across thousands of IPs located in dozens of different countries.

Similar to the OP, Twilio tries to say this is our fault and leaves it up to us to both pay for the issue and to try and fix it.

Maybe a class action possibility here?

1) Scammer leases a "premium phone number" from a provider. From doing some reading, premium numbers are where the caller/texter pays extra for interacting with the service at this number. So like a 1-900-phone-sex line from back in the day, where if you call, you get charged like $5.00 a minute. The provider leased the number to the phone sex operator for $1 per minute. The phone sex operator runs the service and charges access via your telco at $5 a minute, and ends up netting $4. The telco bills you $5 for your 1 minute call.

2) In Twilio's case, they get a request to send a text to a premium phone number leased by the scammer. This text is actually initiated by the scammer, via something like requesting a new one-time password. Twilio sends the text.

3) Twilio then determines that the destination number is a premium phone number. Twilio charges you extra for sending the text because of this. Twilio then remits a payment to someone, either the scammer or the premium phone number provider.

4) Scammer repeats step 3 a very large amount of times and collects. Twilio bills you for all of those texts they sent, on your behalf, to the scammer's premium number.

Step 3 is where I am confused. How do the payment flows work. Is Twilio remitting the money to the scammer, who then needs to pay for the leased number? Or are they remitting the payment to the premium phone number provider, who then pays some portion of that to the scammer?

And come to think of it, how does the phone sex line example work? Which entity actually contracts with the telco to set the cost/toll?

My impression at the time was the fraud detection heuristics helped, but the root cause was scammers working with telcos overseas. Many of these companies have extremely high rates in the first place, and turn a blind eye to the practice because it makes them much of their money.

Some VoIP providers like Twilio may be the same. As a middleman / carrier, they will always profit from traffic on their network, even if they disavow it as fraudulent and wag their finger at you about it.

Email works fine, is more reliable, latency is fine, and it works across devices and on desktops.

Deduplicate your accounts some other way. Owning a bunch of phone numbers is (clearly, from the article) not a hurdle for attackers.

1. Rate limited SMS by number/ip: bypassed by large number of proxies/vpn.

2. Added captcha: bypassed by attacker manually signing up thousands of accounts (mechanical turks?) over months and then iterating over them for login OTP.

3. Identifying what carriers/operators are involved and blocking them asap (usually obscure ones).

4. Careful monitoring of SMS send rates and alerting of anomalies to investigate.

I will say though this isn’t a great look and hopefully Twilio addresses it. Perhaps there are significant trade-offs to enabling this option by default, but it does _seem_ (from an admittedly naive perspective) like perhaps it’s better to start folks with the training wheels on and make sure they know how to ride the bike before you let them go in the street.

We're in the same cat-and-mouse game with the attackers as everyone else, but since we're an auth company, we have full-time folks monitoring for issues and resolving when they come up.

It's worth mentioning that Twilio is in an understandably tough position here. They only receive API requests from your server, and real requests look the same as attack requests except for the phone number.

Clerk is in a better position to help because our API accepts traffic directly from the attacker (e.g. POST /verify-phone-number). We know their IP, user agent, whether they're connecting from AWS, etc, etc. We very much rely on this data to help stop them.

With the rise of AI APIs, I expect we'll see similar attack vectors for apps that integrate APIs from OpenAI or Stability. There won't be a colluding telecomm, but the API output (a completed task) is relatively fungible and far more valuable in itself than a SMS API response. Something to keep in mind if you're building an AI application: https://stytch.com/blog/securing-ai-against-bot-attacks/

E.g. why don't they have KYC controls during account opening? Because it would reduce the # of people who open an account.

My main suggestion would be to avoid any sort of flow, like SMS OTP login, that allows triggering SMS messages without being logged in. Just do a more traditional login, SMS OTP isn’t worth the headaches.

Haven’t tried Twilio Verify, didn’t exist when we were solving these problems ourselves. But like most fraud prevention, it’s probably far from perfect, better to just avoid fraud-prone workflows if you can.

The Tweets he mentioned, that they lost 200.000 Dollars. Unbelievable. And this „please don’t dispute the charge“ is the icing on the cake.

Your service got hit with a ddos-style attack that translated into you using twilio to send lots of texts. This cost you a lot of money.

I don't see how this is categorically different than your kid "accidentally" buying movies on Amazon prime or something like that. No way a credit card company would accept a chargeback in that scenario.

Ultimately, you used their product in the intended way. Of course you're on the hook for the bill.

Where do you find this? I've spent 10 minutes on our Twilio account and couldn't find the toggle.

Spam phone calls... the global phone system is a network of relays. No telecom provider connects everyone on the planet together. To call our grandmother in Russia, we may have to go through Verizon, Deutsche Telecom, MTS, and ~five different smaller, regional telecom providers. The first telecom provider will request the second to complete the call, will trust they do this, and will accept the price they charge upon which they'll add their own costs. This occurs recursively until the phone call has been connected and completed. This implicit trust enables fraudulent actors to get into the circle of trust. Verizon may trust Deutsche, Deutsche may trust MTS, and MTS may trust a smaller telecom provider who in turn trusts a spam caller. This enables you to get spam calls. Telecom providers themselves don't know all the callers on the global telecom network and don't really know how much people will be charged. There is no global government to legislate across all telecoms.

Bots on the internet... the internet as a whole doesn't have a firm sense of identity. It's just a network protocol routing packets to ip addresses. In the past, these ip addresses were mostly human beings. In the current time, the majority of the participants on the internet are bots/computer programs. A website like "Big Tech Retailer" has >90% of all traffic from computer programs. Elon Musk was probably right that Twitter is full of bots, because the entire internet is swimming with bots. They can be incredibly difficult to detect because AI blurs humans with bots.

This toll fraud problem is that bots we struggle to detect place phone messages to phone numbers we struggle to identify. This ends up costing a huge and growing amount of money. You cannot truly solve the problem without solving the two underlying problems of bots on the internet and spam calls. Solutions to those problems may require rethinking and rebuilding the entire communication system we've built our lives around.

Nonetheless, we can greatly reduce the effect of this problem. At "Big Tech Retailer", myself and two others we were able to reduce the cost to a small percentage of what it was. After that point, the business sort of stopped caring because the fraud cost less than the staff. There were perhaps five techniques that were most helpful, all of which were contemporary fraud fighting/bot fighting/security techniques.

If you're a startup facing this problem, I can help give you some guidance. Twilio will probably see this post and start working on a solution, but that may take a long time. There are easy things you can do to mitigate the problem right now. You can contact me at manrajt@gmail.com.