The Glider

The FBI is warning that computer crooks have begun launching debilitating cyber attacks against banks and their customers as part of a smoke screen to prevent victims from noticing simultaneous high-dollar cyber heists.

The bureau says the attacks coincide with corporate account takeovers perpetrated by thieves who are using a modified version of the ZeuS Trojan called “Gameover.” The rash of thefts come after a series of heavy spam campaigns aimed at deploying the malware, which arrives disguised as an email from the National Automated Clearing House Association (NACHA), a not-for-profit group that develops operating rules for organizations that handle electronic payments. The ZeuS variant steals passwords and gives attackers direct access to the victim’s PC and network.

In several recent attacks, as soon as thieves wired money out of a victim organization’s account, the victim’s public-facing Internet address was targeted by a network attack, leaving employees at the organization unable to browse the Web.

A few of the attacks have included an odd twist that appears to indicate the perpetrators are using money mules in the United States for at least a portion of the heists. According to an FBI advisory, some of the unauthorized wire transfers from victim organizations have been transmitted directly to high-end jewelry stores, “wherein the money mule comes to the actual store to pick up his $100K in jewels (or whatever dollar amount was wired).”

The advisory continues:

“Investigation has shown the perpetrators contact the high-end jeweler requesting to purchase precious stones and high-end watches. The perpetrators advise they will wire the money to the jeweler’s account and someone will come to pick up the merchandise. The next day, a money mule arrives at the store, the jeweler confirms the money has been transferred or is listed as ‘pending’ and releases the merchandise to the mule. Later on, the transaction is reversed or cancelled (if the financial institution caught the fraud in time) and the jeweler is out whatever jewels the money mule was able to obtain.”

The attackers also have sought to take out the Web sites of victim banks. Jose Nazario, manager of security research at Arbor Networks, a company that specializes in helping organizations weather large cyber attacks, said that although many of the bank sites hit belong to small to mid-sized financial institutions, the thieves also have taken out some of the larger banks in the course of recent e-heists.

“It’s a disturbing trend,” Nazario said.

Nazario said the handful of attacks he’s aware of in the past two weeks have involved distributed denial-of-service (DDoS) assaults launched with the help of “Dirt Jumper” or “Russkill” botnets. Dirt Jumper is a commercial crimeware kit that is sold for a few hundred bucks on the hacker underground, and is made to be surreptitiously installed on hacked PCs. The code makes it easy for the botnet owner to use those infected systems to overwhelm targeted sites with junk traffic (KrebsOnSecurity.com was the victim of a Dirt Jumper botnet attack earlier this month).

Security experts aren’t certain about the strategy behind the DDoS attacks, which are noisy and noticeable to both victims and their banks. One theory is that the perpetrators are hoping the outages will distract the banks and victims.

“The belief is the DDoS is used to deflect attention from the wire transfers as well to make them unable to reverse the transactions (if found),” the FBI said.

That strategy seemed to have worked well against Sony, which focused on weathering a DDoS attack from Anonymous while information on more than 100 million customers was being siphoned by hackers.

“In the chaos of a DDoS, typically network administrators are so busy trying to keep the network up that they miss the real attack,” said Jose Enrique Hernandez, a security expert at Prolexic, a Hollywood, Fla. based DDoS mitigation company. “It’s a basic diversion technique.”

Another theory about the DDoS-enhanced heists holds that the thieves are trying to prevent victim organizations from being able to access their accounts online. One crime gang responsible for a large number of cyber heists against small to mid-sized U.S. businesses frequently invoked the “kill operating system” command built into the ZeuS Trojan after robbing victims.

Organizations that bank online should understand that they are liable for any losses stemming from cyber fraud. I have consistently advised small to mid-sized entities to consider using a dedicated computer for online banking — one that is not used for everyday Web surfing — and preferably a non-Windows system, or a “live CD” distribution.

Cyber attacks designed to knock Web sites off line happen every day, yet shopping for a virtual hit man to launch one of these assaults has traditionally been a dicey affair. That’s starting to change: Hackers are openly competing to offer services that can take out a rival online business or to settle a score.

An ad for a DDoS attack service.

There are dozens of underground forums where members advertise their ability to execute debilitating “distributed denial-of-service” or DDoS attacks for a price. DDoS attack services tend to charge the same prices, and the average rate for taking a Web site offline is surprisingly affordable: about $5 to $10 per hour; $40 to $50 per day; $350-$400 a week; and upwards of $1,200 per month.

Of course, it pays to read the fine print before you enter into any contract. Most DDoS services charge varying rates depending on the complexity of the target’s infrastructure, and how much lead time the attack service is given to size up the mark. Still, buying in bulk always helps: One service advertised on several fraud forums offered discounts for regular and wholesale customers.

The unwitting conscripts in these cyber armies are hacked PCs that the service owners remotely control via malicious software. Some DDoS services disclose how many bots they have corralled into their armies. One service claims: “Average in-line bots from 1,500 to 5,000 bots, enough to work on challenging projects with an anti-DDoS protection, and protection type CISCO ™ GUARD.”

A DDoS gang that has been in operation for at least three years, sells a do-it-yourself DDoS kit that it markets as an easy way to build your own bot army. The Darkness DDoS army creation package includes a bot builder and a Web-based administration panel that is used to remotely monitor and control the bots.

According to the Darkness creators, the bot is continuously being updated by testers and coders (reportedly in its ninth major revision). It claims to be able to configure infected machines for use in four types of DDoS attacks at a moment’s notice, and to steal passwords stored by a variety of Web browsers and Windows programs.

“Our bot has almost no load on the system, allowing it to remain invisible for very long,” the Darkness team boasts in its ads. “Bot is lightweight and gets along well in the system.”

How many infected PCs or bots does one need to incapacitate an intended target? The individuals pimping the Darkness DDoS botnet creation package provide a handy reference.

From their ad (translated from Russian):

• 15-30 bots (!!!) knock off line a relatively small site.

• 250-280 bots – the average site.

• 750-800 bots – a large site.

• 2,000-2,500 bots – great site with Anti-DDoS protection

• 4,300-4,700 bots – a cluster of sites, even when using the Anti-DDoS protection, blocking, etc.

• 15-20 thousand bots – take offline virtually any site with any protection.

Anyone interested in a technical analysis of the software that powers these DDoS services should take a look at research from Shadowserver.org, Arbor Networks and Dell SecureWorks.

After a week long Internet outage following widespread social unrest and political protest, Egyptian Internet traffic returned to near normal levels this morning at approximately 5:30am EST.

A graph of Egyptian Internet traffic from the vantage of carriers around the world both today and throughout the week below. As in previous posts, I use data from ATLAS anonymous carrier traffic engineering statistics.

A cursory survey of Egyptian Internet infrastructure shows all major providers and web sites are once again reachable from the rest of the Internet.

While other countries, including Iran and Myanmar, experienced telecommunication disruptions following social unrest in the past, the Egyptian outage represents a new Internet milestone. For the region, Egypt enjoys one of the largest and most robust Internet infrastructures with four major national providers and a hundred or more smaller consumer and web hosting providers. Put simply, we have never seen a country as connected as Egypt completely lose Internet connectivity for such an extended period. Also as a sign of the growing importance of social media, and web sites, it is telling that Egyptian telecommunications block largely focused on the Internet — mobile and fixed line service returned earlier in the week.

Today, the Internet is as an integral part the Egyptian economy and society. Unlike periods as recent as a decade ago, governments of technically developed countries cannot disrupt telecommunication without incurring significant economic cost and social / political pressures.

I’ll update this blog and twitter (@labovit) as we get more information.

- Craig

Updated January 31: Added graph and discussion of remaining active paths

Following a week of growing protests and periodic telecommunication disruption, Egypt suddenly lost all Internet connectivity at approximately 5:20pm EST Thursday.

The below graph shows traffic to and from Egypt based on ATLAS data from 80 providers around the world.

Between 3 and 5pm EST, Egyptian traffic rapidly climbed to several Gigabits. At 5:20pm, the all Egyptian transit providers abruptly withdrew the major of Egypt’s several thousand BGP routes and traffic dropped to a handful of megabits per second.

At present, the cause of the outage is unknown though many press reports have drawn parallels to the Internet outages following Iranian political protests during the summer of 2009. Further, the simultaneous failure of Internet across multiple different Egyptian ISPs and diverse physical paths (i.e. satellite, fiber optic, etc) suggests this was a coordinated event rather than a natural failure. Typically, telecommunication companies operate under strict regulatory control in many countries around the world.

As of Monday (January 31), Egypt remains disconnected from the Internet. A week view of traffic in and out of Egypt below.

Normally, Egypt enjoys one of the largest and most robust Internet infrastructures in Africa with a dozen major providers, more than 30% consumer penetration, and multiple high-speed paths to Europe and the rest of the world. Egypt also serves as a major terrestrial fiber optic crossing point for traffic to other countries in Africa and the Middle East. Traffic to other countries using these links through Egypt has not been impacted.

While the Egyptian telecommunication market has enjoyed significant liberalization in the last decade, the Egyptian government Telecommunications Regulatory Authority (TRA) continues to assert a strong level of regulatory control over the telecom licensees. See http://www.tra.gov.eg for more information (although the TRA web site is currently unreachable outside Egypt).

On the Conficker Working Group’s website, the Lessons Learned document has finally been made public. Sponsored by the US DHS, with key efforts at getting it written from Rick Wesson and David Dagon, the document was prepared by in large part by interviewing key folks in the CWG. The purpose was to explore all of the issues we encountered in the CWG, which was an unprecedented event. In short, the document helps illuminate challenges the information security community as a whole faces in the coming years.

As a member of the CWG, there are a number of takeaways for me. I think they illuminate a path for work in the coming years for many of us, which we will have to address collaboratively.

First, it should be clear that technology alone isn’t the solution here. One of the focuses of the CWG was to ensure that all of the AV, IDS and related companies had timely access to the samples to write signatures against. These technologies and companies represent the front line of defense for all of us, end users, enterprises, and ISPs. As should be clear from the infection data, the numbers haven’t plummeted, suggesting that gaps in addressing the problem exist. We have to explore how to get defenses and cleanup to more people more efficiently, if not preventing the infection in the first place. As someone in the CWG said, “we can’t patch our way out of these worms.”

Secondly, the world needs even better global coordination for such events, and clear authority to act for certain groups. In the case of the CWG, some organizations – such as ICANN – assumed authority for coordination when no one had such a clear mandate. In all cases everyone tread carefully and with the goals of protecting users forefront. You can see how contentious this winds up being by looking at the DNS-CERT discussions at ICANN, where issues like roles and responsibilities raise a lot of objections. Figuring out the groups that will choose issues to tackle and coordinating that globally is an open question.

A third – and technical – issue made visible in the experiences of the CWG is that we need tools to quickly tackle complex malware. Our tools are labor and time intensive, things that are in short supply when addressing the volume of threats we face in 2011. There’s a clear set of technical needs and accomplishments that can easily be funded here.

I think the CWG report is worth a study for these and many more reasons. I’m proud to represent Arbor as we battle the worm and protect the global Internet.

Another after action report came from ICANN, who was instrumental in the response. The report was published in May, 2010, and is largely a timeline of events. The two together are very worthwhile reading if you are involved in the operational security community.

This week, we continue our efforts to document the crowded space of Chinese DDoS bots by analyzing Darkshell.  This particular malware family has recently been used to attack quite a few companies involved in the industrial food processing industry.

Malcode Properties

The Darkshell malware is distributed in the form of a small executable which typically ranges in size from approximately 66,048 bytes to 79,360 bytes.  Here are the MD5 hashes for the 42 Darkshell samples we have analyzed to date:

ccb07865a8ba624c27c03024805624d2
0bef3c845c7b83b8c4e67090827c3680
a2b44c7ffce42cd6fcfe5a6e7c57853d
d6932bd1f84b03edb21b6749d25ac267
1a4a37d55a02f4541113a4c7bfaa4a6a
971e89f7e99c2af7117a1ec40d3dfe6d
8cf97cb9f76cc02ecd3a9e9e8ba268fe
07022e10f7dd52fa5f503d53143cf4ff
9f294c680cccf428487768a2eda0b59e
f570a9648575175d7dd1202cfe26474a
86c0a68e2db7fd2b8d3acdb2e864a914
c862538d7b6fceeba9dda0bed74642ab
63672dcde4bae762bc588c42c3189f53
3de053e9bda604a3f4683f87aa046bfa
70f0aada94cac2309faa4cbcaa742dad
d164e9048454bd1b267a8ba8bf50948c
4fa8430485784c68c249005ff9a2a067
ee244509ce21e2c685f129f8f985688f
75240cb1ab2cb9c65035c99f2687c01f
e8e9dd3638d0415d4da6f1b09728986f
c0ad6a2621a2a5925edec03a58a2f159
7fc1194c06700ef5c34edc12418842ea
94063f3b92e4f08ea5c789fc2b31cd4b
e2ff76137d122f7b7d8c609fc7b96abc
5302199cc2fdb3fddf71457f885c777a
28dcabf6d6860c3b303720462adfce80
ccda2b93ed4aacffdc9aab151c24f52b
b07a43cd8062791935cec2f3d1d58c3f
a7fb233ab799e1a0c4e4e57a4a7a2eda
57523283b8fdd9f3f66622b454bb05da
2c22f53b9d7f2144853ffa9683200f6c
20fa022aaf9162e88c7c92e332f99c21
2be7320313ffb59e942eb0a7254b7a19
d9debcb20307e6ed8fface8bf5cbeea6
316a9e1acf24e51f198efa864801fc2f
7bb75a70f95ddb7c8109b397435ea002
2484e79c6403985e7b7081ffd2b01021
c1e66b1167c90446933a26f13a9f26e5
6361ae5f223f9ef8cc799047fa849cc8
b83c0b457d42d5682142558555a6ade8
9c3d1a99d74a0174eebadcb32b80d8c1
726795453f01742e97038ad1a303a71d

Most of the Darkshell samples we have observed were originally hosted in Chinese IP space; here are some representative sample URLs (defanged) that have recently hosted Darkshell executables:

hxxp://1qzf.net/ms.exe
hxxp://www.sudupay.com/down/down.exe
hxxp://61.147.120.135:81/v7.exe
hxxp://www.jishu8.net/a3.exe
hxxp://60.173.8.118:8080/upload/1986.exe
hxxp://61.147.120.135:81/msierit32.exe
hxxp://61.147.120.135:81/srv1112.exe

None of these URLs are still serving Darkshell malware at this time.  Here is a representative sampling of net blocks that have distributed Darkshell malware:

61.164.118.139   CN   4134  SHANGHAI QILI NETWORK TECHNOLOGY CORP
222.186.32.153   CN   4134  CHINANET JIANGSU PROVINCE NETWORK
61.147.120.135   CN   4134  CHINANET JIANGSU PROVINCE NETWORK
60.190.216.46    CN   4134  NINBO LANZHONG NETWORK LTD
60.173.8.118     CN   4134  CHINANET ANHUI PROVINCE NETWORK
61.147.120.135   CN   4134  CHINANET JIANGSU PROVINCE NETWORK
121.12.127.155   CN   4134  SHENZHENSHILUOHUQUHEPINGLUYIFENGGUANGCHANGCZUO32H

Installation

Once launched, a Darkshell bot performs a fairly standard installation process.  It copies itself into the C:\Windows\System32 directory.  In an attempt to be stealthy, it will usually name the installed copy of itself so as to appear to be a legitimate system file; the installation names we have observed include:

regedit32.exe
regedit325516.exe
regedut32.exe
Msierit32.exe
Msbbrit32.exe
domain.exe

Darkshell will then register itself to run as a fake service that is automatically started upon reboot.  This service will be registered with one of the following names:

BackGround Switch
BackGround switch
BackGroucd Switch
BackGround Switch5516
domain Switch
Domain Switch

The display name of the installed service will claim to be “BackGround Switch Disktop Control”, or some derivative thereof (note the misspelling of “Desktop”).

Most Darkshell bots will also install a small driver file, beep.sys, into C:\Windows\System32\drivers.  It is believed that the purpose of this driver is to hook the infected host’s SSDT in order to hide from anti-virus software.  The driver creates a device named “\\.\Re1986SDTDOS” on the system.

Communication Protocol

Upon completion of its installation procedure, the Darkshell bot will phone home to its CnC server by opening a TCP socket and sending a binary block of data exactly 260 bytes in length.  This block of data reports the name of the infected computer (as returned by the Win32 API GetComputerName), the version of Windows and amount of physical memory installed on the host, and the version or ID string of the Darkshell bot.  The format of this data is a rigid structure that can be represented by the following C struct:

// Darkshell bot-to-CnC comms
struct {
   // Header:
   DWORD   dwMagic;    // always 0x00000010 for Darkshell
   // Obfuscated section:
   char    szComputerName[64]; // Name of infected host, NULL-terminated/extended
   char    szMemory[32];    // Amount of memory in infected host; format "%dMB"; NULL-terminated/extended
   char    szWindowsVersion[32];   // Specifies version of Windows; one of: Windows98, Windows95,
                                   // WindowsNT, Windows2000, WindowsXP, Windows2003, or Win Vista;
                                   // NULL-terminated/extended
   char    szBotVersion[32];   // Specifies version of bot; NULL-terminated/extended;
   DWORD   szUnknown1[4];     // ??? - Always NULL-terminated 'n'
   // Binary section:
   char    szPadding1[32];  // Filled with 0x00 bytes
   WORD    wUnknown2;  // ??? - We have seen 0x00A0, 0x00B0, and 0x00C0
   WORD    wUnknown3;  // ??? - Always 0xFD7F
   char    szPadding2[20];  // Filled with 0x00 bytes
   WORD    wUnknown4;  // ??? - Always 0xB0FC
   BYTE    cUnknown5;  // ??? - We have seen 0xD6, 0xD7, 0xE6, 0xE7, and 0xF1
   BYTE    cZero;      // Always 0x00
   DWORD   dwSignature[8]; // Always 0x00000000, 0xFFFFFFFF, 0x18EE907C, 0x008E917C,
                           //        0xFFFFFFFF, 0xFA8D91&C, 0x25D6907C, 0xCFEA907C
};

Here is a representative example of a Darkshell bot-to-CnC message:

00000000  00 00 00 10 a8 95 9b aa  95 91 de de de de de de ........ ........
00000010  de de de de de de de de  de de de de de de de de ........ ........
00000020  de de de de de de de de  de de de de de de de de ........ ........
00000030  de de de de de de de de  de de de de de de de de ........ ........
00000040  de de de de cc c9 c8 91  9c de de de de de de de ........ ........
00000050  de de de de de de de de  de de de de de de de de ........ ........
00000060  de de de de a7 75 70 7a  6f 87 8b a6 ae de de de .....upz o.......
00000070  de de de de de de de de  de de de de de de de de ........ ........
00000080  de de de de a8 75 8e cc  ce cd ce ce c6 cd de de .....u.. ........
00000090  de de de de de de de de  de de de de de de de de ........ ........
000000A0  de de de de 70 de de de  00 00 00 00 00 00 00 00 ....p... ........
000000B0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000C0  00 00 00 00 00 00 00 00  00 b0 fd 7f 00 00 00 00 ........ ........
000000D0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000E0  b0 fc f1 00 00 00 00 00  ff ff ff ff 18 ee 90 7c ........ .......|
000000F0  00 8e 91 7c ff ff ff ff  fa 8d 91 7c 25 d6 90 7c ...|.... ...|%..|
00000100  cf ea 90 7c                                      ...|

Note that bytes 4 through 168 are encoded using a crude obfuscation scheme that can be reversed using the following snippet of Python code:

def decrypt_darkshell(cipherbytes, start_idx=0x04, stop_idx=0xA8):
   """     
   De-obfuscates Darkshell comms encoded using the following method:
     cipherbyte = 0xDE - [plainbyte - (plainbyte & 0x10) << 1]
   The obfuscation is reversed as follows:
     intermediate = 0xDE - cipherbyte
     plainbyte = intermediate + (intermediate & 0x10) << 1
   """    
   len_mesg = len(cipherbytes)
   if len_mesg != 260:
       raise RuntimeError("Darkshell bot-to-CnC comms are always 260 bytes")
   plainbytes = []
   for cipherbyte in cipherbytes[start_idx:stop_idx]:
       intermediate= 0xDE - ord(cipherbyte)
       plainbytes += [chr(intermediate + ((intermediate & 0x10) << 1))]
   return cipherbytes[:start_idx] + ''.join(plainbytes) + cipherbytes[stop_idx:]

Applying this de-obfuscation process to the above sample comms results in the following:

00000000  00 00 00 10 56 49 43 54  49 4d 00 00 00 00 00 00 ....VICT IM......
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000040  00 00 00 00 32 35 36 4d  42 00 00 00 00 00 00 00 ....256M B.......
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000060  00 00 00 00 57 69 6e 64  6f 77 73 58 50 00 00 00 ....Wind owsXP...
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000080  00 00 00 00 56 69 70 32  30 31 30 30 38 31 00 00 ....Vip2 010081..
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000A0  00 00 00 00 6e 00 00 00  00 00 00 00 00 00 00 00 ....n... ........
000000B0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000C0  00 00 00 00 00 00 00 00  00 b0 fd 7f 00 00 00 00 ........ ........
000000D0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000E0  b0 fc f1 00 00 00 00 00  ff ff ff ff 18 ee 90 7c ........ .......|
000000F0  00 8e 91 7c ff ff ff ff  fa 8d 91 7c 25 d6 90 7c ...|.... ...|%..|
00000100  cf ea 90 7c                                      ...|

Note the version/ID string “Vip2010081″ located at byte offset 0×84.  Each Darkshell specimen has one of these strings hard-coded within its executable.  Our conjecture is that this string specifies some form of version identifier for the malcode.  The version strings we have seen to date include:

Vip2010081
VIP100707
Private520

Note that there are several fields within the 260-byte message structure for which we have not yet determined an interpretation.

Upon receipt of the “phone home” message, the CnC will either respond with an idle or “standby” command, which consists of a single byte 0×30 (i.e., decimal “0″ character) indicating that the bot is to perform no further actions for now, or it will respond with a 260-byte binary structure containing the instructions for a DDoS attack.  If an attack is ordered, the format of the response will be as follows:

// Darkshell CnC attack command
struct {
 DWORD   dwCode;         // 0x00000030 for HTTP flood attack
 DWORD   dwParameter;    // ??? - We have seen 0x0800
 char    szTarget[99];   // URL of target to attack, NULL-terminated/extended
 WORD    wPort;          // Port to attack (usually 80)
 char    szPadding[151]; // Always filled with 0x00 bytes
};

Unlike the phone home message, the attack instructions are not obfuscated in any way.  Here is a representative example (with the real target’s host name changed to www.victim1.com):

00000000  00 00 00 30 08 00 00 00  68 74 74 70 3a 2f 2f 77 ...0.... http://w
00000010  77 77 2e 76 69 63 74 69  6d 31 2e 63 6f 6d 2f 75 ww.victi m1.com/u
00000020  2e 70 68 70 3f 61 63 74  69 6f 6e 3d 73 68 6f 77 .php?act ion=show
00000030  26 75 69 64 3d 36 32 30  31 34 00 00 00 00 00 00 &uid=620 14......
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000060  00 00 00 00 00 00 00 00  00 00 00 00 50 00 00 00 ........ ....P...
00000070  04 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000A0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000B0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000C0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000D0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000E0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000000F0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
00000100  00 00 00 00                                      ....

Attack Traffic

Upon receipt of such an attack command, the Darkshell bot will begin flooding the victim with large numbers of HTTP GET requests.  Each of these GET requests is identical.  The GET requests are initiated from sequentially increasing source ports.  Each bot simultaneously opens a large number (e.g., 15-25) of TCP connections to the specified target URL; each such connection continually issues the same identical GET request multiple times, regardless of the response (if any) from the victim; these requests have the following format:

GET /u.php?action=show&uid=62014 HTTP/1.1
Host: www.victim1.com
Cache-Control: no-store, must-revalidate
Referer: http://www.victim1.com
Connection: Close

The Host and Referer header fields will be customized based upon the specified target, but the rest of the HTTP header will be fixed as above.

Control Servers

To date, we have identified at least 30 unique host names and 34 unique IP addresses that have been used as Darkshell CnCs.  32 of these CnC IP addresses have resided in Chinese IP space:

CnC IP Address     Port  CC   ASN   NetName
111.226.71.35      5288  CN   4134  CHINANET HEBEI PROVINCE NETWORK
116.11.186.119     5516  CN   4134  CHINANET GUANGXI PROVINCE NETWORK
119.183.244.214    8012  CN   4837  CHINA UNICOM SHANDONG PROVINCE NETWORK
121.12.117.109      603  CN   4134  SHENZHENSHILUOHUQUHEPINGLUYIFENGGUANGCHANGCZUO32H
121.12.127.155     8000  CN   4134  SHENZHENSHILUOHUQUHEPINGLUYIFENGGUANGCHANGCZUO32H
121.12.127.99      8001  CN   4134  SHENZHENSHILUOHUQUHEPINGLUYIFENGGUANGCHANGCZUO32H
121.14.153.183     8000  CN   4134  DONGGUANSHIWEIYIWANGLUOKEJIYOUX
121.14.155.164     8000  CN   4134  DONGGUANSHIWEIYIWANGLUOKEJIYOUX
121.14.156.126     2345  CN   4134  DONGGUANSHIWEIYIWANGLUOKEJIYOUX
121.14.219.195     2991  CN   4134  SHANTOUSHILONGHUQUHUAMEIZHUANGHUAMEIHUAYUANDI9ZUO601HAOFANG
122.227.45.12       603  CN   4134  ZHEJIANG HUANLONG NEW MATERIALS TECHNOLOGY CO. LTD
122.230.137.109    8080  CN   4134  CHINANET-ZJ HUZHOU NODE NETWORK
124.237.78.135      888  CN   4134  THE YANDA ZHENGYANG ELECTRON LTD. OF QINHUANGDAO
125.113.113.149      80  CN   4134  CHINANET-ZJ JINHUA NODE NETWORK
202.109.143.77     3266  CN   4134  CHINANET JIANGXI PROVINCE NETWORK
218.29.97.162      8080  CN   4837  MZTCWLKJYXGS CORP
218.60.132.110     7080  CN   4837  CHINA UNICOM LIAONING PROVINCE NETWORK
218.61.13.253      9000  CN   4837  CHINA UNICOM LIAONING PROVINCE NETWORK
220.172.151.241    9000  CN   4134  CHINANET GUIZHOU PROVINCE NETWORK
222.189.238.156    7433  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
222.217.155.94     8080  CN   4134  CHINANET GUANGXI PROVINCE NETWORK
222.218.211.229    8080  CN   4134  CHINANET GUANGXI PROVINCE NETWORK
222.83.212.225     8080  CN   4134  CHINANET GUANGXI PROVINCE NETWORK
58.221.33.159      1111  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
58.221.44.193      8000  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
58.53.128.83       8181  CN   4134  CHINANET HUBEI PROVINCE NETWORK
59.188.23.12       4520  HK  17444  NEW WORLD TELECOM LTD. HONG KONG
59.57.113.118      7000  CN   4134  CHINANET FUJIAN PROVINCE NETWORK
59.57.123.203      8001  CN   4134  CHINANET FUJIAN PROVINCE NETWORK
60.173.8.118       1986  CN   4134  CHINANET ANHUI PROVINCE NETWORK
61.129.33.151       603  CN   4812  GREEN POWER BAR
61.147.99.243      8080  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
61.164.150.155     1234  CN   4134  VA OFFICE BRANCH OF CHINA TELECOM CORP
98.126.74.51       4567  US   4213  VPLS INC. D/B/A KRYPT TECHNOLOGIES

The Darkshell bots have the identity of their CnC hard-coded within their executable (in plain, non-obfuscated text); as is common, these CnCs are identified by host name rather than raw IP address.  The majority of Darkshell CnC host names are associated with the 3322.org domain, a large Chinese provider of dynamic DNS services, including:

ddosbox.3322.org
a90722692.3322.org
sawyer.3322.org
babab2hd2.3322.org
gd0168.3322.org
jhz100.3322.org
juhuatai0.3322.org
jzn1986.3322.org
kuilei65551543.3322.org
li0427.3322.org
nacui120.3322.org
nb969798.3322.org
qingcs.3322.org
wudikoko.3322.org
xplin.3322.org
yaolin001.3322.org
yhyhwjwj.3322.org
ziyingtianxia.3322.org
zxswww.3322.org

On occasion, Darkshell CnCs may be found on non-3322.org host names, such as the following:

ddos.zh-cn.cc
winmbddos.8866.org
1qzf.net
appleyhoo.net
dkzy.8866.org
g5512484.8866.org
lang12397007.2288.org
maipianzhu.8800.org
qjwl8866.8866.org
wsxe.8866.org

We have observed Darkshell CnCs operating on a wide variety of ports (usually non-standard ones), including:

80 603 888
1111 1234 1986
2345 2991
3266
4520 4567
5288 5516
7000 7080 7433
8000 8001 8012 8080 8181
9000

Victims

We have been tracking various Darkshell-based botnets for approximately three months using our usual technique of periodically connecting to known Darkshell CnCs and sending 260-byte messages that imitate particular Darkshell specimens that have been captured and analyzed.  During this period of time, we have observed Darkshell botnets issue DDoS attack commands against approximately 97 unique victims in China (65), the United States (23), Hong Kong (4), South Korea (3), Netherlands (1), and Sweden (1).  The victims have been distributed across networks and hosting providers as follows:

CC   ASN   Network
CN   4134  CHINANET ANHUI PROVINCE NETWORK
CN   4134  CHINANET FUJIAN PROVINCE NETWORK
CN   4134  CHINANET GUANGDONG PROVINCE NETWORK
CN   4134  CHINANET HEBEI PROVINCE NETWORK
CN   4134  CHINANET HUNAN PROVINCE NETWORK
CN   4134  CHINANET JIANGSU PROVINCE NETWORK
CN   4134  CHINANET JIANGXI PROVINCE NETWORK
CN   4134  CHINANET SICHUAN PROVINCE NETWORK
CN   4134  CHINANET XINJIANG PROVINCE NETWORK
CN   4134  CHINANET-HN CHENZHOU NODE NETWORK
CN   4134  DONGGUANSHIWEIYIWANGLUOKEJIYOUX
CN   4134  HANGZHOU GSOFT SCIENCE&TECHNOLOGY DEVELOPMENT CO. LTD
CN   4134  HANGZHOU SILK ROAD
CN   4134  LISHUI DIANXIN COLTD
CN   4134  NINBO LANZHONG NETWORK LTD
CN   4134  RUIAN TELECOM
CN   4134  SHANTOU TIANYIN TECHNOLOGY CO. LTD
CN   4134  SHANTOUSHIJINSHADONGLUJINLONGDASHABDONG12A
CN   4134  SHENZHENSHILUOHUQUHEPINGLUYIFENGGUANGCHANGCZUO32H
CN   4134  WENBIN ZHAO
CN   4134  WENZHOU LIANZHONG NETWORK TECHNOLOGY LTD
CN   4134  WENZHOU TELECOM CO. LTD
CN   4134  WORLD CROSSING TELECOM(GUANGZHOU) LTD
CN   4134  WUJINGBO
CN   4134  XIAMEN SANWU NETWARE SCIENCE CO. LTD
CN   4134  XIAMEN TELECOM IDC
CN   4812  CHINANET SHANGHAI PROVINCE NETWORK
CN   4837  CHINA UNICOM HEILONGJIANG PROVINCE NETWORK
CN   4837  CHINA UNICOM HENAN PROVINCE NETWORK
CN   4837  XIAMEN CITY FUJIAN PROVINCE
CN   4847  FOR GREAT WALL BROADBAND NETWORK SERVICE ACCESS IN BEIJING
CN   9929  NINGBO CITY ZHEJIANG PROVINCE
CN  17964  BEIJING XIRANG MEDIA CULTURAL CO. LTD
CN  37943  ZHENGZHOU GIANT COMPUTER NETWORK TECHNOLOGY CO. LTD
CN  38356  HICHINA WEB SOLUTIONS (BEIJING) LIMITED
HK   4058  ASIA DATA (HONG KONG)INC.LIMITED
HK   4645  HKNET COMPANY LIMITED
HK  17444  NWT IDC DATA SERVICE
KR   3786  KOREA INTERNET DATA CENTER INC
KR   3786  LG DACOM KIDC
KR   4766  KOREA TELECOM
NL  47869  NETROUTING TELECOM
SE  49770  SERVERCONNECT.SE
US   4213  VPLS INC. D/B/A KRYPT TECHNOLOGIES
US  23338  DCS PACIFIC STAR LLC
US  25761  STAMINUS COMMUNICATIONS
US  26496  GODADDY.COM INC
US  30058  FDCSERVERS.NET
US  36351  1WEBHOST
US  36351  HOSTING SERVICES INC
US  36351  SOFTLAYER TECHNOLOGIES INC
US  46844  SHARKTECH INTERNET SERVICES

The recent victims have included online merchants of baby products, jewelry, and cosmetics, as well as a social networking site and numerous video game-related sites.

However, the most common targets of Darkshell attacks over the past three months have been the websites of relatively small manufacturers of industrial food processing equipment and machinery.  We have logged attacks against at least 16 such victims emanating from the Darkshell botnets, comprising approximately 40% of the victims that we sampled.  One can only speculate on the reasons for this aggressive focus on such a relatively tiny niche within the online landscape.  Several such attacks have been sustained for over 60 hours at a time, and most of these equipment vendors have suffered multiple repeat attacks during this interval of time.

One common pattern of Darkshell behavior is to attack three or four different URLs associated with a particular food processing equipment vendor; these multiple URLs are typically associated with pages displaying specific products.

We have also observed instances in which multiple Darkshell botnets engaged in coordinated attacks against a single victim (again, vendors of industrial food processing equipment.)

A/V Detections

Overall, anti-virus detection of Darkshell bots is reasonably good at this point.  Detection rates for the specimens we have analyzed are typically in the 65%-85% range, although we have analyzed several samples for which the detection rate was 0%.  Here are some representative detections:

Kaspersky       Backdoor.Win32.DarkShell.fu
Microsoft       Backdoor:Win32/Httpbot.A
CAT-QuickHeal   Backdoor.DarkShell.fu
Antiy-AVL       Backdoor/Win32.DarkShell.gen
ViRobot         Backdoor.Win32.DarkShell.79360
nProtect        Backdoor/W32.DarkShell.79360.B
JiangMin        Backdoor/NetBot.qg
Symantec        Spyware.Ardakey
TrendMicro      BKDR_BVOK.SM

Summary

At first glance we expected Darkshell to be another mundane entry in the seemingly never-ending rogue’s gallery of DDoS-focused botnets; in other words, not terribly advanced in terms of cutting edge technology, but nevertheless quite active and effective at shutting down victims, unfortunately.  However, we were surprised when we discovered that its operators have such a propensity for attacking one particular commercial market segment.  Until we’ve gathered more information, we can only speculate upon the motivations of the criminals operating and/or using the Darkshell botnets, and the nature of the axe they apparently have to grind against certain suppliers of industrial food-processing equipment.

We will, however, definitely be keeping a close eye on this particular family going forward.

We have done some analysis on the Chcod malware family, also known as Ogran, which has been showing up in our sandboxes since at least August 2009.  Like the Yoyoddos and Avzhan trojans, this family is also controlled predominantly from Chinese IP space and appears to be used almost exclusively as a DDoS agent.

Malcode Properties

The Chcod malware is distributed in the form of a very small unpacked executable; we have observed its size vary from 9728 to 20,480 bytes, with specimens most frequently weighing in at approximately 12.5 KB.  Here are some MD5 hashes of some representative samples:

9ec5dbc58ff6f2811596540ada704def
876718d10b42b053df1df4fb0a69f789
32291e232247e9004e520d0e638f565d
e10cf3881ce04f0cde4091c3dad78fe8

Samples are typically hosted on Chinese servers, although we have observed at least one instance of Chcod being distributed from Thai IP space.  Here are some of the (defanged) URLs that have distributed Chcod malware:

hxxp://61.147.120.135:81/zhaomingyang520.exe
hxxp://www.huoyx.com/7758.exe
hxxp://nc3comcn.vip137.2hezu.net/choujin/svchost.exe

Note that all three of these URLs live on CHINANET hosts, none of which are still serving the malware at this time.

Installation

Upon initial execution, Chcod will typically copy itself into the victim’s C:\Windows directory using a name that, more often than not, sticks out like a sore thumb; the operators of Chcod appear to make very little effort at blending in to their infected hosts.  Representative examples of installation names we have observed include:

C:\WINDOWS\QQ.exe
C:\WINDOWS\vx.exe
C:\WINDOWS\dfgc.exe
C:\WINDOWS\d.exe
C:\WINDOWS\zhaomingyang520.exe

Most variants of Chcod will set themselves up to be Windows Services that are automatically started upon system reboot.  Again, Chcod doesn’t make the slightest attempt to be stealthy when choosing a service name; representative examples include:

hytyju234567890
vsdxqq
dsff
txqqc
Aeeu01234567890

The display names Chcod uses for its installed service have often been even worse, such as this one:

Ati External Event UtilityKillOrKillOrPassKillOrKillOrPassKillOr

We have also observed at least one Chcod sample (MD5 876718d10b42b053df1df4fb0a69f789) that did not even bother to install itself as a service.

Communication Protocols

The Chcod bots phone home to their CnC servers by sending a small 56-byte block of structured data over a basic TCP socket; this message contains only the name of the victim computer (as returned by the gethostname() API) as well as a possibly truncated copy of the host name of the CnC to which it is sending the message.

We document the format of the communication protocol in the form of an equivalent C struct as follows:

// Trojan.Chcod bot-to-CnC message structure
struct {
WORD    wMagicNumber;     // Always 0x0100
char    szCnCName[14];    // NULL-terminated CnC hostname, truncated as needed, otherwise
                          //   NULL-extended
char    szVictimName[32]; // From gethostname(), NULL-terminated and extended
WORD    wWindowsVersion;  // Encoded as: 3 (Vista), 2 (XP), 1 (WinME), 0 (Win98),
                          //   or 4 (Server 2003 x64)
WORD    wPhysicalMemory;  // As returned by dwTotalPhys component of GlobalMemoryStatus()
                          //   and converted to MB
WORD    wUnknown;         // Varies; we've seen 0xb808, 0x5014, 0x1450, and 0xa00f
WORD    wZero;            // Always 0x0000
};

We do not currently know the meaning of the 16-bit value we refer to as wUnknown above, although it appears to be stored as a constant within the executable.

Here is a representative example, sent to a CnC hosted at bon19820609.3322.org, from an infected host named VICTIM:

$0000   01 00 62 6F 6E 31 39 38 32 30 36 30 39 2E 33 00   ..bon19820609.3.
$0010   76 69 63 74 69 6D 00 00 00 00 00 00 00 00 00 00   victim..........
$0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
$0030   02 00 FF 00 B8 0B 00 00                           .......

One might wonder why the bot sends the CnC’s own host name back to its CnC?  Presumably so that the operators of Chcod can support a crude form of “virtual hosting” in which multiple distinct Chcod botnets are controlled from a single CnC; each distinct botnet would be controlled via a separate CnC host name; each of these host names could then resolve back to the same IP address upon which the CnC server socket is listening on a single port.  By including its controlling host name in the bot-to-CnC message, the CnC server could in theory determine with which botnet the bot was associated and respond accordingly.

Upon receipt of this “phone home” message, the CnC may respond with one of several different message formats; the nature of the command is specified by the value of the first two bytes in the CnC response:

1. Attack command (0×02): an 80-byte block of data that specifies the victim to be attacked, as well as the parameters of that attack; the message uses the following format:

// Chcod attack command
struct {
 BYTE    nCommandCode;   // 0x02 = Launch DDoS attack
 char    szPadding[15];  // Always filled with 0x00 bytes
 WORD    wAttackType;    // 0x10 = HTTP flood; 0x02 = UDP flood
 WORD    wUnknownParam1; // ???  We have observed values of 0x32 and 0x1A
 WORD    wUnknownParam2; // ???  We have observed values of 0x32 and 0x3E
 WORD    wUnknownParam3; // ???  We have observed values of 0x32 and 0x90
 WORD    wPort;          // Port to attack
 char    szUrl[54];      // Victim URL, hostname, or IP address; NULL-terminated
};

An example from a UDP flood attack (target victim has been obfuscated):

$0000   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
$0010   02 00 32 00 32 00 32 00 50 00 77 77 77 2E 74 61   ..2.2.2.P.www.ta
$0020   72 67 65 74 2E 63 6F 6D 2F 69 6E 64 65 78 2E 68   rget.com/index.h
$0030   74 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00   tm..............
$0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

When engaging in a UDP flood, the Chcod bot will open a large number of simultaneous UDP sockets to the specified victim and port.  UDP floods from Chcod are typically directed against port 80 on the victim.  Chcod will flood the victim with UDP datagrams from each of these sockets; each datagram contains 16 bytes of payload.  The content of each datagram payload is 16 random chosen bytes from the range 0x1E through 0x3E.  The payload is different for each datagram sent by the bot.

Thus, a possible mitigation strategy for dealing with a Chcod UDP flood might be to blacklist any source IP address that is sending a lot of 16-byte UDP datagrams that contain data bytes strictly within the range of 0x1E to 0x3E.  (On the other hand, it might not be a bad idea to blacklist any source IP sending large numbers of UDP packets to your web server’s port regardless of their content…)

Here is an example from an HTTP flood attack (again, the real target has been obfuscated):

$0000   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
$0010   10 00 32 00 32 00 32 00 50 00 77 77 77 2E 74 61   ..2.2.2.P.www.ta
$0020   72 67 65 74 3E 75 73 2F 69 6E 64 65 78 2E 61 73   rget.us/index.as
$0030   70 00 70 00 61 73 70 00 68 64 6F 32 2F 69 6E 64   p.p.asp.hdo2/ind
$0050   65 78 2E 61 73 70 00 00 00 00 00 00 00 00 00 00   ex.asp..........

Note that, although the CnC properly NULL-terminates the string specifying the target, it apparently does not initialize the entire 80-byte buffer with zeroes prior to filling in the structure.  This often results in string fragments associated with previous victims remaining in the response buffer that is sent back to the bots (such as the “…hdo2/index.asp” fragment in the HTTP flood example above.)

2. Download command (0×03): an 80-byte block of data that specifies a URL that is to be downloaded and executed; the message uses the following format:

// Chcod download+execute command
struct {
 BYTE    nCommandCode;   // 0x03 = download URL and execute
 char    szPadding[15];  // Always filled with 0x00 bytes
 char    szUrl[64];      // NULL-terminated and extended URL to download and execute
};

An example message is as follows:

$0000   03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
$0010   68 74 74 70 3A 2F 2F 31 32 32 2E 32 32 34 2E 34   http://122.224.4
$0020   38 2E 38 37 3A 38 38 38 38 2F 64 6F 77 6E 2E 65   8.87:8888/down.e
$0030   78 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00   xe..............
$0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

Upon receipt of such a command, the Chcod bot will initiate an HTTP connection to the specified URL, save the downloaded executable to the C:\Windows directory using its original name (e.g., C:\Windows\down.exe in the above example), and execute it.  This mechanism can of course be used to update the Chcod bot with a newer version, or to drop additional malware on an infected system.

3. Uninstall command (0×05): Causes the Chcod bot to delete the Windows Service under which it is installed.

4. Logoff command (0×191): Force the infected user to be logged out of his/her session.

5. Reboot command (0×192): Force the infected host to reboot.

6. Shutdown command (0×193): Force the infected host to shutdown.

7. Idle command (0×00): a 16-byte block of zeros to indicate that the bot is to stand by and perform no action.

It also appears that Chcod supports an additional command code (0×06) with functionality that is not understood at this time.

In general, upon the completion of this message exchange, the bot will remain connected to the CnC and listen for further instructions on the established socket (barring a system shutdown, etc.)

Control Servers

To date, we have identified at least 18 Chcod CnC servers running on 15 different IP addresses; we’ve observed three instances in which a single IP address hosted two CnC servers running on different ports.  Although 17 of the 18 Chcod CnC servers are hosted in Chinese IP space, they are fairly widely distributed across net blocks, as follows:

IP Address         Port  CC   ASN   NETNAME
61.164.126.228     1777  CN   4134  TAIZHOU SOIDC NETWORK TECHNOLOGY CORP
221.12.138.226     6222  CN   4837  WANGUOCHUANZHEN QUZHOU ZHEJIANG
61.164.126.228     1777  CN   4134  TAIZHOU SOIDC NETWORK TECHNOLOGY CORP
221.12.138.226     1983  CN   4837  WANGUOCHUANZHEN QUZHOU ZHEJIANG
61.164.126.228     1888  CN   4134  TAIZHOU SOIDC NETWORK TECHNOLOGY CORP
122.224.48.87      7890  CN   4134  NINBO LANZHONG NETWORK LTD
221.181.66.77      6222  CN  24400  CHINA MOBILE COMMUNICATIONS CORPORATION
221.181.66.77      3456  CN  24400  CHINA MOBILE COMMUNICATIONS CORPORATION
61.164.127.22      1987  CN   4134  TAIZHOU YAMA NETWORK TECHNOLOGY CORP
116.117.176.5      8888  CN   4837  INNERMONGOLIAHAILAERMZAB80MH02POOL
202.97.185.109     7890  CN   4837  CHINA UNICOM LIAONING PROVINCE NETWORK
119.48.217.19      7758  CN   4837  CHINA UNICOM JILIN PROVINCE NETWORK
218.10.18.160      1118  CN   4837  CHINA UNICOM HEILONGJIANG PROVINCE NETWORK
76.164.231.59      8080  US  36114  R & D TECHNOLOGIES LLC
123.187.107.8      8080  CN  17799  CHINANET LIAONING PROVINCE NETWORK
218.60.65.135      8783  CN   4837  CHINA UNICOM LIAONING PROVINCE NETWORK
121.11.84.83       7758  CN   4134  SHANTOUSHIJINSHADONGLUJINLONGDASHABDONG12A
61.190.149.232     1520  CN   4134  CHINANET ANHUI PROVINCE NETWORK
61.147.74.139      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK

The Chcod bots have the identity of their CnC hard-coded within their executable; as is common, these CnCs are identified by host name rather than raw IP address.  The majority of Chcod CnC host names are associated with the 3322.org domain, a large Chinese provider of dynamic DNS services.  Examples include:

clddos1.3322.org
cl888666.3322.org
zhaomingyang520.3322.org
bon19820609.3322.org
wbbyby.3322.org
sou8sou8.3322.org

Occasionally, Chcod CnCs live on non-3322.org host names, such as the following:

h.xuhongdiy.com
www.sowogame.cn
server01.comying.com

Note that the host name of the CnC is obfuscated within the static bot executable file; however, invoking strings analysis on a memory dump from a running Chcod bot process will yield the plain text host name of the CnC.

The operators of Chcod-based botnets clearly prefer to host their CnCs on non-standard ports as shown in the above listing.

Victims

We have been tracking various Chcod-based botnets since early October 2010 using our usual technique of periodically connecting to known Chcod CnCs and sending 56-byte messages that imitate particular Chcod specimens.  During this period of time, we have observed Chcod botnets issue DDoS attack commands against approximately 31 unique victims in China (19), Hong Kong (5), Korea (5), and the United States (2).  The victims have been distributed across the following networks:

CC   ASN   Network
CN   4134  CHINANET GUANGDONG PROVINCE NETWORK
CN   4134  CHINANET JIANGSU PROVINCE NETWORK
CN   4134  CHINANET JIANGXI PROVINCE NETWORK
CN   4134  CHINANET SICHUAN PROVINCE NETWORK
CN   4134  CHINANET XINJIANG PROVINCE NETWORK
CN   4134  CHINANET-HN HENGYANG NODE NETWORK
CN   4134  DONGGUANSHIWEIYIWANGLUOKEJIYOUX
CN   4134  JINHUA TELECOM CO. LTD
CN   4134  JINHUA TELECOM CO. LTD IDC CENTER
CN   4134  NINBO LANZHONG NETWORK LTD
CN   4134  SHANTOUSHIJINSHADONGLUJINLONGDASHABDONG12A
CN   4837  HEPINGLU-COM XUZHOU JIANGSU PROVINCE
HK   9269  CITY TELECOM (H.K.) LTD
HK  17444  TOP INTERNET COMPANY
KR   3786  KOREA INTERNET DATA CENTER INC
KR   4766  KOREA TELECOM
KR   9848  KRNIC
US   6939  KARIM JELASSI
US  36351  SOFTLAYER TECHNOLOGIES INC

Victims of Chcod DDoS attacks have included several gaming-related sites (not unusual) and a Chinese university.  The typical Chcod-generated DDoS attack lasts from approximately 4 to 12 hours at a time.  However, one of the victims in particular has been on the receiving end of at least nine separate Chcod DDoS attacks in October 2010 alone; two of these attacks were sustained for almost 40 hours each.

Spot checks of victim websites have found them to be non-responsive during periods of actual attack by Chcod, suggesting that the associated botnets could be of reasonable size.

Of the 19 Chcod CnC servers we have identified, the following seven have actively engaged in DDoS attacks over the last three months:

IP Address         Port  CC   ASN   Network
113.105.169.182    8802  CN   4134  CHINANET GUANGDONG PROVINCE NETWORK
122.224.18.27      7758  CN   4134  NINBO LANZHONG NETWORK LTD
124.119.87.233     8802  CN   4134  CHINANET XINJIANG PROVINCE NETWORK
58.221.35.156      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
58.221.35.172      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
61.147.74.139      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
61.147.74.185      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK

The others have either been taken down or otherwise become non-responsive, or have not recently been engaging in active DDoS attacks.

A/V Detections

Anti-virus detection of Chcod bots is pretty good at this point.  Detection rates for the specimens we have analyzed are typically in the 75%-95% range.  Here are some representative detections:

Microsoft     Trojan:Win32/Chcod.A
Kaspersky     Trojan-Downloader.Win32.Ogran.dh
DrWeb         BackDoor.ClDdos.9
Ikarus        Trojan-Downloader.Win32.Ogran
JiangMin      TrojanDownloader.Ogran.o
McAfee        Heuristic.BehavesLike.Win32.Trojan.H
TrendMicro    TROJ_OGRAN.A
VirusBuster   Trojan.DL.Ogran.U

Summary

The Chcod/Ogran family is not nearly as active as other DDoS-focused malware families (such as BlackEnergy and Yoyoddos.)  It does, however, represent another data point in the increasingly crowded landscape of DDoS attack agents.

Much credit to Kenny MacDermid for his significant contributions to this analysis.

If you weren’t paying attention last week, the Internet has gone to war.

ABC News proclaimed  “Welcome to Infowar, Version 1.0″. Fox warned of the “growing data war”. And the Guardian provided minute by minute coverage on the opening salvos of this first “Internet-wide Cyber War”.

Of course, all of the above headlines refer to the rash of DDoS attacks both against the Wikileaks web site and the retaliatory strikes against hosting and commercial institutions that severed ties with the organization.

So are we now in a permanent state of cyber-war? As the San Francisco Chronicle asks, do sixteen year old hackers now control the fate of humanity from their laptops?

Well, this blog uses detailed statistics on the last year of DDoS attacks across the Internet to provide some perspective. I’ll compare the Wikileaks and retaliatory DDoS attacks to historical baselines of attack activity and discuss broader DDoS trends.

In general, getting accurate data about Internet attacks can be a challenge. Namely, a) companies avoid publicly discussing most attacks and b) the attacks can be difficult to measure or at least consistently compare. For example, engineering mailing list discussion of ISP security and DDoS attack trends generate a bewildering variety of responses. In one instance, two engineers at the same ISP debated the largest observed botnet attacking their company — one estimated the size at a few thousand hosts while the other at millions. Later when pressed on the source of their data, both of these engineers readily admitted they were really just guessing (they did not have any infrastructure / tools to actually measure the number of attacking botnet hosts).

In an effort to better quantify DDoS attack trends, two years ago Arbor added support for the export of detailed measurements of confirmed DDoS attacks to our commercial products and ATLAS anonymous statistics (deployed in roughly 75% of all Internet carriers). This blog post provides a first look at quantitative measurements of over 5,000 confirmed (via operator classification or mitigation status) attacks over the last year across 37 large carriers and content providers around the world. We believe this is the largest data set of validated DDoS events ever collected. I presented an earlier version of this blog post at this Fall’s NANOG (link to the presentation here) and we’re currently working on an academic paper version.

Before diving into the statistics, a bit of background — our data includes both survey results and two overlapping measurement data sets: alerts and mitigations. At a high level, alert data include the magnitude and fingerprint of a DDoS (i.e. IP header fields and router / interface topological origins of the attack). Mitigation statistics include finer-grain detail on the payload of the attack, including spoofed source IPs, number of valid (i.e. not spoofed) source IPs, connection attempts, bps and pps rates per attacking IP, etc.

In general, we evaluate DDoS attacks using two metrics: the scale and the sophistication of the attack. At the high end in 2010, we observed a number of DDoS attacks in the 50+ Gbps range. These large flooding attacks often exceed the inbound aggregate bandwidth capacity of data centers and carrier backbone links (often OC192 / 10 Gbps). Mitigation of these high end attacks can be a challenge — carriers generally need specialized, high speed mitigation infrastructure and sometimes the cooperation of other providers to block the attack traffic. The below graph plots the growth DDoS flooding attacks over the last decade (hard to imagine that 400 Mbps was an impressive attack back in 2002).

On the other end of DDoS spectrum, we encounter attacks focused not on denying bandwidth, but the back-end computation, database, and distributed storage resources of large web services. For example, service or application level attacks may focus on a series of web or API calls that force an expensive database transaction or calls to slow storage servers. The attackers then use botnets to inundate the web service with thousands of clients issuing a steady stream of these particularly expensive web / API calls. Other application attacks attempt to overwhelm SIP, HTTP or TCP state (e.g. Slowloris). In many of the more sophisticated application DDoS, attackers perform reconnaissance of the web service for weeks or months before the attack (identifying weak links in the infrastructure). Unlike massive DDoS traffic floods, application attacks can be far more subtle and may only register as increased load on servers or a precipitous drop in five minute real-time sales revenue charts. Also like 10+ Gbps flooding attacks, sophisticated application attacks may required specialized, high speed infrastructure to detect and mitigate the DDoS.

So if we’re in a Cyber-War, then very large (50+ Gbps) traffic floods and sophisticated application attacks are the front-lines. Which brings us back to the question of Wikileaks and the retaliatory hactivist attacks. Were these attacks massive high-end flooding DDoS or very sophisticated application level attacks?

Neither.

Despite the thousands of tweets, press articles and endless hype, most of the attacks over the last week were both relatively small and unsophisticated. In short, other than than intense media scrutiny, the attacks were unremarkable. I note that our ATLAS based observations agree with data from the operators directly involved in mitigating the attacks.

For example, below is a graph of DDoS activity against multiple Wikileaks hosting sites on third day (December 1) following the initial release of “Cablegate” documents. The DDoS traffic (in red) never grew beyond 3-4 Gbps. Today, mitigating attacks of this scale is fairly routine for tier1/2 ISPs and large content / hosting providers (more of an annoyance than an imminent critical infrastructure threat — or “easy peasy” to block as one Internet engineer explained). Also see earlier blog posts (link available here) for more analysis of the Wikileaks attacks.

The retaliatory hactivist attacks took a slightly different approach with mostly low-level application layer attacks against a range of companies perceived as anti-Wikileaks, including banks, hosting and credit card companies. The loosely organized Anonymous group called hundreds of volunteer activists to arms with messages like:


"TARGET: WWW.xxxxx.COM: WEAPONS http://xxx.xx.ru FIRE FIRE FIRE!!! PAYBACK!"


[I replaced the target and Russian download site with xx's].

Based on ATLAS data, the majority (70%) of the hactivist application DDoS came from a Mac / PC down-loadable “Low Orbit Ion Canon” (LOIC) program and a web based Javascript version (JS-­LOIC). Both LOIC variants sent dozens of web requests per second to the victim web sites. The online web version consists of a simple 100 line Javascript for-loop generating web requests and very few options (though you can append text with an appropriately revolutionary message). The PC version supports slightly more complex options, including randomization of URLs and remote control by IRC botnets (“the hive”).

Approximately 20% of retaliatory attack DDoS HTTP requests in one attack last week came from a new variant of LOIC named, predictably, LOIC-2. The new LOIC version (a “total rewrite of LOIC”) supports additional “hive” remote control command channels including RSS, Twitter, and Facebook (LOIC only supported irc). More significantly, LOIC-2 supports two new “slow” class of attack methods (i.e., DDoS strategies where the client deliberately elongates HTTP transaction times to burden the victim server).

In addition to LOIC, ATLAS observed Slowloris like TCP attacks and several other tools / scripts generating web or TCP DDoS traffic. A smaller component of the hactivist campaign included DDoS flooding using ICMP Smurf and LOIC operating in UDP flood mode (sending traffic to UDP port 80).

More recently, Anonymous supporters released two more sophisticated HTTP flooding tools: High Orbit Ion Cannon (HOIC) and Geosynchronous Orbit Ion Cannon (GOIC). The new tools support multi-threaded HTTP flooding, simultaneous attacks against up to 265 web sites, plug-ins and an “easy to use interface”. However, HOIC and GOIC did not appear to play a significant role in the DDoS attacks last week.

While the last round of attacks lead to brief outages, most of the carriers and hosting providers were able to quickly filter the attack traffic. In addition, these attacks mostly targeted web pages or lightly read blogs — not the far more critical back-end infrastructure servicing commercial transactions. By the end of the week, Anonymous followers had mostly abandoned their attack plans as ineffective.

Overall, both the attack traffic and the hundreds of volunteers running the software on their PCs were not terribly sophisticated. Most volunteers clearly did not realize the tools do not anonymize their PC source IP address nor that word processors store incriminating meta-data in revolutionary manifestos. In short, not exactly the work of evil criminal masterminds.

So ultimately, I’d suggest the last week of DDoS attacks surrounding Wikileaks supporters and opponents falls far short of a “cyberwar”. While it makes a far less sexy headline, cyber-vandalism may be a more apt description. In a similar vein, a Foreign Policy Op-Ed called hactivist DDoS the digital equivalent of a sit-in by youth around the world.

All of the above is not to say DDoS is not a serious problem. The number and firepower of botnets grows dramatically each year as well as the sophistication of application attack toolsets. HOIC and succeeding generations of volunteer botnet controlled PCs may evolve to pose a significant Internet-wide threat. However, traditionally the DDoS threat has come more from increasingly professional criminal hackers than volunteer activists.

With discussion of cyberwar out of the way, I’ll compare Wikileaks and related attacks to some of the broader trends we are observing in ATLAS DDoS statistics. The chart below shows the distribution DDoS attack vectors in the 5,000 validated attacks in the ATLAS dataset. Note that this dataset represents a subset of all attacks as not all providers have enabled anonymous export of data and many providers are running earlier versions of the product (i.e., lacking anonymous DDoS statistics export support). See the NANOG presentation (link available here) for more details on the methodology.

As discussed earlier, brute-force flooding continues to dominate most DDoS attacks (60%). Generally, these attacks (including the initial strike against the Wikileaks web site) resemble the early days of DDoS attacks circa 2000 except more distributed (better botnets) and greater use of amplification. As in 2000, most flooding DDoS attempt to overwhelm upstream bandwidth, firewall / load balancer state, or resources on web / application farms.

Though traditional DDoS flooding attacks remain popular, most of the recent DDoS activity has included some level of application or TCP layer attack components. Involved in 27% of the confirmed attacks over the last year, application layer attacks are also the fastest growing DDoS attack vector. Open source tools like LOIC / HOIC and large library of more advanced commercial criminal software targets firewall, load balancer and end-system web, database, and TCP state. A tutorial by security consulting company Securitech provides a nice overview and examples of these layer3+ attacks.

Finally, “Other” in the above chart is a bit of a grab-bag, including operator defined policy around allowed traffic levels for things like ASN, GeoIP (countries), ATLAS filters, large lists of ACLs and payload (e.g. DNS, URL) regular expressions. Although designed as a line-speed DDoS mitigation appliance, some providers use the Arbor TMS to effect policies similar to next-generation firewall or carrier-grade IPS. Our analysis generally cannot distinguish between DDoS mitigations and policies enacted for other carrier security strategies.

As discussed earlier, the Wikileaks flooding DDoS components fell into the small or mid range of our yearly survey data (links available here). The chart below shows statistics on the flooding DDoS bandwidth, packets per second and duration for the 5,000 validated attacks. The average DDoS comes in at 300 Mbps and 200 Kpps lasting several hours. Though given the heavy tailed nature of DDoS attack distribution, the mean is skewed by a relatively small number of extremely large DDoS (including one 22 Gbps and 9 Mpps IP fragment attack against a single web farm lasting four days). The median of 30Kpps suggests that the majority of DDoS by number of incidences remain fairly low bandwidth (and likely reflect provider offering DDoS mitigation services for hundreds of small customers).

The next table focuses on the number of unique sources involved in DDoS flooding attacks. Despite the availability of massive botnets, most confirmed attacks in our study involve relatively few, well-connected IPs — the average is 80 sources generating an average of 162 Mbps and 48 Kpps each. Even the 95th percentile of attacks involves only 300 sources. Why so few botnet hosts in these attacks? I suspect the answer is a) a hundred well-connected hosts is more than sufficient to overwhelm many mid-size web farms (you just don’t need more than this) and b) botnets are an increasingly valuable resource to be used judiciously as discussed in this Security Week article.

Though more than 100,000 users downloaded the LOIC software last week, the actual peak number of simultaneous Wikileaks retaliatory attackers was significantly lower. ATLAS data suggests the number of attackers was in the hundreds (i.e., instead of thousands or tens of thousands). In other words, the number of source IPs observed in the Wikileaks retaliation attacks fell into the mid or higher end of the 5,000 validated DDoS last year.

Of course, just tracking statistics per IP does not tell us if these are real or spoofed source addresses. And indeed, increasingly unrealistic data as we approach the max (4 Gbps per source IP!) in the above chart suggests some degree of either source spoofing (e.g. poorly written attack tools always using the same source address) or large number of hosts behind NAT / mega-proxies. About 10% of attacks fall into this category of unrealistic source IP statistics.

The next table focuses on TCP layer DDoS attack statistics. The first column shows the number of TCP connection attempts per second in each attack and the second column provides the median, mean, 95th percentile and max number of connections that actually pass a range of validation algorithms (i.e. “prove” that the TCP connection is from a real host). Ranging from several hundred thousand to millions of connection attempts per second, the data in above chart suggests most of these Syn floods either use attack tools with incomplete stacks or spoof the source IP address (which is pretty much what you would expect). In the specific case of the Wikileaks retaliatory attacks, we believe most of the traffic did not spoof and used the actual sources IPs.

Finally, the last table below provides statistics on two types of application-layer attacks: HTTP and SIP. In general, HTTP attacks involve highly targeted floods of requests for complex / computational expensive web or service queries. Examples of well-known attacks include Slowloris and Slow Post. From the data, web attacks involve relatively low bandwidth (95h percentile is 10Mbps). Further, web attacks involve large number of hosts (414 in the 95th percentile) than zombie and other types of flooding attacks. Both SIP and HTTP layer attacks tend to be long-lived — targeting infrastructure for days and sometimes weeks. Unlike HTTP, SIP attacks tend to be larger (average 200 Mbps and 77Kpps) and more resemble flooding attacks as hackers attempt to overwhelm SBCs or soft-gateways.

So what conclusions can we draw from all of the above data?

Like the initial Wikileaks attacks, most DDoS continue to rely on brute force flooding to exhaust link capacity or overwhelm load balancer, firewall and web server state. Further, despite the conventional wisdom in the security community that spoofing is no longer common (because botnets are so prevalent), analysis of 5,000 validated DDoS attacks suggests a significant percentage of attackers still take advantage of a lack of BCP-38 and generate large volumes of spoofed DDoS traffic.

While the Wikileaks and retaliatory attacks may not represent the start of “cyberwar”, governments clearly view cyberspace as the battlefield of the future. The trend towards militarization of the Internet and DDoS used as means of protest, censorship, and political attack is cause for concern (the world was a simpler place when DDoS was mainly driven by crime, irc spats and hacker bragging rights). Overall, DDoS fueled by the growth of professional adversaries, massive botnets and increasingly sophisticated attack tools poses a real danger to the network and our increasing dependence on the Internet.

- Craig

Credit to Joe Eggleston, Jose Nazario, Jeff Edwards, Roland Dobbins and Mike Hollyman for their contributions to this analysis.

In the second round of what may possibly be a protracted Internet skirmish, a denial of service attack briefly blocked access to the cablegate.wikileaks.org web site this morning around 8:00 am EST. On twitter, Wikileaks pegged the DDoS as exceeding 10 Gbps (significantly larger than my 2-4 Gbps estimate for the first round of attacks on Sunday).

As compared with this Sunday’s initial attack (blog analysis available here), ATLAS data from 110 providers around the world suggest today’s DDoS was both larger and more sophisticated. Specifically, today’s attack involved several different components, including a low bandwidth application level DDoS and a 2-3 Gbps Syn attack against the primary “cablegate” IP addresses (the hosted web site is load balanced across data center locations in Europe and the US West Coast).

An example of one of the anonymous alerts ATLAS collected yesterday is shown below. This alert is for a modest TCP Syn attack against cablegate.wikileaks.org targeting high number ports. The source address blocks are anonymized with XX replacing the high number bits.


<attack start="2010-11-30 18:10:01 GMT" stop="2010-11-30 18:56:27 GMT">
    <rate bps="70312432" pps="220847"/>
      <protocols>TCP</protocols>
      <tcpflags>Syn</tcpflags>
      <source>
          <ips>xx.xx.25.0/27</ips>
          <ports>1024-2047</ports>
      </source>
      <dst>
          <ips>204.236.131.131/32</ips>
          <ports>16384-32767,32768-65535</ports>
      </dst>
</attack>


In the below chart, I graph traffic from 110 ATLAS carriers around the world to address blocks (BGP prefixes) used by Wikileaks. Note these address blocks may also include traffic to other customer using the same hosting provider. The attack began around 7am EST though a smaller traffic spike occurs around 2am. All times are EST. At the time of this blog posting, the DDoS is still ongoing though not significantly impacting Wikileaks access.

Based on Netcraft and other reports, the outage was brief though cablegate web site performance was moderately impacted throughout the day.

Interestingly, the attack appears to originate from a relatively small number of source IPs, including machines in Russia, eastern Europe and Thailand.

- Craig

Yesterday morning, a DDoS attack temporarily disrupted traffic to Wikileaks hours ahead of the “Cablegate” release of leaked US documents. Wikileaks announced the outage on a Facebook update and Twitter post around 11:00am EST while simultaneously derogating the attack and insisting “El Pais, Le Monde, Speigel, Guardian & NYT will publish many US embassy cables tonight, even if WikiLeaks goes down”.

In the below graph, I show traffic to one of Wikileak’s primary hosting provider on November 28 through 100 ATLAS providers around the world. At approximately 10:05am EST, traffic abruptly jumps by 2-4 Gbps as the attack begins.

Shortly after the attack started, Wikileaks redirected DNS from its AS8473 Swedish hosting provider to use mirror sites hosted by a large cloud provider in Ireland (and later the US as well). While the DDOS attack generated an outpouring of blog posts, news articles and tweets, it appears to have had little impact on the Wikileaks “Cablegate” disbursement of documents.

Overall, at 2-4 Gbps the Wikileaks DDoS attack was modest in the relative scheme of recent attacks against large web sites. Though, TCP and application level attacks generally require far lower bps and pps rates to be effective (more discussion of recent DDoS trends is available here). Engineering mailing list discussion also suggests the hosting provider and upstreams decided to blackhole all Wikileaks traffic rather than transit the DDoS.

At the time of this writing, all Wikileaks domains are reachable from servers in the US, Europe and Asia. The New York Times and most other major media outlets also have since published extensive synopses of the leaked documents.

While the source of the attack is unknown, blogs and social networking sites have alternatively blamed governments and vigilante hacker groups. At least one twitter account with a history of past attacks ( th3j35t3r">“the Jester”) has claimed responsibility. In earlier tweets, the Jester boasted of using low bandwidth application layer attacks instead of relying on large botnets (all of which is consistent with the data ATLAS observed for this Wikileaks attack).

Wikileaks also came under fire in 2008 with a 500 Mpbs DDoS attack shortly before the release of leaked Swiss bank documents.

Update: A follow-on blog post analyzing the second day of Wikileaks DDoS attacks is now available here.

 
- Craig