My (managed) dedicated server, with several sites (not all of which use WP) has been hacked.
OK, it happens. Not the end of the world.
Today, I find permissions changed to 200 – which I suspect might have been done by my service provider (although I’ve not received notification, nor yet an answer to my ‘have you…?’ question).
It may be that someone tried to attack your service provider. It is quite uncommon to have the 200 user permission.
In Linux there are two methods to change the file.php permissions.
-rwxrwxrwx file.php
- Symbolic method
- Absolute Value method
The symbolic method is for geeks such as David MacKenzie who wrote chmod tool, and we will only speak in absolute value method.
The permission of the following file:
-rwxrwxrwx file.php
is 777.
Apparently your files were 200 like this:
--w------- file.php
4 means Read,
2 means Write
1 means Execute
Looks like the hacker got your root access.
I’m curious about what the code does, although decoding it isn’t worthwhile as it’s clearly in some way ‘bad stuff’.
I would not bother with that. I would focus on recovery. Otherwise, you will just loose precious time.
I want to find the extent of the damage, the cause and prevent a re-occurrence.
Correct, I will focus only on prevention.
If your hosting provider doesn’t provide the feedback this was their fault, then this may be your fault.
Have you used the latest version of PHP?
Check out this URL and ensure that in 2016 — 207 security flaws were found in PHP.
http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74
PHP is getting there, but you need constantly to upgrade the version.
Have you used software auto upgrades?
But not only PHP, you need to create automatic updates for the whole web server. This is very important.
Occasionally, there are new vulnerabilities found for CentOS, or Ubuntu you are running. And I was a witness of some great problems, just because the OS was not up to date with security updates.
In Ubuntu you would do something like
sudo apt-get update
sudo unattended-upgrade
somewhere in cron job, or
unattended-upgrade --dry-run --debug
To test the upgrade.
If you like to make upgrades to work as a service, you may try
dpkg-reconfigure unattended-upgrades
You would generally need to do that if your hosting company is not doing this automatically. Please check.
Have you used file change detection ?
Part of the iThemes security plugin you already use is File change detection. This is very important to have set since all the security analytics mention this is a key feature. However, from there you will need to pay attention to files updated. It is important to keep the number of the folders low and to set not to be informed based on the extension of the files. Typically you don’t need to track images.
Did anyone found your log files ?
Log files should be prohibited in general via .htaccess. If you are in Nginx, then in Nginx config file. There are certain backup plugins that use wp-content to store the log files. Some of these do have weak naming convention and scouts may get your logs, with the information about your web server.
The extension of log files may not always be .log. It may be log.1 and like. Keep that in mind.
Can WP SCAN detect your passwords and users
Use WP SCAN tool and check if it can crack your passwords.
You may consider .htaccess rule to prevent WordPress username enumeration if you don’t have any side effects.
RewriteCond %{QUERY_STRING} author=d
RewriteRule ^ /? [L,R=301]
Are your gates wide open?
You may consider closing your mysql port if this is open.
PORT STATE SERVICE
3306/tcp open mysql
Some services such as mysql should not have open ports, like in the example above. You will need to search the web for the good for the good port scanner.
Also, your login form should have the login limit count, as well as your web server SSH and FTP channels.
The another gate is xmlrpc-php. If you don’t need that you may try to eliminate it, because this would be the place where someone may try to log in.
Have you had a firewall .htaccess ?
The sixth generation of the firewall from the perishable press is not in constraint with your .htaccess file at all. https://perishablepress.com/6g/
It includes empty bots, and bad bots removal. As I checked it should work without interfering with the existing .htaccess rules.
You should test this in low traffic time, or on the development server, and possible use all the tips from there. Should be easy, just copy and paste.
Have you used RIPS to test your plugins and themes?
This will allow you to scann plugins and themes from your http(s)://domain.com/rips/index.php
You can download it from here and extract it to the same level as WordPress:
Then check this out. Query Monitor plugin is perfect, but for the other one the tool found security problems.
I tested nextgen-gallery and query-monitor plugins. Look what I found.
There are sometimes false positives this tool may provide you, but in general, you will have the feedback.
So the final advice for you.
You don’t know if your MySQL database is clean. You should probably export all the articles using standard WordPress export and create the new one.
You should install new plugins and new theme. You may even start with the new clean VPS. On Linode this is just few clicks.
You should start with the new WordPress installation for sure..
Probably you may even change the hosting if you determine they are not reliable.
The hosting provider may provide you some feedback from your web server Logs if this is the part of the service, so you can understand what was the problem better.
Anyhow — step by step.
Also, please check my other answer I provided to @Rahul, it may be good for prevention.