- About us
- Code of Conduct
- Google SoC
- Recent posts
- Security Workshops
Today, Steven Adair from Shadowserver imformed us about a new piece of malware that looks like a new version of the infamous Storm Worm. Storm was one of the first serious peer-to-peer botnets, it was sending out spam for more than two years until its decline in late 2008. Mark Schloesser, Tillmann Werner, Georg Wicherski, and I did some work on how to take down Storm back then, so the rumors about a new version caught our interest. Mark, Tillmann, and me started to take the sample apart, and it looks very much like Storm indeed. It even uses the same configuration file, stored under C:\WINDOWS\herjek.config (the same filename as used by the last Storm version), but as the command-and-control channel has been replaced with an HTTP based version, there is no peer list included anymmore. When we looked at it, just contained two lines:
Just like Storm, this new malware decompresses itself into a heap section and jumps to the unpacked code. We just dumped the heap section to a file and fixed the imports to get an executable we can analyze conveniently.
Although this is already pretty good evidence that the two specimens are related, the question remains whether this is really a new Storm version, so let's have a look at the actual functionality. We compared the last version of storm to the new samples. Around 2/3s of the functions in the new sample are simply copy&paste from the last storm code base. Since the source code of storm has never been public, the same team of developers has finally created a new variant or sold it's code.
The original version was rather large, having more than 800 function. A large portion of this was the P2P code. This is missing completely in the new version and the actual command protocol is based on HTTP instead of plain TCP connections. We wonder if they don't rely on P2P anymore because of the attack implemented in Stormfucker.
The HTTP request looks like this:
All parameters and responses are base64 encoded and gzipped. Just like in the original Storm C&C protocol. The IP address of the server is hardcoded in the binary. Well, not really in the code but appended in encrypted form. The encryption is XTEA - the same cryptor used in early versions of Storm's packer.
The new version runs as "asam.exe". So, the authors have changed the executable's filename, but they either didn't look in the source code or were too lazy to change the name of the config file.
One method of command & control is implemented via HTTP requests. While looking at those requests we found another clue that this is actually a spinoff of Storm. The User-Agent is set to "Mozilla/4.0 (compatible; MSIE 6.0; Windoss NT 5.1; SV1)" which includes the (intended?) typo "Windoss" instead of "Windows" (this has already been mentioned by Steven, also). The requested path on the server consists of three random letters concatenated with a random choice from gif, jpg, htm extensions.
Also notable is the use of nginx as the web server as revealed by "Server: nginx/0.7.65" in the response. This is probably then relaying the request to upper tier servers in the C&C structure.
The actual command protocol is identical to the original Storm protocol. It consists of a handshake with two phases.
Stage 1 looks the following:
Sent is the command "1", the machine name, operating system version, and an ID which identifies the machine in the further communication. It's like a session key used in HTTP application. The reponse is a reverse lookup of the public IP address of the host, the public IP itself, and other servers, like a Google MX.
Stage 2 looks the following:
Many people thought that this stage is useless. Actually, we found an "update" command in this stage of the handshake, which we used in our "Stormfucker", two years ago.
After this initial handshake, different requests for Spam (command 3) and DDoS attacks (command 6) are sent to the server.
The request for DDoS target is shown in the following. The response is empty (IP address: 0.0.0.0). In case of active DDoS targets, the IP address can be seen here.
The spam part looks the following. The client sends the spam-request command and the server returns the spam-templates, including faked mail server versions, subjects, receipients, target-domains, ...
Mark took some time to write a command fetcher and decoder. Have fun with it :)