Should I be worried about this hacking tool used on one of my websites?

J

Jackster

Verified User
Joined
Jul 15, 2011
Messages
25
Last edited:
Well, I just went through all the files and it is in every /public_html/ folder.
Within 20 seconds from the first point of entry, it copied that file to every /public_html/ and started getting hit by multiple IPs from all over.


You guys might want to block:
103.144.169.183
109.0.0.0
119.8.112.244
194.5.48.52
45.131.195.101
194.5.48.94
185.198.243.91
103.0.0.0
194.5.48.136
142.54.188.106
 
I would be worried about any hacking tool on my server.
Why asking if you should be worried instead of removing the stuff?

And watch out, mostly it's not 1 file or 2, but multiple files are often adjusted, even code added to exising official wordpress sites.
You really have to check everything. Run a scanner like maldetect.

Most likely the WP install is hacked via a leak script of theme of easy password used.

I would suspend the site, clean as much as possible, then activate again and tell the customer site is hacked and he needs to fix things a.s.a.p. ofcourse.

Often multiple country's attack almost immediatly.
Doublecheck with lsof -i:25 if they did not install a mail daemon.
 
Richard G said:
I would be worried about any hacking tool on my server.
Why asking if you should be worried instead of removing the stuff?

And watch out, mostly it's not 1 file or 2, but multiple files are often adjusted, even code added to exising official wordpress sites.
You really have to check everything. Run a scanner like maldetect.

Most likely the WP install is hacked via a leak script of theme of easy password used.

I would suspend the site, clean as much as possible, then activate again and tell the customer site is hacked and he needs to fix things a.s.a.p. ofcourse.

Often multiple country's attack almost immediatly.
Doublecheck with lsof -i:25 if they did not install a mail daemon.
Click to expand...
I'm more worried about the actual webserver than the user's files.
They are all getting nuked for sure. But I am worried about the OS being compromised.

lsof -i:25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
exim 735 mail 4u IPv4 26395 0t0 TCP *:smtp (LISTEN)
Click to expand...
 
Jackster said:
But I am worried about the OS being compromised.
Click to expand...
Do the users have SSH access? If not and your system is up to date, it's hard to get a real root shell, so OS compromised happens quite seldom, even with ssh for users active, because that's mostly in a jailshell.

Best is to install maldetect or immunify360 or something.
Here's a link with a manual to install maldetect containing custom signs you can use. You might need to whitelist a few things (not much).
malware.expert

Install Maldet Directadmin Server

Maldet Directadmin server (Malware Detect) is easy setup. There is nothing complicated in installation,but root access to your server is required.
malware.expert

As for the output of the lsof command, seems only Exim is working and that is legitimate.

Keep limits on mail accounts (for example 200 or 500) so you get warned if an account suddenly is sending a load of mail, which mostly points to spamming by abusing of an account.
 
Richard G said:
Do the users have SSH access? If not and your system is up to date, it's hard to get a real root shell, so OS compromised happens quite seldom, even with ssh for users active, because that's mostly in a jailshell.

Best is to install maldetect or immunify360 or something.
Here's a link with a manual to install maldetect containing custom signs you can use. You might need to whitelist a few things (not much).
malware.expert

Install Maldet Directadmin Server

Maldet Directadmin server (Malware Detect) is easy setup. There is nothing complicated in installation,but root access to your server is required.
malware.expert

As for the output of the lsof command, seems only Exim is working and that is legitimate.

Keep limits on mail accounts (for example 200 or 500) so you get warned if an account suddenly is sending a load of mail, which mostly points to spamming by abusing of an account.
Click to expand...
Only I have SSH.

Running those maldet now. Will see what it finds.

I don't use DA for email. I thought the ports were turned off but it looks like bots are trying to login to mail accounts.
 
And a full ClamAV scan would also not be bad. Btw - i had never a case, where a malware from customer websites was able to break out into Directadmin or serverenvironment.
If the attacker have web access for uploading shells, also your databases arent save anymore, malware can hide also in DB. And they will upload php mailer and start converting your box into a spamming machine. Then your IP reputation goes down the Jordan. Or they start hosting extortion software which could harm other websitevisitors, thats a legal problem and could cause compensation requests to your adress.
You should deactivate all those accounts immediately.
 
Last edited:
Jackster said:
but it looks like bots are trying to login to mail accounts.
Click to expand...
Bots are always trying to login to mail accounts, existing or non existing on the specific server doesn't really matter to them.

johannes said:
And a full ClamAV scan would also not be bad. Btw - i had never a case, where a malware from customer websites was able to break out into Directadmin or serverenvironment.
Click to expand...
You can combine Maldetect and Clamav. If you have clamav installed then Maldetect uses clamav too if I'm not mistaken.
As for the break in, yes I had once that hackers were able to put a mail daemon in an account of a user. They did not had root access but they were able to spam that way.
That was once in the older days (like around 2009 or 2010).

Several years ago, indeed a script was uploaded by hackers to some subdirectory of WP, which was a script able to be visited from outside and send mail via php mail.
Luckily I got warnings form Munin and CSF about loads of mail. So I could fastly fix it.
We have set limits on php mails since then.

As soon as we detect a hack or malware, the complete account is suspended immediately and customer notified.
 
The issue isn't so much the shell script existing on the account, it's how it got there.

WordPress admin credentials compromised?

WordPress admin credentials weak?

WordPress (or plugin or theme) out of date?

WordPress (or plugin or theme) abandoned by it's developers?

WordPress (or plugin or theme) poorly coded by it's developers?

DirectAdmin login information compromised?

DirectAdmin login information weak?

If the script is owned by the user of that account, then chances are something on that account is exploitable. What I've listed above is just some potential entry points. And admittedly it can be real difficult trying to find where the entry point is at. But unless you close that entry point, there's nothing stopping this from happening again.
 
sparek said:
The issue isn't so much the shell script existing on the account, it's how it got there.
Click to expand...
That seems logical to me, but you have to close the account first to investigate, otherwise they can keep abusing while you are trying to find issues.
Often also scripts rename or delete some files used to get in.
So that's why suspending is the most important, after that indeed investigate as to how they got in, I fully agree with that.
I also mentioned most of the times it's due to some leak script or them, but it can also be other causes. One needs to get the cause.
 
I just remember a case, where it wasnt a shell script at all. It was a code with a link somehow hidden in the DB, which when accessed by browser, it created a hidden admin account. Full system was updated, all files were original, but the intruder was already there, hidden in the DB.
 
I recently had a WordPress admin account (I think bad password) compromised and a malicious "Plugin" was installed.

What helps in WordPress is to add a .htaccess to the /wp-content/ directory with the following content to prevent direct php file access. In WordPress all requests should go through WordPress and never directly to a PHP file in /wp-content/. Better test first per site though...

Code: 
<Files *.php>
  deny from all
</Files>
 
For OS integrity, you may verify it by "rpm --verify --all". You may refer to man page for rpm details.

For WordPress, we personally use password-protected-directory to lock down it,
and give the username/password to end-user, and ask end-user to fix it.
 
You must log in or register to reply here.
Back
Top