from Understanding Java Code and Malware | Malwarebytes Unpacked
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:
- b1380af637b4011e674644e0a1a53a64: main executable
- bc05977b3f543ac1388c821274cbd22e: Carrier.dll
- 7d0ebb99055e931e03f7981843fdb540: Payload.dll
- C&C: web4solution.net
Other found samples:
- 8ea35293cbb0712a520c7b89059d5a2a: submitted to VirusTotal in 2013
- C&C: securedesignus.com
- 6992370821f8fbeea4a96f7be8015967: submitted to VirusTotal in 2014
- C&C: securedesignuk.com
- d9181d69c40fc95d7d27448f5ece1878: submitted to VirusTotal in 2015
- CnC: web4solution.net
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:
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:
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:
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:
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:
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:
3) Execution of the DOS header leads to calling a function inside the code section of the same module:
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:
Carrier.dll
Carrier is responsible for checking the environment, installing, and deploying the bot.
It exports one function: ReflectiveLoader that was mentioned before:
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:
Found handle to the configuration:
If the handle is successfully retrieved (like in the example above), execution proceeds with environment check and, eventually, bot installation is deployed:
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.
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:
Searching the names of browsers among the opened processes:
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_ROOT\HTTP\open\command and finds the application that is triggered.
Having this information, it deploys the found browser as suspended, maps there it’s own code and starts a in a 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):
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.
Bot attacks all the fixed 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.
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.
While the address of the server is read from configuration, the subpath /external/update is hardcoded:
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 got any major improvements. 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 it 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: http://ift.tt/1R6Y8zL.
