Unusual order activity

[Remitur]

It's few days I'm experiencing a strange malicious activity, that is the registration of several fake accounts with the following characteristics:

• all of them use no-existing email addresses, but existing domains ( @palestinedrinks.com, @docomo.ne.jp, @yahoo.com, @aol.com)
• all of them came from USA IP
• all of them use plausible US names and addresses
• they came from different IP, but often belonging to the same IP class (i.e. I blocked 84.32.60.0/24 and 104.165.169.0/24)
• many (or maybe all of them) after the registration try a password reset (which can't work because they're using a non-existent email account)

Not a huge number: just a dozen of them in two days...

Anyone experiencing the same issue?
Anyone having any idea about the goal of such activity?

[bear]

If they know the email won't arrive, that's puzzling. I will say it's likely they're looking at the transaction in real time to see if anything's revealed there. Brings to mind the 2013 issue with AES encrypt spitting out admin details when a carefully crafted name change was used. Not saying it's that, but concerning it's similar.

[NetWise UK]

We’re having the exact same issue with the same users as you’ve listed. 
 

We’ve removed the ability to register without ordering and now we’re getting fake orders too. It seems they create an account and then immediately request a password reset. 

[Remitur]

The activity is slowly going on... every few hours, a new fake account is created.

After the banning of the domains used for emails, "generic" email domains are used (@gmail.com, @msn.com, @icloud.com, yahoo.com)

just for reference, I report here the full list of IP used:

84.32.60.0/24
104.165.169.0/24
156.239.55.38      
45.146.203.224        
5.102.101.151        
104.234.211.171        
104.165.127.0/24        
23.230.167.30        
140.99.127.42           
23.27.240.208

[slim]

Yes, I have noticed this as well - Last 48 hours or so.. Here is my list of banned IP's so far.

5.102.101.38
5.102.101.71
5.102.101.84
23.230.167.19
31.6.43.23
31.6.46.13
45.146.203.74
45.146.203.158
84.32.64.46
84.32.64.65
104.165.127.74
104.165.127.251
104.165.169.110
104.165.169.160
104.165.169.247
104.252.131.65
104.252.131.87
140.99.127.90
140.99.127.120
156.239.50.89
172.121.142.117
 

Many of these match with your list - and I have the exact same issue - Fake signups, with real looking details. (and a few reset password attempts to I just discovered!) I have been Deleting the client as soon as they arrive (they are not even attempting payment - so its an easy thing for me to manage).

Very strange.

Edited July 4 by slim

[bear]

A good portion of the IPs are from Emeigh Investments LLC. A quick search finds this:
https://securityboulevard.com/2022/05/state-of-api-security-activity/

Basically as I'd mentioned, bad actors are checking the website programming looking for flaws to exploit. With WHMCS containing user info along with monetary info, it's a good target. Add to that the simple way to "Google Dork" the sites running it (powered by tagline, generally), not too hard to find potential victims. They find a way in, it's gold. 

[slim]

While I agree, the fact it’s just started and has a pattern, I’d say they know something new. If it was bad actors generally looking for exploits we would have seen it before now.

[bear]

8 minutes ago, slim said:

While I agree, the fact it’s just started and has a pattern, I’d say they know something new. If it was bad actors generally looking for exploits we would have seen it before now.

I didn't want to jump too far ahead. Entirely possible it's not new overall, it just took time to reach your site(s). I find it more likely they are fishing for an exploitable reaction from the software, since it's a repeated thing on each site, and not a very specific request to one. If they "knew something", why keep trying on the same site? It would work or not, I'd guess. Since it's a pass reset that follows creation, maybe they found something in general in other resets (other software) that they think may have been used here. 

If it were me, I'd buy a license and test with that (or even grab a pirated one, which exposes the code (kinda). Doing this to various public installations only calls attention to it. 

[bear]

19 hours ago, Remitur said:

often belonging to the same IP class (i.e. I blocked 84.32.60.0/24 and 104.165.169.0/24)

A quick search shows they're assigned to sprious.com. One of the items offered there is "Scraping Robot
Top-tier scraping paired with competitive pricing to help elevate your company"

Just an FYI. I'd guess they used that to find potential victims and then took the results to attempt exploits. There are cheaper ways with a lot less "noise" and traceability, so they don't seem terribly "ready to exploit" to me. Could be wrong. 

[Eugene van der Merwe]

We have been a WHMCS user since 2007 and firm based in South Africa.

Since 48 hours we are the same victim of a distributed, apparently automated, drip campaign denial of service attack on our system.

At first, random registrations, sometimes with a known address, and then without.

We changed the setting no more registrations without buying a product.

Then the tack changed straight after, now ordering products.

We turned on different captchas on all parts of the system. No difference.

I have reach out to WHMCS to get their official stance. It appears that some of these attacks are automated.

- At first, just new registrations, drip.
- Then we change the setting to only allow registration with prior order.
- Then the tact changed to order products, drip orders.
- To be specific, random domain names, .COMs mostly, and random USA addresses.

We exported the orders table, and all IPs are random:

 

45.146.203.242
31.6.43.209
104.165.127.6
5.102.101.110
45.146.203.230
23.230.167.171
104.164.183.249
5.102.101.211
140.99.127.132
156.239.52.118
84.32.64.198
104.165.127.96
84.32.64.248
31.6.43.137
104.165.169.24
104.165.169.90
23.230.167.244
45.146.203.140
31.6.26.243
104.164.183.70
166.88.122.76
84.32.64.188
172.121.142.159
23.27.240.193
84.32.64.132

[Remitur]

I was just contacted by another WHMCS user, who reported the same issue.

here his message (slightly different behaviour from the bad guy) and his IP list (some of them are already in my own list, and already blacklisted).

Quote

Since 48 hours we are the same victim of a distributed, apparently automated, drip campaign denial of service attack on our system.

I have reach out to WHMCS to get their official stance. It's clear that some of these attacks are automated.
At first, just new registration.
Then we change the setting to only allow registration with prior order.
Then the tact changed to order products.
To be specific, random domain names, .COMs mostly, and random USA adresses.

We exported the orders table, and all IPs are random:

 

45.146.203.242
31.6.43.209
104.165.127.6
5.102.101.110
45.146.203.230
23.230.167.171
104.164.183.249
5.102.101.211
140.99.127.132
156.239.52.118
84.32.64.198
104.165.127.96
84.32.64.248
31.6.43.137
104.165.169.24
104.165.169.90
23.230.167.244
45.146.203.140
31.6.26.243
104.164.183.70
166.88.122.76
84.32.64.188
172.121.142.159
23.27.240.193
84.32.64.132

 

[bear]

The bulk of those are once again "Emeigh Investments LLC". Interesting. 
I'd suggest, at least for now, disabling the ability to register without purchase.

[WHMCS Areeb]

HI @Remitur

We are aware of reports of unusual orders being placed, potentially in an automated way and are tracking this internally.

There are some immediate steps which you can take to help minimise the impact of automated orders :

First of all, please make sure that "Allow Client Registration" is disabled at System Settings > General Settings > Other (tab) , as this provides an easy way for spammers to create accounts without needing to place an order.

Secondly, please make sure that you have enabled "Invisible reCAPTCHA" under "Captcha Type" at System Settings > General Settings > Security (tab) . This is the most secure captcha that is currently integrated with WHMCS.

Next, please make sure that you follow and implement all of the solutions provided in our documentation:
https://docs.whmcs.com/orders/spam-orders/

Importantly, please make sure that you have implemented a Web Application Firewall and gone through the full configuration process. Whilst we don't recommend any particular provider, the following are some of the most popular:
CloudFlare: https://www.cloudflare.com/
Amazon CloudFront: https://aws.amazon.com/cloudfront/
Incapulsa: https://www.incapsula.com/
KeyCDN: https://www.keycdn.com/

We are looking into whether these spam orders are being created by submitting a modified POST request to WHMCS. If that is the case, implementing a well-tuned WAF should mitigate much of the problem.

[slim]

What  is this ‘known issue’ you refer to?

Your first and second last sentence of your response sounds cryptic at best.

Edited July 4 by slim

[bear]

As a guess, they're submitting orders directly to the system via specially crafted POST requests. Kind of like when a contact form allows direct submission, and doesn't make sure the POST came via the expected source page. Just a guess. If, however, it's not checking source and these get through, that can be a rather alarming flaw, but stating this should be handled at the WAF level is a bit more concerning.... 

[Eugene van der Merwe]

Here is an example of them posting: 

cat access_log | grep 104.234.211.39
104.234.211.39 - - [05/Jul/2024:04:59:17 +0200] "GET /register.php HTTP/1.1" 200 6166 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
104.234.211.39 - - [05/Jul/2024:04:59:18 +0200] "GET /cart.php?a=add&domain=register HTTP/1.1" 200 43126 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
104.234.211.39 - - [05/Jul/2024:04:59:20 +0200] "POST /cart.php HTTP/1.1" 200 54 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
104.234.211.39 - - [05/Jul/2024:04:59:21 +0200] "GET /cart.php?a=checkout&e=false HTTP/1.1" 200 20463 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
104.234.211.39 - - [05/Jul/2024:05:01:30 +0200] "POST /cart.php?a=checkout HTTP/1.1" 302 356 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
104.234.211.39 - - [05/Jul/2024:05:01:31 +0200] "GET /cart.php?a=fraudcheck HTTP/1.1" 200 7115 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"

Check the times. Register, one second later, add to cart, one  second last post to register again? Then one scond later checkout, then 2 minutes later POST to cart.

 

[Eugene van der Merwe]

Here is another one, 17 minutes later. Again, see referrer of register.php, seems they use something on this page to do the rest:

 

cat access_log | grep 5.102.101.157
5.102.101.157 - - [05/Jul/2024:05:17:21 +0200] "GET /register.php HTTP/1.1" 200 6168 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
5.102.101.157 - - [05/Jul/2024:05:17:22 +0200] "GET /cart.php?a=add&domain=register HTTP/1.1" 200 43142 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
5.102.101.157 - - [05/Jul/2024:05:17:23 +0200] "POST /cart.php HTTP/1.1" 200 54 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
5.102.101.157 - - [05/Jul/2024:05:17:24 +0200] "GET /cart.php?a=checkout&e=false HTTP/1.1" 200 20441 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
5.102.101.157 - - [05/Jul/2024:05:17:55 +0200] "POST /cart.php?a=checkout HTTP/1.1" 302 356 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"
5.102.101.157 - - [05/Jul/2024:05:17:55 +0200] "GET /cart.php?a=fraudcheck HTTP/1.1" 200 7110 "https://portal.example.com/register.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0"

 

[WHMCS John]

13 hours ago, slim said:

What  is this ‘known issue’ you refer to?

We have received reports of such orders from users and are tracking these reports internally.

If there is some kind of change we can potentially make in future to help in this respect, it's certainly something we want to be aware of.

[slim]

The order are slowly accelerating- I think in total I’d have had around 50 by now

[NetWise UK]

We’re getting them through in batches of around six to eight a few times per day. 

[Remitur]

I greatly reduced the number of fake registrations blacklisting following IP classes:

84.32.64.0/24
172.121.142.0/24 
104.165.169.0/24 
31.6.46.0/24 
31.6.43.0/24 
104.165.127.0/24 
45.146.203.0/24 
5.102.101.0/24 
140.99.127.0/24 
156.239.52.0/24 
23.230.167.0/24 
104.164.183.0/24 
23.27.240.0/24
192.142.242.0/24
192.142.240.0/24
192.142.243.0/24
192.142.244.0/24
192.142.245.0/24

 

[chrismfz]

Assuming this won't continue for ever.... weeks or months, we implement this:

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Check if the User-Agent matches
    RewriteCond %{HTTP_USER_AGENT} "Mozilla/5.0 \(Windows NT 10.0; Win64; x64; rv:127.0\) Gecko/20100101 Firefox/127.0"

    # Check if the request method is POST
    RewriteCond %{REQUEST_METHOD} POST

    # Check if the URL is register.php
    RewriteCond %{REQUEST_URI} register.php$

    # Deny access by returning a 403 Forbidden status
    RewriteRule .* - [F]
</IfModule>

 

The agent is always the same, so we block it on web server layer. 

Hope it helps.

[bear]

6 hours ago, chrismfz said:

"Mozilla/5.0 \(Windows NT 10.0; Win64; x64; rv:127.0\) Gecko/20100101 Firefox/127.0"

Though this may stop them because they're using it, so am I when using Firefox. Assuming POSTing to register.php is part of the normal register/order process, this will disallow anyone using the latest version of FF to register. 

[chrismfz]

It stops POSTs, on register.php when seeing this Firefox agent. Nothing else. only for register.php and only when someone will try to POST something. 

It did the job for us. 

[NetWise UK]

54 minutes ago, chrismfz said:

It stops POSTs, on register.php when seeing this Firefox agent. Nothing else. only for register.php and only when someone will try to POST something. 

It did the job for us. 

It’s worked for us too. Thank you 🙏