Preventing Signup API abuse from botnet

Question

I am working on an e-commerce website, wherein make use of mobile OTP authentication for new signups. We have a fair bit of protection against bots and malicious actors by using aggressive rate limiting and firewalls to protect our APIs and pages.

Recently we are facing a challenge wherein the malicious actor:

1. Is making 5 hits to our signup API in an interval of roughly 1-2 minute between each request.
2. Then he change his IP and repeat step 1
3. Mobile number used to signup belongs to different country every time and mobile number also appears to be valid as SMS do get delivered on those numbers.
4. As soon as he hits the signup API, a SMS containing OTP is sent to the mobile number given while signing up. Each SMS delivery costs us depending on the country, and with this attack this cost can easily go anywhere over $ 4000.

Now, our observations are:

1. We have a check that if signup request is coming more than 5 times from a single IP then we block that IP for a certain interval, hence he change his IP after every 5 request
2. He keep a gap of 1-2 minute and sometime more in every consecutive request to keep it under the radar of rate limiter
3. He is making use of IPs from across the globe, hence we cannot block requests from a certain country or subnet
4. He is using a mainstream User-Agent of Chrome browser, hence can't block based on that as well. Using latest chrome versions.
5. We require CSRF token with this request and he is generating a new CSRF token for each request, can't block/rate-limit that as well.
6. We cannot add a captcha as it's a hindrance for our genuine users and business team won't go for it.

How we are planning to address it:

1. If a person make a hit on signup API and change mobile number in 3-4 request then block that IP or show a captcha. Problem in this approach is that still 3-4 SMS will trigger, at present we are anyways blocking IP after 5 requests. It won't add much value.
2. If we see higher number of signups for a particular country from the average, then show a captcha for all signups happening under that country code. Problem here is that, malicious user can change his mobile number to a different country on detecting captcha.

These are the only 2 solutions that we came up with. I am looking to find out any better solution to fix this security issue.

Answer 1

Does the signup page require Javascript? If it doesn't, then a tool like Curl is sufficient to carry out this type of attack. If you require Javascript, then the attacker will need to use Selenium or Chrome/Puppet, which makes the attack slightly more tedious, but not so much. This will not be enough to deter a motivated attacker though. You can throw in a CSRF token too, but again this will only discourage complete script kiddies.

But let's assume the attacker is using rudimentary means at present, they may be spoofing the user agent, but perhaps the usual headers are missing from the request, and this can be a telltale sign of an automated process. The user agent is very mainstream (Chrome) but perhaps the version number is outdated. Look carefully at your logs.

Try to capture some HTTP traffic (eg use tcpdump on the server then analyze it with Wireshark) to figure out the exact content of the requests. Possibly there is a pattern in the packets that can be used to build a fingerprint. At least make sure the signup is not too easy to implement with a bot.

Cloudflare does a good job at detecting bots too, but this can trigger the dreaded captcha, which you want to avoid. Yet, perhaps you should simply consider outsourcing your problem to a provider such as Cloudflare.

There is some more screening than can be done:

• Identify the country of origin for the IP address (free databases available), for some countries you may want to scrutinize signups based on your previous experience. If you still have the suspicious signups in your DB, some SQL and Group By can reveal some patterns too. You might see that some area codes or phone number prefixes appear repeatedly.
• If the IP address country does not match the phone number country, it's another red flag. In that case, you might want to display the captcha.

I suppose you also require E-mail verification. Perform E-mail verification first, before you move on to sending the SMS token. The point is to delay the sending of the SMS, since it costs money. If the E-mail is not even verified, no point in moving forward.