Ramnit bot

Two copies of the installer’s executable file are embedded in the Windows file system by Rmnsoft.dll. One copy is placed in the directory pointed to by registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Startup, making sure Windows will launch it automatically at start-up.

To decide where the second copy should be placed, Rmnsoft.dll makes an attempt on a series of directories in the following order:

Once Rmnsoft.dll has found a directory (from those listed above) in which a temporary file can be created successfully, it will create a subfolder with a random name and place the second copy of the Ramnit installer in it. A typical location of this copy is %UserProfile%\Local Settings\Application Data\slyaqmdg\brqmbmmw.exe. Two registry keys, HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit and HKCU\Software\Microsoft\Windows\CurrentVersion\Run\BrqMbmmw, are set to point to the location of the second copy.

Rmnsoft.dll gets a name list of anti-virus software from the C&C server and attempts to kill the processes of any anti-virus software running on the victim’s computer. Moreover, it will send the list to the rootkit driver dropped by the installer, which will provide a second-time strike on security software in kernel mode. Figure 3 shows part of the list.

Figure 3. Anti-virus software list (partial).

Rmnsoft.dll harvests the locations which store the cookies of various web browsers. These locations are used to collect and delete local cookies at the command of the C&C server. The web browsers targeted are as follows:

Rmnsoft.dll will upload the collected cookies to the C&C server. However, the work of collecting local cookies is carried out by another module downloaded from the C&C server.

Rmnsoft.dll also creates a thread which has the ability to capture a snapshot of the user’s screen and encode the snapshot in JPEG format. Each snapshot is stored along with a time stamp. Just like the stolen cookies, these screenshots will be sent back to the C&C server for future use.

A TCP connection on port 443 (HTTPS) is utilized for communication between Rmnsoft.dll and the C&C server. RC4 encryption with crypt key ‘black’ is used for network communication. When stolen sensitive information is uploaded to the C&C server, or modules are downloaded from the C&C server, the transmitted data is encrypted.

The domain name of the C&C server is not hard-coded in the module. A DGA (Domain Generating Algorithm) is deployed here to construct domain names which have no literal meaning. Some examples of generated domain names are as follows:

Two MD5s are used to register an infected computer to the C&C server. To get the first MD5, information about the infected computer is obtained and stored in the following data structure:

typedef struct BotSysInfo {
     DWORD       VolumeSerialNumber;
     DWORD       BuildNumber;
     DWORD       MajorVersion;
     DWORD       MinorVersion;
     WORD ProcessorArchitecture;
     DWORD       ActiveProcessorMask;
     DWORD       NumberOfProcessors;
     DWORD       ProcessorType;
     WORD ProcessorLevel;
     WORD ProcessorRevision;
     BYTE ComputerName[LenComputerName];
}

The MD5 of the data in this structure is used as the first MD5. Then a string is made by concatenating ‘45Bn99gT’ and the first MD5. The MD5 of the resultant string is the second MD5. As shown in Figure 4, these two MD5s are sent to port 443 of the C&C server to register the infected computer.

Figure 4. Bot registration routine.

Figure 5 shows two RC4 encrypted MD5s sent to the C&C server.

Figure 5. Bot registration information.

The structure of the data highlighted in Figure 5 is as follows:

typedef struct BotRegInfo {
     BYTE Operation;  //value is 0xE2
     BYTE  Zero;
     DWORD Len1;       //value is 0x20
     BYTE  FirstEncryptedMD5[Len1];
     BYTE  Zero;
     DWORD Len2;       //value is 0x20
     BYTE  SecondEncryptedMD5[Len2];
}

As for the Operation value, it should be noted that different communication data types are represented by different values of Operation, as follows:

Data transmitted between Rmnsoft.dll and the C&C server is organized in a structure which begins with 0xFF00:

typedef struct CommunicationData {
   WORD    Flag;       //value is 0xFF00
   DWORD   SizeOfFollowingData;
   BYTE    Operation;
   DataEntry     Array[];
}

Rmnsoft.dll calls the send API twice to send out data in a CommunicationData structure, the first time for the beginning six bytes and the second time for the rest of the data.

Data in a DataEntry structure begins with 0x00, 0x01 or 0x02. When beginning with 0x00, its structure is as follows:

typedef struct DataEntry {
   BYTE Flag;          //value is 0x00
   DWORD   SizeOfRC4EncryptedData;
   BYTE    RC4EncryptedData[SizeOfRC4EncryptedData];
}

When beginning with 0x01, its structure is as follows:

typedef struct DataEntry {
   BYTE Flag;          //value is 0x01
   DWORD Data;
}

When beginning with 0x02, its structure is as follows:

typedef struct DataEntry {
   BYTE Flag;          //value is 0x02
   DWORD   Data1;
   DWORD   Data2;
}

Rmnsoft.dll periodically connects to the C&C server, uploading local information and getting commands, as shown in Figure 6.

Figure 6. Upload local information and get commands.

The MD5 used for bot registration and a crypt key are uploaded to the C&C server. This crypt key will be used by both the C&C server and the modules downloaded from the server.

The commands received from the C&C server are as follows:

Working in conjunction with Modules.dll, Rmnsoft.dll downloads several other modules from the C&C server.

Rmnsoft.dll and Modules.dll use a named pipe, \\.\pipe\wtglasop, to communicate with each other. Modules.dll acts as the server of the pipe while Rmnsoft.dll acts as the client. To contact through the named pipe, Modules.dll creates an instance of it by calling CreateNamedPipe and waits for a client process to connect to this instance by calling ConnectNamedPipe. On the other end of the pipe, Rmnsoft.dll attempts to connect to any instance of the pipe that is in the listening state by calling CreateFile. If the pipe is busy, Rmnsoft.dll waits until an instance of the pipe is available for connection by calling WaitNamedPipe. This interaction is shown in Figure 7 and Figure 8.

Figure 7. Modules.dll acts as the server of the pipe.

Figure 8. Rmnsoft.dll acts as the client of the pipe.

Figure 9 shows the relationship between all participants in downloading modules from the C&C server.

Figure 9. Process of downloading modules.

The whole downloading procedure can be divided into several steps:

Besides the entry-point function, each module has four other exported functions:

When a module is loaded, its entry-point function is called by Modules.dll using the PROCESS_ATTACH parameter. Then the ModuleCode function is called, which returns a double word which has only one bit set. The result of an OR operation on the returned values of the ModuleCode function of all modules is the important double word which is sent to the C&C server to tell it which modules exist on the local computer. The Virtual Address of the CommandRoutine function is obtained and will be used in future. After that, the StartRoutine function is called to perform the main work of the module. Figure 13 shows this procedure.

Figure 13. Loading a module.

It is unlikely that a module can keep living in the system. Once a module is considered out of date, the StopRoutine function is called by Modules.dll to unload it.

Throughout the life of a module, the CommandRoutine function is periodically called by Modules.dll, and given a handle to an instance of the named pipe between Rmnsoft.dll and Modules.dll. By doing this, the module can communicate with the C&C server while Rmnsoft.dll serves as an interpreter again. A crypt key (‘840480_n_uk’) is also passed to the CommandRoutine function as a parameter. This crypt key will be used by both the module and the C&C server for data encryption.

Figure 14. Invoking CommandRoutine.

In order to manage all the modules downloaded from the C&C server, Modules.dll maintains a log file on the local system. In the log file, it stores all modules in a well designed storage structure described as follows:

typedef struct ModuleBlockInLog { 
 DWORD     HashRawModule;
 DWORD     Flag;
 DWORD     SizeEncryptedModuleBlock; 
 DWORD     HashEncryptedModuleBlock;
 BYTE EncryptedModuleBlock[SizeEncryptedModuleBlock];
}

Figure 15 shows the data in the ModuleBlockInLog of the FTP grabber module.

Figure 15. ModuleBlockInLog of the FTP grabber module.

The data of EncryptedModuleBlock is RC4 encrypted by Modules.dll. The data structure of the decrypted EncryptedModuleBlock can be described as follows:

typedef struct ModuleBlock { 
     DWORD MagicNumber;
     BYTE  ModuleInfo[0x114];
     DWORD TimeStamp;
     DWORD HashRawModule;
     BYTE  ModulePE[PESize];
}

Figure 16 shows the data in the ModuleBlock of the FTP grabber module.

Figure 16. ModuleBlock of the FTP grabber module.

Now, let’s see the data structure describing a running module:

typedef struct ModuleInfoInMem {
   DWORD   HashRawModule;
   DWORD   RetValOfModuleCode;
   DWORD   ModuleBase;
   DWORD   ModuleSize;
   DWORD   ModuleEntry;
   DWORD   PtrCommandRoutine;
}

The bug report function is implemented by a self-designed exception handling mechanism in Modules.dll. When an incurable exception (possible bug) is raised by any module, first, Modules.dll will seek out the trouble-making module by checking the address at which the exception occurred and the address scope of each module in process. Then the information about the exception will be recorded in a local file by Modules.dll and sent back to the C&C server by Rmnsoft.dll. Modules.dll will also change the flag of the buggy module from 1 (useful) to 2 (abandoned) so that it will no longer be loaded. Finally, Modules.dll will call the ExitProcess API to terminate the buggy module’s process.