AntiCloud Trojan Reverse Engineering Analysis

Introduction

In this paper we are going to talk about the Anticloud Trojan, also know as the TrojanDropper:Win32/Bohu.Aand B variant. This malware originated in China and was designed to target the Cloud-Based Technology of major Chinese AntiVirus Vendors. For this reason, Bohu has also been called AntiCloud Trojan.

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.

MD5: 179743623A423D5239B91E6A343FAC23
SHA-1: D40874EE6702014EB87F0D60AA083B40EABB45F0
File Info: Nullsoft PiMP Stub -> SFX
File Size: 2.13 MB (2229512 bytes)

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

MD5: 6158AFB0A85C29748126B2F49E34C1B6
SHA-1: 01D7FF02315E53F2079C4E9076BA31223E10E159
FileInfo: Nullsoft PiMP Stub -> SFX
FileSize: 749.66 KB (767648 bytes)

Due to the fact that this executable is embedded inside main dropper, it maintains the original Timestamps. Let’s enumerate them:

Created: Sunday 20 March 2011, 18.13.18
Modified: Monday 19 July 2010, 19.20.52

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

MD5: E7AA331D4F8669C531FBDF559DBC99FF
SHA-1: A0E19AA2CAFC29064F0D950426504A72FC03568B
FileInfo: Microsoft Visual C++ 8
FileSize: 685.00 KB (701440 bytes)

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\

MD5: 308BF66610B82E2E1D8A982B0A111FA6
SHA1: 2BE86869D33A5098F8C2FE68A33EB55EE1774AE7
FileInfo: Microsoft Visual C++ 8
FileSize: 361.00 KB (369664 bytes)

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.

40562e     CreateFileA(C:\Tools\Bohu\malware\malware.exe)
403083     ReadFile()
402dc2     GlobalAlloc()
405841     RegOpenKeyExA (HKLM\Software\Microsoft\Windows\CurrentVersion)
40562e     CreateFileA(C:\Programmi\baidu\dsop7.xml)
403042     WriteFile(h=218)
40562e     CreateFileA(C:\Programmi\baidu\msfsg.exe)
402fbf     WriteFile(h=218)
40562e     CreateFileA(C:\Tools\Bohu\malware\uuse-5905.exe)
402fbf     WriteFile(h=720)
40562e     CreateFileA(C:\Programmi\baidu\uninst18.exe)
4026c4     GlobalAlloc()
4026e0     GlobalAlloc()
40272f     WriteFile(h=710)
403042     WriteFile(h=710)

It’s pretty easy to catch the file creation order, giving us additional valuable clues. Malicious files are placed in the%\Programs\baidu\path.From the correlation of known filenames and the path uncovered, we can produce evidence of infection.

Let’s prosecute log analysis:

4051b6    CreateProcessA((null),C:\Tools\Bohu\malware\uuse-5905.exe,0,(null))
2111b7 Copy(C:\DOCUME~1\evilcry\IMPOST~1\Temp\nsc4.tmp\nsExec.dll->C:\DOCUME~1\evilcry\IMPOST~1\Temp\nsc4.tmp\ns5.tmp)

The first process created belongs to uuse-5905.exe, containing the deceptive media player application.

4051b6     CreateProcessA((null),C:\Tools\Bohu\malware\uuse-5905.exe,0,(null))
2111b7     Copy(C:\DOCUME~1\evilcry\IMPOST~1\Temp\nsc4.tmp\nsExec.dll->C:\DOCUME~1\evilcry\IMPOST~1\Temp\nsc4.tmp\ns5.tmp)

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

7c81628b     WaitForSingleObject(70,64)
10001a11     WaitForSingleObject(8c,ffffffff)
4051b6       CreateProcessA((null),msfsg.exe uncompress -s dsop7.xml -d setup109807.exe,0,(null))
76bb183b     ReadProcessMemory(h=590)
76bb185a     ReadProcessMemory(h=590)

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 whatsetup109807.exe produces with the same API Spy approach.

Setup109807.exe API Spy

40562e     CreateFileA(C:\Programmi\baidu\setup109807.exe)
40562e     CreateFileA(C:\Programmi\baidu\siglow.dll)
40562e     CreateFileA(C:\Programmi\baidu\dsetup.exe)
40562e     CreateFileA(C:\Programmi\baidu\siglow.sys)
40562e     CreateFileA(C:\Programmi\baidu\mpflt_m.inf)
40562e     CreateFileA(C:\Programmi\baidu\mpflt.inf)
40562e     CreateFileA(C:\Programmi\baidu\newnetgar.dll)
40562e     CreateFileA(C:\Programmi\baidu\spass.dll)
40562e     CreateFileA(C:\Programmi\baidu\SysDat.bin)
40562e     CreateFileA(C:\Programmi\baidu\uninst13.exe)

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:

4051b6     CreateProcessA((null),msfsg.exe md5 -s dsetup.exe -d dsetup.exe,0,(null))
4051b6     CreateProcessA((null),msfsg.exe md5 -s newnetgar.dll -d newnetgar.dll,0,(null))
4051b6     CreateProcessA((null),msfsg.exe md5 -s spass.dll -d spass.dll,0,(null))
4051b6     CreateProcessA((null),msfsg.exe md5 -s siglow.sys -d siglow.sys,0,(null))
4051b6     CreateProcessA((null),msfsg.exe md5 -s siglow.dll -d siglow.dll,0,(null))

As is clear, msfsg.exe is a core component used for a number of support operations. This time, it uses the MD5functionality 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:

4051b6       CreateProcessA((null),rundll32.exe C:\WINDOWS\system32\nethome32.dll RundllInstall NetHomeIDE,0,(null))
10002af4     RegOpenKeyExA (HKLM\SYSTEM\CurrentControlSet\Services\NetHomeIDE)
10002b21     RegCreateKeyA (Parameters)
77f6d5f4     RegCreateKeyExA (Parameters,(null))
10002ba2     RegSetValueExA (ServiceDll)

nethome32.dll is the previously created newnetgar.dll, renamed, copied and successively installed as Service.

4051b6 CreateProcessA((null),C:\Programmi\baidu\dsetup.exe install,0,(null))

dsetup.exe installs the NDIS protection system, that is composed by:

siglow.dll
siglow.sys

4051b6     CreateProcessA((null),C:\Programmi\baidu\dsetup.exe install,0,(null))

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 →

%\Programs\baidu\ 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_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\speednet_sph PathName = %System%\netplayone\netplayone.dll
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetHomeIDE

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.

[Version]
signature  = "$Windows NT$"
Class      = Net
ClassGUID  = {4d36e972-e325-11ce-bfc1-08002be10318}
Provider   = %Msft%
DriverVer  = 03/17/2010,5.00.2071.1
[netsfltMP.AddService]
DisplayName    = %netsfltMP_Desc%
ServiceType    = 1
StartType      = 3
ErrorControl   = 1
ServiceBinary  = %12%\siglow.sys
LoadOrderGroup = PNP_TDI
AddReg         = netsfltMP.AddService.AddReg

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:

System\CurrentControlSet\Services\netsflt\Parameters

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:\passthru\siglow\notifyob\objfre\i386\siglow.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 locatingDriverEntry() 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.

VOID NdisMInitializeWrapper(
  __out  PNDIS_HANDLE NdisWrapperHandle,
  __in   PVOID SystemSpecific1,
  __in   PVOID SystemSpecific2,
  __in   PVOID SystemSpecific3
);

This notifies NDIS that a new miniport driver is initializing. The most important parameter for our analysis isNdisWrapperHandle:, a pointer to the caller-supplied variable in which NDIS returns a handle representing itself.

NdisIMRegisterLayeredMiniport

This defines the function:

NDIS_STATUS
  NdisIMRegisterLayeredMiniport(
    IN NDIS_HANDLE  NdisWrapperHandle,
    IN PNDIS_MINIPORT_CHARACTERISTICS  MiniportCharacteristics,
    IN UINT  CharacteristicsLength,
    OUT PNDIS_HANDLE  DriverHandle
    );

This function registers an intermediate driver’s miniport entry points.

As noted, there is a sequence of mov dword, offset; these instructions belongs toNDIS_MINIPORT_CHARACTERISTICS, by inspecting its members we can obtain additional information about this component.

typedef struct _NDIS_MINIPORT_CHARACTERISTICS {
    UCHAR MajorNdisVersion;
    UCHAR MinorNdisVersion;
    UINT Reserved;
    W_CHECK_FOR_HANG_HANDLER CheckForHangHandler;
    W_DISABLE_INTERRUPT_HANDLER DisableInterruptHandler;
    W_ENABLE_INTERRUPT_HANDLER  EnableInterruptHandler;
    ...

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 byNdisRegisterProtocol as follows:

typedef struct _NDIS_PROTOCOL_CHARACTERISTICS { 

    UCHAR MajorNdisVersion;
 UCHAR MinorNdisVersion;
 UINT Reserved;
 OPEN_ADAPTER_COMPLETE_HANDLER OpenAdapterCompleteHandler;
 CLOSE_ADAPTER_COMPLETE_HANDLER CloseAdapterCompleteHandler;
 SEND_COMPLETE_HANDLER SendCompleteHandler;
 TRANSFER_DATA_COMPLETE_HANDLER TransferDataCompleteHandler;
 RESET_COMPLETE_HANDLER ResetCompleteHandler;
 REQUEST_COMPLETE_HANDLER RequestCompleteHandler;
 RECEIVE_HANDLER ReceiveHandler;
 RECEIVE_COMPLETE_HANDLER ReceiveCompleteHandler;
 STATUS_HANDLER StatusHandler;
 STATUS_COMPLETE_HANDLER StatusCompleteHandler;
 NDIS_STRING Name;
//
// MajorNdisVersion must be set to 0x04 or 0x05
// with any of the following members.
//
 RECEIVE_PACKET_HANDLER ReceivePacketHandler;
    BIND_HANDLER BindAdapterHandler;
    UNBIND_HANDLER UnbindAdapterHandler;
    PNP_EVENT_HANDLER PnPEventHandler;
    UNLOAD_PROTOCOL_HANDLER UnloadHandler;
//
// MajorNdisVersion must be set to 0x05
// with any of the following members.
//
 CO_SEND_COMPLETE_HANDLER CoSendCompleteHandler;
    CO_STATUS_HANDLER CoStatusHandler;
    CO_RECEIVE_PACKET_HANDLER CoReceivePacketHandler;
    CO_AF_REGISTER_NOTIFY_HANDLER CoAfRegisterNotifyHandler;
} NDIS_PROTOCOL_CHARACTERISTICS, *PNDIS_PROTOCOL_CHARACTERISTICS;

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 (ifPacketParser 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 SocketsService Provider Interface (SPI) by a client.

blog posted by Giuseppe Bonfa

Search This Blog

Indian News