Understanding SMS Pumping: Preventing the Growing Threat of SMS Toll Fraud

SMS pumping or SMS Toll Fraud is an attack type which greatly increases the operating costs of companies which use SMS to communicate with their customers. The prevalence of these attacks has increased significantly across the tech industry in the last couple of years meaning there are a growing number of companies that find themselves with an SMS bill that has unexpectedly grown exponentially. Flipdish has had eyes on this issue for 5+ years now and we feel we have learned a lot that may help others in preventing similar attacks on their system.

The basic premise of these attacks is that a bad actor will take advantage of the input fields within a system that send customer SMSs. These SMSs can be powering any part of your system from initial account confirmation to notifying customers that an order has been cancelled. If your system gives an attacker the ability to send multiple SMSs, it is a target that attackers will use to repeatedly send SMSs to phone numbers that they control.

What motive could someone have for such an attack? Initially we couldn’t fathom many valid reasons. So we started digging. We found that attackers will request thousands upon thousands of SMS to be sent through a single mobile operator network. For each SMS that goes through that network, the attackers get a small share of the generated revenue. For example an SMS might cost €0.03 to send. If that SMS travels through the attackers network, they might get 10% of that. This may seem like an insignificant sum, but when multiplied by millions of SMSs the potential financial gains start to quickly add up.

Have You Been Targeted?

How can you tell if you have been targeted by an SMS pumping attack? Unfortunately for many, the first indication is when they get an exorbitant bill from their SMS provider. If this does happen, talk to your SMS provider and explain the situation. They may be able to help by reducing the bill if you can show you were subject to a fraud attack.

To show this we need to invest in observability. The diagram below is a metric that shows how many SMSs were requested from users over a 24 hour period. As you can see there is a steep rise in requests around 1am which would be very suspicious behaviour for our system which provides online ordering to restaurants. By observing this single piece of data, it is quite evident what is normal traffic vs what is fraudulent traffic.

There are lots of data points that you may want to consider tracking:

• SMSs requested

• SMSs delivered

• Phone numbers that SMSs are being sent to

• The country codes of those phone numbers

• The mobile carrier network that phone number belongs to

• The IP addresses requesting the phone number

• Where those IP addresses are located

Depending on the features using SMS in your system, there may be other pieces of data worth observing. But having this data to hand will allow you to investigate attacks after the attack has occurred, examine the attack patterns and shore up your defences to help mitigate the future attacks that are coming.

Problem Ownership

One question with no simple answer is who should own this problem? Some SMS providers are beginning to bring out products that are aimed at preventing SMS pumping attacks. An example of one of those products is Twilio’s SMS Pumping Lookup API which provides risk scores on how likely an SMS is to be fraudulent.

On the surface this is great! However at the time of writing this is a feature that is charged at 3.5 cent per transaction and is not included as a basic feature (at least in the case of this particular Twilio feature). In this humble engineer’s opinion, this is problematic to say the least. It increases the bill of the fraud victim who is forced to try and protect themselves, whereas SMS providers should be striving to protect their customers as a default. At a certain point it will become cheaper to just allow the attack through!

If we were to take an example from another sector such as payments. Large payment processing providers (Stripe, Adyen etc) will have fraud prevention baked into their systems. If somebody tried processing a payment with a fraudulent card, it should be handled by the payment provider. They recognize that it is their responsibility as the service provider to prevent fraud from occurring in their system instead of pushing that problem back onto their customers. My hope is that in the future SMS providers will take a similar view, but for now that is not the case.

Preventative Measures

Now to the interesting part. How can we stop these attacks? In typical engineering fashion, it depends.

The most obvious thing to do is to stop using SMS! Other communication methods such as Email, WhatsApp, Push Notifications etc do not have the same incentive for attackers, as there is no financial gain to be made. If you are using SMS for MFA (Multi Factor Authentication), there are many other MFA methods available such as authenticator apps, email etc. This may be easier said then done, as some systems may require SMS and that can’t change. For those systems, here are some preventative measures that could be considered.

Captcha 🙍‍♂️

Captcha is designed to determine if a user is a real human or a bot. You may think of captchas as big ugly boxes that force users to choose the squares containing horses in a picture filled with zebras. But there are many potential setups which allow systems to weigh up security with user experience, including invisible captchas. Google ReCaptcha is probably the most well known captcha offering, but there are others out there such as HCaptcha and MTCaptcha. Many of these began as limited captcha companies, but have evolved and now offer many additional features to help prevent bot traffic, fraud and other types of common attacks so it is worth shopping around and comparing available features.

Rate Limiting🚫
Rate limiting should be something that comes as part of every api, but we may also want to consider some custom rate limiting on requests for SMS. Custom code can be written to rate limit an anything from phone number, country codes, restaurants, Ip addresses etc. The trade-off you need to consider is that once a rate limit is hit, it may also block requests from legitimate customers that fall into the same bracket.

Shadow Banning 🔕

Shadow banning is the practice of blocking a user in a way that is not immediately apparent to the blocked user. Shadow banning is vital to prevent attackers from automating changes in their attacks as soon as the system has detected they are a bad actor. For this reason, the responses from your api should not alert users that you have identified the user as malicious. Instead it is prudent to send the same response when a request for an SMS is successful and unsuccessful.

Geo-Blocking 🌍

Geo-blocking can block requests that originate from parts of the world where you do not have any customers. This can be done in your traffic layer to block requests based on the geolocation of an IP address. However we can take it a step further and configure our SMS provider to only allow sending SMSs to phone numbers originating from countries where our expected customers are.

Pattern Matching

Often an attack will originate from a large subset of numbers that will fall into a smaller number of patterns. The phone numbers used for the attack might all be from a couple of country codes, many of them could look very similar (+123456787,+123456788, +123456789). This isn’t an exact science but we can write some custom code to try and identify patterns, and rate limit/ block requests originating from these patterns for a specified time.

How granular to go with the pattern matching will depend on what is acceptable for the system. Blocking a pattern of +1 (all of North America) may/may not be viable depending on the system and customer base. For that reason, the pattern length a system blocks on should be giving careful consideration. For example, if a country’s phone numbers have a length of 12 and a single pattern is blocked with a length of 6 (+12345), there are 1 million potential phone numbers blocked. If we instead choose to block on a pattern with a length of 5(+1234) then there are 10 million potential phone numbers blocked (feel free to check my secondary school maths). The important point here is that blocking based on patterns can block both malicious phone numbers and real users so caution is needed when determining the variables involved.

Sliding Window Phone Number Blocking 🪟

Let’s say you are using SMS as a method of MFA. The upper limits of how many SMSs a legitimate user could need might be 5 SMS per day, or 10 SMS per week. If we keep track this information, we can check which users are breaking the system’s upper limits and block those phone numbers from receiving SMS for a specified period. We can also keep track of how many times a user has been blocked and increase the block period for repeat offenders.

Machine Learning + Bot Detection 🤖

There are many companies that offer some form of machine learning solution. These solutions will examine the request properties (headers, Ip address, phone number etc) and will return a score or a determination on whether the request is suspicious or not. Having tried a few of them, I personally have yet to be convinced by any of them. They tend to work in parts, but often too many of their determinations fall into the middle ground of “This might or might not be suspicious”. The solutions may also have evolved since we last checked and they could be useful for other types of bot detection, so I don’t want to write them off completely. Some options out there include MaxMind, Twilio’s SMS Pumping Risk Lookup, Cloudflare JA3 Fingerprints, Azure Bot Detection.

Which of these preventive measures should we use? If I was forced to choose only one, it would be captcha. It is designed to solve the exact problem of identifying non humans in your system. However choosing multiple preventative measures will always yield the best results. Attackers are constantly probing to discover what defences you have in place and to find vulnerabilities. If you rely on only 1 or 2 defences, your system is wide open should an attacker bypass those initial blockers.

Conclusion

There is no “one shoe fits all” solution when it comes to SMS pumping. The approach taken for each system should evaluate all the business variables and decide the appropriate actions. One thing that is for sure is that SMS pumping is not an area where you can rest on your laurels. Any small holes in your defences will eventually be found and exploited. When this happens the attack volumes can be so large that bills can reach tens of thousands in a matter of hours.

If you are struggling to cope with SMS pumping or would like to learn more about our experience in the area feel free to reach out to the Engineering Team here at Flipdish. It first came onto our radar nearly 5 years ago, and although there have been some bumps in the road we have been handling it (mostly) successfully for some time now.