DDoS Attacks in the Wake of French Anti-terror Demonstrations

By: Kirk Soluk -

On January 15th, France’s chief information systems defense official, Adm. Arnaud Coustilliere, announced a sharp rise in online attacks against French web sites:

“Calling it an unprecedented surge, Adm. Arnaud Coustilliere, head of cyberdefense for the French military, said about 19,000 French websites had faced cyberattacks in recent days, …” [1].

As we’ve done in the recent past for North Korea [2], Hong-Kong [3], and Israel [4], we can leverage Arbor’s ATLAS initiative to observe how real world conflict is reflected in the digital realm. ATLAS receives anonymized Internet traffic and DDoS event data from over 330 participating Internet Service Providers worldwide. In particular, we are interested in DDoS attacks before and after Sunday, January 11th. As reported in [1],

“Coustilliere called the attacks a response to the massive demonstrations against terrorism that drew 3.7 million people into the streets Sunday across France.”

In order to gauge this response, we compare the DDoS attacks that took place between January 3rd and January 10th to the DDoS attacks that took place between January 11th and January 18th inclusive.

Attack Frequency

Between January 3rd and January 18th, a total of 11,342 unique attacks were reported as targeting France – an average of 708 attacks per day. The following series of graphs depict the frequency and size of these DDoS attacks for the 8 days before and after January 11th, 00:00:00 GMT.

Figure 1 illustrates the total number of reported DDoS attacks targeting France for the eight-day period before January 11th, and for eight days after January 11th:


Figure 1: Total Number of Attacks

We observe a 26% increase in the number of DDoS attacks in the period after January 11th.

Attack Size

Figure 2 compares the average size of DDoS attacks in terms of bandwidth (Gbps) before January 11th, and afterwards:

Figure 2: Average Attack Size (Gbps)

Figure 2: Average Attack Size (Gbps)

Here we observe a 35% increase in average DDoS attack size after January 11th. Specifically, in the eight days prior to January 11th, the average attack size was 1.21 Gbps. After January 11th, the average attack size was 1.64 Gbps.

Attack Size Distribution

Figures 1 and 2 above illustrate that not only were there more attacks after January 11th, the attacks were larger, as well. The following table details this observation:

France-Table1-AttackSizeDistribution247 (5%) of the DDoS attacks in the period prior to January 11th were greater than 5 Gbps while 678 (11%) of the attacks after January 11th exceeded 5 Gbps in size. Thus, while Figure 2 describes a 35% increase in average attack size post January 11, the percentage of attacks larger than 5 Gbps more than doubled.

Peak Attack Sizes

Figure 3 depicts the size of the largest attack before and after January 11th 00:00:00 GMT:


Figure 3: Peak Attacks

January 9th saw a 40.96 Gbps attack, while a 63.02 Gbps attack was reported on January 11th. The January 11th attack was 54% larger than the attack observed on January 9th.


On January 11th, the largest demonstration in French history took place as millions marched in anti-terrorism rallies across the country [5]. On January 15th, Adm. Arnaud Coustilliere, announced an unprecedented surge in online attacks against French websites, calling these attacks “a response to the massive demonstrations” [1]. Arbor’s ATLAS data presented above appears to support Adm. Coustilliere’s claims.

Comparisons of DDoS attack data over the eight-day periods before and after January 11th show:

  • a 26% increase in the number of attacks,
  • a 35% increase in the average attack size,
  • a 100% increase in the number of attacks larger than 5 Gbps and
  • a 54% increase between the peak attack events in the two time periods.

This is yet another striking example of significant online attacks paralleling real-world geopolitical events.


[1] http://bigstory.ap.org/article/806d34082511483cafe2deaa1a7e6061/car-hits-injures-officer-french-presidential-palace

[2] http://www.arbornetworks.com/asert/2014/12/north-korea-goes-offline/

[3] http://www.arbornetworks.com/asert/2014/11/ddos-activity-in-the-context-of-hong-kongs-pro-democracy-movement/

[4] http://www.arbornetworks.com/asert/2014/08/ddos-and-geopolitics-attack-analysis-in-the-context-of-the-israeli-hamas-conflict/

[5] http://www.cnn.com/2015/01/11/world/charlie-hebdo-paris-march/


North Korea Goes Offline

By: Dan Holden -

It was reported earlier today that North Korea was having Internet connectivity issues.

Given recent events involving Sony Pictures Entertainment (SPE), these reports are of particular interest. The first question when you see this type of report is whether it’s purely a connectivity issue or whether an attack is behind it. While visibility into North Korean Internet is quite difficult, we are able to see quite a few attacks over the last few days.

1.) All targets are in this netblock:

inetnum: –
netname:       STAR-KP
descr:         Ryugyong-dong
descr:         Potong-gang District
country:       KP
admin-c:       SJVC1-AP
tech-c:         SJVC1-AP
status:         ALLOCATED PORTABLE

2.) pDNS Data on the specific targets – This appears to be authoritative DNS servers – This appears to be authoritative DNS servers – smtp.star-co.net.kp – naenara.com.kp – Unknown –  www.ryongnamsan.edu.kp

3.) Port Analysis

– All attacks on the 18th, 19th and 20th target port 80
– All attacks (except for one) on the 21st and 22nd target port 53 (DNS) from either port 123 or 1900 (indicating NTP or SSDP reflection amplification).
– – The one exception, the first attack on the 21st, was from 1900 to 80.

4.) Peaks

Peak Attack Size (bps) = 5.97 Gbps on 12/20/14
Peak Attack Size (pps) = 1.70 Mpps on 12/20/14 (same attack)
Peak Duration: 55m 53s 12/22/14 and still ongoing

Two questions generally come to mind at this point. What are they attacking and who is behind these attacks?

Given the above, it looks as if the targets are government owned and operated sites. Given that this is North Korea and Naenara is the official Web site for the DPRK, this makes perfect sense. The .edu target is Kim II Sung University which was the first University Web site ever hosted by North Korea.

The next question is who might be behind such an attack. The “who done it” is great fun, especially when it involves North Korea, given the events of last week. The real answer is that it would be easier to say who is NOT doing this.

I’m quite sure that this is not the work of the U.S. government. Much like a real world strike from the U.S., you probably wouldn’t know about it until it was too late. This is not the modus operandi of any government work.

Below you will see a recent post on pastebin of a port scan of several of the IP’s mentioned above. This is typical of hacktivism information sharing and would match up very well with recent online chatter.



.8 and .9 listening on 53.
.10 listening on 25.
Nothing for .11.
.67 and  .77 listening on 80 and 110.
Nothing for .79 (the .edu site)

Anonymous has been tweeting about not only releasing the movie, The Interview, but taking revenge on North Korea for the movie being taken out of theaters. A second hacktivist cyber-terrorist group, Lizard Squad, is also active on Twitter:



Going back to the very beginning, what does this all have to do with the Internet being spotty in North Korea? Well, as you can see, two of the above targets were the primary and secondary DNS for much of the Web sites in North Korea. While these attacks aren’t very large, they don’t necessarily need to be. The Internet infrastructure in North Korea isn’t that impressive so it’s not as if a super sophisticated attack is needed in order to cripple it. Without further information to work from, my informed speculation would lead me to think the traffic dropped intermittently due to not being able to resolve IP’s.

While Stuxnet was a very real thing and countries all over the world have increasingly impressive offensive capability and aren’t shy about stating publicly that they are building further capability every day, there are also instances where its been shown that nation states aren’t always to blame. This is likely to be one of those situations.

Here is a view from the Digital Attack Map, a collaboration between Arbor Networks and Google Ideas:



DDoS Activity in the Context of Hong Kong’s Pro-democracy Movement

By: Kirk Soluk -

In early August, we examined data demonstrating a striking correlation between real-world and online conflict [1], which ASERT tracks on a continual basis [2-7]. Recent political unrest provides another situation in which strong correlative indicators emerge when conducting time-series analysis of DDoS attack data.

The latest round of pro-democracy protests in Hong Kong began on September 22nd when “. . . Students from 25 schools and universities go ahead with a week-long boycott to protest Beijing’s decision to proceed with indirect elections for Hong Kong’s Chief Executive position.” [8]. The protests ramped up on September 28th when a larger pro-democracy group, Occupy Central with Love and Peace, combined forces with the student demonstrators [8-9]. On October 1st, protesters vowed to increased the level of civil disobedience if Hong Kong’s Chief Executive, Leung Chun-Ying, did not step down [10].  Since that time, tensions have increased, with police crackdowns, tear gas, barricades, skirmishes, shutdowns of government buildings and infrastructure, and heavy use of social media to promote both pro-and anti-protest sentiment.  By examining Arbor ATLAS Internet-wide attack visibility data we have identified DDoS attack activity in the APAC region which correlates strongly with the ebb and flow of protest activity in Hong Kong.

Arbor’s ATLAS Initiative

The DDoS information provided in the remainder of this report is derived from Arbor’s ATLAS Initiative. Arbor ATLAS receives anonymized Internet traffic and DDoS event data from over 290 ISPs worldwide which have deployed Arbor’s DDoS Mitigation solutions.  While many observed events are symptomatic of attacks during this period, it is important to note that we cannot definitively identify the motivations behind any given event.

Hong Kong as a Target of DDoS Attacks (September-October)

Number of Observed DDoS Attacks

The following graph illustrates that the number of observed DDoS attacks targeting Hong Kong-related online properties more than doubled between September and October, from 1,688 discrete attacks in September to 3,565 attacks in October:

Figure 1: Total Number of Attacks Targeting Hong Kong (September and October, 2014)

Figure 1: Total Number of Attacks Targeting Hong Kong (September and October, 2014)

Although the sheer number of DDoS attacks increased significantly from September to October, there was not a significant difference with respect to other attack attributes such as size or duration.  For example, the following charts break out the percentage of DDoS attacks within a given size range for both September and October, along with the raw number of DDoS attacks in that size range:

Figure 2: Percentage of Attacks within a given Size Range

Figure 2: Percentage of Attacks within a given Size Range

Overall, the percentage of DDoS attacks within a given size range remain fairly consistent from September to October, with the biggest difference being a relative 4% decrease in the number of DDoS  attacks within the 2gb/sec-to-5gb/sec range.

In summary, the analysis of the number and size of Hong Kong-related DDoS attacks depicted by Figures 1 and 2 above can be summed up by stating that “October saw more of the same – a lot more!

Size of Attacks and Related News Events

Figure 3 illustrates the largest DDoS attacks per day, in terms of bandwidth, targeting Hong Kong-related online properties during the month of October:

Figure 3: Peak Attack Sizes per Day (Gbps)

Figure 3: Peak Attack Sizes per Day (Gbps)

Three large DDoS attacks on October 14th (45.4gb/sec), 17th (38.3gb/sec), and 19th (45.6gb/sec) stand out. The total number of observed DDoS attacks targeting Hong Kong-related online properties (289, 419, and 427 respectively) also peaked on these days.  Since the vast majority of DDoS events reported via ATLAS are anonymized, it cannot be definitively determined how these specific DDoS attacks were related to the ongoing protests.  However, it appears that these attacks coincide with reports on Twitter and  by the Wall Street Journal of anti-protest crowds attempting to physically prevent pro-democracy newspaper publisher Apple Daily from distributing its newspapers. Specifically, the Journal noted that Apple Daily “simultaneously faced a cyberattack that brought down its email system for hours” [11]. On October 14th, Computerworld Hong Kong quoted an employee from Next Media (Apple Daily’s parent company), as follows: “The network was a total failure, affecting not just Apple Daily, but all the publications under Next Media” [12].

What’s Next?

Based on in-region DDoS attack statistics for the first week of November, continued DDoS attacks on Hong Kong-related Internet properties appear to be taking place. The following graph illustrates peak DDoS attack sizes in the 30gb/sec-plus range on four consecutive days (November 3rd – 6th):

Figure 4: Peak Attack Sizes per Day (Gbps) in the first week of November

Figure 4: Peak Attack Sizes per Day (Gbps) in the first week of November


While establishing definitive causal relationships and attribution are challenging  it is apparent that DDoS attacks have become the ‘new normal’ during periods of political unrest worldwide. In this case, we observed a 111% increase in the number of DDoS attacks targeting Hong Kong-related Internet properties when analyzing the months immediately before and after protester demands, on October 1st, for Hong Kong’s Chief Executive to step down. Additionally, large-scale DDoS attacks were observed targeting Hong Kong-related Internet properties that coincide with reports of debilitating disruptions of online media outlets sympathetic to the protest movement.


[1] http://www.arbornetworks.com/asert/2014/08/ddos-and-geopolitics-attack-analysis-in-the-context-of-the-israeli-hamas-conflict/

[2] http://www.arbornetworks.com/asert/2007/12/political-ddos-ukraine-kasparov/

[3] http://www.arbornetworks.com/asert/2013/05/estonia-six-years-later/

[4] ASERT Threat Intelligence Brief 2013-5: Observed Syrian Cyber Adversary Capabilities and Indicators. Available to Arbor customers upon request.

[5] ASERT Threat Intelligence Brief 2013-7: The Impact of Protest Activity on Internet Service in Thailand. Available to Arbor customers upon request.

[6] ASERT Threat Intelligence Brief 2013-4: Potential Targeted Attacks Against Various International Interests. TLP Amber. Available to Arbor customers upon request.

[7] ASERT Threat Intelligence Brief 2014-04: Counter Terrorism Expo and Bulgarian State Agency for National Security Cyber-Threat Alert. TLP Amber. Available to Arbor customers upon request.

[8] http://www.theepochtimes.com/n3/1015132-hong-kong-occupy-central-time-line-of-key-umbrella-movement-events/

[9] http://www.scmp.com/topics/occupy-central

[10] http://www.reuters.com/article/2014/10/01/hongkong-china-idUSL6N0RV5F920141001

[11] http://online.wsj.com/articles/hong-kongs-press-under-siege-1413330960

[12] http://cw.com.hk/news/next-media-under-cyberattack-and-operations-disruption

FCC advised on Remediation of Server-based DDoS Attacks

By: Arbor Networks -

Yesterday, the Communications Security, Reliability and Interoperability Council (CSRIC), a federal advisory committee to the Federal Communications Commission (FCC), submitted its final report on Remediation of Server-based DDoS Attacks.

The CSRIC’s Working Group 5 was tasked with developing recommendations for communications providers to enable them to mitigate the impact of high volume DDoS attacks launched from large data center and hosting environments.

The final report includes a comprehensive look at the DDoS threat landscape, covering everything from the massive size of today’s attacks, to the potential for collateral damage. The report describes how DDoS attacks are becoming increasingly complex, how they are being used as a diversion “to distract security resources while other attacks are being attempted, e.g., fraudulent transactions.” The report also discusses how botnet architectures are becoming more sophisticated and difficult to trace.

Given this complex and challenging threat landscape, we were grateful for the opportunity to contribute. The CSRIC has adapted Arbor Networks best practices for DDoS incident response as the Six Phases for DDoS Attack Preparation & Response.


Roland Dobbins, senior analyst with Arbor’s Security Engineering & Response Team (ASERT), served as the Internet sub-group chairman of CSRIC IV WG5 – Server-Based DDoS Attacks. 

Roland has nearly 30 years of operational experience in the service provider and large enterprise arenas. His experience includes designing, deploying, operating, securing, maintaining, troubleshooting and defending many of the highest-visibility networks in the world. He is a recognized industry leader in the fields of operational security and network telemetry with extensive background in security product/feature innovation, devising operational security requirements for network infrastructure devices and protocol design. His focus is on extending the availability, scalability and security of the network infrastructure and the applications/services it enables, with an emphasis on flexible and resilient global service delivery capabilities.

Into the Light of Day: Uncovering Ongoing and Historical Point of Sale Malware and Attack Campaigns

By: cwilson -

Point of Sale systems that process debit and credit cards are still being attacked with an increasing variety of malware. Over the last several years PoS attack campaigns have evolved from opportunistic attacks involving crude theft of card data with no centralized Command & Control, through memory scraping PoS botnets with centralized C&C and most recently to highly targeted attacks that require a substantial amount of lateral movement and custom malware created to blend in with the target organization.

While contemporary PoS attackers are still successful in using older tools and methodologies that continue to bring results due to poor security, the more ambitious threat actors have moved rapidly, penetrating organizational defenses with targeted attack campaigns. Considering the substantial compromise lifespans within organizations that have active security teams and managed infrastructure, indicators shared herein will be useful to detect active as well as historical compromise.

Organizations of all sizes are encouraged to seriously consider a significant security review of any PoS deployment infrastructure to detect existing compromises as well as to strengthen defenses against an adversary that continues to proliferate and expand attack capabilities.

In addition to recent publications discussing Dexter and Project Hook malware activity, Arbor ASERT is currently tracking other PoS malware to include Alina, Chewbacca, Vskimmer, JackPoS and other less popular malware such as variants of POSCardStealer and others. Attack tactics shall also be explored through analysis of an attackers toolkit.

The longevity and extent of attack campaigns is a serious concern. In organizations with security teams and well managed network infrastructure, point of sale compromises have proliferated for months prior to detection. If attackers are able to launch long-running campaigns in such enterprise retail environments, one can conclude that many other organizations with less mature network and infrastructure management are also at serious risk. A sample of high-profile incident timelines, showing the date of the initial compromise, compromise timespan and compromise scope (number stores in this context) is included to highlight this point.

Download the full report: ASERT Threat Intelligence Brief 2014-06 Uncovering PoS Malware and Attack Campaigns

ASERT Threat Intelligence would like to thank fellow ASERT team members Dave Loftus, Alison Goodrich, Kirk Soluk and Matt Bing and also wishes to thank David Dunn of FIS Global and the Shadowserver Foundation for providing additional information.

Trojan.Eclipse — A Bad Moon Rising?

By: Dennis Schwarz -

ASERT’s malware collection and processing system has automatic heuristics that bubble up potentially new and interesting DDoS malware samples into a “for human analysis” queue. A recent member of this queue was Trojan.Eclipse and this post is my analysis of the malware and its associated campaigns.

Analysis was performed on the sample with an MD5 of 0cdd10cd3393d3fe916a55b946c10ad6.

The name Eclipse comes from two places: a mutex named “eclipseddos” and a hardcoded Cookie value used in the command and control (C2) phone home. We’ll see in the Campaign section below that this threat is also known as: shadowbot, gbot3, eclipsebot, Rhubot, and Trojan-Spy.Win32.Zbot.qgxi.

Based on the C2 domain names, GeoIP of the C2 IP addresses, and a social media profile of the owner of one of the C2 domains, I suspect this malware to be Russian in origin. In addition, Eclipse is written in Delphi and empirically Russian malware coders have a certain fondness for this language.

Command and Control

The analyzed binary has a hardcoded C2 domain string. This string is protected from modification by running it through a simple hashing algorithm and comparing it against a hardcoded hash at certain points of the code. The following Python function replicates this algorithm:

 def decrypt(string):
    table1 = "qwertyuiopasdfghjklzxcvbnm.1234567890"
    table2 = "asdfghjklqwertyuiopnbmcvxzeasdfghjklv" 
    out = ""
    for orig_char in string:
        index = table1.find(orig_char)
        if index == -1:
            char = orig_char
            char = table2[index]
        while char in table1[index:]:
            index = table1.find(char)
            char = table2[index]
        out += char

    print out

For example, the domain “milfsdeasing.com” hashes to “zopterrweoxyezpz.”

An example phone home request looks like this:


It is a HTTP GET based C2 protocol where the query string breaks down into the following parameters:

  • bot – 15 random lowercase letters and digits
  • botkey – possibly a hardcoded campaign key
  • os – OS name
  • ram – amount of RAM
  • user – username
  • cpu – estimated CPU speed
  • number of CPUs

After the Host line, the remaining headers are static—note the aforementioned Cookie value. An example phone home response looks like this:


The returned content is a single <base> tag containing base64-encoded data. Once decoded, an XML-like configuration file emerges (newlines added for clarity):

<cmd>stop;</cmd><tcp>GET /index.php HTTP 1.1
Host: $RANDOM$.net
User-agent: $RANDOM$

Another example:

<cmd>type=slow-post; threads=10; timeout=1;
 target=www.victim.com; script=/contact-us.php;
port=80;</cmd><tcp>GET /index.php HTTP 1.1
Host: $RANDOM$.net
User-agent: $RANDOM$

Relatively speaking, for a DDoS bot, Eclipse has a fairly rich configuration mechanism. Starting with the <cnfg> tag, it has four possible options:

  • control-timeout – set C2 poll time
  • control-path – set C2 pathname
  • control-domain – set C2 domain
  • stream-timeout – minimum wait time between attack packets, in milliseconds

The <cmd> tag can contain multiple commands delimited by a “\r\n”, and each command has three possible formats: standalone command, command requiring parameters, and a shortcut command. An example of the first format is:


Identified commands in this category are:

  • stop – stop attacks
  • wait – sleep for one day
  • die – exit process

An example of the second format:

<cmd>type=slow-post; threads=10; timeout=1; target=www.victim.com; script=/contact-us.php; port=80;</cmd>

There are a bunch of types, here are the ones identified:

  • update – update self
  • execute – download and execute
  • tcpint – custom TCP flood
  • browser – HTTP GET flood, look like a web browser
  • dirtjumper – HTTP GET flood
  • sincere – TCP flood
  • http – HTTP GET/POST flood
  • httpspoof – HTTP GET flood with spoofed X-Forwarded-For header
  • slowloris – broken Slowloris attempt
  • tcp – TCP flood
  • udp – UDP flood
  • http-data – HTTP POST flood
  • slow-post – broken slow HTTP POST flood
  • connect – TCP connect flood
  • tcp-oneconnect – TCP flood
  • icmp – broken ICMP echo request flood
  • http-post – referenced in the code, but not implemented

Command parameters depend on the type and include:

  • threads – number of attack threads, defaults to 30
  • timeout – wait time between attack packets, in milliseconds
  • target – target host
  • script – URI path and file
  • port – target port, defaults to 80
  • connint – unknown, defaults to 1
  • dataint – unknown, defaults to 1
  • data – referenced, but unused
  • template – template attacks

Two interesting features here. First, the script parameter can contain variables: $RANDOM$ is replaced with 15 random lowercase letters and digits and $INTEGER$ is replaced with a random integer between 0 and 998.

Second, the template option configures various attacks based on hardcoded templates. They include:

  • nginx – slowloris attack, 30 threads, 10 ms timeout
  • ssh – tcp attack, 45 threads, 10 ms timeout, destination port 22
  • ftp – tcp attack, 45 threads, 10 ms timeout, destination port 21
  • https – tcp attack, 70 threads, 10 ms timeout, destination port 443
  • dns – udp attack, 10 threads, 10 ms timeout, destination port 53

Finally, the shortcut command format looks like this:


This launches an http attack with 100 threads and a timeout of 10 ms.

The <tcp> tag is used in conjunction with the tcpint command and defines a custom TCP flood payload template. The template supports $RANDOM$ variables which are replaced with 15 random lowercase letters and digits.


Campaign-wise, Eclipse can be broken down into roughly four groups: shadowbot, gbot3, eclipsebot, and eclipseddos. The malware implementation used in each campaign varies a bit from what was describe above, but I feel that they’re earlier development versions and warrant being categorized under the same family name.

shadowbot Campaign

The shadowbot campaign was active from July 21, 2013 to August 10, 2013 (using VirusTotal’s first submission timestamp). Its name comes from the use of the shadowbot mutex. Other notable differences include:

  • Use of a shortened query string, “index.php?bot=”, in the C2 phone home
  • Missing Referer and Cookie headers in the C2 phone home
  • Does not use the <base> tag or base64 encoding
  • The <cmd> tag is much simpler and is delimited by “#”s
  • Does not use <cnfg> or <tcp> tags
  • Uses !random instead of $RANDOM$ variables
  • Smaller command set: connect, slow-post, http-data, cs, udp, tcp, and http

Some sample MD5s and C2 URLs:

4c76ed5155b2ee388bd770941a3c0473 http://aktualisieren-soft.ru/blizzer-kidala/index.php
0af74a0029b248b7c4b5129a1a0e5e3b http://teleon2.ru/paranoik/index.php
2596d7b324599240c723429a01ad7310 http://teleon2.ru/paranoik/index.php
dd384ead636a7bd9bf7aa870ae712963 http://teleon2.ru/new/index.php


The last entry in this table is the sample that Microsoft documented at http://www.microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=Trojan%3AWin32%2FRhubot.A. They have named the malware “Win32/Rhubot.A”, but to be honest I couldn’t figure out why or find any good source material on “Rhubot”.

gbot3 Campaign

Next is the gbot3 campaign, which was active from August 9, 2013 to January 1, 2014 VirusTotal time. Its name also comes from the mutex that it sets. The distinguishing features of this version are:

  • As with shadowbot, uses shortened C2 phone home query string, “index.php?bot=”
  • Does not use base64 encoding, but does contain <cmd>, <cnfg>, and <tcp> tags
  • <cmd> is space delimited and still fairly basic
  • Implements “#” shortcut command
  • Implements tcpint command with <tcp> template. The template supports !randomchar, !random-ug, !random-lang, !random-encoding, !random-ac, !random-accept variables instead of $RANDOM$
  • Supports !random instead of $RANDOM$ in URI
  • Command set includes the more novel tcpint, browser, dirtjumper, slow-post, and tcp-oneconnect commands

Some sample MD5s and C2 URLs:

ad8ac73540708d5cd6738a5d5f23a1d5 http://tryboots.ru/asdfgh/index.php


The last entry in this table is the sample referenced in SourceFire VRT’s “MALWARE-CNC Win.Trojan.Rhubot variant outbound connection” rule.

eclipsebot campaign

Third is the eclipsebot campaign, which was active from September 12, 2013 to November 4, 2013. Naming is based on the mutex. Sans some minor changes, this version is very similar to the eclipseddos analyzed in the beginning of the post. Notable features are:

  • Introduction of C2 domain hash check
  • Still uses shortened C2 query string, “index.php?bot=”
  • Introduction of rich <cmd> configuration via type, threads, timeout, target, script, etc. options
  • Has support for attack templates
  • Uses $RANDOM$ and $INTEGER$ variables

Some sample MD5s and C2 URLs:

ab6d483b2d6adf510e07395ceea5b980 http://blog32.ru/wp-admin/dark/index.php
b4e55f09ba681c10c20c50453c85652f http://blog32.ru/wp-admin/dark/index.php


eclipseddos campaign

The eclipseddos campaign has been active since November 28, 2013 VirusTotal time.

Some sample MD5s and C2 URLs:

c6cdd4876771f18efade928c50cf81fa http://milfsdeasing.com/par/index.php
548fbf4dde27e725c0a1544f61362b50 http://vsehnahuy.com/huy/index.php
0b450a92f29181065bc6601333f01b07 http:// test.crack-zone.ru/index.php


The last two samples in the above table are referenced in the Emerging Threats rule called “ETPRO TROJAN Trojan-Spy.Win32.Zbot.qgxi Checkin”. As with Microsoft’s AV detection, I couldn’t find any source material on why they decided to name it this way.

The Trojan.BlackRev Connection

Back in May 2013, I released a blog post titled “The Revolution Will Be Written in Delphi” that profiled a DDoS bot named Trojan.BlackRev. Since that post, there have been a few updates that provide for a preamble to a possible relationship between Eclipse and BlackRev. On June 5, 2013 the author of BlackRev, going by the handle “silence”, posted to an underground forum saying that he had sold the project:


A few months later on October 4, 2013 on another underground forum, somebody going by the handle “chef” leaked the BlackRev source code:


While tracing one of the Eclipse C2 URLs from the shadowbox campaign:


I came across a C2 URL with a similar URI pathname:


The complete C2 protocol looks like this:


This traffic came from a binary with an MD5 of 8da35de6083aa9aa3859ce65e0e816df and I believe this sample to be a “missing link” between the BlackRev and Eclipse code bases.

In addition to the timeline proximity and the feeling of “code sameness” while reversing engineering, some of the major pieces linking this variant to BlackRev are:

  • The query string used in the phone home
  • Comparison against the “|stop|” string
  • Bot command is pipe “|” delimited
  • Launches the same “bot killer” code in a thread
  • Launches the same “memory reduction” code in a thread
  • Uses a similar random character generator
  • HTTP header overlap in some of the attacks
  • Names a command “antiddos”, which is fairly novel

The major pieces linking it to Eclipse (shadowbot specifically) are:

  • Shared C2 infrastructure
  • HTTP header overlap in the C2 phone home
  • Use of XML-like tags in the phone home response
  • Names a command “nginx”, which is a fairly novel
  • Eclipse variants also contain the same bot killer, memory reduction, and similar random character generation code
  • Name overlap in some of the attacks
  • HTTP header overlap in some of the attacks

With silence’s claim of selling the project and the leak of the source code to the public, it is unclear how or if the threat actors behind the Eclipse and BlackRev campaigns are related. I do feel strongly though that Eclipse is a descendant of the BlackRev code base.


This post has been an analysis of the Trojan.Eclipse family of DDoS bots. This malware is interesting because it has a fairly rich configuration mechanism, some novel attack types, and a nice development trail leading back to the either the Trojan.BlackRev code leak or sale of the project by the author.

ASERT is just ramping up attack monitoring of this family. So far we’ve seen a handful of attacks on a consumer complaint website, a venture capital company, a forum for a Russian town, and a rating site for Russian apartment repairs. Monitoring of the attacks and family continue.

The Heartburn Over Heartbleed: OpenSSL Memory Leak Burns Slowly

By: Arbor Networks -

Marc Eisenbarth, Alison Goodrich, Roland Dobbins, Curt Wilson

A very serious vulnerability present in OpenSSL 1.0.1 for two years has been disclosed (CVE-2014-0160). This “Heartbleed” vulnerability allows an attacker to reveal up to 64kb of memory to a connected client or server. This buffer-over-read vulnerability can be used in rapid succession to exfiltration larger sections of memory, potentially exposing private keys, usernames and passwords, cookies, session tokens, email, or any other data that resides in the affected memory region. This flaw does not affect versions of OpenSSL prior to 1.0.1.  This is an extremely serious situation, which highlights the manual nature of the tasks required to secure critical Internet services such as basic encryption and privacy protection.

As the vulnerability has been present for over two years, many modern operating systems and applications have deployed vulnerable versions of OpenSSL. OpenSSL is the default cryptographic library for Apache and nginx Web server applications, which together account for an estimated two-thirds of all Web servers. OpenSSL is also used in a variety of operating systems, including BSD variants such as FreeBSD, and Linux distributions such as Ubuntu, CENTOS, Fedora and more. Other networking gear such as load-balancers, reverse proxies, VPN concentrators, and various types of embedded devices are also potentially vulnerable if they rely on OpenSSL, which many do. Additionally, since the vulnerability’s disclosure, several high-profile sites such as Yahoo Mail, Lastpass, and the main FBI site have reportedly leaked information. Others have discussed the impact on underground economy crime forums, which were reportedly vulnerable to the matter and were attacked.

A key lesson is that OpenSSL, which is a vital component of the confidentiality and integrity of uncounted systems, applications and sites across the Internet, is an underfunded, volunteer-run project, which is desperately in need of major sponsorship and attendant allocation of resources.

Anyone running OpenSSL on a server should upgrade to version 1.0.1g. For earlier versions, re-compiling with the OPENSSL_NO_HEARTBEATS flag enabled will mitigate this vulnerability. For OpenSSL 1.0.2, the vulnerability will be fixed in 1.0.2-beta2. In terms of remediation, there’s a huge amount of work that must be done, not only for servers, but also for load-balancers, reverse proxies, VPN concentrators, various types of embedded devices, etc.  Applications which were statically compiled against vulnerable versions of the underlying OpenSSL libraries must be re-complied; private keys must be invalidated, re-generated, and re-issued; certificates must be invalidated, re-generated, and re-issued – and there are a whole host of problems and operational challenges associated with these vital procedures. Some systems may be difficult to patch, so network access control restrictions or the deployment of non-vulnerable proxies may be considered where possible to reduce the attack surface.

In most cases, exploitation of this vulnerability leaves no sign in server logs, making it difficult for organizations to know if they have been compromised. In addition, even after applying the OpenSSL patch, private keys, passwords, authentication credentials or any other data that was stored in heap memory used by OpenSSL may have already been compromised by attackers, potentially going as far back as two years. Of significant concern is the compromise of private key material, and one security organization reported that they were able to obtain this material during testing. Others reported difficulty in obtaining certificate material but were able to discover significant amounts of other sensitive data. Considering how easy it is for attackers to hammer this vulnerability over and over again in a very quick sequence, the amount of memory being disclosed can be quite substantial. Memory contents will vary depending on program state and controlling what is returned and what position in memory the contents are read from is much like a game of roulette.

Risk to Private Key Material
Security researchers in a Twitter exchange starting on April 8 2014 indicate that private keys have been extracted in testing scenarios, and other researchers suggest that attacking the servers during or just after log rotation and restart scripts run could expose private key material. This allegation has not been tested by ASERT.

For further details, please see the Twitter thread at https://twitter.com/1njected/status/453781230593769472


Incident Response and Attack Tools
While there has been some call to avoid over-reaction, organizations should strongly consider revoking and reissue certificates and private keys; otherwise, attackers can continue to use private keys they may have obtained to impersonate Websites and/or launch man-in-the-middle attacks. Users should change usernames and passwords as well, but should not enter login credentials on Websites with vulnerable OpenSSL deployments. To do so could invite attackers to compromise both the old and new credentials if they were exposed in memory.

Many tools have been made available to test for the vulnerability and these same tools are available for attackers to use as well. It is also reasonable to consider that the password reuse problem will again cause additional suffering, because the same passwords shared across multiple systems create an extension of attack surface. A shared password that provides access to a sensitive system, or to an e-mail account used for password resets, can be all that an attacker needs to infiltrate an organizations defenses along multiple fronts.

Multiple proof-of-concept exploits have already been published, and a Metasploit module has been published. Attackers of all shapes and sizes have already started using these tools or are developing their own to target vulnerable OpenSSL servers. There have been reports that scanning for vulnerable OpenSSL servers began before the disclosure of the bug was made public, although other reports suggest that these scans may not have been specifically targeting the Heartbleed vulnerability.

ATLAS Indicates Scanning Activity
ASERT has observed an increase in scanning activity on tcp/443 from our darknet monitoring infrastructure, over the past several days, most notably from Chinese IP addresses (Figure 1, below). Two IP addresses ( and observed scanning tcp/443 have been blacklisted by Spamhaus for exploit activity. Scans from Chinese sources are predominately coming from AS4143 (CHINANET-BACKBONE) and AS23724 (CHINANET-IDC-BJ-AP).

Figure 1:       TCP/443 scans, Tuesday – Wednesday (April 8-9)



Attacks observed by ASERT decreased by Thursday as of this report writing. China still accounted for the largest percentage of detected scan activity:

Figure 2:       TCP/443 scans, Thursday (April 10)



Pravail Security Analytics Detection Capabilities

Arbors Pravail Security Analytics system provides detection for this vulnerability using the following rules:

2018375 ­ ET CURRENT_EVENTS TLS HeartBeat Request (Server Intiated)

2018376 ­ ET CURRENT_EVENTS TLS HeartBeat Request (Client Intiated)

2018377 ­ ET CURRENT_EVENTS Possible OpenSSL HeartBleed Large HeartBeat
Response (Client Init Vuln Server)

2018378 ­ ET CURRENT_EVENTS Possible OpenSSL HeartBleed Large HeartBeat
Response (Server Init Vuln Client)

Examples of detection capabilities are reproduced below.


Heartbleed detection tool screenshot

Heartbleed detection tool screenshot


Analysis of Historical Packet Captures Using New Indicators
In the event of this, and other security threats that are highly emergent, organizations may wish to consider implementing analysis capabilities on archived packet captures in order to detect first signs of attack activity. Granular analysis using fresh indicators can help pinpoint where and when a targeted attack (or a commodity malware attack, for that matter) may have first entered the network, or when such attackers may have exfiltrated data using a technique that was not yet being detected on the wire during the time of the initial attack and infiltration. The capabilities of Pravail Security Analytics will give organizations the means to accomplish such an analysis. A free account is available at https://www.pravail.com/ and rest assured that this site is using the latest non-vulnerable OpenSSl version.

Longer-Term Implications and Lessons Learned
Serious questions have been raised regarding the notification process surrounding this vulnerability.  The operational community at large have voiced serious disapproval surrounding the early notification of a single content delivery network (CDN) provider, while operating system vendors and distribution providers, not to mention the governmental and financial sectors, were left in the dark and discovered this issue only after it was publicly disclosed via a marketing-related weblog post by the CDN vendor in question.  It has been suggested that the responsible disclosure best practices developed and broadly adopted by the industry over the last decade were in fact bypassed in this case, and concerns have been voiced regarding the propriety and integrity of the disclosure process in this instance.

Recent indications that a significant number of client applications may be utilizing vulnerable versions of OpenSSL as well has broad implications, given the propensity of non-specialist users to ignore software updates and to continue unheedingly running older versions of code.

Furthermore, only ~6% of TLS-enabled Websites (and an undetermined, but most probably even-smaller percentage of other types of systems) make use of Perfect Forward Secrecy (PFS). This configurable option ensures that if an issue of this nature arises, previously encrypted traffic retained in packet captures isn’t susceptible to retrospective cryptanalysis.

Without PFS, there are no automated safeguards that can ameliorate these issues, once a vulnerability of this nature has been exposed.  Many operators and users may not realize that if attackers captured packets of encrypted traffic in the past from vulnerable services/applications which weren’t configured with PFS – i.e., the overwhelming majority of such systems – and have retained those captured packets, they’ve the opportunity now to use analysis tools to replay those packets and decrypt the Internet traffic contained in those packets. This means that attackers can potentially unearth their credentials, intellectual property, personal financial information, etc. with access to previously captured packet-dumps.

The ability for an attacker to decrypt packet capture archives requires that the attacker has obtained the private keys used to encrypt that traffic. As recent research shows, this is not a theoretical vulnerability – private key material has been compromised in a lab environment and therefore we must assume that attackers have at least the same, if not more substantial capabilities.

The ‘Heartbleed’ vulnerability may well result in an underground market in ‘vintage’ packet captures – i.e., packet captures performed after the date this vulnerability was introduced into OpenSSL, and prior to some date in the future after which it is presumed that the most ‘interesting’ servers, services, applications, and devices have been remediated.

This incident has the potential to evolve into a massive 21st-Century, criminalized, Internet-wide version of the Venona Project, targeting the entire population of Internet users who had the ill fortune to unknowingly make use of encrypted applications or services running vulnerable versions of OpenSSL. This highlights the paradox of generalized cryptographic systems in use over the Internet today.

While the level of complexity required to correctly design and implement cryptosystems means that in most situations, developers should utilize well-known cryptographic utilities and libraries such as OpenSSL, the dangers of a cryptographic near-monoculture have been graphically demonstrated by the still-evolving Heartbleed saga.  Further complicating the situation is the uncomfortable fact that enterprises, governments, and individuals have been reaping the benefits of the work of the volunteer OpenSSL development team without contributing the minimal amounts time, effort, and resources to ensure that this vital pillar of integrity and confidentiality receives the necessary investment required to guarantee its continued refinement and validation.

This is an untenable situation, and it is clear that the current development model for OpenSSL is unsustainable in the modern era of widespread eavesdropping and rapid exploitation of vulnerabilities by malefactors of all stripes. Information on how to support the OpenSSl effort can be found here: https://www.openssl.org/support/

Heartbleed and Availability
While Heartbleed is a direct threat to confidentiality, there are also potential implications for availability.

In some cases, attackers seeking exploitable hosts may scan and/or try to exploit this vulnerability so aggressively that they inadvertently DoS the very hosts they’re seeking to compromise. Organizations should be cognizant of this threat and ensure that the appropriate availability protections are in place so that their systems can be defended against both deliberate and inadvertent DDoS attacks.

It should also be noted that initial experimentation seems to indicate that it’s easiest for attackers to extract the private keys from vulnerable OpenSSL-enabled applications and services, using the least amount of exploit traffic, immediately after they have been started.  Accordingly, organizations should be prepared to defend against DDoS attacks intended to cause state exhaustion and service unavailability for SSL-enabled servers, load-balancers, reverse proxies, VPN concentrators, etc.  The purpose of such DDoS attacks would be to force targeted organizations to re-start these services in order to recover from the DDoS attacks, thus providing the attackers with a greater chance of capturing leaked private keys.

http://www.seacat.mobi/blog/heartbleed Note: This event may have been a false positive caused by ErrataSec’s masscan software (http://blog.erratasec.com/2014/04/no-we-werent-scanning-for-hearbleed.html)

Venona Project: http://en.wikipedia.org/wiki/Venona>
PFS: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

Can I Play with Madness?

By: Jason Jones -

Madness Pro is a relatively recent DDoS bot, first  seen by ASERT in the second half of 2013 and also profiled by Kafeine in October 2013. Kafeine’s blogpost gave good insight into one method of infection and how quickly a potent DDoS botnet can be built. This post will take a deeper-dive into what Madness does upon infection of a system and what its attack capabilities are.


Madness uses standard methods to achieve persistence on the system and evade detection. For persistence, it sets up autorun via:

  • HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun if the user does not have admin privileges
  • via HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionpoliciesExplorerRun
  • if that fails to HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun if the user does have admin privileges

It also creates 4 files in the user’s home folder named per, perper, perperper, perperperper (hint: search for these filenames on malwr.com to find more samples :) ) that contain the registry key values above followed by [7] and [8] for WORLD_FULL_ACCESS and WORLD_READ_ACCESS and run regini on the file to setup the registry permissions on those registry keys before doing the above. A mutex named GH5K-GKL8-CPP4-DE24 will also be created to block multiple installations of Madness (since the mutex we have observed has been the same across all samples we have encountered, it also blocks competitors). It will then attempt to bypass the firewall in Windows XP/Vista/7/8 by turning it off the service  and then disabling autostart of that service.

Many of the interesting strings are encoded with Base64, which include the above-mentioned registry keys, commands, mutex values and operating system names. This makes many of the strings very recognizable and easy to identify with a Yara rule. One example rule has been committed to our GitHub repository.


Capability-wise, Madness Pro has a large number of DDoS attacks and a download and execute command. The latest version we have observed in the wild is 1.15. The network phone-homes for Madness resemble the WireShark screenshot below. They include a unique randomly-generated bot ID, a version, the mk parameter, the OS version, privilege level on the system, c – a counter for the number of phone homes, rq – a counter for the number of successful attack payloads sent since the last phone-home. The response from the server is a base64-encoded, newline-separated list of commands. Multiple targets can be specified per command by separating them with a semicolon.

Madness Phone-Home

Madness Phone-Home

I also wrote a Suricata / Snort rule to detect these phone-homes:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"[ASERT] TROJAN W32/Madness Checkin"; flow:established,to_server; content:"GET"; http_method; content: "?uid="; pcre: "/?uidx3d[0-9]{8}x26verx3d[0-9].[0-9]{2}x26mkx3d[0-9a-f]{6}x26osx3d[A-Za-z0-9]+x26rsx3d[a-z]+x26cx3d[0-9]+x26rqx3d[0-9]+/"; reference:url,www.arbornetworks.com/asert/2014/01/can-i-play-with-madness/; reference:md5,3e4107ccf956e2fc7af171adf3c18f0a; classtype:trojan-activity; sid:3000001; rev:1;)

The DDoS attacks use a combination of WinSock, WinInet (InternetOpenRequestA + HttpSendRequestA), and UrlMon (URLDownloadToFileA) functions. The identified commands are shown below:

exe   - download and execute file
wtf   - stop attacks
dd1   - GET Flood using WinSock
dc1   - AntiCookie GET Flood using WinSockds1   - Slow GET Flood using WinSock
dd2   - POST Flood Using WinSock
dd3   - GET Flood Using WinInet
dd4   - POST Flood Using WinInet
dd5   - ICMP Flood Using WinSock
dd6   - UDP Flood Using WinSock
dd7   - HTTP Flood Using URLDownloadToFileA

The POST and UDP floods both support specification of flood text by appending ‘@@@’ and then the flood text (default is ‘flud_text’). The Cookie recognition code will look for document.cookie and cookies specified of the form [“cookie”,”realauth=<value>”,”location”] and attempt to parse the value out.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060731 Firefox/ Flock/
Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; m18) Gecko/20010131 Netscape6/6.01
Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 6.2; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.2; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.6) Gecko/20011128
Mozilla/4.0 (MobilePhone SCP-5500/US/1.0) NetFront/3.0 MMP/2.0 (compatible; Googlebot/2.1; http://www.google.com/bot.html)
Mozilla/4.0 (Windows; U; Windows NT 6.1; nl; rv: Gecko/20100401 Firefox/3.6.3
Mozilla/4.0 (Windows NT 5.1; U; en) Presto/2.5.22 Version/10.50
Mozilla/4.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020326
Opera/10.80 (SunOS 5.8 sun4u; U) Opera 10.8 [en]

The flood template for the WinSock POST request is below, note that the Referer and Cookie headers are only included in the attack if there are referer and cookie values. The user-agent will be incrementally selected from the list above (although the AntiCookie code has a small bug :) ). The WinSock GET and AntiCookie GET attacks use similar templates sans the POST data and of course with the GET HTTP verb instead of POST HTTP verb.

POST <uri> HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
Host: <target>
Content-Length: <length>
User-Agent: <user-agent from list>
Referer: <referer>
Cookie: <cookie>
Cache-Control: no-cache
Connection: Keep-Alive

<post data>

The Slow GET flood only sends the GET request and a Host header, sleeps for 100 milliseconds, and then send the rnrn to finish the request.

The UDP and ICMP floods are pretty standard compared to most other DDoS bots. The download and execute command functionality has been used sparingly from the CnCs that we have tracked, except for….

Playing with Madness

Sometimes a botnet admin mistakenly gives you an FTP download link with server credentials that allows for retrieval of an intact panel that includes credentials for the admin area of the web panel. Fortunately, this admin only had a total of 10 bots and at least 3 of those were researchers :). There’s not much more to the admin panel than what is showed in the screenshot below:

Madness Panel 1.13

Madness Panel 1.13

Madness Symbols

Madness Symbols

Sometimes the malware author forgets to run ‘strip’ on the binaries he’s generating for customers and these end up in my hands. Unfortunately not until after I had finished my initial reversing, but I was able to validate my analysis and also investigate identify a few things I had not noticed before. One of the interesting things that was not referenced in any calls in that version (and has been since – now the dc1 attack) was the WinSockGetAntiCookies function and in the latest 1.15 version.

We’ve also had Madness in our botnet tracking system for a number of months and have some interesting data on some of the sites that have been targeted. One of the most popular targets appears to be the ”underground” forum fuckav.ru, but the botnets do not appear to be very large as the availability of the site does not appear to be affected very much. The locations of the CnCs tracked are fairly geographically disparate –  locations that we have found CnCs hosted include the United States, Russia, Slovakia, Netherlands, and France.


Given the breadth of the DDoS attacks available in Madness and the ability to attack large numbers of targets at the same time, it does not appear that Madness will be going away anytime soon in the DDoS space. A number of very active CnCs have been observed so far, and we can only expect to see more in the future.

Related MD5:

Happy Holidays: Point of Sale Malware Campaigns Targeting Credit and Debit Cards

By: cwilson -

Inside Recent Point-of-Sale Malware Campaign Activities

Curt Wilson, Dave Loftus, Matt Bing

An active Point of Sale (PoS) compromise campaign designed to steal credit and debit card data using the Dexter and Project Hook malware has been detected. Indicators of compromise will be provided for mitigation and detection purposes. Prior to the publication of this Threat Intelligence document (embedded at the end of this post), members of the FS-ISAC, major Credit Card vendors and law enforcement were notified.

It appears that there are at least three distinct versions of Dexter:

  1. Stardust (looks to be an older version, perhaps version 1)
  2. Millenium (note spelling)
  3. Revelation (two observed malware samples; has the capability to use FTP to exfiltrate data)

In early November 2013, ASERT researchers discovered two servers hosting Dexter and other POS malware to include Project Hook.  The Dexter campaign looks more active, especially in the Eastern Hemisphere and therefore shall be the main focus herein. Dexter, first documented by Seculert in December 2012, is a Windows-based malware used to steal credit card data from PoS systems. The exact method of compromise is not currently known, however PoS systems suffer from the same security challenges that any other Windows-based deployment does. Network and host-based vulnerabilities (such as default or weak credentials accessible over Remote Desktop and open wireless networks that include a PoS machine), misuse, social engineering and physical access are likely candidates for infection. Additionally, potential brittleness and obvious criticality of PoS systems may be a factor in the reportedly slow patch deployment process on PoS machines, which increases risk. Smaller businesses are likely an easier target due to reduced security. While the attackers may receive less card data from smaller retailers, infections may be more numerous and last longer due to the lack of security reporting and security staff in such environments.

Figure 1: Dexter (Purple) and Project Hook (Orange) infections in the Eastern Hemisphere

Dexter and Project Hook infections in the eastern hemisphere

Figure 2: Dexter (Purple) and Project Hook (Orange) infections in the western hemisphere

Screen Shot 2013-12-03 at 1.22.00 AM

For the full document to include a list of various compromise indicators and information about the back-end infrastructure, please download the full public report –

Dexter and Project Hook Break the Bank


Athena, A DDoS Malware Odyssey

By: Jason Jones -

The Athena malware family  has existed for quite some time and appears to have a love/hate relationship based on posts in various “underground” forums . The original version was IRC-based, but earlier this year an HTTP-based version was released. While not as prevalent as other malware families, Athena has had a strong presence in our malware processing system for quite some time. This blog post will discuss it’s origins, DDoS capabilities, and go over it’s latest evolution and offer some details on how to identify it.

Athena’s IRC Origins

I first discovered Athena via a Pastebin post that showed an IRC log of someone ordering attacks via an IRC channel. Some googling and then subsequent searching of our zoo for the patterns yielded a wide range of versions of Athena IRC. Many of these appeared to be used to install other malware and not so much for DDoS. The majority of CnC would put a few sets of initial commands in the IRC channel topic to order their bots to botkill, download other malware, attack a specific site, etc. Athena IRC also used a recognizable IRC nick format:

n[<country>|<privilege>|<desktop/laptop>|<OS version>|<architecture>|??][a-z]{8}
AthenaIRC 2.3.1 Manual Cover

AthenaIRC 2.3.1 Manual Cover

Athena has been around for a number of years and is the product of a programmer who goes by the handle “_Stoner“. In the 1.X days of Athena IRC, builders were distributed, but these were cracked and posted online for anyone to use in botnet building escapades without having to purchase. Some of these cracked builders contained strings disparaging the quality of Athena and also referenced IPKiller (aka MP-DDOS) being  superior.

The 2.X versions saw this distribution model change and _Stoner now controls the building and distribution of binaries for his customers. Judging from forum posts and proliferation of various versions that we have seen come through our zoo business seems to be going well. However, there are numerous complaints on some of the forums about _Stoner going into their IRC servers and channels and taking control of their botnets. He is quick to respond that this is not the case, but that does not appear to help his reputation in some of the underground communities. The version 2 series also saw a significant amount of commands added: more DDoS commands, more password stealing functionality, “IRC War” commands, file find and upload, etc. The bot also optionally features an “encrypted” IP option for the CnC that  obfuscates the IP address  by adding or subtracting a static value from each octet of the IP depending on where it falls in the top or bottom half of the valid octet range. This feature was observed in our sandboxing system many times where a CnC hostname pointed to an IP, but a different IP was then connected to for CnC – quite confusing initially, but easy to spot once we found out some of the binaries had this feature. Athena also has encrypted commands that simply use a lookup table to find an index into a keyring and then a secondary lookup to get the decrypted character.

The pricing structure for 2.3.1 is $100 for one build, $10 to rebuild or update, $15 to have _Stoner setup your IRC, and $130 for a ready-made IRC channel that is “capable of holding 20k bots” and one build.

Athena, Goddess of IRC War?

Not quite :) When I first started reversing Athena IRC, I felt like I was Daedalus trying to navigate the Labyrinth. I finally found my way to an exit and avoided the Minotaur whilst discovering where the DDoS commands were processed.

Athena IRC Command Parsing

Athena IRC Command Parsing

Athena offers many DDoS attacks including standard HTTP GET/POST floods, UDP flood, RUDY, Slowloris, Slowpost, ARME, HTTP flood via hidden browser, bandwidth floods and an established connection flood attack.  The attacks perform as advertised, but, unlike other DDoS bots, only one attack at a time can be carried out. This severely limits its ability to compete in the underground DDoS-for-hire marketspace with other bots like Madness, Drive, and DirtJumper

For its HTTP-based attacks, Athena uses one subroutine to construct the HTTP request template. Random numbers are generated and if they are above or below certain values then different values are selected for the header and in some cases the randomly generated value is used to determin whether or not to include a header at all. The image below illustrates the possible headers that are include and the potential values for those that are to be included. Green means the value is selected based on which attack is ordered, values in black are always included, headers in blue are randomly included and then the red values are the values that the final header value is selected from.

Athena HTTP Request Building

Athena HTTP Request Building

Athena Moves to HTTP

The HTTP version of Athena first popped onto my radar in late March of this year when Exposed Botnets covered it for the first time, but I was not able to locate any samples at the time. Fast forward a few weeks and many samples started flowing our way.

The command and control protocol for Athena HTTP is fairly interesting. There are three parameters – a,b and c – that are sent with the POST request to the CnC. The a parameter is a fully URL encoded base64 string, that will provide a colon separated string translation table. The string translation table will be used on the b parameter which is another base64 string – this time not URL encoded – and then base64 decoded to yield the phone-home data of the bot, and c is used as a data marker on the response from the server. The initial phone home format format string is below, where gend is the “gender” (laptop,desktop,etc.), ver is the Athena HTTP version installed, net is the .NET version installed, and the rest are fairly self-explanatory.


and then subsequent phone-homes will use this format string. The bk_ signify “botkill” data, and busy signifies whether or not the bot is busy with a command.


The server will use the string translation table sent by the bot on the set of newline-separated, base64-encoded commands before adding the data marker to the front of the string. Without the original phone-home from the bot, this makes determining the commands sent by the cnc extremely difficult. The commands sent by the CnC are pipe-delimited with taskid=<task id> in the first part and then command=<command>  in the 2nd part.

The commands actually follow the exact same structure as the IRC version and the same parsing method is used once the command is extracted and some examples are presented below:

|taskid=120|command=!ddos.layer4.udp <target-site> <port> <time>|
|taskid=115|command=!ddos.http.bandwidth <target-url> <port> <time>|
|taskid=37|command=!download <target-url> 1|

A script to decode the phone-home and display commands is included in the ASERT GitHub repository.

Athena Commands Her DDoS Army

Some careless botnet admins left archives of their control panels floating around on their CnCs which greatly sped up my reverse engineering of how the Athena HTTP binaries were operating. The server-side PHP code has a decent amount of obfuscation, but it is not terribly difficult to bypass. The screenshots below show the stages of deobfuscation that I went through when recovering to readable PHP code:

The panel isn’t anything flashy, but is quite usable and shows the state of all bots and commands. I fired up an internal version of the control panel to experiment with and the results are below (please note: these are not real commands, all fake):

Athena, Beyond DDoS

Athena HTTP shares the previously described weakness of only being able to carry out one attack at a time and has not been observed to be nearly as active in the DDoS space as other bots monitored by ASERT. This brings up the question of what is it used for? One of most popular uses that we have observed on the CnCs that we monitor is as a pay-per-install (PPI) botnet. Over the last 6 months, we have collected over 150 new executables by monitoring what URLs were told to be downloaded. A timeline graph is shown below, unlabeled yellow dots were samples that were  unidentified by our tagging system and also did not exist on VirusTotal at the time of initial processing. Many of these turned out to be Bitcoin/LiteCoin/etc miners, while other were some password stealing applications. Apologies for the overlap on names, but it was extremely difficult to get them as non-overlapped as they are due to the high volume during a few short periods where people appeared to be testing out their new botnets :). The large gap in late August through early / October was due to a slight change in identification that caused our monitoring system to miss new samples and is not necessarily reflective of new malware not getting dropped.

Athena HTTP Dropped Malware Timeline

Athena HTTP Dropped Malware Timeline


Athena’s Achilles Heel

Easy identification via multiple means. The easily identifiable IRC nicks and recognizable HTTP POSTs discussed previously make detection on the network easy, but there are also many other ways to identify both versions of this malware. Athena – both IRC and HTTP – typically uses mutexes that look like  (UPDATE_|BACKUP_|MAIN_)-?[0-9]{10} (great for finding samples on malwr.com via mutex: search)  and additionally has many easily identifiable strings depending on the version. One such yara rule is presented below that catches many, but not all, versions of the IRC version and another rule that has so far detected all of the HTTP versions we have seen is also presented – these are also available in the Arbor Github repository. The Microsoft Security Essentials engine identifies the IRC and early versions of  Athena HTTP as Trojan:Win32/Squida.A, but has more recently started identifying Athena HTTP as Trojan:Win32/Folyris.A.


rule athena_http{
    author = "Jason Jones <jasonjones@arbor.net>"
    description= "Athena HTTP identification"
    $cmd1 = "filesearch.stop"
    $cmd2 = "rapidget"
    $cmd3 = "layer4."
    $cmd4 = "slowloris"
    $cmd5 = "rudy"
     all of ($fmt_str*) and 3 of ($cmd*)
rule athena_irc {
    author = "Jason Jones <jasonjones@arbor.net>"
    description = "Athena IRC v1.8.x, 2.x identification"
    $cmd1 = "ddos." fullword
    $cmd2 = "layer4." fullword
    $cmd3 = "war." fullword
    $cmd4 = "smartview" fullword
    $cmd5 = "ftp.upload" fullword
    $msg1 = "%s %s :%s LAYER4 Combo Flood: Stopped"
    $msg2 = "%s %s :%s IRC War: Flood started [Type: %s | Target: %s]"
    $msg3 = "%s %s :%s FTP Upload: Failed"
    $msg4 = "Athena v2"
    $msg5 = "%s %s :%s ECF Flood: Stopped [Total Connections: %ld | Rate: %ld Connections/Second]"
    // v1 strs
    $amsg1 = "ARME flood on %s/%s:%i for %i seconds [Host confirmed vulnerable"
    $amsg2 = " Rapid HTTP Combo flood on %s:%i for %i seconds"
    $amsg3 = "Began flood: %i connections every %i ms to %s:%i"
    $amsg4 = "IPKiller>Athena"
    $amsg5 = "Athena=Shit!"
    $amsg6 = "Athena-v1"
    $amsg7 = "BTC wallet.dat file found"
    $amsg8 = "MineCraft lastlogin file found"
    $amsg9 = "Process '%s' was found and scheduled for deletion upon next reboot"
    $amsg10 = "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)"
    // Athena-v1.8.3
    $amsg11 = "Rapid Connect/Disconnect"
    $amsg12 = "BTC wallet.dat found,"
    // v1 cmds
    $acmd1 = ":!arme"
    $acmd2 = ":!openurl"
    $acmd3 = ":!condis"
    $acmd4 = ":!httpcombo"
    $acmd5 = ":!urlblock"
    $acmd6 = ":!udp"
    $acmd7 = ":!btcwallet"
    (all of ($cmd*) and 3 of ($msg*)) or (5 of ($amsg*) and 5 of ($acmd*))

Related MD5:

Athena IRC


Athena HTTP


Go Back In Time →