Illuminating The Etumbot APT Backdoor

By: Arbor Networks -

The Arbor Security Engineering Response Team (ASERT) has released a research paper concerning the Etumbot malware.

Etumbot is a backdoor used in targeted attacks since at least March 2011. Indicators suggest that Etumbot is associated with the Numbered Panda group, also known as IXEHSE, DynCalc, and APT12.  Although previous research has covered related malware, little has been publicly discussed regarding Etumbot’s capabilities.

Indicators suggest that the Etumbot dropper is delivered via spear phishing and is contained inside an archive file intended to be of interest to the target. The attackers use the Unicode Right to Left Override technique and document icons to disguise malicious executable content as document files. Once the dropper is executed, the backdoor is activated and a distraction file of interest to the target is opened for viewing.  ASERT has observed several Etumbot samples using distraction documents involving Taiwanese and Japanese topics of interest, and has also observed recent development activity which indicates that attack campaigns are ongoing.

Once installed, the backdoor connects to it’s Command & Control server and receives an encryption key. RC4 encryption, along with HTTP transactions intended to blend in with typical traffic are used for backdoor communications. Etumbot’s core functionality allows for the execution of commands and the capability to upload and download files.

Attackers attempt to obfuscate the malware by using a technique known as “byte strings”, also known as “string stacking”. Through the use of ASERT tools, these byte strings are deobfuscated and revealed herein.

A timeline containing distraction documents along with backdoor and dropper indicators to include MD5 hashes, Command & Control server information, file system and process artifacts are included herein. Some use of the HTran connection bouncer has been observed, indicating that selected C&C’s were simply compromised sites used to relay traffic elsewhere.

It is our aim to assist incident response and security teams and to provide meaningful insight into this threat.

Download the full report: ASERT Threat Intelligence Brief 2014-07: Illuminating the Etumbot APT Backdoor

A Business of Ferrets

By: Dennis Schwarz -

Trojan.Ferret appeared on my radar thanks to a tweet by @malpush. The tweet revealed a URL that at the time of this writing was pointing to a command and control (C&C) panel that looked like this:


The logo alone convinced me to study this business of ferrets further. Coincidentally (for Arbor), it turns out that this malware is a DDoS bot.

Malware Sample

The sample analyzed can be found at malwr (MD5: 4fa91b76294d849d01655ffb72b30981).

It is written in Delphi and plays the following malware games: UPX packing, string obfuscation, anti-virtual machine, anti-debugging, self-modifying code, and process hollowing.

Based on the Delphi usage and the language used for part of the panel, this bot is likely of Russian origin.


Trojan.Ferret uses two methods of obfuscation; both are a combination of base64 and XOR. Different keys are used for various sections. The first obfuscation method is used mostly for strings and can be decrypted with the following Python function:

def decrypt_strings(msg, key):
  msg_no_b64 = base64.b64decode(msg)

  plain_buf = []
  for i in range(len(msg_no_b64)):
    key_lsb = ord(key[i % len(key)]) & 0xf
    msg_lsb = ord(msg_no_b64[i]) & 0xf

    c = msg_lsb ^ key_lsb
    d = c ^ 0xa

    msg_slsb = ord(msg_no_b64[i]) & 0xf0
    plain_byte = msg_slsb ^ d


  return "".join(plain_buf)

Here are some examples:

>>> decrypt_strings("QG1wZ2xnPj4sZGNk", "12xc3qwfhjeryTTYHH")

>>> decrypt_strings("TG12RGZveGBnSG5mZ2JrQg==", "12xc3qwfhjeryTTYHH")

>>> decrypt_strings("dWpkbXFqZmxi", "mu#X")

>>> decrypt_strings("cn9tY3Nqf2d1", "mu#X")

>>> decrypt_strings("ZXN8djotITgyOyQ0MD4mOD45Jzc5I2NmfS1kaXhzdCx+YXo=", "GMrlZ8t3pypO3423423LpFqCUx")

The second method is used mostly for C&C communications and can be cleaned up with the following Python function:

def decrypt_cnc(msg, key):
  msg_no_b64 = base64.b64decode(msg)

  plain_buf = []
  for offset, enc_byte in enumerate(msg_no_b64):
    plain_byte = ord(enc_byte) ^ ord(key[offset % len(key)])

  return "".join(plain_buf)

Here are some examples:

>>> decrypt_cnc("ChYJCRhta3k=", "x38")
'2.11 USA'

>>> decrypt_cnc("DRhAAA4YeRgIXBgIUBgPVRgKAEs=", "x38")
'5 x86 A 0d 0h 7m 28s'

Command and Control

C&C is HTTP based. Two message types have been identified. The first is message type 0 or the “phone home” and looks like:

POST /hor/input.php HTTP/1.0
User-Agent: Mozilla Gecko Firefox 25
Accept: text/plain
Accept-Encoding: identity
Accept-Language: en-EN,en
Connection: Close
Content-Length: 106
Content-Type: application/x-www-form-urlencoded


Here’s what it looks like decrypted:

m=0&h=18803769021711750776216376939&p=HOME&v=2.11 USA&s=5 x86 A 0d 0h 7m 28s

Its POST parameters are:

  • m – Message type (0)
  • h – Hash based on computer name
  • p – Computer name
  • v – Version and locale
  • s – Windows version, architecture, user type, and uptime

The phone home response looks like:

HTTP/1.1 200 OK
Date: Wed, 04 Dec 2013 14:48:27 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
Content-Length: 32
Connection: close
Content-Type: text/html; charset=UTF-8


Decrypted, it is the User-Agent used in the request:

>>> decrypt_cnc("dVdCUVRUWRh/XVtTVxh+UUpdXldAGAoN", "x38")
'Mozilla Gecko Firefox 25'

The second message type is 1 or “poll for commands”. It looks like:

POST /hor/input.php HTTP/1.0
User-Agent: Mozilla Gecko Firefox 25
Accept: text/plain
Accept-Encoding: identity
Accept-Language: en-EN,en
Connection: Close
Content-Length: 49
Content-Type: application/x-www-form-urlencoded


And here it is decrypted:


Its POST parameters are:

  • m – Message type (1)
  • h – Hash based on computer name

An example poll response is:

HTTP/1.1 200 OK
Date: Wed, 04 Dec 2013 12:56:16 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
Content-Length: 72
Connection: close
Content-Type: text/html; charset=UTF-8



>>> decrypt_cnc("UExMSF5UV1dcElBMTEgCFxdMWUpfXUwWVl1MF1FWXF1AFkhQSBcSAAgSCQ0IEgg=", "x38")

Commands are delimited by “*”s and are formatted like:



The following bot commands have been identified:

  • httpflood – HTTP GET flood
  • httppost – HTTP POST flood
  • udpflood – UDP flood
  • synflood – TCP connect flood
  • tcpflood – TCP flood
  • download – download and execute (all bots)
  • downloadone – download and execute (specified bot)
  • update – update (all bots)
  • updateos – update (specified OS)
  • updateone – update (specified bot)
  • updatever – update (specified version)
  • removeos – remove bot (specified OS)
  • removeone – remove bot (specified bot)
  • s! – stop all floods
  • su – stop UDP flood
  • sh – stop HTTP flood
  • ss – stop TCP SYN flood
  • st – stop TCP flood

More information about each command can be found in the “Task Management” section of the C&C panel:



Note: I didn’t see any references to the “memexec” or “script” commands in the analyzed binary.

C&C Panel

Wrapping up, here is a behind the scenes tour of the C&C panel; the “Statistic/Index” page:


Here is the “Uploads” page:


And, part of the “Bot List” page:



This post has analyzed the crypto, C&C infrastructure, and command set of Trojan.Ferret—a new DDoS bot that is likely of Russian origin.  At the time of this writing only a handful of unique samples and C&C servers have been identified, so the scope and impact of the new threat is still uncertain. ASERT will continue to track this business of ferrets, and any other new businesses that arise.

MP-DDoser: A rapidly improving DDoS threat

By: jedwards -

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:

Command Code Function
PP Ping bot, which echoes PP back to C&C
TC Similar to PP, but echoes back with TP
KC Kill bot client process via ExitProcess()
UN Uninstall
BK Scan for IRC, IM, Skype processes
STF Stop all flooding operations
DL Download via URLDownloadToFile() and run   via ShellExecute()   a new malware binary
SFUDP Start UDP Flood
SFSL Start Slowloris Flood
SFBWD Start “Bandwidth” Flood
SFL7 Start Layer 7 attack
SFARME Start Apache Range Flood (“Apache Killer”)

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:|3030|ipkillerpassword|IPK-MPMutex|-1|Not Available|

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


C&C Hostname C&C Port

Botnet ID

Crypto Password





















































IPK-Mine   Hacktivisme














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|Default@1.6|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.

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:


  • 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, corresponds to the attacked site. was a locally sinkholed hostname.

Content-Type: application/x-www-form-urlencoded
Content-Length: 21

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

The End Of 2008 In A Few Sentences

By: Jose -

In these wee small hours of 2008, some quick thoughts.

Researchers have broken SSL CA root certificates via the MD5 collision issues. No great surprise, I think anyone who gave this some serious thought saw this coming. End of the world? No, not really. Invalid SSL certs rarely stop anyone. This will make it tougher to address. The ISC writeup is mostly spot on. There are some more significant issues afoot in the SSL CA chains, anyhow. Great research, however.

A new variant of Conflickr, aka Downadup.B, is on the loose. Same as before, nothing new. This one appears to be affecting a lot of entreprises who STILL didn’t apply MS08-067. Who knows why they haven’t, they’ve had nearly 2 months for a very obviously critical out of cycle patch. Most of the known domains point to, and sometimes to, as the worm begins its update cycles. The world is not ending here, either.

Is Waladec really Storm in disguise? I’m not totally convinced but the number of operational similarities cannot be discounted. But a number of other key facets do not line up. I’m still skeptical, to be honest.

Lots of website defacements due to the global strife between Israel and the Palestinians in Gaza, the recent issues in India, and of course the US. Zone-H offers a nice mirror for you to check out if you wish. A number of groups are active. Also see the Intelfusion blog on the Eastern Railway hacks in India.

And finally, we were quiet on the IE7 0day. We just didn’t have the cycles to talk about it, end of the year and all. In short, we’re surprised that it was used mainly to drop common infostealers and not anything more sophisticated.

Bonne annee!

US Government Moves Fast on DNSsec

By: Jose -

I honestly didn’t think I would live to see it, and this interview with Mockapetris about DNSsec adoption didn’t help.

$ dig +dnssec

; <<>> DiG 9.3.5-P1 <<>> +dnssec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33216
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

; EDNS: version: 0, flags: do; udp: 4096
;                 IN      A

gov.                    10800   IN      SOA     A.GOV.ZONEEDIT.COM. govcontact.ZONEEDIT.COM. 1226785404 3600 900 1814400 86400
gov.                    10800   IN      RRSIG   SOA 5 1 259200 20081215220741 20081115220741 45162 gov.
    UREQjZUJ9/40y/kZytGcBX0jonfNf/yiu0XKDHlVWeKjLkOFqqwY9cf2 gON/ThzPpWRF7aJyo785PQDhYttg5cjDfSF0GKKhsnNcZjYC3u1nluH6
    noQVYGsQ7MpZrNiQnbzg83I4a8z5DIdj1rksaQddAMmR2kIsB0Jh3Duj zq6tfmCcqyQVxzXPUO9rhq87yuYM9gEttm+zlyqBO+TZrykd5u0OMIXK
    YNHchhYX/KYebwfgUq0jo4AZRyVx8fVNu0WXsedjLMtByokwI26u5TpU DsfDUYabOXWjXn40Dg5Se9msQUzKBXgFZEHTCBQ8N9JN9Z9gM+pY5JO5 7mNDvg==
gov.                    10800   IN      NSEC NS SOA RRSIG NSEC DNSKEY
gov.                    10800   IN      RRSIG   NSEC 5 1 86400 20081215220741 20081115220741 45162 gov.
    s5iu9X5tFvRZCZqkayZbbAXQfSi3Kjj8sh4qyFdDnIqXKXLB/fFRH2rw 2E3QDFLE6mLRbfvwJzJ16xwrtUuVliUK0H0ktP3jU03zcYcK8nRjtsn7
    jPTmD+qcaXc1lbGzdi2srTKrPAqbVdetBQgQ9rDV+ZPMzcUZ5LUqcOVe tqgKGiKbB2xGEZySK0R+dyAmPkhhlcyqpfJtYcyd+nTP2XJ5EqRM9S14
    8A1vb0zZgJwrBaJNEOZL9ZHSyWLRiCqlegu4qyDnVWBC2uKB8Nkwdl9a RR7IgZ4D4K2vgbqprk7U7G+xSp8CMVfK4wAgTVM7MG23U0R3PndrS217 rQa2KQ==    10800   IN      NSEC NS RRSIG NSEC    10800   IN      RRSIG   NSEC 5 2 86400 20081215220741 20081115220741 45162 gov.
    U7zNw6u1syRBTv9uuU2mFEBANbCkJuVNprtU/K0rn3NgCmlt5MNQPKmV oobpjqfoolqPIPeU5TgM3L+CokDvhSXzuM8pmwQwlqD0l/oH3JE5K3zT
    kLsevS2piYeotJAPE4mWl4wZgAkSwuHluwaOqVhjGL6nU01ide5q45HQ lDgjpcTe4VHh38szXOoBNMCDTD6+nvpguniULV6gWj6Cat2cp6vetZc8
    xnxhUXcCBgZbU5Qx876bDy3m1KIoc2A7kgWCDuEuvurvQjXR8UCijigf pIAtVGrXZMOg+TNOk+5eIY/B4oOOY1bdAZHwvVD223BOO8QLdyHycT8S oh8oJA==

;; Query time: 106 msec
;; WHEN: Mon Nov 17 15:40:42 2008
;; MSG SIZE  rcvd: 1088

I know that EXECUTIVE OFFICE OF THE PRESIDENT OFFICE OF MANAGEMENT AND BUDGET Memo M-08-23, dated August 22, 2008, stated:

The Federal Government will deploy DNSSEC to the top level .gov domain by January 2009. The top level .gov domain includes the registrar, registry, and DNS server operations. This policy requires that the top level .gov domain will be DNSSEC signed and processes to enable secure delegated sub-domains will be developed. Signing the top level .gov domain is a critical procedure necessary for broad deployment of DNSSEC, increases the utility of DNSSEC, and simplifies lower level deployment by agencies

But I did not expect to have “dig +dnssec” showing me that the .gov root was signed working before, well, December 2009.

Hats off to the folks involved in getting this moving ahead very swiftly.

You can follow this project’s progress at the FISMA website.

Net Neutrality Gumbo

By: Danny McPherson -

I made it up to San Francisco Saturday for the USF-hosted symposium titled The Toll Roads? The Legal and Political Debate Over Net Neutrality. I dropped in just to listen, as most of the folks there, and discussions on the agenda, were more of the legal, academic, economic, and even political science flavors. I did see several folks I knew, but technical folks were definitely in scarce supply. I figured I’d share a random set of my notes from the the meeting here, until the USF folks make podcasts available.

There have been several incidents that seem to have thrown fuel on the fire as of late, many of these oft-revisited by several of the panelists. These incidents included:

  • 2002 the High Tech Broadband Coalition (HTBC) petitioned the FCC to prevent cable companies from imposing restrictions on the connectivity enabled for broadband subscribers. The discussion was triggered by cable firms such as Comcast and Cox Communications adding user contract provisions that limited the types of access that might be provided, and the types of devices broadband subscribers were permitted to use at the customer premise.
  • 2005 Madison River Communications, LLC for blocking VoIP access (e.g., Vonage) via port filtering. MRC was fined $15k by the FCC, and promised to play nice in the future. The Consent Decree cited section 201(b) of the Communications Act of 1934
  • 2006 Verizon Wireless temporal blocking of Naral’s opt-in text messaging program
  • Comcast’s throttling bittorrent and similar applications
  • AT&T’s discussion of DRM enforcement, and the IFPI’s 2008 Digital Music Report, that’s scattered with sections like “Making ISP Responsibility a Reality in 2008″ and “Time for Governments and ISPs to Take Responsibility”

You can find lots more, for instance here, but the ones above were mostly all that were cited explicitly during the symposium.

A bunch of charts were put up from the Organization for Economic Co-Operation and Development (OECD) Broadband Portal, mostly with the apparent intent of illustrating that the current broadband services models in the United States were lagging internationally in both speed and percentage availability — namely because of the current systems enabling of monopoly and duopoly practices is short-sighted at best, and such practices have huge implications on both affordability and accessibility. Some folks, such as Bob Frankston, taking a bit more radical line, argued that this is all simply a symptom of artificial scarcity, as much of his work outlines.

Another interesting topic discussed was that of Reverse Net Neutrality, in particular that of ESPN360’s behavior. The infamous “We’re sorry, but you don’t have access to ESPN360. Please contact your Internet Service Provider and ask them to partner with ESPN360″. ESPN360 was only permitting access to their sites from ISPs that partnered with them, or wrote them a check, or distributed their content via mobile video or other means, or something of the sort.

I quite liked the Lunch Keynote by Rachelle Chong, Commissioner, California Public Utilities Commission. In December of 2007 she authored “The 31 Flavors of the Net Neutrality Debate: Beware the Trojan Horse“, where she essentially argues that imposing any rules would likely have negative consequences. During the Q&A someone in the audience asked a set of questions that contained about three “What IFs”, to which she replied [paraprhased] “The world of what ifs.. Hrm.. I live in the world of real companies that make real money, and whatever it is that we do, or attempt to regulate, has real a impact on this.” She supported a practical perspective, but clearly understood the bigger issue as well.

The insights provided by economist types; Scott Wallsten, Tom Koutsky and Lawrence Spiwak were all helpful as well. I believe most of these folks settled on more pragmatic cost-benefits analysis side. I believe it was Lawrence (Larry) that said “Consumer frustration is NOT a market failure. Carrier stupidity is NOT a market failure.George Ou shared the observation that this whole issue is being poisoned by political partisanship and that no one talks about actual legislation.

An argument for more transparency was made by some, stating that the ISPs and carriers should provide more information about what they block or throttle and why. Others quickly latched onto this, stating that ISPs and carriers should also be required to provide network design information such as full interconnection policies, over-subscription ratios, and other such information.

In opening statements by Timothy Wu, a Professor at Columbia Law School, he seemed to posit that in today’s information age we all rely on private firms, such as carriers, ISPs and search engines, to provide information, and that intermediaries imposing policy is an issue. However, I didn’t hear Tim and folks in the same camp huffing about $-biased search results returned by search engines, or the ESPN360 issue, for that matter.

Colette Vogele, who focuses on intellectual property law, specializing in media, technology, and arts, seems most concerned with the possibility that any traffic preference models employed by ISPs would hinder growth of smaller firms and individuals, thereby Keeping the Little Man Down. In particular, she cited Alive In Baghdad and Political Lunch, two such firms that operate on shoe-string budgets who could not make their content available if ISPs impose preferential treatment to Internet content.

Others mentioned content and mobile as primary concerns as well (beyond wired broadband), although well over the majority of the discussions were clearly about wireline and broadband, and were very U.S.-centric.

I was surprised I didn’t hear more arguments about the implications on end-user security (e.g., the fact that most of the world seems to be of the opinion that ISPs should do more to protect end users AND the greater Internet), or critical infrastructure availability, or emergency services implications and the like. I think there are many more details under the hood than most folks would care to acknowledge. For example, is it reasonable to throttle web or peer-peer traffic in order to ensure that an emergency services transaction receives the necessary network resources? How about network control protocols that provide Internet destination reachability information? or access authentication? or alerting and performance management? And, of course, what about the fact that Applications and Users vary widely in their politeness to others, as Richard Clarke of AT&T intuitively pointed out.

While I don’t think we ever settled anywhere near a common understanding of what Net Neutrality encompasses, nor what permissible discrimination would entail, or what transparency might reasonably require, amazingly, I do feel a bit more informed about arguments and motivators for many of the folks involved in this debate, and some of what’s currently being lumped into the Net Neutrality gumbo.

I also feel a bit more strongly about the need for more technologists to be involved in the debate, as there’s an obvious lack of technical expertise regarding how things actually work, and how what folks might care to overlook or marginalize today might have grave implications on tomorrow.

Information Security and NFL Espionage

By: Danny McPherson -

In late January 2007 several NFL-related web sites were hacked, to include and Considering the Miami Dolphins stadium was about to host the NFL’s biggest game of the year, Superbowl XLI, this seemed a reasonable enough target. The sites were modified to serve malicious JavaScript code that would compromise victim’s computers, providing a good dose of nastiness to vulnerable clients. Some additional details on the incident are available in this Websense alert.

Over the past several weeks, just as the the 2007-08 NFL regular season comes into full swing, the contents of email boxes everywhere have shifted from being bombarded with e-card Storm malware spam, to yet another NFL-driven social engineering vector, as outlined by our friends at TrendsLabs. And, of course, given that this is employing social engineering vectors, a slightly more inviting version of the spammed malware email has been introduced. In the latter edition, the involved miscreants have got themselves an actual domain name in the included link, rather than an IP address, and replaced most of the text with some nifty graphics, raising the bar from quite obviously malicious to just obviously malicious. Both messages profess to provide unsuspecting users a free game tracking system.

As if this weren’t enough, now fans are being duped by coaches and players themselves.. One of many recent events involves Coach Bill Belichick and his New England Patriots, who last week were punished by the NFL for illegally videotaping defensive signals of their competitors. Now, clearly, they’re not the only ones that have done this, but they are the first to get caught. With the Patriots often being touted as the NFL’s model team, it was sure to disappoint.

And, as you might expect, such behavior is typically followed by considerable additional scrutiny. For example, as discussed here, last season the Green Bay Packers “had issues with a man wearing Patriots credentials who was carrying a video camera on their sideline” and “There also are questions regarding the Patriots’ use of radio frequencies during the game”. There were even reports of untimely audio problems experienced by competing teams, problems that just may have been masterminded by the Patriots.

If the Patriots were able to decode the defensive signals real-time and relay match-ups to their offensive squad on the field via helmet communications systems, surely they’d be capable of adjusting to mismatches and afforded a huge competitive advantage. Else, perhaps at half-time they could train Patriots’ quarterback Tom Brady and team to read the signals themselves, detecting blitzes and the like and adjusting by calling audibles to accommodate.

Interestingly enough, radio communications for defensive signal calling has been voted down again, to include just last year. Now, one might think that if it were approved that this wouldn’t have happened; i.e., filming of competing teams wouldn’t yield defensive signals. Well, perhaps that is the case. Or, perhaps lip readers and body language experts would then be put to use. Or RF interception, or taps or other communications snooping mechanisms, all of which would occur even further behind the scenes.

If I heard the commentators correctly (the television was on in the other room), this evening during the New England/San Diego game the NFL purportedly had scanning gear looking for “stray signals” (whatever those are) and the NY Jets were planning to file something with the league regarding the Patriots having their defensive players miked during earlier games.

The Patriots’ code interception incident got me thinking: If the Denver Broncos are looking for a CISO (or a new field goal kicker), I’m local, so no relocation required. And, well, after today, it’s obvious they’re not spying on anyone.

WiFi, Encryption & Clue Density

By: Danny McPherson -

I regularly use wireless networks at meetings, conferences, airports, hotels, workshops, coffee joints, friend’s homes (and mine) – as I suspect is the case with most folks these days. I often leave Dug’s passive listening toolkit running in the background (where network usage licensing/agreements implicitly permit, of course :-) just to see what type of cruft is running amuck on the network, and, more importantly, if I’m inadvertently conveying some critical bit of information that miscreants might be eagerly awaiting.

In doing so, over the past 3-4 years, I’ve made a somewhat conscious effort to gauge prevalence of clear-text network transactional activities within varying user demographics which I frequent (e.g., IETF v. NANOG|RIPE|APRICOT v. airports v. security conferences, explicit network security workshops v. hotels, etc..) and much to my chagrin – with very few exceptions, the constancy of clear-text password and other indubitably critical information tossed about on the network continues to perplex me -independent of the venue!

For example, at a recent network security workshop with ~40 network savvy folk in attendance, 3.5 hours aggregate listening time encompassing two collection periods (all entirely passive) yielded the following (and this is an abbreviated version):


  • 110: pop (31)
  • 143: imap (2)
  • 389: ldap (1)
  • 5190: aol im (3)
  • 80: http: vhost web access (4, email, std vhost, one)
  • 161: snmp (15 – 2 local, 13 HP jetdirect or the like?))


  • 209 clear text (11 gifs, 2 ms-excel, 1 .doc)


  • 11 cookies, 3 passwords (HTTP POST)


  • 17 conversations

At larger events collecting hundreds of passwords in a day isn’t uncommon, from shell accounts, to direct routers and other network element logins, to a slew of POP/IMAP passwords and the like. Often times I nudge folks I know and point out their (or their colleagues) usual oversight, and at places like NANOG there’s usually a good bit of nudging that needs to be done.

Rather than dive into some tutorial on what, where and why you should encrypt (in particular because I’m likely the least qualified on the ASERT team here at Arbor to do such a thing), or perhaps why you think your cleartext network traffic is encrypted but it’s really not, I’ll simply refer you to Google, where I suspect copious articles on the subject can be found.

If you’re wondering why I’m posting an article here on such a threadbare topic, well, apparently, it’s one of those things so obvious even the self-described network-savvy folk often overlook it. When’s the last time you had a look at what you’re actually transmitting?

If folks have any useful references regarding this topic, please feel free to share them here.

Hello Zfone!

By: Sunil James -

Greetings from Ann Arbor…I’m @ Rendez-Vous Cafe – right in the heart of Michigan’s central campus – having a cup of their delicious chocolate raspberry coffee (a must-try if ever you come up to A2). I returned last evening from Vancouver, still a bit over-whelmed at the strong line-up that Dragos put together (nice job!). If you didn’t get a chance to make it out there, check out the conference’s site for the slides (mucho kudos to BreakingPoint Systems’ Dennis Cox for his very enlightening and entertaining presentation!).

ANYways…for those of you who’ve been living under a rock, or were stranded on a desolate island w/ a freaky crew of 48 survivors, I wanted to pass along news of an interesting beta application built by Phil Zimmerman – Zfone.From the website:

“Zfone uses a new protocol called ZRTP, which is better than the other approaches to secure VoIP, because it achieves security without reliance on a PKI, key certification, trust models, certificate authorities, or key management complexity that bedevils the email encryption world. It also does not rely on SIP signaling for the key management, and in fact does not rely on any servers at all. It performs its key agreements and key management in a purely peer-to-peer manner over the RTP packet stream. It interoperates with any standard SIP phone, but naturally only encrypts the call if you are calling another ZRTP client.”

We’re about one month into the tool’s release, and I’m wondering if anybody has any thoughts or reactions to the software? Also, any reax to the proposed IETF draft?