This is the first malware to specifically target cloud based technologies and will likely set a trend. As more corporations and governments move applications and services into the cloud, it will become an increasingly important target for malware developers. We can expect sophisticated malware that attacks clients and embeds itself into cloud-based apps, potentially without the user being able to determine that the cloud-based service is compromised. This trojan presents some interesting features, such as:

Hash Check Evasion.

Packet Interception via NDIS Filter.

Cloud-Servers Access Lock via SPI network filter in order to Bypass antivirus Detection.

Some of the targeted Antivirus vendors are Kingsoft, Qihoo and Rising. According to Microsoft Malware Protection Center, Bohu is the first wave of trojans that target Cloud based antiviruses. A good summary of Bohu’s global appeal can be found here: http://blogs.technet.com/b/mmpc/archive/2011/01/19/bohu-takes-aim-at-the-cloud.aspx

The Scope

Trojan.Bohu acts essentially as a back door that monitors the victim’s web traffic through various search engines. Bohu also reaches a malicious sServer and downloads additional components and cConfigurations.

Generic Anatomy of Trojan.Bohu Executables

The infection vector is an .exe file executed by the victim via classical Social Engineering Attack.Every reverse engineering based analysis starts with the inspection of generic characteristics of the binary that we are dealing with. In our case, as should be obvious, we have to check the PE Anatomy of our sample. For this kind of task, I use CFF Explorer. File Information clearly indicates the Nullsoft PiMP stub. This mean that the application is compressed (Packaged) with NSIS (Nullsoft Scriptable Install System) technology, a professional open source system to create Windows Installers. From basic information, let’s now view more specific information about its PE Geometry. Here is the Section Headers entry:

Entry Point belongs to .text section and .ndata pertains to Nullsoft Installer. Aadditionally, you can see also the presence of a Resources Section, so now we have to check the content of the Resource Directory.

As you can see, the application has embedded an image that makes it appear to be a legitimate application. This is the first basic technique of social engineering used to deceive common users. → LANG ID Locale / Language ID provides additional information that could help us to establish the origins of a certain executable. For each Country there is a univocal ID to identify it. Here’s a list: http://msdn.microsoft.com/en-us/goglobal/bb964664 But it’s important to specify that this method of Threat Origin Identification is not 100% secure, since it depends on the PC Language used by the user (attacker). Specifically, in this case we will discover that Lang ID 1033 belongs only to the main infector. Inside the dropped executable ,we will observe another ID.

NSIS Files Extraction and Further File Analysis

As stated previously, the sample is delivered as Windows Installer, packaged and compressed with NSIS Technology. Now we need to study the structure of this package and carve out all its files. It’s pretty easy to unpack an NSIS Application. All that is needed is an archive manager like 7Zip. Let’s examine the content by opening the executable with 7Zip application:

As you can see, we have 4 Directory Entries:

$EXEDIR

$PLUGINSDIR

$SHELL[17]

$TEMP

We can now examine the content of each directory: EXEDIR contains:

There are two important clues: first, the presence of another executable called uuse-5905.exe. The second is a timestamp that give us a clear indication of the period in which this package was most recently modified. NSIS also has a wide range of plugins to accomplish various installation tasks. PLUGINSDIR as the name suggests, is the Container Directory of these DLLs. In our case, we have nsExec.dll Plugins can easily be investigated by consulting the following website: http://nsis.sourceforge.net/Category:Plugins PLUGINSDIR contains System.dll which is the core component of NSIS. SHELL[17] contains another directory named ‘baidu’ and inside this:

We have more executable files: msfsg.exe and dsop7.xml (which is an encrypted file). Finally there is TEMP directory which contains some plugins:

Math.dll

nsRandom.dll

AccessControl.dll

Internet.dll

First Layer Components Overview

As shown in the previous paragraph, the main dropper contains also two executables:

uuse-5905.exe

msfsg.exe

We clearly need to inspect these executables as well.

uuse-5905.exe Analysis

Due to the fact that this executable is embedded inside main dropper, it maintains the original Timestamps. Let’s enumerate them: From Resources Directory, we can again see  that the application has some element of a leg application:

As you have probably already noticed, this executable is again packed with NSIS. It would be trivial now to carve additional information from it.

Let’s extract and inspect its content.

$PLUGINSDIR

UUPlayer.exe

loading.gif

main.ini

As usual, PLUGINSDIR contain a dll and some installation files not relevant to our analysis. Additionally, there is another executable called UUPlayer.exe, plus a main.ini file containing the following string. [SETUP] url=kvsq=10wx/84y0mfw1jpgfw0kvl It’s now time to observe generic characteristics of this newly-carved executable.

UUPlayer.exe Component Overview

No longer having to deal with an NSIS executable, we can rediscover some elements previously seen in the main dropper Finally, let’s take a look at Resources:

We have the same picture of the base infector, but this time Language ID changes in 2052. Chinese – People’s Republic of China → 2052 From Lang ID list consulting, we come to another confirmation of Chinese Origins of this Trojan. The essential scope of this inserted executable is to deceive the victim, who will see a legitimate media player application during this malware infection.

Msfsg.exe Overview

We now proceed to the final executable to inspect, contained in SHELL[17]baidu This executable is not NSIS packed and again reveals its Chinese Origins (LangID 2052 ). As you recall, we also have an encrypted file in the same directory, dsop7.xml. This is a compressed resource that will be unpacked by the msfsg executable.

Global Overview of the Installer

When we deal with Installer based malware, we need to follow two essential points in order to profile the global behaviour of this malicious application:

Identify All Components Dropped by the Installer.

Identify Sequences of Operations at Install-Time.

We have already accomplished the first task by enumerating all the elements. Now, we need to establish and schematize their execution flow. Installer Execution Sequences can be profiled in two ways:

Debugging Approach.

Api Monitoring.

The first approach involves keeping track of all the processes created at installation time: revealing, for example, all the breakpoint times that CreateProcess() function is called. But this approach is too slow. There is a faster approach that will allow us to more easily track additional operations performed by the installer, like Created Files, Written Ones, Registry and Networking Operations. (We can reach the same point with the debug approach but this implies placing more breakpoints and therefore, takes more time.) We will follow the Api Monitoring by using the iDefense SysAnalyzer Tool specifically designed to monitor the most common APIs using malware.

SysAnalyzer Log Analysis

After executing our sample in a Controlled Environment (Virtual Machine), we can save a log of all API activities. Now we are going to profile the Malware Installation Process via Log Analysis, which will also provide valuable hints on to carve additional information. It’s pretty easy to catch the file creation order, giving us additional valuable clues. Malicious files are placed in the %Programsbaidupath.From the correlation of known filenames and the path uncovered, we can produce evidence of infection. Let’s prosecute log analysis: The first process created belongs to uuse-5905.exe, containing the deceptive media player application. Netsh is a command-line utility that allows you to display or modify the network configuration of a computer that is currently running. -c: Changes to the specified netsh context. In our case Netsh is used to dump our current IP settings into a file called ipconfig.txt This is a very important hint, enabling us to understand two things:

The nature of dsop7.xml, a compressed file.

How to uncompress it, by grabbing command-line parameters.

The uncompressed file is an executable called setup109807.exe We can now unpack this file and monitor what setup109807.exe produces with the same API Spy approach.

Setup109807.exe API Spy

This executable drops several new files on the system:

siglow.dll

dsetup.exe

siglow.sys

mpflt.inf

mpflt_m.inf

newnetgar.dll

spass.dll

SysDat.bin

Please note that we have also a Kernel Mode Component, siglow.sys. Additionally, NSIS produces an uninstall application called uninst13.exe. The Hash Evasion System We can isolate the following operations performed on the newly dropped files: As is clear, msfsg.exe is a core component used for a number of support operations. This time, it uses the MD5 functionality in the following way: msfsg.exe MD5 Source → File Destination → File This is the first Defensive feature of Trojan.Bohu, the Hash Evasion. By Appending Garbage Data at the end of the file, this will change the MD5 hash signature of the malicious file. In so doing, all hash based checks will be deceived.

Final Installation Phase

After hash alteration let’s see what the executables are called: nethome32.dll is the previously created newnetgar.dll, renamed, copied and successively installed as Service. dsetup.exe installs the NDIS protection system, that is composed by:

siglow.dll

siglow.sys

The user deception application is executed.

Global View

In this chart, you can see entire look of Bohu Infection. The Global View is especially handy during the Analysis Process if designed with the aim to identify components that don’t need additional investigations as well as ones that need in-depth analysis. As you can see, UUPlayer.exe represents the endpoint of the first branch but doesn’t present any other particular implications. Otherwise, setup109807 produces a wide range of elements that need to be further inspected. Next, we’ll work on these executables.

Synthesis of Forensic Evidences of Infection Produced

We now have a clear view of the major modifications produced by Trojan.Bohu , on the system. This allow us to produce a certain number of elements that can lead univocally to the identification of an infected system. File Modification →

%Programsbaidu that contains the following files: dsop7.xml, msfsg.exe, dsetup.exe, mpflt.inf, mpflt_m.inf, msfsg.exe, etc. %System% that contains the following files: nethome32.dll, netplayone.dll

Registry Modification →

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWinSock2speednet_sph PathName = %System%netplayonenetplayone.dll HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetHomeIDE

Mutex Opened →

923UE-9KMutextf 98DI2kMutext ieflag39fiaf3Mutex

Network Activity → Window showing the infected victim:

User Mode Component siglow.dll siglow.dll is the first of a two system components used by the trojan to protect itself from Cloud-Based Antiviruses. Let’s disassemble this dll and inspect Exported Functions.

DllEntryPoint

DllUnregisterServer

DllRegisterServer

DllGetClassObject

DllCanUnloadNow

The most interesting function is DllRegisterServer. According to this, siglow is going to register a server DLL. Let’s take a look at the Graph of Function Calls.

There are a certain number of function chunks, → In this case, it will be much easier to analyze the component by starting with String Observation before coming back to the code via X-Refs.

As you recall, ms_siglow.inf is a file dropped by setup109807 installer. It’s interesting to note the ClassGUID value. Aquick search reveals that {4d36e972-e325-11ce-bfc1-08002be10318} represents the class of network adapter devices that the system supports. We will see in the kmode component analysis paragraphs exactly why this value is used. Using X-Ref navigation, we land to sub_404A11 (renamed in InstallInf). It copies a specified .inf file to the %windir%/Inf directory by way of SetupCopyOEMInf. Going a step up via cross refs:

GetVersionEx retrieves information about the current operating system. The corresponding Major and Minor Version can be seen here:  http://msdn.microsoft.com/en-us/library/ms724833%28v=vs.85%29.aspx This means that the Inf file will be installed only under certain conditions. Returning to string inspection, the next entry catching our attention is: SystemCurrentControlSetServicesnetsfltParameters This string is clearly derived from Registry Key Operations referring to the management of the NDIS filter (analyzed below). There is not much to say about this dll. It’s the usermode installation component for siglow.sys, whose sole purpose is to driver (service) management tasks. → Produces Forensics Evidences Finally, this curiosity: the dll is delivered with debugging informations. Here’s a path that shows where the coder is used to develop this component: E:passthrusiglownotifyobobjfrei386siglow.pdb

Kernel Mode Component siglow.sys

Between the various executables dropped by setup109807, we also have this Kernel Mode component responsible for the second feature mentioned in the introduction, Packet Interception and Deny, if the request is directed to Antivirus Servers. Its relative User Mode component is siglow.dll. Let’s start by disassembling the siglow.sy and locating DriverEntry() function:

At first glance, we can immediately see the nature of the component. This is a NDIS ( Network Driver Interface Specification )-based driver. NDIS defines the standard interface between hardware drivers for devices such as network cards and the windows network subsystem. Windows uses NDIS to communicate with these devices. Network cards communicate packets received upward to the TCP/IP Stack through NDIS, and the TCP/IP stack sends packets out to the network by communicating with network card drivers through NDIS. Additional information about NDIS architecture can be found here: http://msdn.microsoft.com/en-us/library/ms817945.aspx It’s become clear that by working with NDIS technology, we have extremely low level access to network functionalities of the OS. This means that we can accomplish a wide range of operations, including Packet Interception. The first function called is NdisAcquireSpinLock. It acquires a spin lock so that the caller gains exclusive access to the resources shared among driver functions that the spin lock protects. Immediately after, we have NdisInitializeWrapper. According to MSDN, this is an obsolete function, so we must look for the NdisMInitializeWrapper. This notifies NDIS that a new miniport driver is initializing. The most important parameter for our analysis is NdisWrapperHandle:, a pointer to the caller-supplied variable in which NDIS returns a handle representing itself.

NdisIMRegisterLayeredMiniport This defines the function: This function registers an intermediate driver’s miniport entry points. As noted, there is a sequence of mov dword, offset; these instructions belongs to NDIS_MINIPORT_CHARACTERISTICS, by inspecting its members we can obtain additional information about this component. NDIS version adopted is 5.1 successively. We have a sequence of handlers passed to the struct, with each entry representing a function. Further explanations about the handler’s meaning can be found here: http://www.osronline.com/ddkx/network/103ndisx_0sj7.htm The NdisMRegisterUnloadHandler function registers an unload handler for a driver. Driver unloading is performed via the NdisDeregisterProtocol function.

Another interesting and important struct is the NDIS_PROTOCOL_CHARACTERISTICS. It is used by NdisRegisterProtocol as follows:

NdisRegisterProtocol registers a set of functions necessary to handle a certain number of network events. In this way, the malicious driver can intercept packets, parse their contents and take required actions; in thiscase drop requests to a well-defined list of servers. If the protocol registration is successful NdisIMAssociateMiniport informs NDIS that the specified lower and upper interfaces for miniport and protocol drivers respectively belong to the same intermediate driver. The filter is now fully operational. Elsewhere, if protocol registration fails, the malicious driver can remove its own network event handlers by deregistering protocol via NdisIMDeregisterLayeredMiniport and NdisTerminateWrapper. Until now, we have examined the filter installation process. Now, we will deal with the handlers that effectively drop antivirus requests. There are two ways to reach this point:

String Inspection → looking for hardcoded URLs names

Handlers Inspection → looking for Send Packets functions

We will use the second approach. It’s much more interesting, though a little bit slower.

Packet Interception and Request Dropper

An NDIS driver that needs to parse a network packet should start by getting the Current Packet Stack.This can be achieved by using NdisIMGetCurrentPacketStack(). Aquick search through the IDA will give reveal the effective presence of that function to us in perfect back-trace style. We can quickly determine what the function is called by using Cross References. We finally land here:

sub_10970 is one of the Handling Functions used specified into Miniport Characteristics structure.

The code should be clear: the incoming Send Request passes through the malicious driver, pasring the packet content by calling PacketParser subroutine. If the packet contains unallowed sends to AV servers, the request is dropped. Otherwise, it will be transparently delivered to the underlying driver. Let’s see how the PacketParser function works:

This function works with memory containing the data to be delivered to and from our Network Interface Card. The code is fully commented; in other words, we are going to send a block of memory containing the request to the data parser.

The function that processes the recently built block of data is LookForUnallowedURL. As you can see, it takes two arguments: the VirtualAddress and the Length, according to whether its return value esi is cleared or not. This reflects whether an invald url has been found or not. Finally, memory is released with NdisFreeMemory. Let’s see how a url request is checked:

You’ll immediately notice the GET request in the packet. Another way isto look for POST and Host until we land at the list of URLs checked that way:

Here’s a list of all the denied urls:

rsup10.rising.com.cn

rsdownauto.rising.com.cn

cloudinfo.rising.com.cn

cu005.www.duba.net

cu010.www.duba.net

cu.www.duba.net

f-sq.ijinshan.com

geo.kaspersky.com

stat.ijinshan.com

qup.f.360.cn

h.qup.f.360.cn

up.f.360.cn

down.360safe.com

dl.360safe.com

sdup.360.cn

dl.360safe.com

At this point, the parsing is complete and the presence of illegal requests revealed. Returning to the sub_10970 (if PacketParser returns True) execution jump at the end of that call, otherwise the execution flow follows this way:

The packet parameter belongs to the NDIS_PACKET structure defining the packet descriptors, with chained buffer descriptors for which the pointers are passed. The second parameter, StacksRemaining, will be true if one or more stack locations are available in the packet, but false if the number of stack locations is 0. This is determined in our code, if the Send Request is forwarded via NdisSend to the underlying driver and successively operation marked Pending, or if the Packet will be further parsed by jumping to AllocatePacket routine.

Conclusions about Siglow Component

From the above analysis, it is clear that that the system siglow.dll and siglow.sys works together as a unique defensive component of the trojan itself. Next, we’ll analyze the Offensive Components.

newnetgar.dll – nethome32.dll Analysis

This is the first component taking an active offensive role in the infection. The essential role of nethome32.dll is to connect to the malicious server and download additional components and configurations. The first analysis step is the enumeration of exported functions:

InstallService

RundllInstall

RundllUninstall

ServiceMain

UninstallService

DllEntryPoint

The InstallService can be resumed    by the following procedure:

DisplayName is NetHomeIDE. This constitutes more evidence of infection. → The core functionalities of newnetgar.dll can be revealed in the thread creation performed into DllMain.

spass.dll – netplayone.dll Analysis

The second offensive component is spass.dll (also renamed in netplayone.dll). It spies on the traffic directed to AV Servers generated by a defined set of antivirus processes. It also modifies network traffic directed toward 360.cn servers as well as most widespreaded Chinese search engines.

DllEntryPoint

WSPStartup

GetModuleInfo

The most interesting entry is WSPStartup which, according to MSDN, initiates the use of a Windows Sockets Service Provider Interface (SPI) by a client.