0
1
The Avzhan DDoS bot has been known since 2010, but recently we saw it in wild again, being dropped by a Chinese drive-by attack. In this post, we’ll take a deep dive into its functionality and compare the sample we captured with the one described in the past.
Analyzed sample
- 05749f08ebd9762511c6da92481e87d8 – The main sample, dropped by the exploit kit
- 5e2d07cbd3ef3d5f32027b4501fb3fe6 – Unpacked (Server.dll)
- 05dfe8215c1b33f031bb168f8a90d08e – The version from 2010 (reference sample)
Behavioral analysis
Installation
After being deployed, the malware copies itself under a random name into a system folder, and then deletes the original sample:
Its way to achieve persistence is by registering itself as a Windows Service. Of course, this operation requires administrator rights, which means for successful installation, the sample must run elevated. There are no UAC bypass capabilities inside the bot, so it can only rely on some external droppers, using exploits or social engineering.
Example of added registry keys, related to registering a new service:
We find it also on the list of the installed services:
The interesting thing was also that the dropped main sample was infected with another malware, Virut – a very old family (and crashing on 64 bit systems). Once it was deployed, it started to infect other executables on the disk. More about Virut we will cover in another post.
Network traffic
We can see that the bot connects to its CnC:
Looking at the network traffic, we see the beacon that is sent. It is in a binary format and contains information collected about the victim system:
The beacon is very similar to the one described in 2010 by Arbor Networks here. The server responds with a single NULL byte.
During the experiments, we didn’t capture traffic related to the typical DDoS activities performed by this bot. However, we can see such capabilities clearly in the code.
Inside the sample
Stage 1: the loader
The sample is distributed in a packed form. The main sample’s original name is Cache.dat, and it exports one function: Ip.
Looking inside the Ip, we can easily read that it creates a variable, fills it with strings, and then returns it:
Those are the same parameters that we observed during the behavioral analysis. For example, we can see that the service name is “Nationalscm” and the referenced server, probably CnC is: wm.shiquanxian.cn:8080 (that resolves to: 103.85.226.65:8080). So, this is likely the function responsible for filling those parameters and passing them further.
The main function of this executable is obfuscated, and the flow of the code is hard to follow—it consists of small chunks of code connected by jumps, in between of which junk instructions are added:
However, just below the function Ip, we see another one that looks readable:
Looking at its features, we see that it is a good candidate for a function that actually unpacks and installs the payload in the following process:
- It takes some hardcoded buffer and processes it—that looks like de-obfuscating the payload.
- It searches a function “StartupService” in the export table of the unpacked payload—it gives us hint that the unpacked content is a PE file.
- Finally, it calls the found function within the payload.
We can confirm this by observing the execution under the debugger. After the decoding function was called, we see that indeed the buffer becomes a new PE file:
At this moment, we can dump the buffer, trim it, and analyze it separately. It turns out that this is the core of the bot, performing all of the malicious operations. The PE file is in the raw format, so no unmapping is needed. Further, the loader will allocate another area of memory and map there the payload into the Virtual Format so that it can be executed.
To read the original article:
