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


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

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.

References Note: This event may have been a false positive caused by ErrataSec’s masscan software (

Venona Project:>

Bitcoin Alarm – Bitcoin stealing spam

By: Kenny MacDermid -

The rise in Bitcoin values seems to have caused an equal increase of Bitcoin spam as malware authors attempt to make money off the many new market participants. One site that was spammed to me three times in one day is I ignored it the first two times, but they must have really wanted me to look at it, so who am I not to oblidge.

Bitcoin Alarm Logo

The site promises a tool to notify you of market changes by SMS, without ever mentioning any nefarious behaviour. YouTube videos teach you what Bitcoin is, and how to install this free tool.  They even provide a link so you can donate to the author, although it appears no one has chosen to do so. This I have to download.

BitcoinAlarm Icon

The download BitcoinAlarm.exe (MD5: edfa12d4a454b0eb786bbe92050ab88a) had just 1 hit on VirusTotal when I first scanned it (from Kaspersky). Is it a false positive on a nice free tool? Lets dig deeper.

The download is an installer. A quick strings didn’t turn up anything interesting, so lets try binwalk:

Binwalk Results - a rar archive
I carved out this RAR archive to see what it contains:

dd if=BitcoinAlarm.exe.virus of=out.rar bs=1 skip=756224
mkdir ext
unrar x out.rar ext/

Unrar results: an SFX script and 5 files.

There’s an SFX script run, lets see what it does:

CreateObject("WScript.Shell").Exec "winupdate.exe 5943564.IFW"

cat 7246235.vbe

A quick check of winupdate.exe with VirusTotal shows that it’s the valid (and non-malicious) AutoIt executable. AutoIt is a great little scripting language for Windows, it’s especially useful for automating GUI related tasks. So if winupdate.exe is AutoIt that would make 5943564.IFW an AutoIt script. It looks like it was obfuscated somewhat though:

a bunch of comments

head 5943564.IFW

Run it through

sed -e '/^;[0-9]/d'

to clean up the garbage and we end up with this script. It starts by checking if Avast is running and if so it sleeps for 20 seconds. I guess this is long enough for Avast to get bored and go look at something else:

if Avast, sleep for 20 seconds

Well, that’s certainly not a good sign. It’s a pretty solid chance that if software is checking for an antivirus engine that it’s up to no good. A scan of the rest of the file contains other interesting methods like “disable_uac”, “anti_hook”, “persistence”, “botkiller”, “downloader”, “disable_syste_restore”. It’s starting to look like Kaspersky was right, congrats on being the 1/49 to detect this.

I see a lot of calls to IniRead(), and they’re all reading 65901.PPZ. It looks like this is the configuration file. In contains:


Matching these to the script we see find the sections are:

# 6404000 == disable_uac()
# 2244034 == AdlibRegister("anti_hook", 500)
# 3206254 == AdlibRegister("persistence", 500)
# 5378250 == startup()
# 1109021 == $sKey

This crypto key is used in Main to decrypt and run the file 20070.RQT:

decrypt and run 20070.RQT with cryptkey

The easiest way to decrypt this file was to simply let the script do the work. There’s a lot of code outside of functions though, so care has to be taken to remove everything non-crypto related. Remove the _RunPE() and replace it with

FileWrite($uniscriptdir & "DECRYPTED", $sArquive)

The decrypted file had 30/48 hits of VirusTotal when I scanned it (MD5: 224c73f8172123e5ddca2302425664a6). It’s called NetWiredRC and is a remote access trojan made for stealing login information, and likely in this case being used to steal Bitcoins. It connect to on port 3360.

Some choice credential related strings from the decrypted malware:

select *  from moz_logins
SoftwareMicrosoftInternet ExplorerIntelliFormsStorage2

This free utility is nothing more than malware with very low detection rate being spammed to anyone that might have a Bitcoin sitting around. When I checked the domain with urlvoid it had zero ‘bad’ reports and was not blacklisted. I’ve since submitted the domain to multiple scanners and it’s now detected by Scumware.

On a recheck BitcoinAlarm.exe’s detection is up to 14 of 49 scanners, and the download link appears to return 404. is no longer answering on port 3360.

Never before has it been so easy to leave cash accessible from the Internet, so expect more malware to make off with your Bitcoin wallet. Bitcoins that are not in use should be moved off into cold storage, or donated to the human fund at 136K8a5Mb8uDguFb7RnoXz7gzBSe2xaEED (ahem, worth a shot right?).

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


Scavenging Connections On Dynamic-IP Networks Redux

By: Dennis Schwarz -

While a lot has changed since Seth McGann’s 1998 Phrack magazine article “Scavenging Connections On Dynamic-IP Networks,” it’s not hard to extrapolate his idea into modern day malware sinkholes. In this blog post we would like to share some of the connections scavenged over a short period from the No-IP dynamic DNS network–a network we run into time and time again in our malware analysis.

Malware campaigns have not been shy about using these and other dynamic DNS hostnames for their command & control (C&C) servers. With the price (free), dynamic nature, and anonymity (throw-away email addresses and proxies) it’s not hard to see the appeal. Using available APIs, malware authors are building in support directly into their bot builder kits as well.


 No-IP support built-in to the Xtreme Remote Access Trojan (RAT)

Querying our malware zoo for the main free tier domain ( returns almost 6500 unique subdomains. As of this writing, about 4200 (64%) of these no longer resolve and are expired. As a proof of concept, we re-registered 100 of these sub-domains (see Appendix A) and in 4 groups of 25 sinkholed them for 3-4 days at a time. We used a simple sinkhole that redirected all TCP ports minus SSH (22) to a Python daemon that limited the connection time to 5 seconds and logged the first 2048 received bytes.

Disregarding general Internet background noise (hi, proxy scanners, and SQL Slammer), we received connections from around 6650 unique IPs distributed across the globe.


Map of source IPs connecting to a two-week sinkhole of 100 domains

Considering the low number of domains that were registered, many surprises and concerns cropped up. The sheer number of unique sources, geographical distribution, amount of traffic generated by abandoned bots (close to 7 GB of PCAP data), and the variety of malware families was interesting and insightful. There was good representation of both ASCII and binary blob communications, but the latter was more prevalent. The number of HTTP based phone homes was also lower than expected. Further analysis reveals the following interesting elements.

Xtreme RAT

There were two types of phone homes. The first includes a version string and we saw 2.9, 3.1, 3.2, and 3.5 Private (as of this writing, 3.6 is the latest publicly available). The second type of phone home message includes the password used in the campaign and we saw 123123, 87080060, and 1234567890 (default).

Type 1 (130 unique IPs)


Type 2 (57 unique IPs)

GET /1234567890.functions HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/5.0; 
SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center 
PC 6.0; InfoPath.2; .NET4.0C)
Connection: Keep-Alive
Cache-Control: no-cache


Two types of phone homes were seen.

Type 1 (54 unique IPs)


Type 2 (215 unique IPs)


Various IRC Bots (325 unique IPs)

As expected, IRC based bots were well represented. Some sample nicknames:

  • [iRooT-XP-CRI]702619
  • ESP|00|XP|SP3|8254484
  • {00-ITA-2K-ASP–6618}
  • ScAry0518258
  • pwned[00000]

Turkojan (75 unique IPs)


CIA Trojan (3 unique IPs)

details;6333;Administrator;HOME;name;CIA 1.3;No;name

GhostHeart2 (2 unique IPs)

Starting at offset 13, zlib chunk.

00000000  47 68 30 73 74 61 00 00  00 b0 02 00 00 78 9c 4b Gh0sta.. .....x.K
00000010  63 60 60 98 03 c4 ac 40  cc 04 c4 e7 f8 20 f4 40 c``....@ ..... .@
00000020  02 0b 28 2d c4 c8 cc f0  81 0b e2 9e 03 2b 18 78 ..(-.... .....+.x
00000030  f2 72 72 93 49 35 ab 9c  91 81 e1 1e 2f 03 c3 17 .rr.I5.. ..../...
00000040  20 6d 64 60 68 84 2e 6f  7c e6 0d a5 ce 1d 05 54  md`h..o |......T
00000050  04 47 d6 9c 38 bf fd da  f5 97 b8 e4 01 82 d8 11 .G..8... ........
00000060  ac

MyRat (16 unique IPs)

Starting at offset 13, looks like a zlib chunk.

00000000  4d 79 52 61 74 b8 00 00  00 24 01 00 00 78 9c 4b MyRat... .$...x.K
00000010  8b 33 61 9a c3 c0 c0 c0  0a c4 8c 40 ac c1 c5 c0 .3a..... ...@....
00000020  c0 04 a4 83 53 8b ca 32  93 53 15 02 12 93 b3 15 ....S..2 .S......
00000030  8c 19 18 ae c4 98 30 fd  60 40 00 90 da 1b 46 4f ......0. `@....FO
00000040  18 5a 7d 67 17 86 c4 9a  80 b4 30 74 4a cd 2f 04 .Z}g.... ..0tJ./.
00000050  a9 b1 b0 16 66 c8 60 80  e8 61 66 80 98 07 52 cf ....f.`. .af...R.
00000060  06 c4 02 50 8c 02 14 a0  18 aa ee 25 50 13 33 98 ...P.... ...%P.3.
00000070  c3 c8 70 60 05 a3 e9 32  a0 e0 22 a8 bb 18 8a 0b ..p`...2 ..".....
00000080  52 53 53 d0 0d c0 0e fe  b3 33 30 5c 04 ea cd ae RSS..... .30....
00000090  48 2d 4e ce 2f 4a 65 00  ba 6b 81 2a 44 6e 31 d0 H-N./Je. .k.*Dn1.
000000A0  df 30 3b 97 dd de 70 6a  49 f8 de d2 a5 2e fb be .0;...pj I.......
000000B0  63 33 07 00 3f 40 28 73                          c3..?@(s

YoyoDDoS (471 unique IPs)

0xb8 variant.

00000000  79 6d 74 d8 68 90 95 8e  8f 8d d0 84 8d d1 d8 c1 ymt.h... ........
00000010  c6 c5 c8 d8 69 85 99 94  cd 7b 8f 8a 95 d8 68 8a ....i... .{....h.
00000020  8f 9b 95 8b 8b 8f 8a b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000030  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000040  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000050  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000060  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000070  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000080  cb cb ca c7 6d 7a b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........
00000090  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
000000A0  67 91 8e d8 60 68 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 g...`h.. ........
000000B0  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
000000C0  e8 59 3c 56 3c 56 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 .Y<V
000000D0  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
000000E0  e1 b7 b8 b8                                      ....

Trojan.DDoser (5 unique IPs)

Base64 encoded.


Spy-Net RAT (19 unique IPs)

Base64 encoded.


Unknown #1 (2 unique IPs)

104|OnConnect|United States|me|name - me||Not Detected|4.0.4 Update 2
|United States|OnConnect|

Unknown #2 (2 unique IPs)
Two version numbers were seen: 4.0 and 6.0.

LOGIN|Slovakia#SK|name and something like a password hash|#!#|pixel|name|name-
PC|Windows 7|Connection Established|Intel(R) Pentium(R) M processor 1600MHz 1598MHz
|0,5|Not Available|Not Available||140|4.0|123456

Unknown #3 (16 unique IPs)

Two version numbers were seen: 0.7 and 1.2.


This analysis of a small sample of No-IP domains and their associated malware gives us a tiny peek into some, possibly forgotten, attack campaigns and how active they can be. While No-IP and other dynamic DNS hostnames shouldn’t automatically be assumed to be bad, we feel they warrant further scrutiny and attention if seen on your networks.

It should come as no surprise  that there is a lot of malware out there, in all sorts of shapes and sizes. Sinkholing is just another tool in the malware researcher’s toolbox for the endless task of classifying, analyzing, and mitigating the shadier half of the Internet. In the meantime, the ASERT team work continues on the sinkholing project. Goals include expanding the scope, automating collection and classification as much as possible, and, of course, integrating the data into the ATLAS portal.


 Appendix 1: Domains 

Between Nov


Between Nov 9 – 12



Between Nov 13 –


Between Nov 16 – 19:




How likely is a DDoS Armageddon attack?

By: Carlos Morales -

The recent DDoS attacks against many of the North American financial firms had some unique characteristics that put a strain on the defenses in place and resulted in a number of well publicized service outages. The escalating threat is not new.  It’s been steadily building up over the last few years as botnet command and control has matured, the tools available to exploit those botnets have gone mainstream, and the cost of using the tools has plummeted.  What the attacks did do is raise the industry’s collective consciousness around how bad the situation has gotten.    The effectiveness of the attacks has changed the way that Internet operators, whether service provider, hosting provider, government or enterprise think about their defenses.   It has also raised a number of troubling questions.

The most common question that I have been asked is around the growing size of attacks and the capacity of Internet operators to withstand such threats.   How big does an attack have to be to overwhelm the biggest, most prepared financial company?   How big does an attack have to be to overwhelm the biggest and most prepared service provider?   Is there an Armageddon attack on the horizon that threatens to take down the entire Internet?  There are indications that this could be the case.

It should be noted that size is by no means the only means by which an attack can be effective.  It’s a very visible way of taking down a network similar to the way a 7 mile backup on a local highway is a visible sign that you’re not getting to your destination quickly.   Application layer attacks, IP protocol attacks, connection attacks and other stealthy attack methods can be just as effective in taking down a victim while being much more difficult to detect and mitigate.  The financial sector attacks were multi-vector and had aspects of both volumetric and application layer attack traffic.

This article is going to focus on larger sized attacks and the possibility of an Armageddon attack.   First, there are a few different measures of size including bandwidth (bps), packets (pps) and connections (cps).    In all three cases Internet operators such as enterprises will have a limit which they can handle.   Bps is the most commonly considered measure of size and it is easy to estimate network bandwidth limits.  If the internet operator has 10Gbps worth of upstream bandwidth, then attacks bigger than this will overwhelm the links.   Packet per second (pps) limits are more of a challenge to estimate limits because each device that is in-line with traffic will have limits in handling pps that will be dependent on the configurations that they are running and the type of traffic seen.   High pps attacks often cause more challenges than high bps attacks because multiple bottlenecks may exist on the network.     High cps attacks are typically targeted at stateful devices on the network that have a connection table.   These tend to be the harder to measure because network traffic analyzers tend to focus on just bps or pps.

With all three attack types, all enterprise, government and hosting provider networks will have bottlenecks that can be over-run relatively easily by big DDoS attacks.  Most enterprise and government datacenters have no more than 10 Gbps with some ranging slightly higher than this.   Arbor Network frequently sees attacks much larger than this.  As an example, Arbor’s ATLAS system receives anonymous attack statistics from hundreds of Arbor Peakflow SP deployments.   The largest bandwidth attacks measured in 2011 and 2012 were 101.4 Gbps and 100.8 Gbps respectively.   The largest packet per second attacks measured in 2011 and 2012 were 139.7 Mpps and 82.4 Mpps respectively.   Another source of data is the annual security survey of Internet operators that Arbor runs.   One of the survey questions is about the largest bps attacks seen over the previous year.    The chart below reflects that biggest attacks reported each year since the survey was first conducted in 2002.

Based on the data from the chart above, there have been DDoS attacks capable of overwhelming a 10 Gbps datacenter since 2005.   All this means that enterprises, governments and hosting providers need help from their upstream service providers to deal with threats of this magnitude.   Many of these providers offer managed security services that will provide protection against bigger attacks.   At a certain point, the attacks are big enough that the providers consider them their responsibility anyways because of the potential impact to multiple customers.  However, it’s heavily recommended to have an agreement in place to ensure SLAS and guaranteed response times.

That brings me back to the question on whether an Armageddon attack is possible that can not only overwhelm the end victim but also all the Internet providers in between.   Based on the current Internet environment, this is all too possible.   The first thing that you need to consider what the available bandwidth is to generate an attack.   There have been botnets discovered that have contained more than 1M infected hosts.   Assuming an average of 1 Mbps worth of upstream access per host, a conservative estimate based on the number of broadband subscribers, 4G and 3G users deployed in the world, a 1M host botnet could generate an attack of 1 Tbps.   Now what if this botnet and multiple other large botnets attack at the same time?   Service providers have a lot of bandwidth throughout their network but there are limits to how much traffic they can handle.   Attacks of that magnitude described would have profound effect on the Internet as a whole exploiting bottlenecks in many places simultaneously.  No single service provider, even the largest tier ones, would be able to handle all this traffic without adversely affecting their user base.

Is this possible?  It certainly seems so.  Is it likely?   It doesn’t seem so since it would affect everyone on the Internet and not just a single victim.   That said, many attacks that didn’t seem likely before are now becoming commonplace as motivations have shifted.   It is something that CSOs from within the carrier community are likely considering and hopefully taking steps to plan for the worst.


Exterminating the RAT Part I: Dissecting Dark Comet Campaigns

By: cwilson -

It should be abundantly clear that there are serious concerns at play when dealing with Remote Access Trojans, as they are used in many espionage style attacks where sensitive data and valuable intellectual property are stolen. Occasionally, a RAT is also used to launch DDoS attacks, but these DDoS attacks are less common.  The real value of the RAT to the attacker is the core remote control functionality that breaches the confidentiality and integrity of the victim and the victim network by allowing the attacker full access to the target system. The monitoring of all keystrokes (including passwords, sensitive data entered onto secure sites), control of file upload/download, the ability to steal any file, access network shares, spy via webcam or microphone, download and install additional malware, and other features make these RATs a formidable threat when wielded by a focused attacker. A common targeted attack methodology starts with initial network penetration by compromising one or more systems and installing a RAT or something similar to a RAT that calls back to the attacker. Once the RAT is installed, that infected system becomes a valuable launching pad for the attacker to move laterally on the internal network, seeking information of value to the goals of the attackers campaign.


Arbor Networks and others have previously profiled the Dark Comet Remote Access Trojan (RAT). While the author of Dark Comet claims that the tool is not intended for malicious purposes, it has been used for  many malicious campaigns, including the recent attack on Syrian opposition leaders where the Dark Comet Trojan was delivered to them disguised as a Skype component. Dark Comet is clearly popular, free and stable enough for many attack campaigns with varying motives and therefore provides some insight into this arena.

When an organization is hit by a RAT infection, it can be helpful to attempt to determine what the attacker was up to and what indicators point towards their motives. Using a combination of open source intelligence and ASERT insight, we will try to piece together some interesting elements. While these indicators can help, unless verbose logging or system/network monitoring is in place, it can be difficult if not impossible to determine every action taken via the RAT.  Unfortunately, a “wipe and reload” approach isn’t sufficient to determine what took place.  An extensive analysis may need to be undertaken to determine the depth and scope of the breach.

We will profile several potentially interesting Dark Comet campaigns that we have discovered in this first part of the RAT series. Future entries in this series will cover other RAT campaigns of interest as our research delivers additional insights.

Interesting campaign indicators

How might we start trying to narrow down the campaigns of interest from among the 4000+ Dark Comet samples that we have in our malware analysis repository? One method might be to take a look at the passwords, server IDs and Command & Control infrastructure being used by the RAT itself. While it is of course possible for any attacker to set any password, C&C or server ID or name for any reason such as for misdirection purposes, it is also possible that these elements may reflect the intent of the campaign and give a hint towards the actors behind the scenes. It is also possible that attackers are smart enough to use very vague or generic names for all of the user-selected components of any RAT campaign in order to reduce visibility and fly under the radar.

Campaign #1: Password contains the phrase “Boeing747”

C&C Name/IP address : port Password Server ID Md5 hash Boeing747!@#Legacy123 Guest16 40f1aac00c440ed7811cd042bca1b4d8

The password caught my eye due to its contents and also the length and use of mixed case, numbers and special characters. The use of “Boeing747” may have nothing to do with a real Boeing 747 and could have just been something chosen to make a strong password. The C&C in this case is a South African IP, apparently located in an area called Centurion, which houses two Air Force bases which could account for the password reference. There is clearly not enough information available here to determine motive.  Very little public information is available when searching for the MD5, only virus scan results showing that many antivirus scans from early in 2011 provide a generic detection name, except for a vendor that alerts for “BackDoor.Comet.16” and two other vendors that alert using the name “Fynloski”.  Enterprises seeing hits that match these names need to be aware of what they are dealing with and take proper investigation measures to determine the intent and scope of the breach.

Campaign #2: Server ID “SearchandDestroy_GOV”

C&C Name/IP address : port Password Server ID Md5 hash SearchandDestroy_GOV 2770f5bd84bb585d449a7c0e1223920f

This campaign, while noisy is a little bit more interesting as it suggests that the attacker may be experimenting with redirecting .gov sites. After infection, the hosts file of the infected machine has been changed, adding the following entries:

These are all bogus domains, however it does illustrate the potential to perform a redirect or a man-in-the-middle attack on the unsuspecting user. The destination IP address is a webserver containing several virtual domains, which included “”.

The IP address of the host at the time of the attack seen in our analysis infrastructure was and currently resolves to Both IP addresses are associated with the hostnames and

Campaign #3: Server ID “server-Bifrost1.3” and hostname “”

C&C Name/IP address : port Password Server ID Md5 hash server-Bifrost1.3 0e492c93cbaec7b5d4cc432e2c66454f

The C&C name here is associated with multiple RAT campaigns. For example, we see information on an Arabic language forum thread including a user named “9D1” discussing TCP port 288 as being associated with a message about “Xtreme RAT” in late 2011.  The topic of that thread relates to password theft. Another likely Xtreme RAT campaign can be found mentioned at running on TCP port 3460 from late April 2012. We also see another Dark Comet campaign on TCP port 3333 in sandbox output which is using a default DarkComet mutex that starts with the characters DC. The mutex in this case is DC596I04Z1. Clearly, this dynamic address is up to no good.  The server name, Bifrost 1.3, could indicate that this attacker or group of attackers is also working with the Bifrost RAT.  As of May 29, 2012 this hostname points to the IP address that appears to be located in or near Cairo, Egypt.

Campaign #4: Server ID “SynBots” and C&C named “syncenter”

C&C Name/IP address : port Password Server ID Md5 hash roflcopter SynBots 4fdcc3e11d84d11df182375e83d52938

This campaign appears to be aimed at Runescape users or other gaming communities, as indicated by the sample seeking file attributes for the following files:

Runescape Dicing Hack.resources.dll

Runescape Dicing Hack.resources

Runescape Dicing Hack.resources.exe

Based on the indicators seen here, it is possible that the purpose of this particular campaign could be to build a DDoS bot, potentially for use as a host booter to boot other gamers off-line with SYN flood attacks.

Campaign #5: password used “mafia007”, Server ID “Hack Kurd”

A case of watching too much James Bond, or something more threatening?

C&C Name/IP address : port Password Server ID Md5 hash mafia007 Hack_Kurd 0e492c93cbaec7b5d4cc432e2c66454f


It looks as though this particular sample was packed using some type of .NET crypter or packer that makes the sample more difficult to analyze. The only quickly discovered public reference to this sample by its MD5 hash  is a sandbox report found at which reveals basically nothing about the sample except that it was unable to run, generating an error code “KilledByWindowsLoader”.

This sample drops a file  C:Documents and Settings[Username]Local SettingsTempAdobeUpdate.exe and attempts to enumerate elements of the Microsoft .NET runtime version 2.  Based on the nickname “mafia007” and a little bit of digging reveals that the crypter likely used here is called “Crypter Zero” or “Zero Crypter” which claims to be 100% FUD (fully undetectable by antivirus). This particular crypter is from 2011, and the authors point to an underground file-scanning service to illustrate their point. Zero Crypter is being sold for 50 euro.

While packers can complicate matters, thankfully we have memory dumps that bypass the need to perform a manual unpacking/decrypting process in many cases.

We also determine that an Italian e-mail address containing the string “mafia007” has shown much interest in Dark Comet and other Trojans and demonstrates the use of the Zero Packer on them. A similar username was found on various underground forums that had been compromised, and passwords leaked by LulzSec. resolved to during the initial sample analysis and currently resolves to Both are Italian IP addresses.

While I cannot be 100% certain, I don’t believe this person to be a serious attacker based on the weak operational security demonstrated here.  Therefore, this campaign may be a case of “too much James Bond” although appearances can be deceiving. It would not be the first time that an attacker does not attempt to hide very well.


Dark Comet is very popular RAT and is actively developed and widely used. It can be difficult to determine the motive of the attacker, however sometimes there are enough traces left over that can help us piece together the potential goals of a campaign.  RAT infections can be very serious, requiring an in-depth investigation to determine the goals of the attacker and the level of risk posed.

Future articles covering other RAT threats will emerge as part of the “Exterminating a RAT” series.





World IPv6 Launch : A Longer View

By: Scott Iekel-Johnson -

World IPv6 Launch has come and gone, and we now have the opportunity to examine its impact on Internet traffic delivery and the migration to IPv6.  While our previous blog posts focused on the day itself, this time we are taking a longer view and looking at IPv6 traffic over the past month.  This will provide some context for World IPv6 Launch, as well as allow us to see what has been happening since and whether the goal of  World IPv6 Launch to permanently enable new IPv6 services was successful.

Below is a graph showing IPv6 traffic levels for the past month as a percentage of all Internet traffic.  This data comes from the same providers we have been following, which are all of the providers sharing flow-based data with us as part of our ATLAS Internet monitoring infrastructure and which report carrying both native and tunneled IPv6 services.

As we have noted before, World IPv6 Launch wasn’t like flipping a switch and seeing a sudden spike of IPv6 traffic. Instead, it was a more gradual ramp-up of traffic starting about two weeks before the day itself. This resulted in IPv6 traffic growing from 0.06% to almost 0.15% of all Internet traffic in the weeks leading up to June 6. This is an impressive amount of growth over such a short time. We believe this more than anything else demonstrates the success of World IPv6 Launch as a tool to encourage more providers to adopt IPv6 and make IPv6 services available more broadly. Even more importantly, the increased levels of IPv6 traffic did not diminish after IPv6 Launch Day, but have remained fairly steady since then. This shows that hopefully many of the newly enabled IPv6 services are here to stay – another important milestone on the road to ubiquitous IPv6 adoption.

In addition to looking at the overall levels of IPv6 traffic growth, it is also interesting to take a look at how IPv6 is being used, and how that may have changed as a result of new IPv6 service offerings. Here is the application breakdown for native IPv6 traffic for the same month as the IPv6 traffic level measurement above. Note that it’s not possible to identify applications being used by tunneled IPv6 traffic from flow-based data – that requires direct packet inspection.

We can see that as expected HTTP traffic dominates application usage at up to around 60% of all native IPv6 traffic. It is interesting to note, however, that HTTP’s share of native IPv6 traffic grew in advance of IPv6 day, perhaps indicating increased usage of native IPv6 by “regular” Internet users. Even more interesting, if we take a closer look at certain applications that are very common in IPv4, we can see a noticeable shift in usage over the World IPv6 Launch period:

In this graph we have zoomed in on the non-HTTP applications to take a closer look at three that showed a noticeable shift over IPv6 Launch Day. DNS has historically been a much higher percentage of IPv6 traffic compared to IPv4. This is likely because IPv6 has been used less heavily by users, who consume most of the volumetric content (such as streaming video) on IPv4. Shorter and lower-volume connections (such as HTTP page loads) on IPv6 mean that the DNS lookup that precedes each connection consumes a higher relative percentage of the overall traffic volume. In the lead-up to June 6, however, we saw that change significantly, with DNS dropping from around 3% to less than 1% of IPv6 traffic. This indicates that with World IPv6 Launch more users are consuming larger amounts of content over IPv6, leaving DNS as a much smaller proportion of the traffic volume.

The growth in SSL usage over IPv6 was another interesting trend we observed and may also indicate an increase in traditional Internet activities such as banking or e-commerce taking place over IPv6. Unexpectedly, SSL traffic dropped again after World IPv6 Launch, perhaps indicating that some of those services did not maintain IPv6 access. However, levels of SSL are still significantly higher than they were before World IPv6 Launch so it would seem that at least some of these services have maintained their presence via IPv6 in the ensuing days.

Finally, although not a significant percentage of IPv6 traffic overall, POP email traffic has grown noticeably since June 6. From less than 0.01% of IPv6 traffic, it has grown to almost 1%. While not large compared to other applications, this is an important benchmark for IPv6 adoption since it indicates a core Internet service making the migration to IPv6 and IPv6 starting to look more like IPv4 in terms of usage. It’s one thing for websites to enable IPv6 for HTTP, but it means a lot more if the basic applications that make up the “plumbing” of the Internet also make the leap. This is a hopeful sign for broader IPv6 adoption and for IPv6 meeting its ultimate goal: to become a transparent and ubiquitous way for users to carry out their everyday activities on the Internet.

World IPv6 Launch: How did we get here?

By: Arbor Networks -

By Darren Anstee, Solutions Architect for EMEA and Scott Iekel-Johnson, Product Manager

Now that we are in the thick of IPv6 Launch Day and seeing the payoff to a lot of hard behind-the-scenes work on the part of many ISPs and content providers, we thought it would be interesting to take a longer look at how we got here. Was IPv6 Launch Day a flick of the switch that suddenly turned on large volumes of IPv6 traffic? Or has it been a more gradual process of testing, service enablement, and gradual rollout of IPv6 connectivity?

To answer these questions we pulled IPv6 traffic data for the last year from the same 15 native IPv6 providers that have been included in our detailed IPv6 Launch Day reports. This graph shows the amount of native and tunneled IPv6 traffic these providers have carried over the last year, expressed as a percentage share of all Internet traffic. Please note that in order to capture longer term trends, this graph is showing the daily peak rate from each provider, which may not correspond exactly to the short-term measurements provided in our other data.

The first thing we noticed was a steady increase in IPv6 traffic volume over the past year (dating back to last year’s IPv6 Day). This slow but steady growth continued up until about 1 week ago, at which point it suddenly took off. Presumably, this is due to providers testing and then turning on IPv6 services in preparation for IPv6 Launch Day.

We are very pleased to see an overall bump of up to 33% in IPv6 usage in the runup to IPv6 Launch Day. Because we are measuring IPv6 as a share of all IPv6 traffic, this means that not only was there an increase in the overall IPv6 traffic volume, but this shift represents users who were using IPv4 actually migrating to IPv6 for at least some of their Internet usage. This is exactly the type of trend we need to see if IPv6 is going to become an accepted and standard part of how people use the Internet.

World IPv6 Launch Day: Early Returns

By: Arbor Networks -

By Darren Anstee, Solutions Architect for EMEA and Scott Iekel-Johnson, Product Manager

IPv6 Launch Day has now been ongoing for several hours and we are starting to see trends emerge in the traffic data we are collecting from our ATLAS data participants.  For this analysis we have chosen to examine only those ATLAS participants who are reporting native IPv6 traffic.  This allows us to make clear and consistent comparisons between usage of native IPv6 connectivity and the use of IPv6 tunneling.  Other providers may be carrying native IPv6 traffic but are simply unable to report it due to technical limitations  (some router platforms that don’t support exporting traffic data for native IPv6 traffic).

First, let’s look at the overall volume of IPv6 traffic as observed at the peering edge of those providers which are reporting both native and IPv6 traffic to us.  These providers cover a range of sizes and locations, from Tier 1 and tier 2 ISPs, MSOs, and smaller regional providers across North America and EMEA.

As we can see, the overall volume of IPv6 traffic peaked at a higher rate last night due to an approximately 20% increase in native IPv6 traffic.  This would seem to represent an increase in the number of users and the amount of content being delivered over native IPv6 connections as providers enable more of their services for native IPv6 access.  Since then, traffic has decreased back to typical levels for the overnight low. This may indicate that participation for IPv6 day is lower in Europe, which should already be showing an increase now that Europe is well into the business day.  It could also reflect bias in the set of providers that are able to provide IPv6 measurements due to infrastructure limitations in reporting of native IPv6 traffic.

As more of North America starts it’s day we will be following the trends to see if IPv6 traffic continues to grow today to even higher levels after the official start of World IPv6 Launch Day.


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

By: jedwards -

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


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

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

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

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

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

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

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

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

Go Back In Time →