Spam Account Keeps Registering

brian! · September 26, 2014

Now what WHMCS could do to help all of us is to come up with some mod security rules, even basic ones, that we would use to assist us all with this issue.

this jogged a memory with me - didn't whmcs have (or planned to have) an agreement with a modsec company (atomicorp?) to produce their own modsec rules?

for the life of me, I can't find the post - don't know whether it was here or in the blog - so i'm operating purely from memory with this...

all I could find was this post from a year ago...

http://forum.whmcs.com/showthread.php?80347-10-ways-to-make-your-WHMCS-installation-more-secure&p=344330#post344330

Speaking of rules, we'll have some cool news soon for this.

easyhosting · September 26, 2014

i hate to be the giver of bad news, but WHMCS probably has no intention of fixing 5.2 as its past its end of life im pretty sure.

Most likely not, but even if you are on the latest version these orders are still being made. It is the person/group making this orders that is trying to use a 5.2 exploit.

since i spoke to the guys at Singlehop about their network being used for these orders i have never had another one of these order ( i am not using a server on the Singlehop network)

sytry · September 26, 2014

Hi,

I have same problem.

Client ID: xxx - Aganteng Rooterz has requested to change his/her details as indicated below:

First Name: 'Aganteng' to 'DM'

Last Name: 'Rooterz' to 'DM'

Address 1: 'JL SYNTAX ERROR' to 'syntaxerror'

Address 2: 'JL SYNTAX ERROR' to 'syntaxerror'

City: 'DM' to 'AES_ENCRYPT(1,1), city= (SELECT GROUP_CONCAT(0x3a3a3a3a3a,id,0x3a,username,0x3a,email,0x3a,password,0x3a3a3a3a3a) FROM tbladmins)'

Postcode: '404404' to '102030'

Default Payment Method: '' to ''

If you are unhappy with any of the changes, you need to login and revert them - this is the only record of the old details.

This change request was submitted from eros.thewebhostserver.com (37.26.108.145)

I had 3 attempts

ip with 1 in USA, UK and Lithuania a "LT"

I have since not create an account without an order.

Prohibits changing the information in the account.

Then activated CSF paranoid fashion: D + more security nginx

This is 3 to 4 hours it nice ...

It would be nice to put a limit on the rate change information

For example that one person can change once every X hours or if it changes it must validate email like this one on many forums ...

Because it may be on old version of whmcs but when it will come to the right value it will react.

I also recall that this is one year that day to day whmcs wipe monster has flaws ...

PPNSteve · September 26, 2014

They hit us as well.. daily or more with

Order Information
Order ID: 63
Order Number: 6622151750
Date/Time: 09/26/2014 14:32
Invoice Number: 1265
Payment Method: PayPal
Customer Information
Customer ID: 41
Name: Aganteng Rooterz
Email: DM7WE@GMAIL.COM
Company: DMASTERPIECE 
Address 1: dm
Address 2: dm
City: dm
State: Arizona
Postcode: 404404
Country: US
Phone Number: 086969696969
Order Items
Domain Registration: Register
Domain: hacked-by-dm-team.com
First Payment Amount: $12.96 USD
Recurring Amount: $12.96 USD
Registration Period: 1 Year/s

Total Due Today: $12.96 USD
ISP Information
IP: 192.185.12.45
Host: prizm.websitewelcome.com

Always on diff IPs and small variations in inputted data, then later the 'address change' with the injection attempt,. I've been frauding, changing passes, closing, then banning their IP as soon as I see these now. However it is becoming very annoying and want a better solution.

...
Now what WHMCS could do to help all of us is to come up with some mod security rules, even basic ones, that we would use to assist us all with this issue. This issue is not and never was and never will be a single pronged battle. It takes several ways of attaching this to keep it under control..

I so agree.. some mod_sec rules would really help as they tend to be effective VS many script kiddies if properly written.

ephost · September 28, 2014

This keeps happening to us as well. We are growing tired of deleting and banning these. Even if this is a old hack it's really annoying and allows someone access to an account to test hacks.

The problem seems to be that during checkout if your card is declined, or you otherwise didn't pay yet, you are already logged into the account after submitting the order. This enables automated attacks on the code without the benefit of a successful order or some sort of email confirmation. Additionally, there is no CAPTACHA on the order form contributing to the issue (though it's enabled).

I though there used to be a security option preventing access to an account without an approved order. I can't seem to find.

I am trying to work on some sort of hook or cron job or Hook to close these fraud accounts using the suggestion here but I modified slightly to prevent false-positives in a situation where a good customer had a past fraud order that did not get its status changed.

https://www.blog.whmcs.com/showthread.php?27312-Automatically-close-fraud-accounts-(CRON)

This is untested. Any feedback on getting this to fire on the AfterFraudCheck hook (or something) would be appreciated:

<?php 

function close_fraud_accounts_hook($args) { 

   $query = "SELECT * FROM tblclients, tblorders WHERE tblclients.id = tblorders.userid AND tblclients.status = 'Active' AND tblorders.status = 'Fraud' AND tblclients.id NOT in (SELECT tblclients.id FROM tblclients, tblorders WHERE tblclients.id = tblorders.userid AND tblclients.status = 'Active' AND tblorders.status = 'Active')"; 
   $result = full_query($query); 

   while($record = mysql_fetch_array($result)) { 
       update_query("tblclients",array("status"=>"Closed"),array("id"=>$record['id'])); 
   } 
} 

add_hook("DailyCronJob",1,"close_fraud_accounts_hook",""); 

?>

Thanks,

Joe

davey · September 28, 2014

We have this guy now for months on our site. Each ip we have been banned manually.

Might be interested to share these ip's.

IP Address Ban Reason Ban Expires  
178.32.239.141 Hack attempt 03/10/2031 13:28  
192.157.220.120 Hack attempt 02/10/2031 16:20  
204.93.159.77 Hack attempt 02/10/2031 11:50  
108.170.46.130 Hack attempt 01/10/2031 02:14  
108.175.145.28 Hack attempt 30/09/2031 14:11  
108.179.225.71 Hack attempt 28/09/2031 11:52  
192.185.2.31 Hack attempt 26/09/2031 15:34  
188.165.14.158 Hack attempt 26/09/2031 15:25  
75.127.126.17 Hack attempt29/08/2030 14:25  
68.64.167.182 Hack attempt29/08/2031 14:25  
216.185.103.164 Hack attempt25/08/2030 11:14  
79.106.109.243 Hack attempt24/08/2030 01:49  
39.250.33.211 Hack attempt08/01/2032 13:12

vsooe · September 30, 2014

I did not wasted time banning him, i started writting his IPs first and i found its always new IP. These i recorded so far.. (sorrted from highest nuber to lowest)

204.93.159.77

188.165.14.158

184.107.178.26

178.32.239.141

174.121.78.194

108.175.145.28

75.127.126.17

thx

pagehosting4u · October 5, 2014

Can't we block this kid based on company name, DMASTERPIECE, or for invalid phone number? My list of ban IPs is growing.

Rick

easyhosting · October 5, 2014

Strange ever since i spoke to Singlehop i have had no more orders from this kid

pagehosting4u · October 5, 2014

After I had contacted the last hosting company he/she was going through it stopped for me as well. Now they are going through

IP: 204.93.159.77

Host: phnompenh.khmerwebhost.com

Rick

durangod · October 5, 2014

For those of you that tried the new client block mod let me know how it works for you, if it needs to be tweeked then that certainly can be done.

maiainternet · October 14, 2014

Hi guys,

just thought I'd let you know about an event that happened on my install just a few minutes ago.

Not sure if they were successful but a url was entered to change the details of a new, prob bogus, account that had been created. The result in WHMCS was thus:

First Name	Andri
Last Name	Cyber4rt
Company Name	DMASTERPIECE
Email Address	[email]a@b.com[/email]
Address 1	AES_ENCRYPT(1,1), address1= (SELECT MIN(username) FROM tbladmins)
Address 2	AES_ENCRYPT(1,1), address2= (SELECT MIN(password) FROM tbladmins)
City	dm
State/Region	Arizona
Postcode	dm
Country	US - United States
Phone Number	086969696969

as you can see an attempt was made to get the 'admin' details out of the database.

Does anyone know if these attacks are known about and if so are they successful.

I have only 1 admin and have changed the password, but it's out there that people are trying!

Cheers,

Dave

Infopro · October 14, 2014

Threads merged.

oktarin · October 19, 2014

Hi everyone,

I was also bullied by Andy Cyber4rt and used WHMCS option to Close Clients account. After that it stopped.

However, today, 10days after last visit from Andy I had another registered user "La Tief", company "Ncyber4rt" with the same hacking method - trying to get passwords for servers.

Downside is that he managed to create hosting accounts on servers, and he didn't do it through WHMCS.

My only conclusion is that he managed to get the data from my database and log in to the servers WHM.

Can someone please confirm that data for the servers saved in WHMCS is secure enought so it cannot be accesed through:

AES_ENCRYPT(1,1), city= (SELECT MIN(accesshash) FROM tblservers)

AES_ENCRYPT(1,1), address1= (SELECT MIN(ipaddress) FROM tblservers)

AES_ENCRYPT(1,1), address2= (SELECT MIN(username) FROM tblservers)

WebzPro · October 19, 2014

Got hit by the same guy, using IP out of Spain

IP Address: 37.247.121.196

Host: ns1.nuevosdominiosweb.org

Honestly wouldn't a simple solution to be able to ban certain addresses as you can IP addresses?

or

AES_ENCRYPT(1,1) gets put in to the address 1or 2, City or State and the system kicks back not allowing it.

Until there is fix for this we are simply not allowing address changes and have informed clients such changes will be submitted to Billing in a support ticket.

For as long as this has been going on WHMCS should have thought of something so simple and implemented the solution.

By the way you know these people trying this hack are watching this thread. :oops:

Edited October 19, 2014 by WebzPro

easyhosting · October 19, 2014

Downside is that he managed to create hosting accounts on servers, and he didn't do it through WHMCS.

My only conclusion is that he managed to get the data from my database and log in to the servers WHM.

Well this would mean your server is not secure and nothing to do with WHMCS. you need to change all your server passwords to strong password and then ask a server admin to see how they actually got into your server.

- - - Updated - - -

Honestly wouldn't a simple solution to be able to ban certain addresses as you can IP addresses?

this is already available

http://forum.whmcs.com/showthread.php?4640-Free-Emails-Banned-Addon

WebzPro · October 19, 2014

this is already available

http://forum.whmcs.com/showthread.php?4640-Free-Emails-Banned-Addon

]

That is Free Emails Banned Addon. Not what I was referring to.

Again....

Honestly wouldn't a simple solution to be able to ban certain addresses (not refering to email addresses)as you can IP addresses?

or

AES_ENCRYPT(1,1) gets put in to the address 1or 2, City or State and the system kicks back not allowing it.

Until there is fix for this we are simply not allowing address changes and have informed clients such changes will be submitted to Billing in a support ticket.

ephost · October 21, 2014

I may have come up with a work-around for this using a hook. I was also thinking the automatic status change feature in WHMCS may do the same thing but I elected to go this route as I had that feature disabled.

It fires on the AfterFraudCheck hook point and will close fraud accounts (the current one AND any old ones) at the time of the fraud order. If a user attempts to go to one of their account screens they end up getting logged out before they can do anything. I use MaxMind, and hopefully you are using something similar, but in the case you are not I am not sure if the hook point will fire or be effective. In this point you could change the hook point to "ClientAreaPage" though it would run as often as people log in so I don't know if some sort of race condition could crop up.

This code is provided as-is and without warranty etc.. backup your database and files prior to using it as a precaution. I would also test the select query before doing anything to make sure the right results are displayed. Your first run may return many old fraud orders and customers than have not been closed. The query will not flag an account if they have one or more "active" orders to reduce false-positives.

Instructions: Copy the code into a file called fraud_account_close.php and put into includes/hooks/. Clear your template cache using utilities >> system >> system cleanup >> clear template cache. Turn on hook debugging though the hook will log the activity (minimally).

There is an issue with this code. Do not use.

<?php  

function fraud_account_close($args) {  

   $query = "SELECT tblclients.id FROM tblclients, tblorders WHERE tblclients.id = tblorders.userid AND tblclients.status = 'Active' AND tblorders.status = 'Fraud' AND tblclients.id NOT in (SELECT tblclients.id FROM tblclients, tblorders WHERE tblclients.id = tblorders.userid AND tblclients.status = 'Active' AND tblorders.status = 'Active')";  
   $result = full_query($query);  
   $num_rows = mysql_num_rows($result);

   while($record = mysql_fetch_array($result)) {  
       update_query("tblclients",array("status"=>"Closed"),array("id"=>$record['id']));  
   }  

logActivity('AfterFraudCheck hook was called returning ' . $num_rows . ' rows.');

}  

add_hook('AfterFraudCheck',1,'fraud_account_close');  

?>

I am putting this up after a bunch of internal fraud testing but have not yet seen it in action with an actual "Cyber4rt" fraud order. Hopefully it works for this. Please PM me if the code above looks broken because of the forum "cleaning" it or if you find a bug.

Joe

Edited October 21, 2014 by ephost

ephost · October 21, 2014

I guess this may have been premature as it appears to be catching legit orders too. I will post a revised script if the issue can be resolved.

arumdev · October 21, 2014

This is so irritating, would be great to get a solution. Joe I tried running your query but didn't get any results at all.

ephost · October 21, 2014

That is probably a good thing. The query should return results only if there is an "active" client with an order that is marked "fraud" and that doesn't have another order marked as "active".

Please do not use that code as it will close the account of a legitimate order. The issue I am having is that it would appear the order is marked as "fraud" at the time this hook is fired. It is later marked as "active" if the fraud check passes but by that time it's too late.

I am trying to find a work around so we can see the fraud results and only update to closed if they failed.

ephost · October 21, 2014

This is what I have and I am not sure I can make it any better without some help. To solve the issue with the fact that the previous version of the hook script (a few posts back) would close a legitimate order-- I am doing a test to see if MaxMind returns an array of data in the isFraud field which I think indicates it didn't pass then closing the account. If that field is not an array I am assuming it's okay and don't update the account.

I would really appreciate is WHMCS or anyone else had a thought on this and how we can make sure the update part doesn't run on orders that pass fraud screen. Or frankly provide a security update to this issue.

Please use at your own risk. Conduct your own testing. This version requires the use of MaxMind (or possibly other fraud service) and the uses the AfterFraudCheck hook specifically.

Instructions: Copy the code into a file called fraud_account_close.php and put into includes/hooks/. Clear your template cache using utilities >> system >> system cleanup >> clear template cache. Turn on hook debugging though the hook will log the activity (minimally).

<?php  

if (!defined("WHMCS")) die("This file cannot be accessed directly");

function fraud_account_close($args) {  

if (is_array($args[0]['isfraud'])) {

	$query = "SELECT tblclients.id, tblorders.status FROM tblclients, tblorders WHERE tblclients.id = tblorders.userid AND tblclients.status = 'Active' AND tblorders.status = 'Fraud' AND tblclients.id NOT in (SELECT tblclients.id FROM tblclients, tblorders WHERE tblclients.id = tblorders.userid AND tblclients.status = 'Active' AND tblorders.status = 'Active')";  
	$result = full_query($query);  
	$num_rows = mysql_num_rows($result);

	while($record = mysql_fetch_array($result)) {  
		update_query("tblclients",array("status"=>"Closed"),array("id"=>$record['id']));
	}  

	logActivity('AfterFraudCheck hook was called. Order was fraud so we closed the account. ');

} else {

	logActivity('AfterFraudCheck hook was called. Order was not fraud.');

}

}  

add_hook('AfterFraudCheck',1,'fraud_account_close');  

?>

Please let me know if you find any bugs or other reasons it may not work right. It is hard as heck to test these fraud orders.

Joe

bluebirdnet · October 22, 2014

This order was not flagged as Fraud by Maxmind.

most recent attempt.

Name: Bzad Rooterz

Email: ritatea0@gmail.com

Company: Bzadteam

Address 1: JL SYNTAX ERROR

Address 2: JL SYNTAX ERROR

City: Bzad

State: Arizona

Postcode: 404403

Country: US

Phone Number: 081234567890

ISP Information

IP: 192.185.83.183

Host: nikken.websitewelcome.com

Edited October 22, 2014 by bluebirdnet

durangod · October 22, 2014

How many times have they registered now, using similar information.

If you go here and search the word - block - you might find something that might help depending on your circumstances.

https://www.whmcs.com/appstore

Edited October 22, 2014 by durangod

sheldows · October 25, 2014

i keep getting c-blocked by the forum automatic modulator posting the script kiddy order details. pissing me off.

Spam Account Keeps Registering

Recommended Posts

Link to comment

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Posted Images

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Similar Content

Recently Browsing 0 members

Important Information