Analysis of HTTP-posted PHP malware

Recently we experienced a surge in compromised web sites, mostly by means of vulnerable Joomla and WordPress components. We are constantly researching methods of protecting our customers sites without affecting their codebase* and have mitigated many attack waves. However, this new challenge requires a new protection strategy. 

A common denominator of these recent exploits is the upload of PHP malware on the compromised sites. Comparing the creation times of these files with suspicious POST requests leads to the hypothesis that these files are uploaded through HTTP. However, we don’t log HTTP POST data. But to collect evidence, we have activated logging of all HTTP file uploads over the past two days. Out of these uploads, we have automatically filtered all files that contain PHP code. 

  • In two days, our filter found 1631 uploaded PHP files.
  • Nearly 80% was disguised as GIF files (using a binary GIF header to delude MIME magic detection). 
  • 75% contains eval(), preg_replace(), base64_decode() and gzinflate() to execute arbitrary and/or obfuscated code
  • 28% contained code to enable further arbitrary file uploads
  • And 99.8% contained code that would hand over control of the affected site

The creativity of these attackers to evade detection is admirable. Let me show you some particular “clever” examples.

The first one is a basic single-level obfuscation. It can be decoded using the excellent PHP Obfuscation Decoder

And some more sophisticated examples, that try to mask their malicious intent by multiple levels of encoding and obfuscation.

How clever they may be, these examples show only three basic methods to execute arbitrary code, namely:

  1. eval()
  2. preg_replace() with the /e execution modifier
  3. PHP code that allows uploading other PHP files through HTTP

However, filtering for these functions isn’t enough, as this last example will show us:

In the coming week, we’ll closely monitor the ratio of malware / legitimate PHP file uploads. If the amount of false positives stays below 0.5%, we’ll most likely block all code uploads through HTTP. 


* We pursue a policy of actively scanning for vulnerable code and notifying customers upon detection. However, we do not force customers to upgrade said code, nor do we patch this code ourselves, as such intervening would blur the line of responsibility. Apart from severe circumstances, such as 0-day exploits that would likely compromise 100+ customers within 24 hours.