The Latest in IT Security

This blog post is the fifth installment in our ongoing series of articles surveying the crypto systems used by different DDoS-capable malware families. Today’s topic is MP-DDoser, also known as “IP-Killer”

As far as we are aware, MP-DDoser was first documented in February 2012 by Arbor analyst Curt Wilson in his pioneering survey of modern DDoS threats. Like many of the malware families we see these days, MP-DDoser is exclusively a DDoS bot; it has no ability to do key-logging, info-stealing, spamming, or other such mayhem. We started seeing the first MP-DDoser samples back in December 2011, which billed themselves as “Version 1.0″. These early versions had a number of serious flaws, such as a completely broken Slowloris attack implementation, and really awful crypto key management. But the latest samples (now up to “Version 1.6″) are much improved; the key management is quite good, and the buggy DDoS attacks are not only fixed, but now include at least one technique (“Apache Killer”) that may be considered reasonably cutting edge.

The full details of our analysis are included in the attached report, but here are the highlights:

In addition to a Slowloris-style attack and various generic flooding capabilities, the newest versions of MP-DDoser support an ApacheKiller-style attack, which is a relatively new (and sophisticated) low-bandwidth technique for inflicting denial-of-service attacks against Apache web servers. It first appeared in the form of a proof-of-concept Perl script in August 2011. Then toward the end of 2011 we saw a version of it incorporated into the Armageddon DDoS bot; however that implementation turned out to be severely flawed. Now, we are seeing it show up in MP-DDoser – and a review of the bot’s assembly code indicates that it does indeed appear to be a fully functional, working implementation of the Apache Killer attack.
The core of the attack involves the sending of a very long Range HTTP header that is intended to bring web servers (especially Apache) to their knees by forcing them to do a great deal of server-side work in response to a comparatively small request. It is therefore one of the more effective low-bandwidth, “asymmetrical” HTTP attacks at the moment.

The complete MP-DDoser command code vocabulary is as follows:

Besides being armed with some potent DDoS weaponry, MP-DDoser is also interesting because of the multiple layers of encryption it uses for key management in order to secure its network communications. Again, the full details are provided in the attached report, but the high-level summary is as follows:

The malware actually uses a pretty straightforward algorithm for encrypting and decrypting the transmissions sent between bot and C&C server. It modulates the plaintext message with a key string using the XOR operator, but it applies this XOR operation only to the least significant 4 bits of each message byte. The following Python snippet replicates MP-DDoser’s network crypting functionality:

def decrypt_mpddos_comms(msg_text, key_text):
    key_bytes = [ord(key_byte) for key_byte in key_text]
     msg_bytes = [ord(msg_byte) for msg_byte in msg_text]
     len_key = len(key_bytes)
     return ''.join([chr((msg_byte & 0xf0) + \
                    ((msg_byte & 0x0f) ^ (key_bytes[k % len_key] & 0x0f))) \
                    for k, msg_byte in enumerate(msg_bytes)])

The tricky part is finding the key string! In earlier versions of MP-DDoser, circa late 2011, this key string was simply hard-coded into the bot executable in plain text. But since then, MP-DDoser has improved rapidly on the key management front. Now the key string itself is encrypted and stored in an RCDATA resource named MP, along with some other sensitive information such as the hostname and port of the C&C, the botnet ID, etc.:

Furthermore, the algorithm used for decrypting this resource is string is different from the aforementioned algo used for crypting the actual communications. The resource decryption mechanism appears to be a “home brew” algorithm. The details are in the report, but the algorithm can be summarized by the following Python snippet:

def decrypt_mpddos_rsrc(rsrc_crypt, plain_lut):
    accum_A = accum_B = 0
    plain_rsrc = []
    for rsrc_byte in rsrc_crypt:
        next_byte = plain_lut.index(rsrc_byte)
        accum_B = next_byte + (accum_B << 6) accum_A += 6
        if accum_A >= 8:
            accum_A -= 8
            plain_rsrc += [(accum_B >> accum_A)]
            accum_B %= (1 << accum_A)
    return ''.join([chr(dstbyte) for dstbyte in plain_rsrc])

To decrypt the MP resource string, the bot uses a lookup table (“LUT”) that maps ASCII characters to integers for the initial phase of the decryption loop. But even this lookup table is itself encrypted! Fortunately, it is encrypted using the same algorithm used for crypting the network comms, and thus the aforementioned decrypt_mpddos_comms() Python function will handle it. And mercifully, the key string need to decrypt the LUT happens to be stored in plain text in the bot executable. In all the samples that we’ve encountered to date, that key string is: 00FF00FF00FF, but that could easily change in the future.

So in order to decrypt MP-DDos transmissions, one needs to:

1. Decrypt the LUT using decrypt_mpddos_comms();
2. Then use the LUT to decrypt the MP resource via decrypt_mpddos_rsrc();
3. Then pull the comms key from the plain text resource and provide it to decrypt_mpddos_comms() to decrypt the actual network traffic.

The attached diagram illustrates the process:

On top of all that, the bot binary itself is doubly packed using UPX followed by a .Net-based crypter. The author of MP-DDoser has clearly spent some time trying to beef up operational security.

We have put all the pieces together into an “auto-ripper” tool that tears apart a memory dump of each MP-DDoser bot we encounter and extracts the three ingredients needed for traffic decryption (highlighted by yellow ovals in the above diagram) for use in our botnet monitoring operations. Once decrypted, the sensitive MP resource ends up being a pipe-delimited string containing C&C host, C&C port, network comms key, installation mutex, installation filename, botnet ID, etc. For example:

tgm991.no-ip.info|3030|ipkillerpassword|IPK-MPMutex|-1|Not Available|
Windefender.exe|Windefender|IPK-Victim|0|

And here are some representative samples of the comms keys and botnet IDs for various MP-DDoser botnets we’ve seen (all of these C&Cs are currently deceased at the time of writing):

Applying this information to live MP-DDoser traffic yields transmissions formatted as follows (with some information modified to protect the parameters of our sandbox machines of course):

 Encrypted Bot Phone Home Transmission:
 0x0000 48 47 7e 41 67 65 60 75 68 77 49 3c 2f 33 75 4d   HG~Age`u hwIq Vlg`mrq#
 0x0030 59 50 24 7b 31 3b 7d                              YP${1;}

 Decrypted Transmission:
 AC|[email protected]|Idle...|Hawkeye@Mash4077|Windows XP x86|

The AC stands for “Add Client”; Default corresponds to the botnet ID, and 1.6 is the MP-DDoser version. The remainder of the phone home message contains the usual information, such as bot status (Idle), and username, computer name, and operating system of the infected machine.

All in all, MP-DDoser uses some of the better key management we have seen. But of course, at the end of the day, every bot has to contain – or be able to generate – its own key string in order to communicate with its C&C, so no matter how many layers of encryption our adversary piles on, they can always be peeled off one by one.

The complete reverse engineering report for this version of MP-DDoser is available here

To summarize, the MP-DDoser code base is clearly being actively developed, and is improving rapidly on both the attack/flooding capability and network crypto fronts. We will keep monitoring this evolving DDoS threat in order to stay one step ahead of it – and use the intel we gather to continue defending our customers.