Dissecting The Storm Worm

The Storm worm marked its presence in early 2007 and became an infamous robot network primarily known for its spamming and phishing activities.

Also known as  Nuwar / Zhelatin / FakeAV / Peacomm, this bot reappeared early this year, distributed by fake AV   software  and Trojan downloaders. Storm is a major botnet when compared  with  many other spamming bots, due to the massive volumes of spam it sends from the victim’s machine. It also uses a fast-flux mechanism to hide its distribution areas. During our static analysis of the Storm executable, we observed it to be heavily obfuscated with an unknown packer and an infinite loop to halt its activity whenever it detects a debugging or virtual machine environment.

Storm’s spam campaign activity includes a variety of spam, with most related to online pharmacy scams and adult products. This botnet also includes malicious links to URLs that exploit several client vulnerabilities.

Our analysis of Storm confirmed and uncovered some of its unique characteristics, which help network intrusion prevention systems to implement reliable detection mechanisms for Storm’s control activity.

Static analysis of Storm Worm binary

We looked inside the variant we received in April 2010. In the initial part, this sample has various decryption routines. This binary starts with moving 0×5090 bytes to the heap and thereafter executing decryption routines to unpack the binary in stages.

After a complete execution of the loop, the binary is moved to the heap section and then decrypted:

This executable then copies itself as asam.exe into c:\windows, modifies the registry key to execute at Windows start-up, creates the process asam.exe, and terminates itself.

Analysis of the HTTP Communications Code Within the dropped file asam.exe

We reverse-engineered this Storm file and came across some of the unique characteristics of its control channel, which is based on base64-encoded, gzipped HTTP data. The code snippets below reveal our analysis of its HTTP communications.

URI Extensions in the POST Request:

Hard-coded URI extensions and the URI length that is used in the POST request initiated by Storm:

Random Generation Functions to form the URI Request Path:

The next code snapshot shows the random character-generation function that generates 3 bytes of random alphabetical characters which are appended with the “.” to form the request URI path. Thereafter, the random generation function is called again to select any random extension from .jpg, .htm, and .gif, and completes the URI formation by appending it to the previously generated request path:

HTTP POST Request Header:

These are the low-level details of how the POST request will look when the worm is executed on the machine:

As we figured out from the code above, this variant communicates with the bot master via an HTTP POST request. In examining the POST request code, another clue is the possible typo in the user-agent header, in which it is set to “Mozilla/4.0 (compatible; MSIE 6.0; Windoss NT 5.1; SV1).” (Note “Windoss” instead of Windows. This is a very good hint that Storm is in action; intrusion prevention systems can use this hint to detect Storm on the wire.) The botnet server then responds with the spam template used by the bot to send the spam.

All the preceding data from the server is base64 encoded. After decoding the response from the server, we found following spam template:

Once the bot client decodes this data, it uses the following looped SMTP engine code to send spam mails based on the spam template.

 

Below is one of the spam mails generated by this bot

More Uncovered Commands

Scanning the Drive for Files

Storm also includes a routine to scan the drives for files with the following extensions:

.wab, .txt, .msg, .htm, .shtm, .stm, .xml, .dbx, .mbx, .mdx, .eml, .nch, .mmf, .ods, .cfg, .asp, .php, .pl, .wsh, .adb, .tbb, .sht, .xls, .oft, .win, .cgi, .mht, .dhtm, .jsp, .dat, .lst

It also searches for particular strings within these files, probably to extract the information about the host and email addresses contained in them:

@microsoft, rating@, f-secur, news, update, anyone@, bugs@, contract@, feste, gold-certs@, help@, info@, nobody@, noone@, kasp, admin, icrosoft, support, ntivi, unix, bsd, linux, listserv, certific, sopho, @foo, @iana, free -av, @messagelab, winzip, google, winrar, samples, abuse, panda, cafee, spam, pgp, @avp., noreply, local, root@, postmaster@

Detecting Storm Worm on the Wire

The majority of mail traffic over the Internet is spam. We need to detect these spam bots and try to keep them from proliferating. Our analysis provides good hints for detecting Storm traffic on the network. One high-confidence approach would be to correlate multiple suspicious events happening on the network within a short time. One example is a user-agent check for the typo we saw; we can correlate this with the multiple outbound DNS MX queries from the same source within a short time. An even more reliable detection would be to correlate those two events with a spontaneous increase in the outbound SMTP connections from the source.