Author
Topic: Digging Into the Nitol DDoS Botnet (Read 1942 times)

Nitol is a distributed denial of service (DDoS) botnet that seems to be small and not widely known. It mostly operates in China. McAfee Labs recently analyzed a few samples; we offer here the communications protocol and the Trojan’s capabilities.

Most of the samples we encountered were not packed and were very easy to reverse engineer. The Trojan was written in Visual C++ either in a hurry or by an untrained programmer. We found a lot of bugs in the code.

Nitol copies itself to a random filename ******.exe (where every * is a randomized alphabet character) in the Program Files directory. The new file is registered as a service, “MSUpdqteeee,” with the display name “Microsoft Windows Uqdatehwh Service.”

Bot Activities

After installation, the malware connects to its command server (we found between one and three hardcoded addresses per sample) using a TCP socket and sends a digest of the victim’s computer information.

Both incoming and outgoing packets are 1082 bytes long (including TCP/IP headers, 1028 bytes of raw data) without regard to the actual size of the data.

The transmission to the server can be described by the following structure:

typedef struct _ComputerInfo{

DWORD Command; // Always “1″ Computer Info.

char LocaleLanguage[0x40];

char ComputerName[0x80];

char WindowsVersion[0x40];

char PhysicalMemorySize[0x20];

char CPU_Speed[0x20];

char Ndis_Version[0x20];

}ComputerInfo;

It appears this information is used mainly to get an estimation of the botnet’s power and diversity. The data can be used to decide what type of DDoS tasks to give this specific bot. However, this is not enough information for the server to decide whether the bot is running on a virtual machine or is being debugged.

After receiving the information, the command server usually returns a command and parameters.

Possible commands:

enum commands{

GenericFlood = 2,

HTTPFlood = 3,

RawDataFlood = 4,

StopRunning = 5,

UninstallAndDie = 6,

DownloadFileFromUrlExecUrl = 16, // ?!?!?!?

DownloadFileFromUrlExecFile = 17,

UpdateBot = 18,

ExecuteIE_NoWindow = 19,

ExecuteIE_ShowWindow = 20

}

DDos Attacks

In the preceding group of commands, the DDoS functionality is represented by GenericFlood, HTTPFlood, and RawDataFlood.

Next we have command number 3–HTTPFlood–followed by the HTTPFloodData structure:

typedef struct _HTTPFloodData{

char Address[0x80]; // 0×000

char Path[0x80]; // 0×080 // BUG!!! The second DWORD is also NumberOfMinutesToRun

unsigned short Port; // 0×100

unsigned short dummy; // 0×102

DWORD dummy1; // 0×104

DWORD NumberOfThreads; // 0×108

DWORD IsDummyGetRequest; // 0x10c

DWORD dummy2; // 0×110

DWORD Command; // 0×114

}HTTPFloodData;

enum HTTPFloodCommands

{

Get_Image_Every_50_MS = 5,

Get_HTML_Every_50_MS_OR_GET_WITH_IE = 6, //BUG

Get_HTML_Every_10_MS = 7,

Get_Image_Every_5_MS = 8

}

None of the samples we ran returned the RawDataFloodData, so we don’t have a recording.

Command number 4–RawDataFlood–should be followed by the RawDataFloodData structure:

typedef struct _RawDataFloodData{

char Address[0x80]; // 0×000

char Buf[0x208]; // 0×080 // BUG!!! The second DWORD is also NumberOfMinutesToRun

DWORD NumberOfThreads; // 0×288

DWORD Command; // 0x28C

}RawDataFloodData;

RawDataFlood takes two possible commands: SendUDPData and SendTCPData. To use SendUDPData you need to set the command parameter to 21, else SentTCPData will be used. Both commands interpret the Buf parameter as a null-terminated string.

We encountered two important bugs:

•It looks like the function to stop the attack after a certain amount of minutes was designed to work with the GenericFlood command and only later was also used for the HTTP and RawData floods, so it uses unrelated data as the amount of time to wait in seconds (always using the DWORD at offset 0×84 from the start of the parameters structure).•The function in charge of getting the path to the Internet Explorer executable concatenates the string coming back from the GetWindowsDirectory function (usually c:\Windows) to “\Program Files\Internet Explorer\iexplore.exe,” which is normally not the path to the IE executable. The problem resides in the HTTPFlood’s command 6, which performs an infinite loop of running IE from that path.