I believe I finally got the upper hand on this attack. From what I’m reading on-line it was part of the drupalgeddon2 exploits. I didn’t upgrade to 7.59 fast enough. People are claiming you should scrap your sites and servers over this. Not willing to do that. You may not be able to clean this attack if you do not have WHM root access.

This hack is characterized by a few things:
1. Admin accounts you didn’t make showing up.
2. Roles you didn’t make showing up.
3. Malicious “ico” files showing up on the server with php code in them.
4. Random php files showing up across the site directories.
5. A lot of extra “index.php” file showing up across the site.
6. php and inc files that have been modified with obfuscated code.
7. Cross-site infections on a shared WHM. Infected files in the home/cpeasyapache directory.

Some are saying there are “back doors” made where the hackers are getting in. I highly doubted this after patching to 7.59 as the malicious admin accounts were not showing back up. What was happening is that the “ico” files were popping up every 5 – 10 hours, and these in turn were creating a bunch of random string php files and index.php files that pointed back to the ico file. This code seemed to be able to affect multiple sites sharing the same WHM.

Steps to fix the hack without trashing your sites:

Prep:
1. Backup your site and database, put site into maintenance mode.
2. Make sure you have SSH access to your WHM or Cpanel
3. Login to site and remove any malicious admin accounts.
4. Remove any roles you didn’t make.
5. From cpannel, using phpmyadmin, look at your database tables for users and roles, delete any tables you know shouldn’t be there. (user 0 is supposed to be there)
6. Change all database and user passwords.

Fix:
1. From SSH. run a query from the public_html folder like this:

find -name index.php

If you see a shitload of files come up on Drupal, you are hacked. There is only supposed to be 1 index.php.2. Delete ALL of the index.php files with this command:

find -name index.php -exec rm -rf {} \;

We will replace the main index.php file when we update to the newest Drupal.3. Search for icon files that don’t belong with this command:

find -name "*.ico"

If you see a bunch of strange icon files starting with a . and having a random string, they are php files. I just removed all icon files as I don’t give a shit about them with:

find -name "*.ico" -exec rm -rf {} \;

If you want to keep your icon files, just manually delete the suspicious ones with ftp.I’m reading that there were also files other than .ico that were associated with this hack. An easy to way to identify which extension they are using is to open up one of your hacked index.php files and copy this line of text:

@include "\057h\157m\145/\147l\145n\143c\057p\165b\154i\143_\150t\155l\057p\162o\146i\154e\163/\164e\163t\151n\147/\0564\0621\142e\071a\067.\151c\157";

Paste it here: Unphp.net

It will tell you which malicious file it is pointed at. Use that information to remove all of the files of that type using the SSH command above but for the malicious extension instead of .ico.

4. Find the other malicious php files that don’t belong. On my site, they were all php files with 8 a-z character names. Like dkelfesa.php or something. Use this regex to look for 8 character php files:

find . -type f | egrep './[a-z]{8}\.php'

Remove any you suspect are malicious. Typically the name wont make any sense. If you open them and see a punch of php code you cant read, they are malicious.5. After doing all of that, I was still getting hacked and couldn’t figure it out. I decided to open my database for the site in phpMyAdmin and run a search on all tables for:

<?php

to look for any malicious php code I had missed. It turns out that when the original hack happened the hacker had used the admin account to created a block called “Development”. He gave it no title, and in the body inserted his malicious php code. He then enabled this on the site. He could remotely call it and it would reinfect the site with the ico files, the index.php files, and the random string php files. Run a database search for the php tag above and look at all results for malicious code across your site in content nodes or blocks. Remove any code you can’t easily read.6. There were also quite a few php and inc files across the Drupal installation that had either been modified with malicious php at the top of the file, or just didn’t belong. They were cleverly named and stashed away into modules folders, library folders, everywhere. As I discovered them I created these grep patters to help others find them. Unfortunately I found 4 malicious files in the /home/cpeasyapache directory. These looked to have the ability to scan all sites on the shared host and infect them all. Use these searches at the WHM root level to look for malicious php and inc files. Remove or clean them.

find . -type f -name '*.php' | xargs grep -l " *=PHP_VERSION *" 
find . -type f -name '*.php' | xargs grep -l " *Phar::interceptFileFuncs() *"
find . -type f -name '*.php' | xargs grep -l " *@include *" 
find . -type f -name '*.php' | xargs grep -l " *interceptFileFuncs *"
find . -type f -name '*.php' | xargs grep -l " *eval *( *gzinflate *( *base64_decode *( *"
find . -type f -name '*.php' | xargs grep -l " *base64_decode *"
find . -type f -name '*.php' | xargs grep -l " *function *wscandir *"
find . -type f -name '*.php' | xargs grep -l " *HTTP/1.0 *404 *Not *Found *"
find . -type f -name '*.php' | xargs grep -l " *@gzuncompress *" 
find . -type f -name '*.php' | xargs grep -l " *Array *( *) *; *global *" 
find . -type f -name '*.php' | xargs grep -l " *@unserialize *"

If you don’t have access to your root, contact your host provider to have them scan it for the above patterns to remove the malicious files.

Here is an example of some malicious code found in a file in the /cpeasyapachy directory of the WHM root:

The full file had some functions that scanned the root, looked for inc and php files, changed folder permissions, and created the index.php files. There were 4 files in the cpeasyapache directory that looked similar to this:
Malicious.txt

Wrap up:
Once you have done this. Download the latest version of Drupal and copy it over to your site. This will replace the main index.php file and your site should be up and working again.

Install latest modules.

Run update.php

Lastly, check the file permission settings in the public_html folder. Directories should be set to 740 and files to 644. A quick way to do this is:
find . -type d -exec chmod 740 {} \;
find . -type f -exec chmod 644 {} \;

Once done, install the “Hacked” module to inspect your site for changes associated with this hack.

Other good modules are login security, and path2ban.

Clear all site caches and web browser history / caches.

Cheers