Malware storms: a global climate change

Since late 2006, the family of W32/Nuwar malware threats, often called the ‘Storm worm’, have been slowly but surely taking the Internet, if you’ll excuse the pun, by storm.

In this article we examine the evolution of Storm from its rather humble beginnings as a minor malware threat into what is probably one of the most bleeding-edge malware technologies currently affecting systems across the globe. We will focus particularly on the ways in which the malware authors have attempted to combine advances in social engineering techniques with changes in behaviour (and particularly network communication) to avoid detection by anti-virus systems. These changes are significant for their impact on anti-malware detection and perhaps more significantly on intrusion detection and prevention systems (IDS and IPS).

For some time, malware researchers (including us) have been predicting the move of botnets away from centralized command and control servers towards decentralized control models using peer-to-peer technology [1]. The Storm worm (also known as Zhelatin, Nuwar, Peacomm, Tibs, Peed and Fuclip) was one of the first bots to be seen using peer-to-peer communications. The bots were now swarming.

It has become increasingly clear that the authors of the Storm family are not simply hobbyists, but rather are investing seriously in their creation, actively seeking to increase its capabilities and to protect it as far as possible from detection.

Storm gets its name from one of its early spam/seeding runs, which was seen in early 2007 just after the severe storm Kyrill that ravaged large parts of Europe. As is typical with many email worms and seeding runs, the messages in the initial Storm seeding runs used a variety of topics related to current news to entice recipients to open the email and execute the attachment. One of the early messages claimed to contain a video of the execution of Saddam Hussein in Iraq. The message came with a file called ‘Full Clip.exe’ which, when executed, would infect the PC with the latest variant of the Storm worm. One of Storm’s common aliases, ‘Fuclip’, was derived from this seeding run. Earlier subjects involved claims of imminent nuclear war (from which ESET took the Nuwar alias), the death of Cuban president Fidel Castro and US aircraft being shot down by missiles.

Interestingly, the Storm worm has changed its seeding methods several times, from initially using the tried and tested ‘enticing’ email subjects as described above, through using electronic greetings cards (a move that had a huge impact on the revenues of legitimate e-card retailers), via websites containing exploit code, to the most current form – websites that do not contain exploits, but which offer ‘free’ downloadable content, such as sport scores and computer games. The common factor in all these social engineering techniques is that the malicious files or websites are advertised through emails.

A chronological breakdown of the different social engineering methods used by Storm [2] is shown in Table 1.

Drawing on different techniques of social engineering is probably intended to hit as many ‘hot-buttons’ as possible. By using techniques from classic email worms, phishing and so on, and covering a wide spread, the worm variants are more likely eventually to be successful. The use of such techniques can also deflect attention, because the threat becomes just another one of the many, rather than being noticed immediately as another Storm worm.

Of course, many businesses filter out executable attachments in email. This may have forced the change seen in seeding methods to those in which only a link was included in the email – which required more sophisticated social engineering to tempt the user. Some of these links directed the user to websites containing code that would exploit vulnerabilities in popular browsers or applications, but as time progressed (and as patches for those vulnerabilities became available) a switch was made to more legitimate-looking sites.

One of the most recent versions of the Storm seeding mails offers arcade games for download (see Figure 1). Of course, all the links on the site simply download ArcadeWorld.exe – a variant of the Storm worm. No doubt by the time this article is published, things will have moved on again.

Figure 1. Storm’s ‘Arcade World’ site.

Once it’s on a system, the biggest strength of the Storm worm is its communication mechanism, which allows its authors to monitor the performance of their botnet closely and to update the code base rapidly. Storm uses its communication for the following purposes:

During the first six months of its existence, the Storm worm used the Overnet peer-to-peer network protocol to exchange information about the location of update files on the Internet.

To bootstrap the connection to the Overnet network, a node needs to establish connections to a certain number of peers on the network. It does this using a file containing the IP addresses of a number of known peers. When a new node connects, it sends its information to these peers which, in turn, reply (assuming they are online) with a list of other peers to which the new node can connect. In most cases, a newly connected node needs to establish contact with a few hundred peers before it can begin searching for information.

Systems infected with the Storm worm would perform the following steps to connect to the network and find a new version of their binaries:

The network bootstrap process and subsequent status updates generate significant amounts of traffic on the network. Figure 2 shows the number of IP addresses contacted when sending (blue) and receiving (red) peer-to-peer information. Figure 3 shows the number of network packets being sent (blue) and received (red) by a system recently infected with a variant of the Storm worm. The first 20 minutes are spent connecting to the peer-to-peer network. Afterwards, an update of the available peers is performed once every hour. These updates can be seen in Figure 3 as peaks after 80 and 140 minutes of activity on the graph.

Figure 2. IP addresses contacted by a newly infected Storm node.

Figure 3. Network traffic pattern from initial infection onwards.

The Overnet protocol relies on 32-bit hashes [3] to identify nodes uniquely on the network. When a node searches for information on the network, it generates an MD4 hash using the name of the information and then searches for a match to that hash. To search for the hash, the node sends search queries to peers in its list of known peers that have a hash closest to the one it is looking for. These hashes are XORed with the one the node generates to find the ‘distance’ between them – the lower the value, the closer the hash.

When we discovered that Storm was using the Overnet protocol, and a fixed set of hashes generated by a key within the binary, we were able to create a program that let us monitor Storm worm communications transmitted on the Overnet network. This was essentially a set of Ruby classes that implemented part of the Overnet protocol. This allowed us to connect to and search for Storm-related information on the Overnet network, and gave us the capability to parse packet captures of Overnet communications. Using this method we were able to monitor the Storm worm network for more than four weeks, effectively finding update locations and fetching new samples as they were released.

Unfortunately (probably because there were a number of security researchers doing similar things) the malware authors later modified their code and changed the communication scheme.

Around the month of May, the Storm worm started encoding its communication data inside strings that looked more legitimate for peer-to-peer file sharing. An infected system would still perform a search for an MD4 hash on the Overnet network but the answer would come as a set of strings similar to file names and sizes (e.g. ‘14173.mpg;size=83526;’). It seems that the update mechanism was changed and update locations were no longer transmitted over the peer-to-peer network.

The Storm authors use a variety of means to hide their creations and hinder the reverse engineering process. A simple, but very effective way of hiding the functionality of an executable is to fetch the code for a certain behaviour only when it is needed. In variants discovered at the beginning of the year, Storm worm programmers decided not to include any payload in their malware other than an update mechanism [4].

If they wanted to use the botnet to send spam, they would issue an update containing all the code to send that spam and the addresses to which they wanted it sent. In the same way, a DDoS component with hard-coded victim address would be distributed via the update mechanism present in the Storm worm. This functionality allows the worm to maintain a measure of stealth against detection, and to give away nothing to malware scanners because all ‘attacks’ are planned offline, and a customized ‘update’ delivered on each occasion.

Storm’s authors have always used their own custom packers, but around mid-August, they released yet another version with a new packing method. The latest version of their packer calls unusual functions such as DragQueryFile from SHELL32.dll and CreateMDIWindow from MDI.dll. The return values of these function calls are used by the packer algorithm to decode the original program. This technique seems to be used to fool emulators that haven’t implemented the complete set of API calls made available by Windows. Some emulators will simply return 0 if a call is made to an unimplemented function. In this case, the packer will use a bad return value and the packed code will never be unveiled properly.

The following assembly code shows a technique used in the Storm worm packer to obfuscate the way it writes to memory. Instead of moving a modified value directly to the destination address with the mov operator, the packer changes the stack pointer and then pushes a 32-bit value on the stack. The real stack pointer (esp) is saved in the edx register. After that, the destination address is moved in esp. The value that needs to be written to memory is then pushed from eax to the target memory using the push operator. Finally, the good stack pointer value is restored in esp:

mov edx, esp 
mov esp, edi 
push eax 
mov esp, edx

It is possible to hide the presence of programs and files on a Windows system by hooking specific APIs within the operating system and by injecting code in other processes. Figure 4 shows how a version of the Storm worm executes its code while keeping its presence hidden from the user and from some security solutions.

Figure 4. Example of Storm worm code injection.

The malicious file enters the victim’s system as a Portable Executable (PE) file. In most cases, the executable file will be packed, as previously described. When executed, it drops a Windows driver file in the %windir%\system32 folder. Before finishing its execution, a (malicious) driver is loaded by calling the CreateService and StartService system calls. This process is described further in [5]. The loaded driver will inject code from the kernel side into the services.exe process. The code injected in services.exe then connects to the peer-to-peer network in search of further payloads or software updates.

One of the more recent tactics has been to modify a Windows driver file to take advantage of the fact that it is loaded in memory every time the system boots. Storm modifies tcpip.sys, located in the Windows system folder, to load the malicious driver spooldr.sys. The malicious driver will, in turn, hide its presence through API hooking and inject code into services.exe.

In common with other modern malware, Storm tries to terminate a list of predefined processes belonging to anti-virus programs. If Storm is allowed to execute on a system, it will terminate those processes, and disable any anti-virus protection – so it’s clear that proactive detection is critical.

Around the beginning of October 2007, the authors of the Storm worm made a significant modification to the communication protocol being used. They decided to encode the traffic by using a pre-shared key and XORing the traffic with that key. Figure 5 shows a disassembly of the XOR loop being applied to data before the network communication routine.

Figure 5. XOR loop application.

Below is a dump of a sent packet. Offset 0x2A is the protocol identifier (usually 0xe3 for Overnet) and the next byte should be the Overnet message type field (in this case, it should be 0x0c for Publicize).

0000  00 1c 42 00 00 02 00 1c   42 96 1d 6a 08 00 45 00   ..B..... B..j..E.

0010  00 35 00 23 00 00 80 11   57 99 0a d3 37 05 44 c4   .5.#.... W...7.D.

0020  5c 60 38 77 47 35 00 21   7d 72 10 a6 d8 9c 9b 2f   \‘8wG5.! }r...../

0030  7d 45 b3 6e f9 61 62 2d   da c1 fc 72 63 3d e6 13   }E.n.ab- ...rc=..

0040  a8 54 46                                            .TF

The answering packet (showing that communications are encoded both ways) is shown below. At offset 0x2A, we still have 0x10 as the protocol identifier and the next byte is 0xa7 instead of 0x0d for Publicize ACK.

0000  00 1c 42 96 1d 6a 00 1c   42 00 00 02 08 00 45 00   ..B..j.. B.....E.

0010  00 1e 4f 63 00 00 ff 11   a3 8a 44 bc 42 4d 0a d3   ..Oc.... ..D.BM..

0020  37 05 7c af 38 77 00 0a   71 2b 10 a7               7.|.8w..q+..

This change in behaviour is quite significant since only systems that are infected with Storm will answer these encoded p2p messages – ironically making it easier to identify and disinfect infected hosts.

The developers behind the Storm worm seem to be members of an organized crime gang. In February 2007 they were observed using their network of infected hosts to conduct denial of service attacks against the infrastructure used by the competing Warezov botnet [6] – again used to send out spam.

However, the main functionality and final goal of the Storm worm seems to be to send pump-and-dump emails [7] in an attempt to accumulate large profits for its programmers and operators – although it’s not clear if the operators are the same people profiting from the scams, or whether the operators are simply renting capacity to those scammers.

Pump-and-dump scams have become very popular in recent months, and according to some sources, the return on investment is high [8].

Fraudsters use the infected systems to send emails enticing recipients to buy typically very cheap stocks of a company, predicting a major upturn in the share price over the next couple of days. Before sending the spam, the scammers purchase large amounts of the company’s stock and when the stock begins to gain value (as a result of the increased interest generated by their emails) they sell all their stock and cash out, often doubling their investment. After this large selling action, the stocks often crash and the other buyers (and even investors who didn’t buy) lose what they invested [9].

Because the Storm worm has undergone such rapid, complex and challenging evolution, it has drawn a lot of attention from researchers investigating it. However, it seems that the developers behind the worm recently included an automatic denial of service capability, which will attack IP addresses that make too many queries to key systems on their infrastructure. It is therefore our advice to tread lightly!

There seems little doubt that the effort and development time put into malware like Storm is an ongoing trend, and will be the major challenge facing the anti-virus industry for the foreseeable future. Never in the field of malware has so much been released to so many by so few. (Our apologies to Sir Winston Churchill for the awful paraphrase.)