Recently, a new Worm/Trojan has been very "popular" in our Net world. This worm uses email and various phishing Web sites to spread and infect computers. When the worm breaks into the system, it installs a kernel driver to protect itself. With the help of the driver, it then injects and runs malicious code from the legitimate process "services.exe". So, it can bypass firewalls easily and open a back door for the bad guys.
This worm contains an SMTP client engine and a peer-to-peer client component. Obviously, these components are prepared for spamming or mass-mailing purposes.
During my research, I found that this worm used various rootkit techniques to protect itself (such as hiding files, registers, ports, and the like), so it's not easily detected and removed. The worm also used a custom packer and encryption to protect itself. In the driver that the worm dropped, we learned that it employs a user-mode APC to inject malicious code (embedded) into the process named "services.exe".
In this paper, I will explain the worm from three aspects:
1. The interesting things that reside in its executable file (custom packer and encryption)
2. Rootkit techniques it uses
3. Peer-to-peer botnet & spamming
Okay, lets start our journey.
When this worm is running, it unpacks itself first, and then drops a malicious PE file that is embedded in the executable file. Then, it decrypts the malicious PE file into heap memory. When these steps are complete, the worm jumps to the heap memory (containing the malicious PE file) and executes the decrypted malicious code. This is the code that is responsible for the bad behavior.
Figure 1 is a high-level view of this worm's activities:
Figure 1. Overview of the worm
Next, I will explain how this worm accomplishes all of this, step by step.
The worm uses a custom packer and encryption to protect its binary file, so the first step it takes is to unpack and decrypt the embedded PE file.
In this section, I will demonstrate how to use OllyDbg and IDA Pro to analyze the worm.
First, I use OllyDbg to debug the worm and try to dump the unpacked file.
Figure 2. Main Routine of the Worm
Notice that Figure 2 shows the main routine of the worm. It exports two functions: plr and wsx . The plr function is used to unpack worm-self, and wsx is the real entry point.
The plr function is passed to wsx as a parameter. This function implements the custom packer used by the worm.
Figure 3. Calling Unpack Routine – plr
After the execution path reaches the wsx function, the first thing it does is to unpack the data section, which contains the code that will be executed further.
Figure 4 shows the packed data section.
Figure 4. Packed Code
From Figure 4 we can see that this code does not have any actual functions and is used only to obscure its purpose.
The figure below shows the same data section after it has been unpacked:
Figure 5. Unpacked Code
Well, it looks very nice. At this moment, we can dump the memory to a file and do a static analysis (using IDA Pro or other tools). This is my favorite way, but we can continue debugging this worm by OllyDbg and watch what it does next.
In the next section, I will use the IDA Pro tool to continue exploring the worm.
I am very grateful for IDA Pro, which is an amazing too