Just recently, Microsoft shut down the command-and-control infrastructure (C&C) of Win32/Nitol malware – one of the most active DDoS-performing malware families today. The take down, dubbed as “Operation b70“, was a great success. To amplify its disruption, DDoS:Win32/Nitol was included in this month’s Malicious Software Removal Tool (MSRT) release.
Microsoft’s study [PDF] behind Operation b70 found that PC consumers might be at risk of getting infected by malware even with brand-new computers, if the computers come pre-installed with counterfeit versions of Windows software. This is what happened to some consumers in China who purchased their computers from an untrusted supply chain. A staggering 4 out of 20 machines were found to be infected with malware, and one of those infectors was Nitol.
In this blog post, we’ll tackle the technical aspect of Nitol and why malware found in counterfeit software seems to be counterfeit itself. In the follow-up blog post, to be released next Tuesday, we’ll talk about the numbers we’ve seen around Nitol, both before and after the takedown.
Nitol source code
An interesting discovery from a researcher’s perspective is that a relevant portion of Nitol’s code was found to be copied or heavily borrowed from at least two malware sources freely available in Chinese websites. As proof, Figure 1 shows a code snippet from a particular Nitol function that performs a denial of service attack by sending very distinct and recognizable strings. Figure 2 shows the original source code likely copied by the Nitol authors. With the help of certain tools, it’s very easy to see that Nitol is the copycat, not the other way around. Other Nitol samples were also found to be copied from another C++ source code, though not discussed further in this blog.
Figure 1 – Decompiled Win32/Nitol variant in IDA
Figure 2 – Snapshot of actual source code available from a Chinese website
Our analysis also revealed that the Nitol family could be part of a larger DDoS malware class. The most active variants, Nitol.A and Nitol.B, could just be rehashes from old variants, which closely resemble the DDoS threats analyzed sometime ago by Damballa and Arbor Networks and called IMMDOS and Avzhan respectively. There is currently no evidence that they were all created by the same authors.
Win32/Nitol variants may behave slightly differently from each other, but their DDoS’ing functionalities are very much alike. Most of the variants are composed of two components: the loader executable and the DLL component. The loader executable drops the DLL component (usually from its resource section) and installs it by setting it up as an NT service or a legacy driver. Some variants may run the DLL immediately by calling the DLL’s main function from the loader (EXE component), while others may wait until the next reboot.
It’s interesting to note that most of the recent Nitol samples use the name “lpk.dll”, which is the same file name as a legitimate Windows file that’s always loaded when support for East Asian languages is installed in your computer. The purpose is not clear, but one possibility is to utilize an old well-documented Windows vulnerability called “DLL preloading” by dropping the “lpk.dll” file to every folder that contains an EXE, RAR or ZIP file on all local and removable drives. The DLL is modified such that, when loaded, the LpkInitialize() export function is executed which, in turn, runs its appended malicious code.
When the DLL component runs, it creates a thread, acts as a server, and starts talking with the remote command and control (C&C) server. It knows which C&C server to connect to, as the server address is indicated in the binary code. More than 50% of the Win32/Nitol families were observed to connect to the subdomain 3322.org as their primary C&C server. This server was located in China. This server was taken offline as part of the Microsoft takedown.
Nitol could collect system information such as computer name, version of the operating system, processor speed, installed RAM, and the infected machine’s geographical location. It could then send the information to the C&C server after encrypting the data with a simple algorithm.
The bot master may issue a command to launch a DoS attack to target domains or websites using different DDoS options such as SYN, UDP, TCP, HTTP, and ICMP flooding. The bot master uses a simple token to synchronize the botnets. The C&C may command the botnet to sleep for a specified time and become dormant. DDoS commands are not permitted when the bot is in dormant mode.
The bot master may also carry out other malicious behaviors, such as downloading and executing additional malware (or Nitol updates) into the infected machines. Nitol may also open a URL, which could be malicious, using Internet Explorer. The bots may also receive commands to uninstall themselves from the computer should the bot master wishes to. For more information, please read the Win32/Nitol family description.
Leave a reply