Recently, a new Worm/trojan has been very "popular" in the We Net world. This worm uses email and various phishing the 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 are components are prepared for spamming or mass-mailing purposes.
During my found, I-this is worm used various rootkit techniques to protect itself (such as hiding files, regist ERS, 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 which is the worm dropped, we learned that it employs a user-mode APC to inject malicious code (embedded) into t He process named "Services.exe".
In this paper, I'll 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.
Overview
When this worm is running, it unpacks itself-I, and then drops a malicious PE file that's embedded in the executable File. Then, it decrypts the malicious PE file into heap memory. When this steps are complete, the worm jumps to the heap memory (containing the malicious PE file) and executes the decry Pted malicious code. This is the code of the 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'll explain how-worm accomplishes all of this, step by step.
Analysis Sequence
The worm uses a custom packer and encryption to protect their binary file, so the the "the" the "It takes is" to unpack and decry PT the embedded PE file.
In this section, I'll demonstrate how to use ollydbg and IDA Pro to analyze the worm.
Dynamic Analysis
The 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 are 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 thing it does was to unpack the data section, which contains T He code that would be executed further.
Figure 4 shows the packed data section.
Figure 4. Packed Code
From Figure 4 We can-I-does not have any actual functions and are used only to obscure its purpose.
The figure below shows the same data section after it has been:
Figure 5. Unpacked Code
So, 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'll use the IDA Pro tool to continue exploring the worm.
Static Analysis
I am very grateful for IDA Pro, which are an amazing tool. With it help, we can search every corner of the malware.
Stage 1–decrypt & Decompress in heap memory
During the analysis, I found a tea constant–0x9e3779b<?xml:namespace prefix = st1/>9 in the unpacked file, and AF ter A short analysis I is 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 this, 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.
Figure 8. Fix IAT & Relocation
Assuming everything is okay, the worm jumps to the heap of memory to execute the malicious PE file. From this 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 the They are the same. At I, 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 are to drop a driver and a peer-to-peer configuration file, an D to start a Win32 service to the load its driver.
Drop the driver:
Figure. Release Driver
This driver contains another malicious PE file that has been. So, this worm carried so many PE files; What a hard worker. In the next section, I'll show the technique the worm uses to inject this PE file into a system process from its driver.
Drop The Peer-to-peer configuration file:
Figure. Release Configuration File
Contents of this configuration file:
The worm reads other bots ' information from-configuration file, and then uses this information to contacts its brother s residing in the botnet.
Start a Win32 service to the load its driver
Figure. Install Service
Now the worm has broken into the system. Next, I'll investigate the heavy weapon that this worm uses to protect itself and bypass the firewall. This weapon are built from rootkit techniques and so in the next section we'll dive into the Windows deep.
The heavy weapon–driver (rootkit technique)
Figure. 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 Configurati On file named "Glok+serv.config". The worm starts a WIN32 service to load its driver.
Normally, it is difficult to find this sorts of malicious behaviors, but by intercepting the API call, we locate them wit H ease.
API Calling
Figure. API Call
Win32 Service
Figure. Register Changes
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)
1. Hide file or directory
This worm hooks the native API named "Ntquerydirectoryfile" and so the worm can hide the file or directory whose name Contai NS the string "Glok +". Do and remember the name of its driver I mentioned earlier? Yes, the name of the driver is "Glok +<random_id >.sys"; It contains the string– "Glok +".
Code Slice–hook Ntquerydirectoryfile :
Figure. Filter in Ntquerydirectoryfile
2. Hide Win32 Service
As we know, using the WIN32 service to load the kernel driver'll leave some 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. Filter in Ntenumeratekey
Code slice–hook Ntenumeratevaluekey:
Figure. Filter in Ntenumeratevaluekey
3. Hide TCP Por
This worm would send spam and connect to other bots that are in the botnet, so it must obscure network-related things 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:
Set up a completion routine for each IRPs
Code Slice-hideport:
4. Inject malicious PE to "Services.exe"
This worm does is not with 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 search ing by itself.
The detailed steps are shown in Figure 13.
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.
locating kernel32 && searching Apis–often used by Shellcode
Start Main thread
the Super Weapon–p2p-based botnet
Overview
In recent years, Peer-to-peer technology has been used frequently, worms and has more and more become. The p2p-based botnet is very hard to trace and to shut down, because the botnet has robust, network connectivity, uses ENCR Yption, and controls traffic dispersion. Each bot influences only a small part of the botnet, and upgrade/recovery are accomplished easily by its botmaster.
The botnet this worm constructed are a decentralized architecture, not like the traditional peer-to-peer system. This is kind of botnet does not need a, and control location; It can allow the attacker to Upgrade/control infected hosts without the botmaster.
Implement
This worm implements a distributed hash table based on the Kademlia algorithm and assigns a random 128bit IDs to each bot. The format of the information is similar to this:
Steps:
1. Using the system time as a random seed.
2. Depending on the timing seed to generate the 128bit Botid
3. Randomly picking up the ip/udp Port of a static array that is carried by itself
4. Keeping a part of the bot information in the configuration file.
You can find these botid from the Peer-to-peer configuration file named "Glok+serv.config" which is dropped by this worm. The contents of this file were described earlier.
An example of how to translate the Botid this is saved in Glok+serv.config
Analysis of Botnet communication
Protocol Analysis
For analyzing this worm's peer-to-peer and spamming functionality, I captured the packets from a infected computer. The statistics of the captured packets look like this:
Protocol Hierarchy Statistics
From the statistics, we have the main protocol this worm uses is UDP protocol; The worm also uses SMTP protocol to send spam.
Protocol Port Type
Botnet Traffic Map
Spamming
Depending on the built-in SMTP client, the worm can send spam through many free SMTP servers.
TCP Connection with SMTP Server
When the "worm is connected" to "other bots", it can get the latest instructions/upgrades, then download and run any files. During the analysis, I found that the worm could exchange the list of SMTP servers with other bots. The contents of spam and adware are also exchanged from their brothers.
The figure below shows the worm trying to connect to Google ' s SMTP server:
It looks as if Google has improved the security of its SMTP server; The worm failed to connect to it.
This is another the SMTP server this worm are trying to connect with:
Send spam–through Google ' s SMTP Server
Send Spam–through the "videotron.ca" SMTP Server
Some examples of spam sent by this worm:
Another One:
Last one :
interacting with the other bots
I kept running this worm in a test environment and collected the packets it sent. By analyzing the "captured packets, I found that" worm interacted with than 5796 minutes! This evidence proves so the worm has already set up a large botnet!
To protect its botnet, "worm does not carry" entire list of bots, so, it can avoid exposing the entire botnet fr Om a single bot. It uses an XOR encryption algorithm to encrypt traffic, and randomly assigns the UDP port for each bot, to improve the TRA Ffic dispersion. All of this methods highly enhance the security of the botnet.
udp-based Bots Conversation
The conversation list is huge; The figure above shows only part of it. Each remote host in this list is infected. The total number of bots I observed is 5746!
UDP Port Distribution
Bot IP Distribution
encryption of network traffic between bots
This worm uses a special XOR algorithm to encrypt/decrypt the network traffic. Using This, the worm can avoid researchers who use network analyzers to study it.
Code slice-encrypt/decrypt UDP Packet
C Code -encrypt/decrypt algorithm
This encryption algorithm are very simple, but good enough for bypassing IDS or IPS.
Botnet Message
So, to work against this botnet, I wrote a tool to observe the traffic and analyze the messages the between.
example:searching Other Bots
example:reply Message
Example:exchange bot-list
The huge botnet
Conclusion
And that ' s all. From the analyzing this worm, we notice the current malware looks the more and the like business software. Malicious footprints are less obvious today than those of malware ancestors. The traditional signature-based scan technology can barely detect today's bad stuff. So, a challenge for all of us.
The purpose of most current malware is economic. The malicious author can derive financial benefit from the spreading of the malware.
From the technology viewpoint, we find this some malware combines more than one malicious technique, and thus it has becom e more powerful. Is this a new stage in the evolution of malware?
Future Work
As we saw, Peer-to-peer botnets are more powerful and more efficient than. Traditional malware. I The follow-on work would include a way of tracing peer-to-peer botnets and simulating their results, to better stud Y their resiliency.
