Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I recently had all of my WordPress accounts on my server hacked. The only suspicious files I found are listed below. These were the only files edited in the last 5 days (June 3, to be specific).

Suspicious files found:

  • /host.txt - This file only had the wordpress installed domain name in text (e.g.: example.com)

  • /wp-admin/includes/class-wp-style-table.php - This is a nasty one. See sample of the code in this pastebin.

How can I detect where these files came from to prevent them from being regenerated? I searched Google, and there are 0 hits for this file name. Is this a new WP attack?

UPDATE I found an exact replica of the malicious file in a Joomla install called "mod_googleapi.php". I think this is the source of my breach. It's a dated install of Joomla that must have some leaky extensions/plugins.

share|improve this question

closed as too localized by Rook, Adnan, Scott Pack, NULLZ, tylerl Jun 9 '13 at 6:39

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Seems to be same as this -news.nucleusdevelopment.com/2013/03/14/… –  user93353 Jun 7 '13 at 23:45
    
    
I'm curious how come you didn't find any results for this filename on Google? It's part of the WordPress installation and the original and intended version of it is published on GitHub. Anyway, the contents that you're posting (I've removed your image with the link to pastebin) and the contents of the original file are obviously quite substantially different, but the one you're posting looks rather strange for a backdoor (not saying that it isn't), as it's even got an easy to use control interface. –  TildalWave Jun 7 '13 at 23:47
    
you're looking at "class-wp-list-table.php" no "class-wp-style-table.php". the style-table.php is not standard code. it is completely malicious. –  theLucre Jun 8 '13 at 0:08
1  
@TildalWave I think it's too-localized in that the core question is "what happened in this particular instance". What's in this shell that you don't find in r57, c99, et.al.? –  tylerl Jun 9 '13 at 6:43

1 Answer 1

up vote 5 down vote accepted

Your server was infected with a PHP backdoor trojan that goes by these names:

a-squared: Backdoor.PHP.Shell!IK
AVAST!: VBS:Malware-gen
AVG: PHP/BackDoor
BitDefender: Trojan.Php.Backdoor.APF
ClamAV: PHP.Shell-38
Dr.Web: PHP.Shell.26
F-Secure: Trojan.Php.Backdoor.APF [Aquarius]
GData: Trojan.Php.Backdoor.APF [Engine:A]
Ikarus: Backdoor.PHP.Shell
Kaspersky: Backdoor.PHP.PhpShell.dd
Microsoft: Backdoor:PHP/Shell.G
NOD32: PHP/WebShell.NAH trojan
nProtect: Trojan.Php.Backdoor.APF

It is currently detected by roughly 38% of AV scanners that VirSCAN.org tracks. The way to test your AV for this exploit is simply by opening this pastebin and trying to download it as a file. Your AV should detect it, notify you of malware under one of those names from above, and deny download. If it's not detected, simply delete the downloaded file. Your system won't be infected, unless you run it through a PHP interpreter on your web server.

I've been reading the exploit's code, and frankly, it's pretty scary stuff and one of the most complete shells I've ever seen. Here are a few things it can do:

  • Read, Edit, Overwrite any file the web application process it runs in will have access to.
  • Extract from, Compress to ZIP and TAR archives (can inject itself into existing archives)
  • Brute-force FTP, MySQL, PostgreSQL access using web server's own CPU
  • Scripted interface for easy remote C&C shell control
  • POST requests for everything to hide from simpler WAF and avoid detection by web server rules
  • Complete Database Control including SQL shorthands for most common injections
  • Automated password and shadow file extraction for offline password extraction/cracking
  • File System Access Control including rewriting access permissions on files, directories
  • Enable / Disable reporting services to avoid detection through log files
  • Self-Destruction Mechanism to perform cleanup after other backdoors are installed
  • Password and cookie token protected to prevent easy sandboxed inspection of its functions (albeit the protection scheme is pretty weak, see my comment to the question)
  • e.t.c.

Presume all your data, file system, operating system, everything infected and other backdoors installed to them. Presume all your passwords stolen, password and shadow files packed and downloaded. This is not a joke!

                               Sometimes, all you can do is...

           Nuke It From orbit!

                               It's the only way to be sure.

So what can you do? Like the image suggests, nuke it from orbit. Start from a clean slate and restore from a known good offline backup, before this exploit happened:

  • Format the drive and reinstall OS, any other software you'll need, keep them updated
  • Assume all your installation files infected / out of date and download latest versions
  • Rethink what software packages you really need, and how you could harden remote access
  • If you don't have it yet, install a SSL certificate on your web server, use encrypted access protocols on everything
  • Reassess firewall rules, deny traffic on all ports you won't be using, inbound and outbound
  • Install a good antivirus software and update its virus definitions regularly both on your server and on all clients that you'll be accessing your server from, enable heuristic scanning, regularly perform full system scan
  • Never access your web server remotely from an untrusted location and/or unsecured connection like public access points for administration purposes
  • Secure access to your CMS/panel software folders, files, URLs, password protect everything
  • Assume all your passwords stolen, including passwords of any users of your online services
  • Restore from an offline backup from before the date of the infection
  • Inspect all restored from backup files and database records for injections, trojans, backdoors,...
  • Write support code in your online services to demand password change for all your users and deny access before they do
  • Notify all your users their passwords might have been compromised and they ought to change their passwords for any other third-party services they might use them for too
  • Run each domain on your server from a separate VM and assign as limiting privileges to their processes as you can live with, lock files and database access permissions
  • Hire an IT security consultant to assess vulnerability of your server and services it's running, act according to consultant's recommendation
  • Assume I've forgotten to include something in this list, and find more information and recommendations to a similar scenario on this and other websites that you trust

Best of luck!

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.