Storm Worm & Botnet Analysis
Total Page:16
File Type:pdf, Size:1020Kb
Storm Worm & Botnet Analysis Jun Zhang Security Researcher, Websense Security Labs June 2008 Websense Security Labs Introduction This month, we caught a new Worm/Trojan sample on ours labs. 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, let’s start our journey. Overview 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. Page 2 of 26 Websense Security Labs Analysis sequence 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. Dynamic Analysis First, I use OllyDbg to debug the worm and try to dump the unpacked file. Stage 1 – Getting Start 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. Stage 2 – Unpack 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. Page 3 of 26 Websense Security Labs 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. Page 4 of 26 Websense Security Labs Static Analysis I am very grateful for IDA Pro, which is an amazing tool. With its help, we can search every corner of the malware. Stage 1 – Decrypt & Decompress in heap memory During the analysis, I found a TEA constant – 0x9E3779B9 in the unpacked file, and after a short analysis I was sure that this worm uses a TEA algorithm to encrypt the embedded malicious PE file. Figure 6. TEA Algorithm Entire Decrypt & Decompress Routine: Figure 7. Decrypt & Decompress in Heap memory Stage 2 – Jump to Heap Memory From here, the worm has already expanded its payload (the malicious PE file) to heap memory, and the last thing it does is to fix IAT and handle relocation. Page 5 of 26 Websense Security Labs Figure 8. Fix IAT & Relocation Assuming everything is okay, the worm jumps to the heap memory to execute the malicious PE file. From that point forward, the worm can start breaking in to the system. Figure 9. Jump to Heap to execute Please compare Figure 9 with Figure 5, and note that they are the same. At this point, the execution path expands to heap memory, and in there, the worm accomplishes its evil task. Stage 3 – Drop a driver & Start Services The main purpose of the malicious PE file residing in the heap memory is to drop a driver and a P2P configuration file, and to start a Win32 service to load its driver. Page 6 of 26 Websense Security Labs Drop the driver: Figure 10. Release Driver This driver contains another malicious PE file that has been encrypted. Well, this worm carried so many PE files; what a hard worker. In the next section, I will show the technique the worm uses to inject this PE file into a system process from its driver. Page 7 of 26 Websense Security Labs Drop the P2P configuration file: Figure 11. Release Configuration File Contents of this configuration file: The worm reads other bots' information from this configuration file, and then uses this information to contact its brothers residing in the botnet. Page 8 of 26 Websense Security Labs Start a Win32 service to load its driver Figure 12. Install Service Now the worm has broken into the system. Next, I will investigate the heavy weapon that this worm uses to protect itself and bypass the firewall. This weapon is built from rootkit techniques, so in the next section we will dive deep into the Windows kernel. Page 9 of 26 Websense Security Labs The heavy weapon – Driver (rootkit technique) Figure 13. The workflow of the worm's driver As we saw earlier, this worm drops two files: a driver named “glok+<random_id>.sys” and a peer-to-peer configuration file named “glok+serv.config”. In the end, the worm starts a Win32 service to load its driver. Normally, it is difficult to find these sorts of malicious behaviors, but by intercepting the API call, we locate them with ease. API Calling Figure 14. API Call Win32 Service Figure 15. Register Changes Page 10 of 26 Websense Security Labs Worm's rootkit functionality The worm uses its driver to achieve the goals below: 1. Hide File (Avoid being deleted) 2. Hide TCP Port (Bypass the firewall) 3. Hide Win32 Service (Avoid being detected) 4. Inject Code to “services.exe” (Smart because it can easily bypass the ring3 detector) 1. Hide file or directory This worm hooks the native API named “NtQueryDirectoryFile”, so the worm can hide the file or directory whose name contains the string “glok+”. Do you remember the name of its driver that I mentioned earlier? Yes, the name of the driver is “glok+<random_id>.sys”; it contains the string – “glok+”. Code slice – Hook NtQueryDirectoryFile: Figure 16. Filter in NtQueryDirectoryFile 2. Hide Win32 Service As we know, using the Win32 service to load the kernel driver will leave some footprint in the register. So the worm hooks two register-related native APIs named “NtEnumerateKey” and “NtEnumerateValueKey”; through them the worm can erase its footprint. Code slice – Hook NtEnumerateKey: Figure 17. Filter in NtEnumerateKey Code slice – Hook NtEnumerateValueKey: Figure 18. Filter in NtEnumerateValueKey 3. Hide Port This worm will send spam and connect to other bots that are in the botnet, so it must obscure network-related things from everyone's eyes. In the kernel, the worm searches the TCP device (Device\Tcp) and inline hooks its dispatch function. When people try to query the network information, the worm hides itself from the result of the query. Inline hook TCP DeviceIoContorl functions: Page 11 of 26 Websense Security Labs Set up a completion routine for each Irps Code Slice - Hide Port: 4. Inject malicious PE to“services.exe” This worm does not use the normal way to inject the malicious code to other processes, such as through “CreateRemoteThread”. Instead, it does this from the kernel through a user-mode APC. In the injected code, the worm uses some shellcode techniques to locate the base address of kernel32.dll and do API searching by itself. The detailed steps are shown in Figure 13. Page 12 of 26 Websense Security Labs Code slice: Using user-mode APC Running in “services.exe” As mentioned earlier, the injected code is responsible for initializing the bot and joining the botnet. Page 13 of 26 Websense Security Labs Locating kernel32 && Searching APIs – often used by shellcode Start main thread Page 14 of 26 Websense Security Labs The super weapon – P2P-based botnet Overview In recent years, P2P technology has been used frequently in worms and has become more and more popular. The P2P-based botnet is very hard to trace and to shut down, because the botnet has robust network connectivity, uses encryption, and controls traffic dispersion. Each bot influences only a small part of the botnet, and upgrade/recovery is accomplished easily by its botmaster.