DirtJumper’s DDoS Engine Gets a Tune-Up with new “Drive” Variant

By: Jason Jones -

Over the last few months ASERT has been tracking what appears to be a new variant in the DirtJumper family (for more information on the history of the DirtJumper family see our previous posts [ 1 ] [ 2 ] [ 3 ] ) – that we have dubbed “Drive.” Drive is written in Delphi and sports a new and much more powerful DDoS engine than its predecessors. It has also changed the format of attack commands and added some new features to those commands. In addition to the new engine, a few CnCs have also been observed serving up Gzip-compressed data and at least one has exhibited blocking based on geographic location. The “Drive” name comes from multiple URI paths being named or containing /drv/ or /drive/ and a few CnC hostnames containing the word “drive”. This new variant does not seem to have made it to the “mainstream” underground forums yet with only a total of 15 unique CnC hostnames being observed so far.

Drive Revs its Supercharged Engine

Drive sports 2 POST floods, a GET flood, 2 connection + data floods and a UDP flood – although the UDP flood was not seen in all instances. It also has the ability to specify a post query string of random data to add additional stress to a server in the cases where login pages, search pages, etc. are targeted.

It also sports a new string encryption algorithm that is very similar to the Khan algorithm that Jeff Edwards wrote about in 2012 [ 4 ] . A representation of the assembly code for the algorithm is shown in Python below. This algorithm could be made more efficient, but is presented as-is to represent exactly what Drive does:

def decrypt_drive(crypted):
    ebx = 1
    edi = 1
    esi = 1
    decrypted = ""
    while len(decrypted) < len(crypted):
        if esi == 2:
            tmp_chr = ord(crypted[edi-1])
            tmp_chr += ebx + 1
            decrypted += chr(tmp_chr)
            tmp_chr = ord(crypted[edi-1])
            tmp_chr -= (ebx + 1)
            decrypted += chr(tmp_chr)
        if ebx == 1:
            ebx = 2
        elif ebx == 2:
            ebx = 3
            ebx = 1
        esi -= 1
        if esi == 0:
            esi = 2
            esi = 1
        edi += 1
    return decrypted[::-1]

Any “sensitive” data – cnc host, cnc port, cnc URI, install name, ini name – is encrypted with this algorithm.

The phone homes retain the k= POST parameter, but unlike DirtJumper v5 and Khan the length of the value is 15-bytes instead of 32. A randomly generated User-Agent following the format described in the attacks section below is also included.

New Turn-by-Turn Attack Directions

Attacks are no longer specified by 3 pipe-delimited integers and then targets, they are

now specified using an attack command – any of -get, -post1, -post2, -ip, -ip2, -udp – that is mapped to a corresponding integer that is referenced everywhere else it is needed. The assembly code for this is shown in Figure 1. Other options for the command are -timeout to specify a timeout, -thread to specify the number of threads to launch (defaults to 30), and -request – only used in the POST attacks. Once the attack_code is set, the code will branch based on the value – if it’s greater than or equal to 3, then it will branch to a section of code that handles the -ip, -ip2, and -udp attacks, otherwise it will branch to a section to handle the HTTP attacks.

Figure 1: Attack Command Parsing

Figure 1: Attack Command Parsing

In the parsing of the HTTP attacks, it will parse the hostname out from the URL – first checking for http:// or https:// and perform a gethostbyname call to obtain the IP address of the target. It will also look for any “:” and parse out the targeted port as well. While the code searches for https://, we have not seen any copies of Drive that have an embedded SSL library to actually support an attack over HTTPS and it uses socket / send / recv  to establish a connection and send data to add more evidence to a lack of SSL support.

Parsing for non-HTTP attacks is slightly different – an IP and port combination are expected. A small number of example commands are shown below:

-ip <ip address>:<port> -timeout 0 thread 999

-get hxxp://<target>/ -timeout 3000 -thread 1

-post1 hxxp://<target>/<uri> -timeout 0 -request username=[5]&password=[5]&submit=Submit -thread 150

-udp <target>:<port> -timeout 0 -thread 80

Upgrading the DDoS HorsePower

HTTP Floods

The HTTP-based attacks randomly select one of three User-Agents and then randomly generate values for each one – including version number and patch-level and also randomly chooses whether to include the WOW64 string to indicate a 64-bit Windows system. Regular expressions that represent the 3 possible User-Agents are displayed below:

Mozilla/5.0 (Windows NT [56].1; WOW64; rv: [9-17].0 Gecko/20100101 Firefox/[9-17].0

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT [56].1; WOW64; ; Trident/4.0; SLCC2; .NET CLR 2.0.[0-9]{6}; .NET CLR 3.5.[0-9]{6}; .NET CLR 3.0.[0-9]{6}

Opera/9.80 (Windows NT [56].1; WOW64; U; Edition <Random country>  Local; ru) Presto/2.10.289 Version/[5-12].0[0-9]

The Referer field also contains a randomly generated value between 5 and 14 characters that is concatenated with a randomly selected TLD to form the full URL. Previous versions / variants of DirtJumper used a hard-coded User-Agent string, so the switch to a more dynamic set of User-Agents that more closely resemble legitimate browsers make for harder fingerprinting. Closer inspection by the reader will show that there do exist some anomalies that would not exist in a real-world browser.
The two POST attacks differ slightly – one appears to target just making sure the server has processed the POST request and closes the connection after it received the first 1024 bytes, while the other attack waits until the response has been completely received before closing the connection. In addition to the random User-Agent string, the POST attacks also contain the above mentioned ability to randomize their POST data. The default clearly targets login forms, but others have been observed targeting search pages and user profile pages. The integer value between the brackets represents how long of a random string to generate. Hard-coded values are also allowed in POST data. 


IP Floods

The two IP attacks – -ip and -ip2 – are both connection style flood attacks that also include more randomly generated data that is sent to the target. These attacks have been seen targeting HTTPS, SSH, MySQL to name a few. An interesting tidbit with these attacks is that they will only operate on an IP address – if a hostname is sent it will fail as no calls to gethostbyname are made to retrieve the IP address to open a socket to. One attack will allocate a buffer of 1460 bytes, memset to set all bytes in the buffer to null and then memcpy the randomly generated data into it and send the full 1460 byte buffer. The random data consists of 2 15-byte strings concatenated together with a space separating them. The other attack only sends the random data. This set of attacks seems to attempt to get around general connection flood protections that only classify floods based on no sending of data, but is not difficult to protect against – especially in the case of targeting SSL-encrypted services where it will lack a proper SSL handshake.

UDP Flood

The UDP flood is a pretty standard UDP flood with the port specified by the attacker and more random data sent to the target. This attack has only been seen a handful of times from the CnCs that have been monitored.


Under the Hood of a few CnCs

Drive has certainly been ambitious with its targets – targeting a popular online retailer, search engine, a popular security news site and some foreign financial institutions for a number of hours – but with some attacks being successful and some not. Using the excellent – and free –  OpenDNS Security Graph, we have been able to obtain a rough low-end estimate on the number of infected hosts – with the caveat that an unknown number may be from others monitoring the same CnC or dynamically analyzing a piece of malware attempting to connect to the CnC. The graph shown below is a snapshot taken during a successful attack and shows a peak of around 1,000 queries during the attack.

This particular CnC was co-hosted with a BetaBot CnC and a BitCoin mining harvestor and all 3 were dropped by a Smoke Loader.

OpenDNS Security Graph for www.mogains.com

OpenDNS Security Graph for www.mogains.com

The CnC located at kers2.com was the first CnC that we observed hosting Drive, but we found that it was difficult to monitor for a number of months. Later we discovered that it was blocking connections based on geographic location and switching where we routed through allowed us to determine what it was targeting. This CnC was seen targeting foreign financial institutions and has recently appeared to go offline again, but it is possible that it once again shifted its allowed victims to a different geography. This CnC was online for at least 3 months, which is one of the longest-lived DirtJumper family lifetimes that we have seen recently. With queries peaking above 2000 and mostly averaged above 1500, it represented a significant threat when it was active.

OpenDNS Security Graph for kers2.com

OpenDNS Security Graph for kers2.com


Drive is an up-and-coming threat on the ASERT radar and something we will continue to monitor closely in the coming months as it continues to spread and attack new targets. The attacks we have witnessed have proved to be more potent than other variants and we have even seen CnCs name over 60 targets at once for extended periods of time.



[ 1/asert/2011/08/dirt-jumper-caught/

[ 2/asert/2012/04/a-ddos-family-affair-dirt-jumper-bot-family-continues-to-evolve/

[ 3/asert/2012/05/dirt-jumper-ddos-bot-increasingly-popular/

[ 4/asert/2012/03/kahn/

Lessons learned from the U.S. financial services DDoS attacks

By: Arbor Networks -

By Dan Holden and Curt Wilson of Arbor’s Security Engineering & Response Team (ASERT)

During the months of September and October we witnessed targeted and very serious DDoS attacks against U.S. based financial institutions. They were very much premeditated, focused, advertised before the fact, and executed to the letter.

In the case of the September 2012 DDoS attack series, many compromised PHP Web applications were used as bots in the attacks. Additionally, many WordPress sites, often using the out-of-date TimThumb plugin, were being compromised around the same time. Joomla and other PHP-based applications were also compromised. Unmaintained sites running out-of-date extensions are easy targets and the attackers took full advantage of this to upload various PHP webshells which were then used to further deploy attack tools. Attackers connect to the compromised webservers hosting the tools directly or through intermediate servers/proxies/scripts and issue attack commands. In the September 2012 attacks there were several PHP based tools used, the most prominent of which was “Brobot” along with two other tools, KamiKaze and AMOS which were used a bit less often.  Brobot has also been referred to as “itsoknoproblembro”.

The attack tactics observered were a mix of application layer attacks on HTTP, HTTPS and DNS with volumetric attack traffic on a variety of TCP, UDP, ICMP and other IP protocols. The other obvious and uncommon factor at play was the launch of simultaneous attacks, at high bandwidth, to multiple companies in the same vertical.

On December 10, 2012 the group claiming responsibility for the prior attacks, the Izz ad-Din al-Qassam Cyber Fighters announced “Phase 2 Operation Ababil”.  A new wave of attacks were announced on their Pastebin page:  which described their targets as follows:

“Continually, the goals under attacks of this week are including: U.S. Bancorp, JPMorgan Chase&co, Bank of America, PNC Financial Services Group, SunTrust Banks, Inc.”

On December 11, 2012, attacks on several of these victims were observed. Some attacks looked similar in construction to Brobot v1, however there is a newly crafted DNS packet attack and a few other attack changes in Brobot v2.

These attacks have shown why DDoS continues to be such a popular and effective attack vector. Yes, DDoS can take the form of very large attacks. In fact, some of this week’s attacks have been as large as 60Gbps. What makes these attacks so significant is not their size, but the fact that the attacks are quite focused, part of an ongoing campaign, and like most DDoS attacks quite public. These attacks utilize multiple targets, from network infrastructure to Web applications.

Lessons Learned

While there has been much speculation about who is behind these attacks, our focus is less on the who or why, but how we can successfully defend. There are multiple lessons to be learned from these attacks, by everyone involved – the targeted enterprises, their managed security providers, Website and Web application administrators, and the vendor community.

For enterprises, it is clear that typical perimeter defenses such as firewalls and IPS are not effective when dealing with DDoS attacks, as each technology inline to the target is actually a potential bottleneck. These devices can be an important part of a layered defense strategy but they were built for problems far different than today’s complex DDoS threat. Given the complexity of today’s threat landscape, and the nature of application layer attacks, it is increasingly clear that enterprises need better visibility and control over their networks which require a purpose built, on-premise DDoS mitigation solution. This could sound self-serving, however, visibility into a DDoS attack needs to be far better than the first report of your Website or critical business asset going down. Without real-time knowledge of the attack, defense and recovery becomes increasingly difficult.

For providers of managed security services, they have begun to evaluate their deployments and mitigation capacity. These attacks were unique in that they targeted multiple organizations within the same vertical, putting a strain on the capacity of provider’s cloud-based mitigation services.

What these attacks have continued to demonstrate is that DDoS will continue to be a popular and increasingly complex attack vector. DDoS is no longer simply a network issue, but is increasingly a feature or additional aspect of other threats. The motivation of modern attackers can be singular, but the threat landscape continues to become more complex and mixes various threats to increase the likelihood of success. There have certainly been cases where the MSSP was successful at mitigating against an attack but the target Website still went down due to  corruption of the underlying application and data. In order to defend networks today, enterprises need to deploy DDoS security in multiple layers, from the perimeter of their network to the provider cloud, and ensure that on-premise equipment can work in harmony with provider networks for effective and robust attack mitigation.


ATLAS October Snapshot

By: Arbor Networks -

DDoS attack size continues to rise with average attacks hitting the 1.67 Gbps range, a rise of 72% year-over-year. This data comes from ATLAS, is an innovative partnership with our customers who share traffic data with us on an anonymous basis. It’s through ATLAS that we’re able to deliver unparalleled visibility into the backbone networks that form the Internet’s core. This data gives Arbor a globally scoped view of the Internet threat landscape.

DDoS attacks targeting traditional telecom systems

By: cwilson -

DDoS affects many types of systems. Some have used the term TDoS to refer to DDoS or DoS attacks on telecommunications systems (Telecommunications Denial of Service).  This is just another application for a DDoS attack, and was mentioned in 2010 by law enforcement and since discussed on a variety of blogs. Typical motives can be anything from revenge, extortion, political/ideological, and distraction from a larger set of financial crimes.  Just as we’ve seen the Dirt Jumper bot used to create distractions by launching DDoS attacks upon financial institutions and financial infrastructure at the same time that fraud is taking place (with the Zeus Trojan, or other banking malware or other attack technique), DDoS aimed at telecommunications is being used to create distractions that allows other crimes to go unnoticed for a longer period.

Recently, ASERT came across a few advertisements for traditional DDoS services that also included phone attack services starting at $20 per day. Screenshot (translated from Russian):


The original advertisement was posted around the end of 2011. On June 27 2012 the DDoS service provider placed another advertisement focusing only on the telephone flooding capabilities:

Another DDoS provider has advertised this at $30 per hour:

And a third provider also advertising such attacks charges $5 per hour, $20 for 10 hours, and $40 per day (roughly translated from Russian).

When discussing a recent ideological telecommunications-based DDoS attack upon a law enforcement entity around April of 2012, the attackers revealed some details about their approach. In that case, their attack script was based around Asterisk and put to use on a compromised server.

ASERT has helped mitigate SIP flooding attacks on several occasions. Often, SIP flooding attacks take place because attackers are running brute-force password guessing scripts that overwhelm the processing capabilities of the SIP device, but we have also seen pure flooding attacks on SIP servers. Once the attackers obtain credentials into a VoIP or other PBX system, that system can become a pawn in their money-making scheme to perform DoS, Vishing, or other types of attacks. Default credentials are one of the security weaknesses that the attackers leverage to gain access to the VoIP/PBX systems, so organizations should ensure that their telecommunications systems credentials are strong enough to resist brute force attack, and that the ability to reach the telephone system is limited as much as possible in order to reduce the attack surface and convince the attacker to move on to the next victim.

In other instances, I have seen telephone systems connected to the Internet that were very brittle – even a simple port scan could bring them to their knees quickly. In such cases, an attacker could bring down an organizations phone system quickly if they were able to reach the controller. The benefits of proactive security testing can help identify such brittle systems ahead of time, before an attacker might latch onto the vulnerability.

Any system is subject to availability attacks at any point where an application layer or other processor-intensive operation exists as well as the networks that supply these systems via link saturation and state-table exhaustion. Telecommunications systems are no exception to this principle, as we have seen. Clearly, there is money to be made in the underground economy or these services would not be advertised.

Thanks to Roland Dobbins of Arbor ASERT for operational insight.




Dirt Jumper DDoS Bot Increasingly Popular

By: Jose -

We’ve profiled the Dirt Jumper DDoS bot before and shown its evolution over the years. We then took this analysis into our zoo to see which DDoS bot families are growing in popularity with attackers. The marketplace has opened up significantly (see Curt’s excellent overview of DDoS tools and services) in recent years, and with that comes competition.

In the past few years, the popular kit we saw in our zoo was Black Energy, an easy to use, powerful DDoS bot distributed in Russian-language spheres. You could find it on the net for anywhere from $40 to free, depending on how hard you looked. Starting in 2009, Black Energy version 2 was available. It boasted a modular architecture and included banking theft Trojan functionality to augment the DDoS functionality. Another competitor that appeared in this timeframe was Optima or Darkness. It then becomes interesting to look in one’s zoo to see which families are popular at present.

The graphic below is from some quick analysis of our zoo, looking at our automated classification system that tags samples with the appropriate family name. Optima includes the group of Darkness, Optima and Votwup samples we have seen; Black Energy focuses on the BEv1 samples we have seen in the wild, and omits any BEv2 samples we have; Dirt Jumper includes all Russkill variants and Dirt Jumper variants we have seen. What we saw was a bit surprising, namely the rate at which Dirt Jumper samples appear in our zoo and quickly overtake the other families in terms of popularity. This matches anecdotally what we had seen, but the magnitude itself is surprising.

Some ideas as to what is going on:

  • With BEv2, the Black Energy author (back in 2009 which it was being developed and tested) appears to have tried to piggy back on the Zeus and SpyEye craze that was really gathering momentum at the time. Modules to steal from banks would have been a great complement, in theory, but in reality BE targeted DDoS actors who hang out in different forums than the financial thieves. With the notable exception of the Gameover series of attacks, these two groups don’t spent a lot of time together from my own observations.
  • Optima and Darkness make a decent product. I didn’t keep track of pricing or advertising, but their usability, reliability and features all come together to make a great follow-on to the Black Energy model (kit which includes an easy to use web UI and a builder to configure the feature-rich DDoS bot). Why it didn’t take off is really something I can’t explain.
  • Finally, Dirt Jumper’s meteoric rise in popularity in this time frame suggests that author (and any promotors they have working for them) is doing something right. Features are getting incorporated well, new versions are released, and the bot’s got traction in the community. An alternative explanation is that the leaks we see leading to “unofficial versions” are also classified as DJ and explain the rise.

In this competitive underground world, it’s fascinating to see market forces at work so clearly. Bear in mind that all this popularity leads to attention, both in terms of CnC tracking (and shutdown) and AV detection, which is counter-productive. We’ll see how these guys react to larger responses.

A DDoS Family Affair: Dirt Jumper bot family continues to evolve

By: cwilson -

Previous blog entries and analysis by others in the security community have shined a light upon the Dirt Jumper DDoS bot. Dirt Jumper continues to evolve (version 5 appears to be the newest) and a variety of other associated bots packages have emerged over time to include Simple, September, Khan, Pandora, the Di BoTNet and at least one private version of Dirt Jumper 5 that I am aware of. While we have collected about 300 malware samples of the Dirt Jumper family, it is likely that other variants are available, as the binaries and back-end PHP for Dirt Jumper has leaked several times. This makes it easy for someone to make slight modifications to the PHP or Delphi binary code and attempt to re-sell the bot, use the bot for their own purposes, or start making money with their own commercial DDoS service. Attacks from the Dirt Jumper family of bots continue to target victims all around the world in a robust manner and we will take a look at who is being attacked, although we cannot always determine the motive.


Let’s start with a quick review of Russkill, which was seen around 2009-2010:

RussKill has been profiled previously, featuring HTTP and SYN flood attacks.  The start of things to come.

Back-end panels changed and bot binaries gained new capabilities over time.

RussKill evolved into Dirt Jumper:

Which evolved into Dirt Jumper September:

(Thanks to Andre’ DiMino of DeepEnd Research for the screenshot)


September looks very similar to this version of Simple:

Another version of Simple has a different look and feel (three back-end panels pasted together in this particular image for a total of 11,878 bots online):

Dirt Jumper version 5

The latest version of Dirt Jumper that I know of is version 5, likely written or at least leaked in mid-2011. A few MD5’s:

ef9c4bfa9906251d52c3658252224d85 (leaked sometime in October 2011)
506ba7a322288cc4dc55b7c32fea9f4f (leaked around Feb 2012)


The attack types supported by version 5 are as follows:

  • Type 1: HTTP flood –with an example of a dynamic Referer:

Referer: k7569i5p.biz

  • Type 2: Synchronous flood

This attack looks the same as type 01 but opens more connections to the target(s).

  • Type 3: Downloading flood

This flood looks the same as types 01 and 02 (an HTTP GET) but is intended to be aimed at some type of downloadable content in order to burn resources on the server.

  • Type 4: POST flood

The POST flood is similar in style to attacks 01-03 however it has a body payload that consists of the attacked site. A portion of an attack packet shows a dynamic Referer with a properly calculated Content-Length header.  The payload, http://attacked.box corresponds to the attacked site. attacked.box was a locally sinkholed hostname.

Content-Type: application/x-www-form-urlencoded
Content-Length: 21
Referer: 82w6x.info

  • Type 5: Anti DDoS flood – NEW as of Version 5 (does not appear to work however)

Attack type 5, “Anti DDoS flood” did not function at all. No attempts to get this to work were successful, despite this feature being hyped in the underground. Perhaps the version(s) I’ve analyzed are not yet fully realized.

Another back-end screenshot with a modified look is seen below, although the exact version number is unknown. I suspect this is a modification to version 5. This is taken from a small botnet with 27 total bots, 5 active.

Some of the more recent evolutions/changes/code ripping of Dirt Jumper include Trojan.Khan, which is very similar to Dirt Jumper. Jeff Edwards from Arbor ASERT wrote about breaking the crypto in Trojan.Khan recently

We do not currently have any screen-shots from the Khan back-end, however I suspect it is very similar to the Dirt Jumper v5 backend based on traffic analysis.

Dirt Jumper has inspired copies or modifications, such as the recent Di BoTNet version 1.0:

The author of the Di-BoTNet doesn’t try to cover it up and states outright that the bot is “Modification Dirt Jumper 5” on an underground forum.

The listed features of the Di-BoTNet are very similar, if not identical to Dirt Jumper version 5. The feature list, translated from Russian with some text corrections, indicates that Di BoTNet has a “bot killer” feature which can eliminate other bots from an infected box.  Also mentioned are anti-virtual machine and anti-debugging techniques and performance increases. Some versions of Dirt Jumper do indeed bog down the CPU of the infected box, which from the botmasters perspective is a bad thing as the bot may then be noticed. Also mentioned is a variation upon the request header that involves rotating between HTTP 1.0 (the Dirt Jumper default), HTTP 1.1 and HTTP 2.0 HTTP versions. Based upon my analysis of a leaked copy of Dirt Jumper v5, it does not perform such rotation, but it does rotate User-Agent and referer values including adding dynamic elements to make itself harder to block. The only “additional functions” explicitly listed for the Di BoTNet is the ability to control the number of threads and the interval from the panel. This is likely an attempt to make the bot less noticeable as a high number of threads can indeed bring the infected box to a near standstill with 100% CPU utilization.

Modules attack:

+ HTTP flood

+ SYN flood

+ DoWN flood

+ POST flood

+ AntiDDoS flood

(these are all identical to the aforementioned Dirt Jumper v5 attack types)


+ Killer Unit: Bot destroys the competition.

(This was not seen in Dirt Jumper v5)

+ UPDATE: The bot uses inzhekta to update the main module.

(I believe inzhekta here means injection of some kind)

+ Many threading: Can attack simultaneously up to 300 target.

(back-end resets attacked sites back to 300 if more than 300 are specified)

+ Reproduction: The bot itself is a function of distribution.

+ Statistics Today: Today statistics by country.

+ Statistics Online: Online statistics by country.

+ Anti virtualke: Bot does not work on virtual machines.

+ Anti Debugging: Can not ban the domain, the bot will live longer.

+ Productivity: The bot improved performance, better attacks, the system loads less.

+ Randomly: When you receive a random attack uses the full (but not chaotic requests) – HTTP 1.0 2.0 1.1; referer, etc.

Additional functions:

+ Streams: The number of threads during the attack indicated in the admin panel.

+ Interval: The interval is specified in the otstuk config.php, or in the admin panel.

Changes to Command & Control

In addition to other changes seen, Dirt Jumper version five sends a longer unique ID to the Command & Control site than previous versions. In previous versions, this has been the k= value, consisting of a 16 byte number. In version 5 (and in Trojan.Khan) this value is a 32 byte alphanumeric string, unique to each bot install. In the case of Khan, we’ve seen the bot binary use u= instead of k= perhaps in an attempt to evade intrusion detection systems that might flag the suspicious outbound traffic to the C&C.

Dirt Jumper version 3 C&C interaction – red indicates the bot posting its unique ID:


HTTP/1.1 200 OK
Date: Mon, 25 Jul 2011 16:54:37 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
Content-Length: 56
Connection: close
Content-Type: text/html; charset=UTF-8


One site was attacked with an HTTP flood attack.

Dirt Jumper version 5 (and Khan) feature this type of C&C POST:


HTTP/1.1 200 OK
Date: Thu, 23 Feb 2012 10:01:45 GMT
Server: Apache/2.2.22 (CentOS)
X-Powered-By: PHP/5.2.17
Content-Length: 29
Connection: close
Content-Type: text/html; charset=UTF-8



One site that was previously under attack has its attack stopped (command code 11).

With regards to the samples I analyzed, the 32 byte k value is dropped onto the file system as C:Documents and SettingsLocalServiceLocal SettingsApplication DatasLT.exf. This is the exact same filename used by a sample of Trojan.Khan with md5 5c2514c04231f2ca531e368a767f678e for it’s original dropper.

Pandora DDoS

Pandora is the latest bot apparently written by the author of Dirt Jumper.

Pandora has also been cracked/leaked and available in the underground. It was originally on sale for $800, and then later sold for $100 just before it was obviously leaked. Analysis is ongoing, however there are many similarities with Dirt Jumper. There are indications that Pandora has less features than previous versions of Dirt Jumper.

Advertising for Pandora describes the bot as follows (translated from Russian):

<start of translated text>

A. Product description

From the creator of Dirt Jumper and Simple!

The Key DDoS system in 2012!

New, Universal DDoS botnet PANDORA!

This unique product combines the best moments from all the created earlier versions.

Bot written with the participation of the clients of the previous version of the author.

Yes arrive with Your Pandora!!!

Operating instructions

The bot has Five modes of attack.

One. Requests on the TCP protocol, without receiving a response.

A connection is broken so that the server continues to wait until the client receives a response.  And at this time is already running another request.

Thus not only that is 100% load on apache, database, channel, but there are many half-open connections, which creates a queue on a server and additional burden on apache.

To the methods of possible attack as on the specific script, and so on ports!

Two. Almost the same as the first method, but unlike him, this type of attack takes the answer, creating another type of load.

Namely: Employment connect, traffic, load apache in return information.

Three. This method of attack combines the first and the second.

Bot in turn queries the first method, then the second.

Four. And this method is written solely on top of sockets. Bot performs connect to the server, and while he did not refuse to accept the information, the bot will send the traffic.

Port, you can specify any.

Five. The method that allows you to score a channel. Queries with a very large packages.

The numbering of the attack starts FROM SCRATCH!

The bot also there is a system timeout.

In the field you need to specify the timeout in milliseconds. Timeout is performed in each thread separately.

In order to stop the attack to specify zero the number of threads.

All methods of attacks support the ability to strike at the port. The fourth method of attack beats only for IP. (If you specify a domain, he himself will determine the IP.)

<end of translated text>

Who is being attacked and how? A sample of victims

Attacks are diverse and world-wide. Looking at attack logs from our Project Bladerunner we can get a sense of this diversity and learn about some interesting sites. Based on a small sample of 149 attacks, attack types are as such:

Many of the sites that had been attacked in the past were online, however several sites were unfortunately inaccessible, indicating either legitimate downtime or damage from ongoing attacks. One observed target posted about the DDoS attack to their forum and mentioned there were about 50,000 bots attacking. A sample of targets, including targets attacked more than once:

Unfortunately not all of the sites checked were able to withstand the brunt of the attack. Several sites found in the logs returned error messages of one kind or other such as this:

Typical anti-malware evasion tactics help increase botnet lifespan

While many anti-malware vendors will detect Dirt Jumper bots at least under a generic name, tried-and-true evasion techniques such as the use of packers and crypters help protect the bots from detection. Like many other malware authors, botmasters using Dirt Jumper use private anti-virus scanning services in an attempt to keep bots undetected for a longer period of time. This scan performed by a botmaster from March 8, 2012 indicates that this particular version of Dirt Jumper was not detected. The md5: 02c422fa8a7374ae6b693e909229fd78 has been engineered to be undetected via typical file-based anti-malware scanners. Dynamic detection is likely better.

This particular scanner advertises a notification feature:

The next scan of a Dirt Jumper binary from March 9, 2012 scanned by a different service is only detected by one antivirus engine (file-based detection), which appears to flag on the presence of a .NET crypter:

This second example comes from a site that offers a notification service as well as the ability to encrypt files with a variety of methods. The site shows the following stats:

Summary and what’s next?

The Dirt Jumper family continues to expand. As one type of bot demonstrates success, others copy it often with minor modifications. It can be difficult to determine if a site has been attacked by Dirt Jumper or one of it’s variants, and if so, which one. Therefore we will refer to all of the bots profiled here as well as any future bots as the Dirt Jumper family. Development will continue, and there are increasing trends towards the development of attack techniques that will bypass certain types of anti-DDoS protection measures. The underground economy continues to flourish, and DDoS services are a piece of that rotten pie.

It’s not the end of the world: DarkComet misses by a mile

By: jedwards -

This blog post is the fourth installment in our ongoing series of articles exploring the crypto systems commonly found in various DDoS malware families.  Previous subjects have included Armageddon, Khan (now believed to be a very close “cousin” of Dirt Jumper version 5), and PonyDOS.  Today we’ll be diving deep into the details of the DarkComet RAT’s crypto.  Over the last several months, we have encountered a large number of unique DarkComet samples – over a thousand and counting.  DarkComet, also known as Trojan.Fynloski, is primarily a general purpose remote access trojan (RAT). It’s capabilities support quite an extensive laundry list of mischief, including but not limited to key logging, web cam (and sound card) spying, deleting victim files, scanning ports, hijacking MSN sessions, etc.


Above and beyond these standard RAT features designed for general purpose mayhem, the malware includes DDoS capabilities as well – hence our interest in reversing its communications so that we can keep tabs on whom the DarkComet botnets are attacking.  In fact, it is believed to have recently been used as a DDoS weapon by supporters of the Syrian regime against opposition forces in the ongoing Syrian uprisings; TrendMicro has a nice article on this topic.

This article builds on the reversing work documented in the excellent DarkComet analysis by Laura Aylward of Contextis.  The report provides a full description of the important disassembly blocks that implement DarkComet crypto and, as usual, a Python module for encrypting and decrypting DarkComet communications.  Conceptually, the core encryption engine used by DarkComet is very similar to that used by PonyDOS, although there are some important differences in terms of key strings, and DarkComet lacks the cryptographic hashing steps used by PonyDOS.

As described in the report, DarkComet supports the use of a custom password to secure its bot-to-C&C communications.  When a new bot binary is built, this password is encrypted using a standard key string which varies with each version of DarkComet; for example, version 2 uses #KCMDDC2#-890, version 5 uses the string #KCMDDC5#-890, etc.  The encrypted password is stored as a resource named PWD; other important bot parameters are also encrypted and stored as resources, such as the C&C server hostname and port (in the NETDATA resource) and the server ID (in the SID resource.)

Upon initialization, a DarkComet bot will use its standard (version-specific) key string to decrypt these resources.  Once it has decrypted the PWD resource, it will append this custom botnet-specific password to the standard key string to yield the final key that is used for securing communications with its C&C.  So for example, a version 5 DarkComet botnet that uses the default password (0123456789), would end up using #KCMDDC2#-8900123456789 as its comms key.  If the botmaster chooses to not provide a password when building his/her bot binary, the comms will be encrypted using just the standard version-specific key.

The encryption mechanism used by DarkComet is relatively decent compared to many other malware families; alas, the same cannot be said of its DDoS technology.  Due to several catastrophic bugs in DarkComet’s HTTP flooding routines, described in detail in the report, the malware’s DDOSHTTPFLOOD application layer attack does not even manage to come close to producing RFC-compliant HTTP flooding requests.  Instead, the traffic it generates is essentially equivalent to a very weak volumetric TCP flood.

A complete review of the crypto system used by DarkComet, with Python re-implementation, is available here:

Report: It’s not the end of the world:  DarkComet misses by a mile

This completes the fourth installment in our ongoing series on breaking the crypto systems used by contemporary DDoS malware families.

Not just a one-trick PonyDOS

By: jedwards -

Reversing the crypto used by the PonyDOS attack bot

This blog post is the third installment in our ongoing series of articles exploring the crypto systems commonly found in various DDoS malware families.  In previous articles we covered the reversing of the Armageddon and Khan DDoS bots; today we will cover a new malware family that we are calling Trojan.PonyDOS.  This malware family started showing up on our radar screens late in 2011.  Based on a static analysis of the malware, it seems that PonyDOS bot is yet another example of a bot that is exclusively focused on launching DDoS attacks against victim websites.  During dynamic analysis in a sandbox, we observed one PonyDOS sample phoning home to its C&C, and getting a response back; sadly, the communications were encrypted.  It turns out that PonyDOS uses a relatively complicated encryption mechanism to secure its communications, the reversing of which is discussed in detail in the linked report below.  As described in this report, PonyDOS has quite a few tricks up its sleeve that are designed to make its communications resistant to casual attempts at breaking.

PonyDOS gets its named from the string PNYDOS00 that is embedded within the bot binaries; as discussed in the report, the bot includes this identifying string in the “phone home” messages it sends to its command & control (C&C) server.  In addition, some of the samples also like to install themselves into sub-directories named pny within the infected user’s Application Data directory for example, as the file:

C:Documents and Settings$USERNAMEApplication Datapnypnd.exe

We reversed the malware’s crypto in order to gain a better insight into its behavior.  A complete analysis of the crypto system used by PonyDOS – including a Python implementation of a decryption/encryption module, is available here:

Report:  Not just a one-trick PonyDOS

Breaking the encryption used by our little PonyDOS was instrumental in understanding its various DDoS attack mechanisms, and developing defenses against them.  It turns out that PonyDOS supports the four following different types of attacks supported by PonyDOS:

  • A TCP Connection Flood;
  • An HTTP GET flood that does not attempt to read any response from the target web server;
  • An HTTP GET flood that does read responses from the target web server;
  • An HTTP POST flood;

Of course once we had broken the PonyDOS crypto, we started using our Python script (in encryption mode) to generate fake phone home messages in order to impersonate bots and trick the PonyDOS C&C servers into giving up their current attack orders.  This allows us to monitor PonyDOS botnets and observe attacks.  To date we’ve logged attacks against various target web sites hosted in the United States, Russian, and Luxembourg.  The PonyDOS botmasters seem to favor the GET flood attacks, with almost half (94 out of 192 logged events) of its attacks being specified as attack code 0x01 (GET without server read) or 0x02 (GET with server read).  TCP Connection Floods (code 0x00) and POST floods (code 0x03) were used less frequently as alternate attack types:

This completes the third installment in our ongoing series on breaking the crypto systems used by contemporary DDoS malware families.

It’s 2012 and Armageddon has arrived

By: jedwards -

Breaking Armageddon’s latest and greatest crypto reveals some interesting new functionality

Armageddon is one of several notable Russian malware families that are designed exclusively for DDoS attacks; it has been on our radar screens for some time now. Its primary competitors within the market of Russian DDoS vendors are Dirt Jumper (a.k.a. RussKill), Darkness/Optima (a.k.a. Votwup), and of course BlackEnergy.

We’ve noticed that the Armageddon code base has undergone some relatively rapid evolution lately, and the purpose of this blog post is to report on some of the new functionality we have observed. With this latest release, the bot uses some new crypto protection to hide its features from casual observers; breaking this encryption revealed some interesting goodies…

It turns out that the latest version of Armageddon contains support for a few new flavors of DDoS flooding which have been customized to target certain types of web sites. The names of the commands give some indication of the gist of the attacks: .apacheflood, .vbulletinflood, .phpbbflood, The implementation of the .apacheflood command was of particular interest; it makes use of the following (decrypted) string when formulating its flooding requests:

Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,,5-1299,5-1300

This string represents an optional HTTP header that turns out to be included in DDoS flooding requests generated by the bot when performing an .apacheflood attack; this string, along with another encrypted Armageddon string, Accept-Encoding: gzip, have been associated with the so-called “Kill Apache” attack, a type of highly assymetric low-bandwidth DDoS technique that has emerged relatively recently.

In a nutshell, the Kill Apache attack abuses the HTTP protocol by requesting that the target web server return the requested URL content in a huge number of individual chunks, or byte ranges. This can cause a surprisingly heavy load on the target server; in particular, certain versions of the Apache HTTP server handle such requests extremely poorly and in some cases can be brought to their knees by a single attacking client. To our knowledge, this is the first time that the Kill Apache attack has reared its ugly head in actual botnet code in the wild, as opposed to proof-of-concept and/or standalone attack tools.

Of course, once we have taken the liberty of prying open Armageddon’s kimono, it was straightforward to write a “fake Armageddon” client that phones home to the (decrypted) C&C URL strings, and engages in communication that impersonates a real bot. This allows us to gather additional intelligence on the activities and behavioral patterns of Armageddon; in particular, we can now monitor the various Armageddon botnets to log the targets that it attacks, and the types of DDoS floods uses in those attacks. Among other things, this technique allowed us to discover that at least one of the botnets powered by the most recent Armageddon code base took part in the DDos attacks related to the recent Russian election in early December. We will continue to keep a watchful eye on Armageddon going forward.
The full article reporting the details of reversing Armageddon’s crypto, a Python decryption script – and an overview of the findings that were revealed once the strings were decrypted – is available here:
Report: It’s 2012 and Armageddon has arrived

This article is intended to be the first in an upcoming series that will provide a guided tour of the inner workings of various crypto systems that are used by contemporary DDoS malware families in order to hide their communications and sensitive data – and how to go about breaking them!

Update: Today we found some similar analysis of Armageddon and its crypto by the team at Onthar’s Malware Research Laboratory:

Go Back In Time →