Republished Malware Analysis Blog Posts From March 2018

Hiding Malicious Code in Compromised Databases

Malicious code is often stored in compromised databases, and referenced later for execution. This is a common method by which potentially dangerous PHP functions such as eval(); are hidden from automated and manual file contents searches.

An example of one implementation of this can be seen here:

global $wpdb;
"SELECT option_value FROM $wpdb->options WHERE option_name='rss_f541b3abd05e7962fcab37737f40fad8'");
preg_match("!events or a cale\"\;s\:7\:\'(.*?)\'!is",$trp_rss,$trp_m);

In this example, a value is retrieved from a compromised WordPress database. The value is reversed back to front using PHP’s strrev(); function. A new function is then created from the resulting value, and executed.

Lost? The value being retrieved from the database will help clear things up:


Still lost? Remember, PHP’s strrev(); (string reverse) function is being applied to this string prior to its execution. Let’s see what it looks like reversed….


And there it is! We have our malicious code, neatly hidden from automated and manual searches within the confines of a compromised WordPress database.

Not only that, but the potentially dangerous PHP functions we may be searching for (eval(); and base64_decode();) are stored in reverse, making them that much more difficult to locate.

Final Thoughts:

The storage of malicious code in a compromised database for later execution can be accomplished without using the strrev(); trick to hide the presence of eval(); and other such functions from searches – that just happens to be a method that this particular attacker happened to employ in this case.

This particular example is a very good illustration of why database audits are important when a site and its related databases are compromised and known-clean backups do not exist.

Malware Research

Original Research and Blog Posts by Sky Larsen