Shakti Trojan: Technical Analysis

Recently, we took a look at the interesting Trojan found by Bleeping Computer. Our small investigation on its background and possible attribution has led us to the conclusion that this threat is in reality not new – probably it has been designed in 2012 for the purpose of corporate espionage operations. Yet it escaped from the radar and haven’t been described so far. More about that research, as well as the behavioral analysis of the malware, you can find in the article Shakti Trojan: Document Thief.

In contrary to the first part, this post will be a deep dive in the used techniques.

Analyzed samples

Recent sample mentioned by Bleeping Computer:

Other found samples:

Inside the main executable

The main executable is a loader responsible for unpacking and deploying the core malicious modules. Often, malware distributors use ready-made underground crypters to pack and protect their bots. After unpacking that first layer, we usually get a fully independent PE file.

In this case it is slightly different. The main loader looks like it is prepared exclusively for this particular bot (rather than being a commercial crypter).

In resources we can find content obfuscated by XOR with 0x97:

resource

This content is loaded and decoded during malware execution. The author tried to obfuscate the XOR operation performed on the buffer by splitting it into three and hiding in between redundant API calls:

decoding_res

byte ^ 0x97 = byte ^ (0xc7 ^ 0xe7 ^ 0xb7)

After decoding the buffer, we find that it is a Trojan’s configuration file, which contains the following strings:

EA20E48B6CBC1134DCC52B9CD23479C7
web4solution.net
{40f550c2-a844-49e6-ba74-ded0ab840d5b}
igfxtray
JUpdate
Java Update Service

The first string of the configuration:

EA20E48B6CBC1134DCC52B9CD23479C7 -> md5("HEMAN")

must match the one hardcoded in the executable:

check_resource
Another curious fact about this executable is a huge overlay. Below you can see the size of the overlay (at the end of the file) versus the size of the space consumed by the main executable’s sections:

sections_with_overlay

As we found out, two more (encrypted) PE files are hidden in this space. In order to decode them and deploy, the application reads its own file into a newly allocated memory.

Those two hidden modules are, appropriately: Carrier.dll and Payload.dll.

Flow obfuscation

This Trojan utilizes some techniques of flow obfuscation. Among them, there is an interesting trick of redirecting execution to the new module – via DOS header. It takes the following steps:

1) The new PE file is unpacked into a newly allocated memory block. Address to its beginning is stored. Below we can see the main executable making a call to such address. This way, it is redirecting execution flow to the beginning of Carrier.dll:
call_dos_hdr

As we can see above, the main module passes to the Carrier.dll some additional parameters: handle to the decrypted configuration and a magic constant (0x0DEFACED) that will be used further by the DLL as a marker for searching parameters on the stack.

2) The bytes of the DOS header are being interpreted as code and executed:

executing_dos_header

3) Execution of the DOS header leads to calling a function inside the code section of the same module:

exec_carrier

In the analyzed case the called function is ReflectiveLoader – a stub of a well-known technique allowing to easily map any PE file into memory (you can read more about this technique here).

Reflective Loader is responsible for doing all the actions that Windows Loader would do if the DLL was loaded in a typical way. After mapping the module it calls its entry point:

reflective_loader_calls_EP

Carrier.dll

Carrier is responsible for checking the environment, installing, and deploying the bot.

It exports one function: ReflectiveLoader that was mentioned before:

carrier

Execution of the important code starts in the DllMain. First, the DLL searches the magic constant on the stack, and with its help retrieves the handle to the configuration:

check_magic_val

Found handle to the configuration:

found_configuration

If the handle is successfully retrieved (like in the example above), execution proceeds with environment check and, eventually, bot installation is deployed:

carrier_deploy_main

Defensive techniques

Before performing the installation, the Trojan checks the environment in order to defend itself from being analyzed. If any of the defined symptoms are found, the program terminates. Here’s how it proceeds:

1) Uses standard function IsDebuggerPresent to check if it is not being debugged
2) Checks names of the running processes against the blacklist:

"VBoxService"
"VBoxTray"
"VMware"
"VirtualPC"
"wireshark"

3) Tries to load library SbitDll.dll (to check against sandbox)
4) Tries to find a window from the blacklist:

"SandboxieControlWndClass"
"Afx:400000:0"

If the check passes and no tools used for analysis have been detected, the program proceeds with installation.

Installation

Before deciding which variant of the installation to use, the application checks the privileges with which it is deployed. If it has administrator rights, it attempts to install itself as a service. The name of created service is given in a configuration (mentioned before). In the described case it is Java Update Service.

install_service

active_setup

If this variant of achieving persistence is not possible, the application injects itself into a browser.

Injection in a browser is a good way to cover the operation of uploading files. The process of a browser connecting to the Internet and generating traffic does not look suspicious at first. Also, if the victim system uses a whitelist of applications that can connect to the Internet, the probability that a browser is classified as trusted is very high.

First, it checks if any of the following browsers are already running in the system: chrome.exe, firefox.exe, opera.exe.

Enumerating processes:

enum_proc

Searching the names of browsers among the opened processes:

open_process

If it finds the appropriate process running, it injects itself as a new thread.

If no browser is running, it tries another way: finding the default browser, deploying it, and then injecting itself inside. In order to find out which browser is installed as a default in the particular system, it reads the registry key HKEY_CLASSES_ROOTHTTPopencommand and finds the application that is triggered.

http_command

Having this information, it deploys the found browser as suspended, maps there it’s own code and starts a in a remote thread.

remote_thread

Payload.dll

Payload is the piece responsible for carrying the main mission of stealing files.

This module is a DLL exporting two functions (one of them is also ReflectiveLoader):

payload_dll

Execution starts in the function Init that is called from inside DllMain. To prevent being deployed more than once, the program uses a mutex with the hardcoded name CStmtMan.

init_proc

Bot attacks all the fixed drives:

enum_drives

It searches for files with  the following extensions:

inp, sql, pdf, rtf, txt, xlsx, xls, pptx, ppt, docx, doc

The list of found files is passed to the thread responsible for reading them and sending to the C&C.

read_and_send_file

Internet connection is opened with a hardcoded user agent string: “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)” – that was used by Internet Explorer 7 on Windows XP SP2 – confirming the hypothesis that the bot has been written several years ago.

connect

While the address of the server is read from configuration, the subpath /external/update is hardcoded:

external_update

Conclusion

The code is not very sophisticated, yet it’s effective—probably written by a person/team with some knowledge of malware development. We can see simple obfuscation and well-known injection methods used for reasonable goals (deploying network activity under the cover of a browser). There are some weaknesses in the implementation and lack of optimization (sending open text not compressed or encrypted, user agent string doesn’t match the deployed browser, etc). The unpolished design may suggest that the samples were released/sold in the early stages of development

Over the years, the bot didn’t have any improvements – only the configuration changed. It leads to conclude that the distributor of the malware may not be the same entity as the author. Analysis of the C&Cs depicts that the bot was used by a single threat actor – so probability is high, that this tool has been ordered by the actor from an external programmer, for the purpose of small espionage campaigns.


This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.