LatentBot is a multi-modular Trojan written in Delphi and known to have been around since 2013. Recently, we captured and dissected a sample distributed by RIG Exploit Kit.
The main executable is a persistent botnet agent which downloads additional modules and reports about the performed activities to its Command and Control server. Depending on the modules that have been installed, LatentBot has various capabilities, including:
- Act as a keylogger and form grabber
- Steal cookies
- Run a Socks Proxy from the victim system
- Give remote access to the attacker (VNC / Remote Desktop)
In this post we will describe those modules by taking apart several layers of obfuscation and encryption in order to reveal their true nature.
- 011077a7960fa1a7906323dbdc7e3807 - original sample, distributed in the campaign
Downloaded modules, injected into svchost:
- e3fb224201592c02b6250532e99416f0 - main module
After being deployed. the original sample installs itself and deletes the sample from the original location. It injects into svchost the initial module (60c3232b90c773ed9c4990da7cc3bbdb). That module performs another injection (of module: b622a0b443f36d99d5595acd0f95ea0e) - into Internet Explorer (iexplore.exe):
The module injected in the iexplore.exe process is responsible for establishing connection with the CnC and downloading submodules.
At this stage, LatentBot creates two groups of registry keys:
In the key named "0" the initial PE file is stored:
Another, encrypted key is added under:
The data under the key "in" is encrypted by a custom algorithm, typical for the LatentBot, that will be described further (it can be decoded by a dedicated application). After decoding, it gives the path where the malware installed itself, i.e.:
If the CnC is active and the bot managed to download sub-modules, they are run injected into new instances of svchost:
The main module is deployed with a parameter: -l MxN4ViazcD
This parameter specifies a group id where the bot belongs (also encrypted by Latent Bot's custom crypto).
MxN4ViazcD -> Group 1
Also, the registry keys related to the new modules are added under:
Decrypted names of the modules are very descriptive:
FtUFJu5xP3C -> formgrab hdtWD3zyxMpSQB -> Bot_Engine l551X+rNDh3B4A -> Found_Core QdG8eO0qHI8/Y1G -> send_report QdW/DoI2F9J -> security RRrIibQs+WzRVv5B+9iIys+17huxID -> remote_desktop_service VRWVBM6UtH6F+7UcwkBKPB -> vnc_hide_desktop w97grmO -> Socks
Some of the modules are collecting data on the victim machine, and saving them in the %TEMP% directory in encrypted form:
Further, they are being uploaded to the CnC.
The basic persistence of Latent Bot is simple. The initial sample is copied into:
It is executed on each system startup thanks to a simple Run key:
Once the main module is run, it is responsible for decrypting all the submodules from the registry and loading them.
The bot starts communication with CnC by sending a beacon. If the beaconing went successfully, it starts to download additional modules in encrypted form. They are pretending to be .zip files:
The beacon is encoded by two algorithms: Latent's custom encryption and then Base64:
Latent custom decoded:
As we can see, it contains data about the infected machine, as well as the group name and a random token.
However, not all the communication is encrypted. Some of the further requests are very verbose. Name of each action is identified by a string, in capital letters. Examples:
Client beacons to the server by a HELLO command. In return, the CnC gives it a cookie that is further used as an ID. The content posted between the client and the server is encrypted:
Analyzing the traffic, we can find that the bot sends to the CnC some stolen data, packed as Cabinet format. The content inside is encrypted by a custom encryption algorithm, typical to LatentBot, that will be described later. The file is uploaded using HTTP PUT method:
The original sample of Latent Bot, that is distributes in campaigns, comes packed with a crypter. After removing this first layer, we get a loader with the following structure of sections:
All the used strings are obfuscated - particular chunks of the string are being moved to consecutive variables:
The basic role of the main element is to to make injection into svchost.exe. In the memory of svchost.exe, another PE file is unpacked and loaded:
If we dump this file, we find another stage. Starting from this element, all further pieces of Latent Bot have some common patterns. They are written in Delphi, and their strings are obfuscated by the same set of functions. Example:
In order to defeat this obfuscation I prepared a dedicated IDA script (latent_dec.py). Not much of the other obfuscation techniques has been used, so after applying it, the code looks much more understandable:
Another thing, typical for LatentBot's pieces are the resources following similar schema. The current sample comes with 2 resources: CFG and R. Both of them are encrypted:
This element unpacks another module (b622a0b443f36d99d5595acd0f95ea0e), that is injected this time into iexplore. The new module has resources with a structure similar to the previous one. It's CFG file contains strings encrypted by an algorithm typical for this bot:
The configuration of this element contains the bot group ID and the CnC address:
MxN4ViazcD -> Group 1 j5kmNVnZPcAt18wWBH3kfMOzGQ6ENA -> http://18.104.22.168/
The main element of the LatentBot is an engine downloading and managing the modules. Each module of LatentBot have some different task to do. Overall, it has capabilities of a typical RAT and stealer. Downloaded submodules are various for various samples. In the analyzed one, elements with the following names has been fetched:
Let's have a look inside some of them...
As the name states, this is the main module of the bot. It is responsible for the communication with the C&C and loading the plugins.
It fingerprints the environment and send the collected data in the beacon to the CnC.
'tkNFKRA' -> '&ver=' 'tA8OqC' -> '&os=' 't4M5zB' -> '&av="' 't4c85aF' -> '&acs=' 'tct4rwD' -> '&x64=' 'tgszOD' -> '&gr=' 'tMc36A' -> '&li=W4' 't89KWAf3QyCh' -> '&plugins=' 'to8KKL6mYGs8' -> '&errcode=' 't08rKTC' -> '&bk=1' 't08rKXC' -> '&bk=0' 'tEMeVgHimC' -> '¬e=1' 'tEMeVgHinC' -> '¬e=0' 'tsMSYj/L' -> '&dom=1' 'tsMSYjvL' -> '&dom=0' 'tw9sex5WXDzsMB' -> '&sockslog=' 'tk9H0psjw5Wv' -> '&vncpass=' 'tkNGWE8KNC+N' -> '&vidtype='
Example - checking installed AV products:
The dedicated function contains a long list of the directories that are checked,i.e.
This module gives to the attacker remote control on the victim's environment by executing various commands, such as:
'/tKvXgFBlB' -> 'testapi' 'slx6nfFi' -> 'get_id' '5J5eN0Wp9A' -> 'restart' '4FEa7FfTRCI' -> 'shutdown' 'nxRY+d/E' -> 'logoff' 'slx6nLVh9Et/qqi2eUpf9D' -> 'get_label_engine' 'slx6nLVh9Et/qOCYBWP' -> 'get_label_load' 'slx6n7kxqMcKNsq0UkmG' -> 'get_plugin_list' '7hfCrPhOfgfTX28h8TZS' -> 'plugin_stop_all' '7hfCrPhOfkfbTM6EplCNCN1d' -> 'plugin_restart_all' '7hfCrPhOfg+PtNcXVAc8JLsPUA' -> 'plugin_clear_storage' '41l3p17Xus/kRtagq7ObrZEM/WucXWH' -> 'stop_engine_and_plugins' '+FJV1v6mXl5SW7r8cB' -> 'uninstall_all' 'slx6njktomFaQ0F' -> 'get_version' '7hfCrPhOfgfTX2M' -> 'plugin_stop' '7hfCrPhOfkfbTM6EplC' -> 'plugin_restart' '7hfCrPhOfgfTX28h8bppqx+bZm/CQDXSnB' -> 'plugin_stop_and_uninstall' '7hfCrPhOf4vfz5NHktwwJB' -> 'plugin_uninstall' '7hfCrPhOfgfTZiCd' -> 'plugin_start' '7hfCrPhOfgfTZiCdhJwYvUM' -> 'plugin_start_auto' '7hfCrPhOfgfTX28h83I9CD' -> 'plugin_stop_autox' 'slx6n7kxqMcKNsazBUKWvC' -> 'get_plugin_start' 'o5SQ6EkjlBwmdJhahA' -> 'clear_cookies'
Example - fragment of the function stealing and clearing the cookies:
After completing a task, it also sends a report about the operation status:
This module performs extended environment check against various security products. Looking at the resources, we can find three elements: DFX, VBL, FDL containing lists of strings encrypted in the typical way:
In comparison to other modules, this one does not contain string or API obfuscation.
We can find it grabbing the content of fields of the windows:
...and tapping the typed keys:
This is the only module that has been written in C++ instead of Delphi. It comes with a default icon added to Windows projects by Visual Studio.
It's original name is installer.exe and it exports various functions, that can be used to make injections into 64 bit applications:
It has various features that are different from other modules, i.e. lack of string obfuscation. Performed actions are reported by debug strings, that are stored inside the binary as open text, i.e.
The compilation timestamp of this executable points at the February of 2017: 2017:02:28 18:21:01+01:00. This element was not observed in previous years, so probably indeed it is added this year, to expand injection capabilities of the LatentBot to 64 bit processes.
LatentBot has been around for several years, however, looking at the modules we can find out that it is still being actively maintained. The distributed package is a mixture of old and new modules.
The authors of this bot are not very advanced in malware development. They program in Delphi and use some ready-made templates. Also, the obfuscation they use can be easily defeated. However, they delivered a bot that is very rich in features and easily expandable, thus, it still poses a serious threat.
https://www.cert.pl/news/single/latentbot-modularny-i-silnie-zaciemniony-bot/ - Polish CERT on LatentBot (December 2016)
https://www.fireeye.com/blog/threat-research/2015/12/latentbot_trace_me.html - FireEye on LatentBot (2015)
https://cys-centrum.com/ru/news/module_trojan_for_unauthorized_access - CyS Centrum report (2015)
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.