Introduction
Kuluoz, or commonly known as Asprox by some
antivirus vendors, is a Trojan botnet
that is usually distributed thru spam emails.
Kuluoz imitating a word
document
It spoofs the icon of a Microsoft Word
document in an attempt to fool the user in executing it.
The most common and obvious indicators of
compromise (IOC) of kuluoz on an infected system are:
Kuluoz in
%USERPROFILE%\Local Settings\Application Data
·
Presence of an autorun entry
located in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
pointing to the botnet’s executable image
Copy of SVCHOST.EXE
injected with kuluoz
Breaking Into Bits and Pieces
UNPACKING ROUTINE:
The unpacker section of kuluoz needs to
meet two conditions in order to properly continue its execution.
First is the existence of
“HKEY_CLASSES_ROOT\ typelib\{640d3148-a423-11d2-b943-00c04f79d22f}\1.0” in
registry. If not found, it self terminates.
Checks for a specific
registry entry
And second, the height of the target
machine’s full screen window on the primary monitor in pixels should be greater
than 500 pixels.
Checks screen height if
greater than 500 pixels
Then what happens if the height of the window
falls short of 500 pixels? A debug exception occurs, and again the Trojan
terminates.
As a reader you might ask, "What is
the purpose of kuluoz doing these two checks?". Simple answer, kuluoz
assumes that by calling these fake APIs some antivirus engines may fail in
emulation, thus successfully bypassing its heuristic/generic detections.
An encrypted data within its body
(starting at 0x40F003) with a size of 0x12300 bytes is then copied and
decrypted in memory using VirtualAlloc. After which, execution is
then transferred.
It then gets the image base of
kernel32.dll by parsing its value in Win32 Thread
Information Block (TIB). In turn, it then populates its API table based
from the image base of kernel32.dll.
The following imported APIs that are to
be populated are listed below.
Once again, it will make use of VirtualAlloc to
allocate a memory region for itself to copy and decrypt a part of its code.
This time the data that is decrypted in memory contains an MZ-PE header.
An MZ-PE file copied and
decrypted in memory
This newly decrypted PE file is then
overwritten to the memory region of the original executable before transferring
execution.
You can dump this into a new file and we
have successfully created an unprotected version of Kuluoz!
PROCESS INJECTION (INJECTING THE MODULE):
Kuluoz creates a mutex name of
“2GVWNQJz1” to prevent duplicate process of it running in memory.
“2GVWNQJz1” as mutex name
It then proceeds to gather all the
necessary APIs that it needs, which are listed below:
Next it will inject a portion of its dll
code to a normal process “SVCHOST.EXE”.
I will explain in detail how this
process injection is done.
First, it spawns a suspended process of
svchost.exe in memory using CreateProcessA.
Create suspended process of
svchost.exe
Next, it will create a memory section
using ZwCreateSection and maps a section
location using ZwMapViewofSection in order to copy portion
of its code into memory address 0x00090000.
A portion of kuluoz code
copied in memory
Then it allocates another memory region
to copy svchost.exe data in memory using ZwReadVirtualMemory.
svchost.exe copied in
memory
It then traverses the entry point for
svchost.exe in memory and overwrites it with the following instructions in
order to jump to its malicious code.
Entry point of svchost.exe
overwritten to point to malware code
Bingo! From the image above we can see
that kuluoz wants to execute at memory space 0x00090000, which in truth holds
its malicious routines that was mapped earlier.
After that, it will recopy all the
changes done to svchost.exe into another memory region before unmapping,
effectively saving all the modifications done to svchost.exe that is loaded in
memory.
After which, the suspended process of
svchost.exe is resumed by calling ZwResumeThread.
GETTING TO “WORK” (WHERE THE FUN STARTS!):
Let’s analyze the code injected at
svchost.exe shall we?
It starts off by traversing Process
Environment Block (PEB) to obtain the image base address of kernel32.dll
and get to its export table.
A more detailed explanation on how it
was done is seen in the image below.
Traversing PEB to get to kernel32.dll exports
It gets to the list of module names and
compares it against a hash of kernel32.dll
which is 0x6A4ABC5B. This little code of “walking” the PEB to get to
kernel32.dll has also been used by other malwares such as Zeus.
It looks for GetProcAddress function and uses it to get function addresses of GetModuleHandleA, LoadLibraryA,
ExitProcess, and VirtualAlloc in kernel32.dl, and memset, memcpy and _stricmp in ntdll.dll.
It then continues to get addresses of
the following APIs:
For ADVAPI32.DLL:
For SHELL32.DLL:
For OLE32.DLL:
For WS2_32.DLL:
For WININET.DLL:
For MSVCRT.DLL:
For CRYPT32.DLL:
Using VirtualAlloc, it will allocate memory space for itself to copy
stubs of it code using memcpy.
Work Function copied in memory
These code stubs belongs to its kuluoz
dll exported function named “Work” which
is subsequently called after.
SO WHAT’S INSIDE?:
Inside of “Work” module, the Trojan
uses again GetProcAddress to get the
addresses of the following APIs.
After
everything is now properly setup first thing that it does is to get the user
name of the account that is currently logged on to Windows by using GetUserNameA and retrieves its equivalent
Security IDentifier
(SID). It then checks for the installation date of Windows in registry located
at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\
“InstallDate”.
All
these data gathered are then transformed to its MD5 hash equivalent using MD5Init, MD5Update and MD5Final functions. The MD5 hash is used
as a unique ID by the bot in order to be identified by a C2 server.
Each
time it attempts to make a network request to a C2 server (Command-and-Control),
it enumerates all the keys found in HKEY_CURRENT_USER\Software and decrypts
their values and compares to the string “You Fag!!!!!”. If it matches, the data
after the string you fag is translated as an in_addr struct.
It
then contacts the C2 server by generating an IP address either thru registry
(as stated above) or by using a hardcoded IP address that is encoded using RC4
encryption with a hardcoded key.
It
will use the following request headers in contacting the C2 server as an
example.
Where
“67454D7C3015100394CEF4D903E2D5DDDB1FA83AD0”
is the unique ID generated by hashing user account name, SID and operating
system installation date and “Host:
213.21.158.141:443” is the IP address of the C2 server that was generated
either thru registry or hardcoded in the malware body.
Request header of kuluoz
Where:
It checks for the presence of the
following malware analysis tools window names and registries and places the
result in <src></src> in its knock data.
FOR
WINDOW NAMES:
FOR
REGISTRY:
It uses the following RSA public key certificate
(which is found embedded in its body) to encrypt data before sending over a
secure shell.
After sending encrypted data to a C2
server, it will attempt to acquire a list of current IP addresses and ports of other
possible C2 servers to ensure its continuity in communicating to the REAL C2
server (the mother) accompanied by commands issued by the C2.
Communicating with a C2 Server
A sample of a response header is seen
below.
Response Header from C2 Server
The commands are sent also by using the
following knock data format
Where:
A list of possible commands are:
