Websense.com / Security Labs / Blogs / Do we protect against the STORM attacks?

Archived Blog

Do we protect against the STORM attacks?

08.25.2007 - 11:32 AM
Since early July the Storm Trojan has been the most active attack that we have seen in a couple years on the net. Is it a worm? A Trojan? A Bot? A spam agent?  The answer is “All of the above”!

WE PREFER TO CALL STORM AN ATTACK

Some reasons we believe the Storm attack is significant are:

* It is very widespread and appeared to have infected literally hundreds of thousands if not millions of users
* It is sophisticated (has some polymorphism attributes)
* Traditional firewalls and signature based methods are not being affective in preventing it
* The attack infrastructure is very resilient and difficult to take down (FFlux DNS, moving targets, lots of name servers, etc).
* The sheer number of machines that have the capability to perform a DDOS at the instant of the operators command
* The massive amount of email lures and spam it is spewing out
* The profit motive on pump and dump stock scams
* It was very well planned out and orchestrated

We also believe that this is a sign of things to come in the future. This is a very well thought out attack that has been the plague of security departments around the globe for more than a month now and it does not appear to be letting up.

SecureWorks has a good write-up if you are looking for more technical information the Trojan itself and how it all works here: http://www.secureworks.com/research/threats/view.html?threat=storm-worm

Due to the fact that many signature-based products are having problems keeping up with the large amount of samples changes and modifications, and the fact that the code is served up through the web, we are getting a lot of requests from our customers on if we are blocking the attacks.

THE OVERWHELMING ANSWER IS YES, WE HELP PREVENT THE STORM ATTACK

* NOTE1: we often block the IP address or URL of the master servers not the IP of the proxy / bot that is redirecting the traffic
* NOTE2: we often block the file download but if you check the category of one of the IP's of a proxy/bot machine you will see it as uncategorized. This does not matter as the code is being served from the master location and/or via the filename

The net result is that have been preventing the infections of Storm attacks on thousands of corporate networks every day. Depressingly enough we see thousands of attempts of users clicking on the latest greeting card, login info, and to get updates. However, these attempts at downloads are being stopped at the gateway through our security classification.

The below chart shows our internal Threatseeker portal reporting on a set of our honeyclient results (see more details on honeyclients below this section). This shows that for this particular set of identification methods, we started seeing attacks on July 3rd and the number of machines which matched this profile peaked around July 31st. Of course we have several attack identification methods and the attack profile changes almost daily, but the sum of all our attack detection methods shows us discovering tens of thousands of sites on a given day. 


 

We are also getting a lot of questions on "how" side of things. In particular how are we finding these sites and protecting our customers from visiting them. While we can’t give away the secret sauces here are some details:
Threatseeker is the systems, processes, and intelligence, that powers the Websense products by identifying malicious sites and applications on the Internet and funneling the results into customers products in real-time.

1) Threatseeker honeyclients : designed to find the sites through our passive, active, and hybrid honeyclients. Most of the time we are catching them via passive exploit signatures that we maintain and develop. The methods that the Storm attackers are using to attempt to exploit users has not changed much and they deploy pretty obfuscation techniques we have been tracking for a while now. Note: our active honeyclients also detect unknown attacks through our machine/browser simulation and behavior state machine analysis. The below screenshot shows an example of what a site looks like when you connect with Internet Explorer. As you can see the page uses obfuscation techniques in an attempt to thwart detection. If a user connects with a vulnerable machine the storm code will run on their machine. If not they will get a message in their browser luring them to download and run the file manually.


But what if they changed the obfuscation methods? We are seeing this more and more and in some cases websites are using pseudo-polymorphic script to change on each connection or with each user. Because of that we also have a de-obfuscation function integrated. The above encoded text ends up being broken into several of the functions and the tool then outputs the decoded text as you can see below from a screenshot of our Threatseeker internal research portal:


 
The screenshot shows the functions of the obfuscated code on the right and the de-obfuscated code on the left. This particular snippet is the shell code the Storm attack attempts to run based on exploit code.

2) Threatseeker honeypots: Storm Bot's are pumping out a *lot* of spam with lures to their sites in email. Our extensive deployment of email honeypots are tracking the latest tactics and methods used.
Here are some interesting screenshots from our Threatseeker honeypot mail collections. This is in an approximate 24 hour period and shows the number of emails that we received for only one single *Storm IP address lure*.

 The next screenshot shows the volume of actual mails we sent for only one IP address with the highest number per subject for the reporting timeframe. The unlucky winner is “new user info” with close to 4000 emails with lures for one single IP address!


 
3) Binary Analysis: The Storm Trojans to date have all been packed with proprietary packing techniques. By maintaining inventory and identification of well known “good” and “bad” packers we can make content classification choices.

The storm worm appears to be encrypted using a custom "packer" tool. It doesn't seem to be compressed at all, just encrypted. The decryptor first self decrypts some of its code, and the newly decrypted code will allocate memory, and copy all the remaining "unpacking" code there. It uses self patching technique in order to know when it has to execute specific code. The last version we discovered, had a nice trick using a windows API function in order to zero out a register, used within the decryption. It’s important to notice that, it will trigger exceptions within the debugger, and will slow down the decryption, unless you patch it that is.

The decryptor starts in the first section, and in order to do this, they had overwritten 0x46 bytes from the first section. So right before decrypting the executable, it will replace the overwritten pieces, which is 0x46 bytes long. Then, the decryptor will execute two big decryption loops. Every sections of the executable were encrypted twice, so they will be decrypted twice, from last, to first.

The packer also makes sure the Export Directory RVA and Size are set to zero.

-- unusual stuff for a packer that is important to mention starts here --

The decryptor will then unprotect c:\windows\system32\drivers\tcpip.sys for one minute using SFC_OS ordinal 5 undocumented API call. This allows one to update the file without triggering any warning from windows.
The decryptor will make a copy of the encrypted file inside the WINDOWS directory, under the name of "spooldr.exe". It will also drop one of the two embedded drivers it contains as "spooldr.sys". Indeed, the decrypted file has two embedded drivers, and one of them is used to backdoor the kbdclass.sys file. Therefore, the decryptor will try to open both "\dllcache\kbdclass.sys" and "\drivers\kbdclass.sys" in order to backdoor them.In order to do so, it creates a .tmp file that has the backdoored driver and doesn't touch the original fileas they are still protected by the Windows File Protection threads. The backdoor’d driver has a new entry point, and the file has been enlarged, and the Driver checksum was updated, using the imagehlp.dll, function: CheckSumMappedFile.

The packed file will either calls the ExitProcess function now, or will dynamically resolve his imports, before executing the original entry point.

-- another very unusual thing for a packer --

Right before executing the original entry point (decrypted application), the decryptor will first execute the following command on the machine:

"netsh firewall set allowed program "C:\WINDOWS\spooldr.exe" enable"

This way, the packed sample will be able to bypass the Windows Firewall, without any Security Warning. The storm worm "dropper" is then executed and can do his dirty job.
Notes:

- The packer itself does NOT use any Anti VM code.
- The decrypted application on the other hand, does have Anti Vmware (Vmware backdoor), and
Anti Virtual PC (VPC invalid Opcode trick).

Some screenshots of interest…
Self patching routine:
 
Start of code execution on heap: 0x46 bytes overwrite:

TCPIP.SYS unprotected by SFC_OS Ordinal 5:


 
Driver Backdooring:


 
4) Binary analysis combined with site reputation: One of the big problems with blocking binary downloads is the chance you may have a false positive (FP). One way we can afford to be more aggressive on our classification in cases like Storm is that we combine the attributes of where the code is coming from. In the Storm case the URL's that are embedded within the spammed emails are mostly hosted on compromised machines that are connected on broadband end-user networks (i.e. residential IP addresses). We correlate many attributes along with the contents of the exploit code and binary with items such as; geo, IP address assignment, URL strings, and history in the case of Storm in order to be more aggressive without causing undue false positives. So, we combine the where (residential broadband IP), with the what (unknown custom packers / exploit code / obfuscation identification / etc), to identify malicious sites.

Conclusion: The Storm attack is something we can expect more of in the future.  It is an organized, sophisticated, well planned out and resilient attack that has infected millions of machines around the world. The techniques use a combination of attack vectors including; DNS, Web, P2P, encryption, and several evasion techniques. This not only highlights the need for deploying sophisticated counter measures to mitigate your companies risks, but also shows the need for more collaborative efforts across borders with law enforcement, ISP’s, and other folks moving forward.

Bookmark This Post: