DirtJumper Drive Shifts into a New Gear

The last time I wrote about Drive it was still following the old model of DirtJumper-variant phone-homes and all the communications were in plaintext. I recently discovered a new variant that diverges from the DirtJumper-variant phone home and adds a number of new attacks, including one that attempts to bypass some known mitigation techniques that it calls -smart and appears to be one of the first pieces of DDoS malware that attempts to detect mitigations being used and bypass them.


This version proved slightly more difficult to reverse than the first version with IDR not recognizing many of the standard Delphi library functions – possibly due to the Delphi version – when it was generating the IDC script to load into IDA Pro. Additionally, the first sample analyzed caused IDA Pro numerous problems, including failing to recognize local variables, but subsequent samples did not have those issues. Thankfully, BinDiff was useful when comparing against my IDB of the original version to identify both the Delphi library functions and all of my existing tagged global variables and previously reversed functions. Using that, the new command encoding became much easier to find. A yara rule to identify this version is below and is also in the ASERT Github repository:

rule dirtjumper_drive2
   $cmd1 = "-get" fullword
   $cmd2 = "-ip" fullword
   $cmd3 = "-ip2" fullword
   $cmd4 = "-post1" fullword
   $cmd5 = "-post2" fullword
   $cmd6 = "-udp" fullword
   $str1 = "login=[1000]&pass=[1000]&password=[50]&log=[50]&passwrd=[50]&user=[50]&username=[50]&vb_login_username=[50]&vb_login_md5password=[50]"
   $str2 = "-timeout" fullword
   $str3 = "-thread" fullword
   $str4 = " Local; ru) Presto/2.10.289 Version/"
   $str5 = "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT"
   $newver1 = "-icmp"
   $newver2 = "-byte"
   $newver3 = "-long"
   $newver4 = "<xmp>"
   4 of ($cmd*) and all of ($str*) and all of ($newver*)

Attack Command Structure Change

The old style of DirtJumper and Drive phone home was a simple POST request with a single parameter named k and was either 15 or 34 bytes long. This new version now renamed k to req and still uses a 15-byte bot identifier. Along with this change there is now another, different POST request that has been observer to both precede and follow the the request for targets from the server. This request sends a hard-coded string – newd=1 – as the POST  data and is returned what appear to be a list of backup URLs to use in the event that the main CnC server goes down.

The string encoding detailed in the previous post still holds for all strings except for the CnC information. Previously, the CnC host and URI were specified as separate strings, but they are now specified as a full URL that uses the same encoding method as the attack commands from the CnC. First, the information is XOR-encoded with a static key (in all samples seen so far, “okokokjjk” is the XOR key used) and then it is Base64-encoded. I did manage to waste a couple of hours reversing their slightly abnormal Base64 decoder to verify that it was indeed a standard Base64 decoder. Given that all the CnCs are specified in URL format and all of the URLs so far start with http://, it is possible to determine the first 7 bytes of the XOR key without running the sample or searching for the key. Once the sample is run, the rest of the XOR key can easily be found. An example function to decode messages sent from the CnC is below:

def decode_comms(message,key='okokokjjk'):
 message = base64.b64decode(message)
 decoded_message = ""
 for i in range(len(message)):
   decoded_message += chr(ord(message[i]) ^ ord(key[i % len(key)]))
 return decoded_message

An example response from a server might look something like:


where 0x28 is the length of the message and when decoded look like the same as the first version:

-smart hxxp://

New Attacks

The new variant has four new attacks: -icmp, -byte, -long, and -smart. Of these, the most interesting is the -smart attack which attempts to incorporate some DDoS mitigation bypass techniques and this is the first piece of DDoS malware that ASERT has seen that attempts to do this. The least interesting attack is the -icmp attack which sends a standard icmp echo request towards the target host.

There was also one new option added to the existing attacks in this version: a -cookie parameter where the attacker can choose to specify a specific or randomly generated cookie value with the attack.

Byte and Long

The byte attack looks to be a variant of the previously discussed -ip and -ip2 attacks where only one random lowercase alpha byte is sent before the socket is closed instead of the other payloads. It is not clear what the purpose of such an attack is as they have only been witnessed targeting port 80 and the existing IP attack allows for sending small payloads as well.

Drive2 Byte Attack ASM Code

Drive2 Byte Attack ASM Code

The -long attack is more interesting and as its name implies, attempts to keep a socket open for a long period of time while also sending a decent amount of data during that time. A random payload is generated, sent and then randomly sleeps for 2 to 6 seconds before executing the send up to 10240 times. It seems unlikely that this attack will succeed for the maximum time as most services will close a socket upon receiving malformed data defined by their service, but it is possible some may not and allow the attack to continue long enough to exhaust available connections.

Smart Attack

The smart attack has only been seen in one sample so far and has been observed when ordering attacks against sites. The attack sends an initial attack packet and then looks for either a Set-Cookie or a Location header and will parse out either the Cookie value or new URL location using those values in the next packet it sends. It will also look for a meta equiv refresh tag, location= or document.location.href inside of the response from the server in an attempt to defeat mitigations using those countermeasures as well.

This is one of, if not the, first pieces of DDoS malware that ASERT has seen actively attempt to defeat known mitigation techniques.

When parsing out the Set-Cookie header, there is a lot of convoluted calls to @LStrPos and @LStrLen as it searches for the relevant parts of the cookie value. Once all that is sorted, it will then store the cookie value in the global cookie array for the attack and that cookie value will be available to all subsequent requests sent to the server as part of the attack. The other parsing mechanisms perform similarly with respect to redirects – they store the new location in the global variable so the next time the attack is run it will target the proper path. It will also check for the existence of the mitigation options each time a request is sent. While this adds some overhead, it will also ensure that the attack packets have a high chance of getting through.

After parsing out the appropriate value to bypass, the attack will build a new HTTP request to send and also generate a new random User-Agent that will be used in the new attack. The assembly code for this can be seen below in Figure 2. There are some weaknesses in the implementation of the parsing sections of this attack that can be manipulated by an endpoint as well.

Drive2 Bypass Request Construction

Drive2 Bypass Request Construction


Just as the first version of Drive raised the bar for DirtJumper variants, this version looks to be raising the bar for DDoS malware in general with its purposeful attempts at bypassing mitigations with its new -smart attack.  We expect that this is just the first of many pieces of malware to attempt to incorporate these bypass techniques and also expect that Drive will continue to evolve and attempt to improve its techniques for such bypass attacks.

Related md5: fd94080ea9aa6e69f46f59b87a4fba88