Unusual order activity

[bear]

5 hours ago, chrismfz said:

Nothing else. only for register.php and only when someone will try to POST something

I understand. My point was, in order to register an account in your WHMCS, doesn't someone have to post to that page? You fill out the details, and it posts it to the system in order to register.  The POST would include the user agent, I'd expect.
Is that not the case? You've had successful signups for actual clients following that?

[snake]

having the same issue, got hundreds of fake orders now.
All orders are the same, a random domain name,.

Having to go through and manually delete the users 1 at a time, so it doesn;t increase my licence cost.

Does the script above block orders or just user registrations?

[snake]

is there any way to bulk delete all these fake accounts and associated users?

[bnb]

We are also facing this problem.

We started getting about 10-20 registrations daily.
We disabled the registration form, and then we started to get new orders with new registrations.

It has been over 200 new users that we have manually deleted so far.
I hope there is a quick fix soon.

[Basic Matrix]

Same problem here. Started for us on 7/3/2024 (5 days ago) and there are already 150 accounts.

I'm going to try the .htaccess solution posted here.

I tried the free FraudLabs Pro account, but it will only cancel the order and mark it fraud AFTER the account is created... which doesn't fix the issue.

I'm hoping the developers allow us to do something like disable online orders from non-existing customers and prevent new customer registration completely.

Has anyone tried using a CAPTCHA? If they are using an automated attack for this with 1 sec per page, that could stop them.

[Basic Matrix]

On 7/7/2024 at 5:34 AM, bear said:

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. 

I implemented the code above into my .htaccess file in the root of WHMCS installation. I was still able to load the page, place an order, and register a new account through Firefox. I'm waiting to see if this stops the fradulent orders.

Thanks for FraudLabs, I got the fraud detected page appropriately since I put in garbage info.

[Basic Matrix]

While I was waiting, I found one extra option. All of these orders aren't submitting any payment information. If your situation allows you to disable the "Mail in Payment" option only on the order form, you can force them to submit valid payment information that will be fraud checked by your payment processor.

I'm banking on that working. Simply go to Settings > Payment Gateways > Mail In Payment and uncheck the box next to "Show on Order Form"

[Basic Matrix]

I can now confirm that the .htaccess MOD code did NOT work for me.

I placed it at the top of the .htaccess file in the root of WHMCS where register.php resides. For those of you this method is working for, could you share how and where you placed that code?

Perhaps they have updated or changed their user agent? It was only a matter of time....

[snake]

sadly that script did not help at all, still getting 20 fake orders a day.
They are all using US based addresses, if I can block those that will solve my problem, as we are UK based.

 

[bnb]

4 minutes ago, snake said:

sadly that script did not help at all, still getting 20 fake orders a day.
They are all using US based addresses, if I can block those that will solve my problem, as we are UK based.

 

It is not ideal, but the support team gave me a temporary solution that worked right away - no more user registration spamming so far.

Just add a custom field to the registration form, and it should stop. Here's how: https://docs.whmcs.com/orders/spam-orders/#custom-client-fields

[Vander Host]

This worked for us:

https://docs.whmcs.com/orders/spam-orders/#custom-client-fields

Now on checkout we have this:

But like I said in my earlier log file analysis, there is an exploit or "bug" in `register.php`. I did a comparison between a normal orders and the spam automated orders and the spam automated orders all use `register.php` as referrer whereas normal orders don't. I have informed WHMCS via a ticket but I guess this problem is much more complex than usual.

 

[snake]

i have given it a try, but I didn;t think that would work as these seem to be manually placed orders by humans.
they are using a VPN, as IP says they are in UK too, despite having a USA address

[bnb]

1 hour ago, Vander Host said:

This worked for us:

https://docs.whmcs.com/orders/spam-orders/#custom-client-fields

Now on checkout we have this:

But like I said in my earlier log file analysis, there is an exploit or "bug" in `register.php`. I did a comparison between a normal orders and the spam automated orders and the spam automated orders all use `register.php` as referrer whereas normal orders don't. I have informed WHMCS via a ticket but I guess this problem is much more complex than usual.

 

This also worked for us. Zero spam orders after implementing this custom field on the registration page. It has been 24h so far. We were getting around 20-30 registrations per day.

 

captcha was on all the time, and strong WAF in place. These registrations are made by bots, somehow…

[Remitur]

On 7/9/2024 at 12:22 AM, Basic Matrix said:

 

Has anyone tried using a CAPTCHA? If they are using an automated attack for this with 1 sec per page, that could stop them.

I have invisible reCAPTCHA enabled, but this does not prevent fake registrations.

So, possible explanations:

•  the bad guy knows how to null Google reCAPTCHA, so his script is able to go through Google reCAPTCHA, but fails to go on the trivial manual captcha suggested in other posts
• registrations are done manually, but by some kind of monkeys that aren't able to go over the trivial manual captcha
• the bad guy is using on his side some kind of chrome script, that is able to go through Google reCAPTCHA (but when Google ask for manual verification... but we don't know when this happens), but fails to go on the trivial manual captcha suggested in other posts 

 

[Remitur]

It seems that also a check on country (preventing registrations from the US) works fine. 
I implemented it 12 hours ago, and since then zero fake registration.

I did it modifying our old (but still working) checkuser hook (which prevents the user from registering using fake or disposable email address, or entering for name, company name, address etc. string with special characters or too long).

Obviously the decision to block any registration from the USA is not viable for anyone: if your business is US-based, or if significant part of your business is in the US area, this does not fit.
As far as we are concerned, the only utility of the US for us is to keep the North Atlantic and the Pacific oceans separate, and so it is not a problem... 😂

The up-to-date version of the script is available here:

https://github.com/DomainRegister/WHMCS/blob/master/checkuser.php

[bnb]

1 hour ago, Remitur said:

It seems that also a check on country (preventing registrations from the US) works fine. 
I implemented it 12 hours ago, and since then zero fake registration.

An easier solution is to add a custom field in the registration form by following these instructions: https://docs.whmcs.com/orders/spam-orders/#custom-client-fields
About 48h now with zero fake registrations.

I believe this is all automated from a bot using some sort of script targeting WHMCS websites.

[bear]

2 hours ago, Remitur said:

As far as we are concerned, the only utility of the US for us is to keep the North Atlantic and the Pacific oceans separate

Panama Canal, dude. 😉

1 hour ago, bnb said:

I believe this is all automated from a bot using some sort of script targeting WHMCS websites.

I'd say that's likely right. I have to wonder if they will see the additional field in use and find a way around it, but if everyone used it, that would be harder to automate, possibly. 

[slim]

It won’t take them long to work around the custom field. I just hope WHMCS are working on this.

[bnb]

39 minutes ago, bear said:

I'd say that's likely right. I have to wonder if they will see the additional field in use and find a way around it, but if everyone used it, that would be harder to automate, possibly. 

If they find we are all using the same answer in the custom field, then it might be easy to go through this protection. So far... so good... but I am sure WHMCS is working on this matter. At least that's what one support representative told me.

Edited July 10 by bnb
Na

[Vander Host]

12 minutes ago, slim said:

It won’t take them long to work around the custom field. I just hope WHMCS are working on this.

I logged a ticket with WHMCS.com, but I got the usual yes no,  no yes, yes no, yes maybe. No real answer, just high level vagueness. I have however mentioned here and in the ticket that the referrer in the access log holds a major clue. I found some source code and it appears that register.php is mostly Smartly template preparation, so I guess maybe with Smarty templating it's easy to POST to the order forms and avoid CAPTCHA. Or maybe Smarty has a security hole. At least after our custom field no more fake orders, more than 48 hours already.

EDIT: I should add, a competent hacker would be following this thread already and planning their next move.

Edited July 10 by Vander Host

[bnb]

1 hour ago, Vander Host said:

I should add, a competent hacker would be following this thread already and planning their next move.

Thankfully, the words "competent" and "hacker" do not always go together.

[bear]

1 hour ago, Vander Host said:

it appears that register.php is mostly Smartly template preparation

The copy  saw included several function files from WHMCS at the start. Strongly doubt this is a smarty issue, but instead possibly the included file(s) missing a check the hacker found and is allowing it. 

1 minute ago, bnb said:

Thankfully, the words "competent" and "hacker" do not always go together.

Kind of naive assumption there. Script kiddies might be, but an actual hacker is generally competent enough to "do things" at will.

[bnb]

3 minutes ago, bear said:

Kind of naive assumption there. Script kiddies might be, but an actual hacker is generally competent enough to "do things" at will.

Let me remain naive until I am proven wrong  😉 
Wishful thinking is part of my lifestyle. "Fear"... not so much.

[bear]

On 7/10/2024 at 8:48 AM, bnb said:

Wishful thinking is part of my lifestyle. "Fear"... not so much.

Being paranoid doesn't mean "they" are NOT out to get you, it just shows a sense of heightened awareness. 🙂

[WHMCS Juan]

Howdy folks,

I'd like to offer some additional advice for mitigating these automated submissions from disparate IP addresses.
If you're reading this and have not already configured the additional protections listed in our Spam Orders recommendations, then I suggest using those steps first to eliminate a majority of automated actions performed on your installation.

From admin reports of this behavior, I have observed that a large majority of these requests are being placed from networks that would be highly unlikely to provide genuine user traffic.
For example, a majority of the IPs and CIDR ranges in this thread belong to proxying or hosting services.

Using a third-party lookup tool, such as https://ipinfo.io/, you can obtain the Autonomous System Number (ASN) for these IPs and find additional information about the IP address custodian.
Specifically, if you see that the IP address is from a hosting provider, then it is safe to assume that none of the traffic from the hosting provider's ASN is legitimate user traffic (unless the hosting provider is a customer of yours).
However, be careful not to block residential ASNs or legitimate traffic by double-checking the order's legitimacy and the ASN owner's information.

With the ASN number, you have a few options:

Block the ASN
If your WAF or other security tools outside of WHMCS allow this, you may block the entire ASN at a level that prevents any requests from reaching the web server itself.
As an example, with Cloudflare, you may use an IP Access Rule: https://developers.cloudflare.com/waf/tools/ip-access-rules/
Other providers may have similar configurations available.

Block the ASN's IP ranges on WHMCS
If you do not have a WAF or are unable to block an entire ASN in your firewall or server configurations, then blocking these IPs in WHMCS is also an option.

Note: before performing any database operations, please take and validate a full database backup in case of unforeseen events

After you have obtained an ASN that is a known repeat-offender, you may look up the IP ranges assigned to the ASN.
One service that allows this is MXToolBox: https://mxtoolbox.com/asn.aspx

With the CIDR ranges, you can convert them to a format that tblbannedips will accept:

Quote

The last two blocks accept wildcards to enable you to block IP address ranges (for example, 189.123.789.* or 189.123.*.*).

https://docs.whmcs.com/system/banned-ip-addresses/#manually-banned-ip-addresses

The following calculator can assist with determining the IP ranges for each CIDR: https://www.ipaddressguide.com/cidr

Then, use a query similar to the following (feel free to add as many ranges as needed) to ban these ranges for a specified time period (in this example, 100 years):

INSERT INTO tblbannedips (ip, reason, expires)
SELECT
    ip,
    'Abusive network - ASN NUMBER HERE',
    DATE_ADD(NOW(), INTERVAL 100 YEAR)
FROM (
    SELECT '10.0.0.1' AS ip UNION ALL
    SELECT '10.0.1.*' UNION ALL
    SELECT '10.1.*.*'
) AS ips;

While I can appreciate that this mitigation may be more involved than some users would be comfortable with, our team is continuing to track these reports internally to ensure we can provide the best advice (and potential product improvements if any are identified) to mitigate and prevent such automated behaviors that mimic human interactions.