About 3 weeks ago, one of our readers, Andrew, submitted a very interesting malicious binary. Andrew did some analysis himself and told us that he found encrypted files and some certificates which immediately caused interest amongst handlers.
If you are regularly reading ISC, you probably read the diary I wrote back in January about unsophisticated malware (http://isc.sans.org/diary.html?storyid=2022). Well, this time, things were completely different.

Initial analysis by Andrew showed that the machine was infected with a VML exploit. A small binary is dropped on the infected machine which, in this case, was a bit more than a typical downloader.

The analysis of unknown malicious programs can be a very difficult task. The first step in any analysis is to determine if the binary is packed or not. PEiD (http://peid.has.it), a tool I mentioned in the previous diary quickly determined that the binary was packed with UPX. UPX is a very common packer that is easy to unpack – various utilities exist that can help you with unpacking UPX and even doing it manually is very simple.

Once the binary was unpacked, you will typically want to run the strings command on the unpacked code, to see if there is anything that you can determine quickly by manually inspecting strings result.
The following two lines looked very interesting:

inflate 1.2.3 Copyright 1995-2005 Mark Adler
unzip 1.01 Copyright 1998-2004 Gilles Vollant - http://www.winimage.com/zLibDll

It looks like our malware has been linked with zLibDll, an open source ZLIB compression library. This also explained what Andrew was seeing as he said that a password protected ZIP file was downloaded by the downloader. A quick search of potential passwords did not result in anything so we concluded that the binary must either generate the password with some code, or download it from the Internet. In this case, the second assumption was correct.

Now we come to the most interesting (and difficult part). You could, of course, manually analyze disassembled malware code (IDA Pro is of great help here, if you can afford it), but an easier approach (in my opinion) is to run the downloader through a debugger and carefully watch what it is doing. The debugger of my choice is, of course, OllyDbg (http://www.ollydbg.de), which is the best free debugger for Windows operating system.
In order to debug a program you will need x86 assembly knowledge, so this would be a good time to refresh it (or read some books about it).

The debugging process is relatively simple: you load a file into the debugger, and execute it step by step while carefully watching what’s going on.
The downloader in question did the usual stuff. After copying itself into C:\Documents And Settings\All Users folder, it opened a HTTP connection to the control Web server:

http://ijk [dot] cc/cgi-bin/ [REMOVED] oadfile=q/q2_started_ok
(the site is still up)
Once it registered properly, the downloader downloaded a file called qa.zip, which was the password protected ZIP archive.
Now came the interesting bit. By stepping through the binary with the debugger, we were able to determine the password used to protect the archive. You can see how it is slowly appearing in the EDI register (the real password is much longer which makes brute forcing the ZIP archive difficult). A method similar to this one is always used when a malware generates a password programmatically – it will either keep it in one of the registers or somewhere in the memory.



Knowing the password it is easy to extract the ZIP archive now and as the standard ZIP format was used this can be done even with a standalone ZIP program.

The archive contained some interesting binaries:

$ ls -l
total 144
drwxr-xr-x 2 test test 4096 Jan 10 19:57 .
drwxr-xr-x 4 test test 4096 Feb 12 14:05 ..
-rw-r--r-- 1 test test 1505 Aug 10 2005 cert.pem
-rw-r--r-- 1 test test 692 Jan 8 09:49 crontab.cb
-rw-r--r-- 1 test test 432 Jan 8 09:49 _qbot.cb
-rw-r--r-- 1 test test 96768 Jan 8 09:30 _qbot.dll
-rw-r--r-- 1 test test 20480 Dec 29 08:19 _qbotinj.exe
-rw-r--r-- 1 test test 600 Jan 8 09:49 updates.cb

Casual inspection of files did not show much and we concluded that all the .cb files were encrypted (or obfuscated) as they had purely binary contents. The cert.pem file was obviously used as some kind of a certificate to encrypt something. So we continued with the debugging of the main downloader.

After some time spent on it, the part that decrypted the *.cb files was executed. It was a simple obfuscation function. Typically in cases like this what most analysts do is write a perl program that does the same thing so you can decrypt the files without running the malware.
The file contents were pretty obvious – updates.cb contained list of URLs to update from and _qbot.cb contained information about the C&C IRC servers.

The last thing that puzzled us was the certificate – what was it used for? The answer was in the _qbot.dll file. This file contains the main IRC bot, that is injected in another process and executed. Analyzing this file revealed that it was linked with another package (this time commercial), called MatrixSSL. MatrixSSL is a library by PeerSec Networks (http://www.peersec.com/matrixssl.html) that allows application to support SSL/TLS. This was obviously used by the malware to encrypt its network communication. In this case, the cert.pem file was used to connect to the IRC C&C server and encrypt the session, so network IDS tools would not see any commands issued to the bot.

As most anti virus analysts already saw, malware authors often reuse their code. It’s not strange to see code from one malware family used in another. This case showed us that malware authors are happy to use open source or even commercial packages that can help them. And they treat their programs as full blown projects, as one string from the bots binary confirmed: J:\projects\qbot\matrixssl\src\matrixSsl.c.

Finally, the AV detection on submitted files is still very bad, even weeks after it has been released. The original downloader was detected by only a handful of AV programs, while the second stage (real bot) was detected by only 3 programs. It is clear that you can not rely only on the AV program and that you should have defense in depth. In this case, blocking outgoing TCP traffic would at least prevent the bot from contacting the C&C server and doing more harm on your internal network.