Friday, 10 July 2009

Korean/U.S. DDoS Attacks - Perplexing, Disruptive, and Destructive

A lot of people have been asking about these "Korean DDoS Attacks". Like a lot of people we have been staying fairly quiet so the issue could be worked. It's time to get a little more information out there and we hope this is of use.

Starting some time on July 4, 2009, the Independence Day holiday in the United States, several U.S. Government websites came under a fairly sizable distributed denial of service (DDoS) attack. Most notably, as reported by CSO affecting the FTC, FAA, and Treasury. The attack, however, was not limited to these websites and would soon spread to both government and commercial websites in South Korea and the United States.

DDoS Targets and Methods

The following is a full list of the 46 known targets we are aware of that were that were seen from the malware samples in the wild:

We know that some of these websites were downed during their attack periods, but we are not sure of the numbers or for how long. Additionally, we know that the following attack methods were used:

TCP SYN Floods

UDP Floods

ICMP Floods

HTTP GET Request Floods

For the first three attack types the traffic was often spoofed with random source addresses with the actual attacker IP intermingled. The HTTP floods were of course not spoofed. Infected systems would start DDoS'ing portion of the above list of targets at specified times. The malware would send millions of packets of DDoS traffic to these targets should the machine be left on over this period of time. In case you were wondering.. that's a lot of traffic.

Botnet Size & Infection Mechanism

One thing we know is that this involved a pretty large botnet that seems to have appeared over night. Some of the DDoS attacks were known to have involved over 100,000 attacking hosts. Further reliable botnet estimates put the total infected count about 200,000. This is not a small botnet by any account. Even more interesting is that different sources put the total number of infected systems that are from South Korea at 90-95%. It is rare for a botnet of this size to be so geographically centralized.

As of the time of this posting on July 10, 2009, we are *NOT* aware of anyone that has identified a mechanism by which this malware spreads or how it ended up on so many systems -- especially Korean systems. Speculation includes drive-by exploit sites (most likely on Korean websites) and e-mail propagation. However, we have yet to see anyone post any conclusive evidence. We would personally lean towards the drive-by exploit vector, potentially spreading through some of the unpatched exploits for various ActiveX controls. Once again though this is just speculation.

The Malware

We know what the malware does because we have copies of it. The company AhnLab has gracious supplied us with copies and allowed for us to analyze it. They have also been working to put out a lot of the information that is currently available. Here is what we can tell you. The initial dropper of the malware we have examed installs several files on the system. One of the files is a .dll that is then added as a service. At this point the malware begins to attempt to beacon to these three IP addresses:

213.23.243.210:443
213.33.116.41:53
216.199.83.203:80

I have not read all of the malware analyses that have been done out there, but I believe they look to these servers for updates. None of these servers were responding at any point when we first looked into the malware a few days ago. Once the service that is installed is started, it will look to a file called "uregvs.nls" for its list of DDoS targets. If the system clock matches the magic time its looking for the DDoS will commence. Once the clock reaches the time at which it is to end, it will stop the DDoS.

Another file dropped by the system that we observed was called "wmcfg.exe". This file once executed also drops a dll and installs itself as as service. It immediately starts connecting out to the web on tcp port 80 with a pre-set list of update servers. The malware would look to pull a file with a ".gif" extension from the following list of hosts:

Should it succeed in getting this file, the malware will then update itself and beginning spamming itself out. These spams are constructed as follows:

From: "Independence" <wmdcznh480@gmail.com>

To: bricecotte@gmail.com

Subject: Memory Of...

Date: Wed, 8 Jul 2009 09:04:32 -0500

MIME-Version: 1.0

Content-Type: multipart/mixed;

.boundary="----=_NextPart_000_0009_9C750172.81837DFD"

X-Priority: 3

X-MSMail-Priority: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0009_9C750172.81837DFD

Content-Type: text/html;

.charset="euc-kr"

Content-Transfer-Encoding: 8bit

<html>

<body>

last<BR>

</body>

<html>

------=_NextPart_000_0009_9C750172.81837DFD

Content-Type: application/octet-stream;

.name="memory.rar"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

.filename="memory.rar"

UmFyIRoHAM+QcwAADQAAAAAAAAA=

------=_NextPart_000_0009_9C750172.81837DFD--

You might be quick to notice a few things. The first is that the .charset is "euc-kr". Sound familiar? Next, yes there is an attachment, but no it is not malware! Convert "UmFyIRoHAM+QcwAADQAAAAAAAAA=" from base64 to ascii and you get the beginning of a .rar file header, but that is all. No magic to that. Here is a screen shot of what the e-mails look like:

Please take immediate action to clean systems on your network if you see the web and spamming activity described above!

At this point it's a mere annoyance, but the malware gets dangerous. It has been widely reported that on July 10, 2009 the malware will become destructive and destroy the PCs. This is actually fairly accurate. Should "wmcfg.exe" be executed, start, and update a new version of a filed named "wversion.exe" is placed on the system. Once executed (supposed to on July 10) this file then starts damaging the hard drive and encrypted gzipping (with a password) several file extensions on the system (correction: we have since learned from people that looked closer that these while named .gz are actually .zip files with passwords on them - perhaps done using pkzip). Notably it does this to document and web files. If the computer is rebooted it will no longer function. In our testing the system destruction did occur when the clock hit July 10, 2009 but required an reboot to start destroying the files. We are not sure if this is different in the wild. The following is a screen shot from Filemon from when "wversion.exe" was excuted:

We would also like to point to a write-up done by Sang-Keun Jang from HAURI in South Korea. He has put together his report in English at the following link:

North Korea, Cyberwar, and a Somewhat Final Conclusion

First we have seen no evidence to point a finger at North Korea. How could we tell anyway without an extensive investigation and access to all kinds of logs and other data? Unless someone has a lot of extra information, this has to be pure wild speculation as well. Cyberwar? NO way! The term Cyberwar gets thrown around all the time. It's hard to define and everyone has differing views. However, I would venture to say this is far from what most people would call a Cyberwar. It is a bit closer to Cyber Terrorism but definitely not Cyberwar.

We are very interested to find out how this malware is spreading and infected so many systems. If you happen to find out and it's not main stream, please drop us a line and let us know. It is still a mystery how a botnet of this size can just appear out of the blue. It also goes to show how ill prepared many of us are to defend against DDoS attacks. Please keep an eye out in your logs for traffic to the above IP addresses and clean machines immediately if you see activity that's indicative of infection or they might lose all their data. We don't have many more updates we can share beyond what you see here.

Credit

We should like to especially thanks AhnLab for providing malware samples to be analyzed. Without that we would have only a limited amount to go on. There are also several anonymous sources that allowed us to use bits and pieces to fill in parts of this report. We would like to thank them as well. Additional we would like to thank all of the other security researchers and related parties have been and still are working these issues even though it is not required of them.