It’s like trying to plan your life by picking a college major as a high school student. You think you’re picking a destination; however, you’re just picking a trailhead that’s marked with a destination you think you’d like to get to. You are in fact picking a path through unknown territory to a place you’ve only read about.

To make this more concrete with an example, I remember sitting down with Farnam at a coffee shop and interviewing our first VP of Sales – Arbor’s first VP hire. Not only did we not know what makes a good VP of Sales, we didn’t really even know what a VP of sales did day-to-day. Should they run Marketing? What is Marketing? Advertising? Hell if we knew… did we like this guy? We did – and that turned out to be the actual right question for that hire.

Well, suffice to say, it’s been a long time since 2000. There have been a lot of executive positions that have been filled and refilled since then – I’ll leave it as an exercise to the reader to count them via google and the way-back machine.

However, it turns out that building teams is only part of a founder’s job. Over the course of the last twelve years I’ve constantly shifted my focus as Arbor matured: I used to love to code – still do – I wrote the first version of the Peakflow system; I turned into a salesman – I was the pre-sales engineer that sold all of our early customer wins (paired with our VP Sales); I opened up EMEA sales, hired our early team there and sold the first customers; I stepped in as VP Product Management for three years – most thankless job in the company btw; I led our strategic entry into the Enterprise market with countless trips to NYC and DC; I was tasked with making APAC a meaningful contributor to revenue; I was tasked with M&A – find something to buy – pretty hard problem for VC-backed stock-only private-to-private currency; and I was tasked with M&A again – find someone to buy us; serve as a board member – until the acquisition; and most recently, come up with a next-gen fixed-line and mobile strategy. I’m not trying to write a resume here, but just to point out that wow… that’s a lot of stuff that was certainly not disclosed on the sign at the beginning of the trailhead that said, “Start a Tech Company and be its Chief Technology Officer!” You can see why I always groan on the inside when someone asks me what a CTO does.

The most unexpected part of starting the company, that was both humbling and weighed the most on me though, was the responsibility to the employees and customers that I felt. As a researcher, I was used to doing all the lifting on my own. I could be as risky and crazy with my ideas and projects as I wanted – the way to innovation. However, you quickly learn in a startup, that you need to share the load in order to carry anything meaningful. The problem is, once you’ve convinced friends (and friends to be) to relocate their families and join you on your crazy trip, the joint weight of that responsibility (kids’ shoes, medical care, food, mortgage payments) comes to bear on you.

We started raising our second round of funding Sept 1, 2001 – not good timing. We came to really appreciate our capital for the oxygen that it is. We closed it in February of 2002, the last dollar we took in fundraising. Needless to say, that a day didn’t go by when I didn’t worry about all of the families that depended on our decisions. Don’t screw it up, Rob!

Another unanticipated aspect of founding the company was the travel. For the past twelve years my home has been Northwest Airlines (now Delta). I spent more days on the road than at home. I’ve been {platinum, diamond} at {Northwest, Delta} since 2000 – at least Detroit’s (DTW’s) only one-hop from anywhere on the planet. I’m past the million-mile mark and closing in on two. I’ve used up all of my visa pages (and extensions) in two passports. As a kid, the idea of traveling to the South Seas was intoxicating. Last month I finally got there – spending a week in APAC attending Arbor’s customer summit in Bali. That trip along with some follow-on meetings with customers in Singapore gives a good example of my flight itineraries: DTW->AMS->SIN->DPS->SIN->NRT->DTW. I spent 48 hours travel time for about 72 combined hours in Indonesia and Singapore – multiply this by twelve years to approximate my travel. It was sitting on the beach in Bali under a tree watching the surf – and wishing I were only home – that it finally hit me. Time to take a break.

There are reasons why it won’t be so bad on Arbor for me to leave now. Arbor’s been on a hiring tear these last twelve months (and it’s still going strong). We’ve filled out the management team with great players, and have been building onto a fantastic engineering team as fast as we can hire in all three development centers: Ann Arbor, Boston and Atlanta. We’ve hired new product managers for the enterprise product lines that are full of energy and come from battle tested security companies. We just hired a new leader for our corporate development team and another for our security research team. I won’t spoil any of the surprises, but there are lots of great new products and features coming down the roadmap that are just what the customers need, want, and in some cases, don’t even know they need or want yet. The sales teams continue to do what they do best: overachieve in every region.

I remember meeting with a VC back in October or November of 2001 on Sand Hill Road with Farnam. Due to the terrible funding climate post Sept-11 attacks, we had scaled back our sights to just trying to raise a mezzanine round. He sneered at us, told us that denial-of-service was a fad that had passed, and that we’d be out of business within six months. It turns out that his firm is the one that no longer exists. Denial-of-service attacks – unfortunately for society – were not a fad. They continue to escalate in sophistication and magnitude. Arbor’s core market is only growing. Arbor’s acquisition by Danaher has gone smoothly. Two years into the merger, life is pretty much the same for most of the company. The promise of the acquisition has been playing out: stand alone Arbor backed with significant financial firepower. This combination of company and market stability allows me to be able to pick now as an opportune time to step off – without any worries.

We’re a long way from the winter of 2000, when our small band of crazies broke onto our building’s rooftop to raise the pirate flag; or the winter of 2001 when we drilled a hole through the roof to get a live Olympics feed for our “SOC”. These days people bang on the glass and feed the hackers. There are so many people that have made Arbor great, that I can’t call them all out here. You know who you are: Employees (what a horrible way to say friends), Customers, Partners, even Competitors – you’re all there! Thank you all, from the heart.

Your friend always,
-Rob

PS. If you get confused, just listen to the music play.

What do we mean when we talk about measuring botnet populations? We are trying to measure the number of infected devices to figure out how many people are affected, the number of accounts or customers, and the like. Because of the way the Internet is structured, we can only measure the number of infected PCs or IP addresses received in a time period. We then have to use this information to estimate how large the botnet infected population is.

We count botnet populations for several reasons. First, we want prevalence measurements in order to understand which threats to focus our limited efforts on. We want to understand the prevalence of a botnet by geographic region, for example, to understand to whom we need to reach out. We also want to understand how we should prioritize our efforts, focusing on botnets that will yield a significant impact if they are addressed. Finally, we want to understand the scale of the resources we need to gather as we tackle the botnet. Continuous measurement is vital in order to understand what mechanisms are effective at reducing the botnet’s population. Also, if the numbers ever drop to zero, we can call it a victory. Finally, we also want to understand the size of the possible attacks and any expected financial impact, in order to prepare defenses.

Measurement Methodologies

Counting methodologies are broken into several different methodologies. Measurements using sinkholes are the most popular mechanism right now to count. In this method, we take the botnet command control server and redirected either by DNS or IP redirection to servers that the good guys operate so it’s now outside of the botnet operator’s hands. Then we’re able to count the number of unique IP addresses connecting every day to this server, and we know that these belong to a particular botnet. We can also fingerprint the traffic coming in and are able to distinguish one botnet from another, giving us a prevalence count.

Sinkholes are the most common mechanism right now to count botnets, and are widely done by many groups. All we have the number of IP address is a connect to us here, but sometimes there is a piece of information and the communications from the botnet to the server that we can use to uniquely identify the client and identify when there are more than one PCs source IP address. This might include for example the MAC address for from the botnet, the hostname from the PC, or in the case of the recent Flashback malware the UDID from the device itself. This can help give us some better numbers about the population size.

Shown above is the number of Conficker infected systems that we counted over a two week period. This was gathered using the “q” value from each individual communication and then summed per source IP every day, yielding a decent estimate of the size of the botnet. In this period we estimated the botnet grew from 200,000 zombies to much more than 700,000 zombies.

Another method for counting botnets and estimating their size we call dark IP monitoring. This method takes large unused IP address blocks and then listens for traffic. The collection system is able to fingerprint bots based on specific signs. This could include the exploit traffic or traffic to a specific TCP/IP service used. This then gives you some passive mechanism to watch the botnet and try to spread. Arbor used this method to measure the size of the 2003 Blaster worm, watching a /8 network and counting worm sources.

This graphic is from of paper that we wrote called The Blaster Worm: Then and Now covering the Blaster worm’s propagation over time. Shown here are the various stages of the worm’s specific traffic from our dark IP monitors, showing the worm’s initial burst onto the Internet, followed by the decay phase as networks shut down those hosts and the TCP/IP services the worm used to propagate. The final phase in the graphic shows the diurnal rise and fall of the worm’s populations as PCs are turned on and off each day. The counts are the number of unique source IP addresses every hour.

A direct method for measuring botnets is actually counting on infected hosts. Microsoft has the best option here because they’re able to count reports from their Windows antivirus software, the MSRT executable pushed down during Windows Update, and other host-based antivirus solutions. Distributing this tool globally has enabled them to measure how many infected PCs hit each individual signature. While this is the most direct measurement possible, this is not accessible to many people outside of Microsoft.

Another direct methodology is to crawl a peer-to-peer botnet, gathering the peer list from every node and recursively walking the botnet. This enumeration of the botnet is possible if you know the P2P protocol, but is easily thwarted by strong cryptography. Kaspersky Labs has used this to track the Storm worm, the Miner.h botnet and others. Shown below is a graphic from a Kaspersky Labs blog post on the Miner.h P2P botnet, showing how the nodes are connected.

Limitations

Clearly with botnet measurements you have possible visibility issues. If, for example, ISPs are blocking ports or are blocking collection addresses and instead directing clients to go to their own sinkholes on their own servers, identifying customers, this will lead to under-counting. Similarly, if the domain names for the botnet, which now point to sinkholes, are used in DNS blacklists, clients will never be recorded at the sinkhole, again leading to undercounting. Also, if hosts are offline – not connected or just powered off – they wont be counted. Finally, if the bot’s self-reporting mechanism is to be trusted to count the botnet population, you are possibly the victim of inaccurate reporting by the bot, either being actively deceived or through errors in the bot’s counters. All of these can lead to inaccurate values.

Complications

There are also problems in estimating populations from the source IP counts we gather. DHCP, for example, can lead to over counting. We know that one IP address does not mean equal one device, as DHCP churn can lead to the same device getting multiple IP addresses in a given day. NAT is another issue that can lead to reductions in the numbers. We see ratios about 10 to even 100 to 1 in the wild, meaning we believe that 100 PCs exist for every IP address in some parts of the network. The Blaster worm example from 2003 that I showed earlier is a striking example. Our estimate we present in the IEEE paper was about 800,000 hosts infected with the worm, while Microsoft’s direct measurements showed about 8 million hosts in the same timeframe.

Conclusions

Botnet infection data is widely available now from groups such as Arbor, Shadowserver, Team Cymru, and others. Data feeds from sinkholes and other measurements can be used by network administrators to identify infected hosts and remediate their problems. A number of these are covered in a recent report from ENISA entitled Proactive detection of network security incidents.

Obviously robust measurements are a crucial element to addressing the botnet problem. In the measurement community, we have identified gaps and inconsistencies in our available methods. Where we are going with this now is trying to standardize methodologies so we can measure consistently. Furthermore, we’re trying to identify the causes for the gaps in the methodologies (e.g. network vs host measurements) and provide stronger data by closing those gaps. Based on this data, we also work globally to identify working strategies that effectively shut down botnets and drop infection rates. We then want to coordinate these efforts globally to lead to lower infections in each region.

Over the last two years in particular, Arbor has grown as a company both in the solutions we provide and the problems those solutions enable our customers to solve. Most people, among our customers and across the industry as a whole, understand the thought leadership and expertise ASERT delivers through our blog, and the technical expertise we provide through our security reports and frequent media appearances.

I wanted to take a few minutes and explain the importance of ASERT, ATLAS, and the Security Intelligence they provide. I would also like to introduce a strategic addition to the security research team who will drive new capabilities and areas of focus for Arbor Networks.

ASERT is a world-renowned group of security engineers and researchers dedicated to monitoring Internet threats at all times. With ASERT, service providers and enterprises gain the expertise needed to reinforce their overworked security response groups and optimize the defense of their entire network infrastructure. ASERT lets our customers and products detect and mitigate DDoS attacks, worms and other security threats long before they impact business service availability and integrity.

In partnership with our service provider customers, Arbor Networks launched ATLAS in February 2007, creating the world’s largest distributed darknet sensor network. Today, ATLAS sees 24Tbps of Internet traffic. For Arbor customers, ATLAS delivers a globally scoped view of malicious traffic traversing the backbone networks that form the Internet’s core. Additionally, the ATLAS Intelligence Feed (AIF) provides built-in, automated protection from virtually all known botnets plus a real-time update service that protects customers from new botnets as they emerge. No other vendor can deliver the combination of micro- and macro-level visibility like Arbor does.

In concert with our investments in ASERT and ATLAS, we have focused on increasing the capabilities of our solutions via new products, such as the enterprise and data center focused Pravail Availability Protection System. Pravail APS is a purpose-built platform to identify and block application-layer DDoS attacks that threaten enterprise and data center availability.

With that backdrop, I am excited to announce an important addition to the leadership team at Arbor Networks. Dan Holden has joined Arbor Networks, reporting directly to me as Director of Security Research, responsible for overseeing and leading the strategy and execution of Arbor’s ASERT, ATLAS, and overall Security Research mission.

There are a few reasons why it was the right time to bring on an executive level leader for Security Research:

• To add to Arbor, someone who has successful built out world class, marketplace differentiated research functions that span both Service Providers and Enterprise
• To provide complimentary, new DNA into the team as we expand and grow our security research function and evolve our products to take on new types of security problems
• To work with Dr. Jose Nazario, Senior Manager of Security Research, and provide an unprecedented “one-two punch” in the expertise and capabilities we can provide our customers.

I am excited for Arbor Networks but more importantly, I am excited for our customers as they get to benefit most directly from Dan, Jose, and the rest of the security research and intelligence team we have assembled here at Arbor. Welcome aboard, Dan, we are fortunate and excited to have you join the Arbor team!

Communication between a client out on the internet and a data center server begins (in most cases) with the traditional TCP handshake. This is true for both SSL secured communications and non-secured.

The TCP layer is a very common target of DDoS. There are various flavors of these attacks but they share one aspect in common – the attack target is the capacity of the infrastructure to support concurrent TCP connections. Regardless of how many servers or how robust the infrastructure (firewalls, load balancers) there is a finite capacity to maintain TCP connections. One of the most common of this type of attack is the well-known Syn Flood, where attackers initiate enough connection open requests (“SYNs”) without completing the handshake to exhaust that capacity. A variant of this method of attack is for botnetted hosts to open large numbers of TCP connections simultaneously and actually complete the TCP handshake, thereby bypassing standard Syn Flood protections. Another means of bypassing traditional SYN-flood protections is Slowloris and its variants, which also complete the TCP handshake but then send a request to the server very slowly, one byte at a time, never actually completing the request.

Once the TCP handshake is completed there is a network layer session available for the SSL handshake to take place. The purpose of this exchange is to validate the authenticity of the parties and to establish the encryption key and options that will secure the subsequent communications. The SSL handshake is shown below.

There are numerous known and potential attacks which exploit the SSL handshake to exhaust server resources. The Pushdo botnet accomplishes this quite easily by sending garbage data to a target SSL server. The SSL protocol is computationally expensive and it generates extra workload on the server to process garbage data as a legitimate handshake. Firewalls don’t help in this case because the clients have completed the TCP handshake and are sending traffic to an allowed service.

Another SSL-based attack tool is the THC-SSL-DOS tool, which works by completing a normal SSL handshake but then immediately requests a renegotiation of the encryption method. As soon as the renegotiation completes, it requests another renegotiation, and so on. If the server has SSL renegotiation disabled (a standard security best practice), then the tool simply closes the SSL connection as soon as the negotiation completes and opens a new connection to start the negotiation process all over again. This is extremely computationally expensive and is effective at making services unavailable to legitimate users due to resource exhaustion. There are numerous other potential attacks that target various aspects of the SSL negotiation process to cause server overload and denial of service.

The diagram below is a simplified view of the infrastructure data centers use to provide ecommerce, email or other services protected by SSL.

What is the DDoS attack surface in this infrastructure? First off, the entire data center can be cut off from the outside world through very high volume traffic floods that saturate the incoming links from the internet. Assuming the data center has a provider capable of detecting and screening those types of attacks, what comes next? The firewall is the next target, prone to TCP state exhaustion attacks. Similarly the load balancer/SSL Offload devices are vulnerable. Both maintain tables that track ongoing TCP sessions. In the face of TCP based attacks these devices may become overwhelmed, causing them to stop accepting new connections, remove existing connections or even crash. These actions effectively accomplish the purpose of the attack. Further up the stack, devices supporting SSL and actual application services are attack targets in themselves and have additional application-layer vulnerabilities such as the SSL attacks discussed above.

Most firewalls, ADCs, and WAFs include some DDoS protections yet many high end data centers with the most up to date infrastructure have fallen victim to DDoS.

Why do DDoS attacks continue to succeed?
• Detection is reactive – if attacks are detected based on session tables filling up, server response times rising, etc.
• DDoS attacks (by definition) are distributed. What is normal and acceptable behavior from a single session becomes an attack when repeated by thousands of sources. Firewalls, ADCs view traffic on a session by session basis.
• Blended attacks are effective because each element in the infrastructure is dedicated to performing a particular function.
• There is a lot of NAT out there. DDoS protections built into firewalls and ADCs are heavily based on behavioral attributes of the requesting hosts – e.g. how many sessions from a given source IP. With more and more NAT’d and proxied sources (inside enterprise networks, behind carrier grade NAT, Content Delivery Services) behavioral methods have a hard time teasing out the bad from the good.

What is Arbor’s approach?
• Put DDoS protection at the data center edge – in front of the DDoS attack surface.
• Be as invisible as possible – not part of the attack surface.
• Multiple levels of detection. Use individual host behavior, aggregate behavior of multiple hosts, known signatures and attributes of botnet traffic, IP location, reputation, etc.
• Multiple levels of mitigation. Packet based, header based, behavioral, challenge response techniques that indentify infected hosts and spoofed addresses, white and black lists.
• Automate as much as possible, provide manual controls, and report on what is going on (where traffic is coming from, going where, what is requested, rates, what was blocked, what was passed).

In short, stop attacks before they reach the attack surface and enable the data center to do what it was designed for.

RussKill

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)

Simple

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
http://attacked.box

• 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)

Functionality:

+ 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:

k=795078752145971

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

01|300|150http://<removed>.net/

One site was attacked with an HTTP flood attack.

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

k=o695zw356tm41qhk3346j1wdl357r4mw

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

11|30|60http://s*********.ws/

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 Settings\LocalService\Local Settings\Application Data\sLT.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.