Learning about Bflient through sample analysis

The malware gets the base address of kernel32.dll from the InInitializationOrderModuleList of the PEB_LDR_DATA structure in the PEB (Process Environment Block). It compares the length of each of the module names on the list with the length of kernel32.dll, and fetches the base address of the first match it finds. The malware uses LoadLibraryA() to get the base addresses of other modules, as it insists on walking the export table in order to obtain APIs instead of calling GetProcAddress().

The module and API information is saved into a table. Each record in the table points to a module information chain, and the index of the record is a hash byte value based on the module name. If different modules have the same index, the malware links them to the same chain. At the end of each module information chain, there is also a table for its API information. Here, the hash index is generated based on the API name. Whenever there is a request for an API, the malware looks up this table first. In the case of both the module and API information chains, if there is no record for the request, a new one is appended.

Figure 1. DLL and API table.

The malware takes advantage of the Windows message-handling mechanism for its own purposes. It creates a hidden window to handle messages dispatched elsewhere. If the message is WM_QUERYENDSESSION and the user is logging off from Windows, it notifies the C&C server. Any other messages will initially be forwarded to the malware-defined message-handling function. Any messages that the malware does not care about will be passed onto the default Windows procedure.

There are six hard-coded module blocks, each of which consists of a BLOCK_HEADER structure and encrypted data. The decrypted data includes a piece of code – if the code needs to be relocated, it also includes a relocation table. The malware XORs the checksum value of the decrypted data with the hash key, but the result is somewhat irrelevant, since the malware can also get the block from the C&C server. The result is probably used to verify the integrity of the downloaded data.

typedef struct _BLOCK_HEADER
{
   BYTE MajorID;
   BYTE MinorID;
   BYTE Key;
   BYTE Flag;
   LONG HashKey;
   LONG BlockSize;
   LONG CodeOffset;
   LONG DataOffset; 
   LONG NumberOfRelocs;
   LONG EntryOffsetToCode;
} BLOCK_HEADER, *PBLOCK_HEADER;

The malware checks the major ID first. If it is not zero modulo four, the module block is a decryption or encryption function. Otherwise, the malware checks the minor ID and appends the block to a MODULE_BLOCK structure described block chain. The block is ignored if the minor ID is zero and the major ID is not equal to an odd multiple of four.

typedef struct _MONITOR
{
   struct _MONITOR* Next;
   PVOID fMonitor;
...
} MONITOR, *PMONITOR;
typedef struct _MODULE_BLOCK
{
   struct _MODULE_BLOCK* Next; 
   PVOID fEntry;
   PVOID fFree;
   PVOID fMain;
   PVOID fDelete;
   PVOID fMessage;
   ...
PMONITOR pMonitor;
...
} MODULE_BLOCK, *PMODULE_BLOCK;

The structure defines which members rely on the concrete module block. According to the hard-coded blocks, the functionality of the members can be summarized as follows:

Figure 2. Handling module block.

Resource blocks are usually downloaded from the C&C server, with the exception of one that is hard coded. Although the content of the block is variable, it always contains a minor ID and an action ID. Table 1shows the actions based on different IDs.

The case of the action 0xA0 is a little more complicated. Table 2 shows the actions of the different commands.

typedef struct _RESOURCE_BLOCK
{
   struct _RESOURCE_BLOCK* Next;
   PVOID pResource;
   LONG Size;
   ...
   BYTE MinorID; 
...
} RESOURCE_BLOCK, *PRESOURCE_BLOCK;

Figure 3. Handling resource block.

The malware provides two different en/decryption functions. The encryption function encrypts the information before it is sent to the C&C server. The decryption function decrypts the downloaded configuration data from the server. The en/decryption functions can be updated from the C&C server, for instance to use new algorithms.

The malware copies itself to the %user profile% folder. In order to perform this duplication each time the system boots up, it adds a new registry entry. The malware also has the ability to delete the copy and corresponding registry entry.

The C&C server provides a list of browser window titles and a URL list. The malware enumerates each of the victim’s windows to determine the title of each, then compares the titles against its list of window titles. If a window title matches one on the list – for example, a title belonging to a window of the Internet Explorer browser – the malware selects a URL randomly from its URL list and opens it in a new browser window. All of the URLs in the list direct to advertising sites controlled by the attackers.

The data that comes from the C&C server includes a URL that is used by the malware to download a new file. The downloaded file varies – one example is W32/Oderoor, a notorious backdoor trojan.

In terms of hard-coded blocks, this is the only one that handles the messages transferred by the hidden window. In fact, this block only handles the WM_DEVICECHANGE message. The resource block provides an autorun.inf configuration file. By intercepting the WM_DEVICECHANGE message, the malware is able to drop both a copy of itself and an autorun.inf file onto the removable drive.