Tales from of a base64 WordPress Hack, part 4: dissection

posted in: Tech | 1

Got hit again, briefly. Was able to recover very quickly thanks to the Git repos I had set up previously. I found a couple extra backdoors, using some alternate obfuscation methods. Instead of the typical eval(base64_decode(... the attacker instead took an existing file, commented out all the code, and interwove a series of variable assignments.

I think it’s a good thing to know the enemy, and the more we know about both (a) what they are doing, (b) what they are CAPABLE of doing — the better we can both recover and detect / identify future attacks. I’ve decrypted their backdoor application and pasted it below (after the jump), with some commentary.

It looked like this:

Beast v2.0

Detection, in this case, was mainly due to poor hiding on the attacker’s part. They went for a very bland “index?.php” where ? was some random letter. The shellscript scan used in the previous post will not locate these files, however one could be modified, though it will be slightly more difficult.

Inter-woven backdoor method

I tamed the content by removing the eval() and echo’d it to the terminal instead. Here’s is what it showed; I’ve reformatted it to be more readable.

The main purpose of this backdoor, aside from making it appear as though the size of the attacker’s genitals are large enough to be viewed under a microscope, is to provide some basic filesystem operations. I’ve added in some commentary in each block.

As I expected, the backdoor can do basic stuff like create files and directories, and upload stuff too. I didn’t know that they could update the access times of the files, but like I said, they weren’t doing that much, it seems. Though I admit it’s possible they WERE doing it and I just wasn’t detecting it.

Anonymous Function backdoor

Another backdoor I discovered was a lot more ingenious. This one used hexcodes and ASCII character values to anonymize the true intent of the script — it then created an anonymous function, decoded the text, and ran the script via eval()

Here’s a sample of what it looked like in the beginning. I added comments and carriage returns — it was just one fat line beforehand.

What’s clever about this is what the decoded text looks like. Again, comments and carriage returns are my edits.

The XOR trick was pretty clever. It XORs each number against the key (143 here) and then converts the resulting number into its corresponding ASCII character by using the chr() method.

The end result is this script, pasted here in its entirety. This was pre-formatted — I have done nothing to it.

Note, in particular, the fact that this one can run PHP directly *and* has built-in functions for running MySQL queries directly on a database. That’s chillingly creepy.

Lastly, this appears to be the actual backdoor that the attacker would use to execute code against the backdoors found elsewhere, as it renders an HTML form with javascript-base64 decoding built-in.

The Injected Code Itself

Last but not least is the code that the backdoor actually injects at the beginning of ALL OF YOUR PHP FILES in a given location. It’s the bit that has eval(base64_decode(...)). Here it is, with carriage returns added.

And there you have it.

One Response

  1. […] tales from a base64 wordpress hack part 4 dissection […]

Leave a Reply