In previous articles on Reverse Engineering PHP security exploits I’ve explored malicious PHP and even associated Javascript code by reverse engineering the files left behind. While most of these exploits have fallen into the following general categories:

  1. Downloaders with a simple execution mechanism.
  2. Command shells with file explorers.
  3. Embedded websites redirecting users to alternative content.
  4. Application specific tool sets.

Few have integrated themselves into an application and attempted to remain resident. Most are standalone and small, and in a recent trend rather than a single exploited file, several variants are deposited around the file system of the infected Container allowing the malicious user to have several entry points should one exploit be discovered and removed.

That was until we recently discovered a growing trend in malicious penetrations where code is now embedding itself with the application. This requires knowledge of the internal architecture and workings of the application and allows potentially multiple entry points to the code. If you are lucky to find the file, finding the entry points becomes an issue as removing the exploit has resulted in a crashed application.

Fortunately, PHP like a lot of modern Just In Time Compiled programming languages provides the ability to generate a backtrack. Often the back trace is seen on screen after a crash however it can be written to the HTTPD error_log.

Here is an edited sample from the live infected site, the start of the error_log lines has been removed to show just the message text:

#0  require() called at [/sample/localconf.php:2]
#1  require(/sample/localconf.php) called at [/sample/config_default.php:711]
#2  require(/sample/config_default.php) called at [/sample/index_ts.php:128]
#3  require(/sample/index_ts.php) called at [/sample/index.php:78]

Its certainly not an in depth penetration, but it does not need to be, a single load of the site activates the exploited file (called main.php in this exploit) in which I have placed the back trace code. Here is what that code looks like:


In this example, the localconf.php file has called the exploit using a “require()” statement to include the exploit code. So all we need to do is remove this line and retest to make sure the call is not present elsewhere.

Printing a backtrace in any file can help to both debug the running application as well as see what hooks into a file. This allows safe removal of the exploit and hooks.

If the exploit code contained  methods then the method call names can also be found using this method. The file itself needs to be included in some way using either include() or require() so removal of just these lines would still crash the application but the method names would then be even easier to find as the error_log file will record the calling file and method name(s) for you!