SCF Advanced Search

  • Total Members: 13113
  • Latest: CROYA86
  • Total Posts: 32052
  • Total Topics: 9704
  • Online Today: 1314
  • Online Ever: 51419
  • (01. January 2010., 10:27:49)

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

0 Members and 1 Guest are viewing this topic.


  • SCF VIP Member
  • *****
  • Posts: 774
  • KARMA: 117
  • Gender: Male
  • Pez
Digging Into the Nitol DDoS Botnet
« on: 23. April 2012., 10:04:37 »

Digging Into the Nitol DDoS Botnet

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.

Larger picture

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];


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.

Each of the flood commands implements several other commands:

Larger picture

Here we have command number 2–GenericFlood–followed by the GenericFloodData structure:

typedef struct _GenericFloodData{

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

DWORD NumberOfMinutesToRun;  // 0×84

DWORD NumberOfThreads;               // 0×88

DWORD Command;                              // 0x8C


enum GenericFloodCommands


send_Random_TCP_Data_Every_10_MS = 1,

Send_UDP_Packets_Every_20_MS = 2,

Send_ICMP_Packet_Sleep_Missing = 3,

Open_Socket_Every_500_MS = 4,

Send_UDP_Packets_Every_20_MS_Random_Source_Address_On_Server = 9,

Send_UDP_Packets_Every_20_MS_Random_Source_Address_On_Server_number_of_threads_plus_20 = 16,

Send_UDP_Packets_Every_20_MS_Random_Source_Address_On_Server_number_of_threads_plus_20_no_Passthru = 17,

Send_TCP_Packets_Random_Source_Address_On_Server_number_of_threads_plus_20  = 18,

Send_TCP_Packets_HardCoded_Source_Address_On_Server_number_of_threads_plus_20  = 19,

Same_As_1_20_More_Threads_If_Client_64_If_Server = 20,

Send_UDP_Packets_Every_20_MS_Source_Address_On_Server_number_of_threads_plus_20  = 23,

Send_TCP_Packets_Every_10_MS_Source_Address_On_Server_number_of_threads_plus_20  = 24,

Open_Socket_Send_1000_TCP_Packets = 25,

Connect_Disconnect_loop = 32,


Larger picture

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


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


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.

The following recording shows the traffic of the ICMP attack.

Larger picture

The following recording shows the traffic of the UDP attack.

Larger picture

Other Commands

StopRunning: Stops current DDoS attacks

UninstallAndDie: Unregisters the service, runs another process to delete the file, and exits the current process

DownloadFileFromUrlExecUrl: Looks like another bug, downloads a file from a URL to a local temp file, then tries to execute the URL

DownloadFileFromUrlExecFile: Downloads a file from a URL to a local file (random name in %temp% “*****.exe”) and executes the file using WinExec API call

UpdateBot: Downloads a file from a URL to “%temp%\stf******.exe.” If download succeeds, deletes the service, executes the file, and exits. (The current version is not deleted from the disk.)

ExecuteIE_NoWindow: Executes Internet Explorer with command-line arguments supplied by the server, doesn’t show the IE window

ExecuteIE_ShowWindow: Executes Internet Explorer with command-line arguments supplied by the server, shows the IE window

Command Servers

We identified the following command server domain names: Targets some diet products hosted on Targets some diet products hosted in Hong Kong Targets a site in China This American IP address is registered to Hong Kong American IP for German IP for domain registered to a Russian individual

(All the nonspecified IP addresses are in China.)

As we can see, most of the hardcoded domain names are resolved by Chinese dynamic DNS services.

I would like to thank my colleagues Zheng Bu and Benjamin Cruz for their input.

Orginal article: Thursday, April 19, 2012 at 1:30pm by Itai Liba

Their is two easy way to configure a system!
Every thing open and every thing closed.
Every thing else is more or less complex.

Start Turfing !,8405.msg21475.html#msg21475

Samker's Computer Forum -

Digging Into the Nitol DDoS Botnet
« on: 23. April 2012., 10:04:37 »
Sponsored Links:


  • SCF Administrator
  • *****
  • Posts: 7444
  • KARMA: 312
  • Gender: Male
  • Whatever doesn't kill us makes us stronger.
    • - Samker's Computer Forum
Pez, thanks for detailed explanation. :thumbsup:


With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Name: Email:
Type the letters shown in the picture
Listen to the letters / Request another image
Type the letters shown in the picture:
Second Anti-Bot trap, type or simply copy-paste below (only the red letters)

Enter your email address to receive daily email with ' - Samker's Computer Forum' newest content:

Terms of Use | Privacy Policy | Advertising