LokiBot is Being Distributed by Windows Shortcut Files

Overview

The SonicWall RTDMI ™ engine has recently detected Windows Shortcut Files (LNKs) inside archives that execute LokiBot malware on the victim’s machine. The malicious LNK file is packed inside an archive along with a text file that says, “Find attached March Order” in Spanish, essentially pretending to be a legitimate file. The LNK file executes a PowerShell script to download and execute the LokiBot loader executable from a URL. LokiBot malware has been observed using image steganography, multi-layered packing and Living Off the Land (LOTL) techniques in past campaigns. The malware authors' trend of using a low-profile file type as an initial vector keeps increasing, and they prefer the use of custom packers and protectors to prevent detection rather than updating the core executable code.

Figure 1: LNK file executing PowerShell to download LokiBot

Loader Executable

The downloaded executable is protected in two layers by the Confuser application to make the analysis difficult for the reversing engineers. After unpacking and de-obfuscating both of the layers, the actual code that is responsible for loading and executing the LokiBot executable is exposed. The LokiBot binary is kept RSA-encrypted and Base64-encoded in the resource of the loader executable, which is only visible after unpacking.

Figure 2: Encrypted LokiBot executable in the resource of loader executable

To get the RSA key, the malware computes MD5 of the string “UV?vgotlHR?P\Y?LEhgU]CdJIS?W;yBTkDZw??FTEi>Z” and self-concatenates the MD5 value by overwriting the last byte of the MD5. After doing Base64 decoding, the malware decrypts the encrypted executable data using an RSA algorithm with the below parameters:

Figure 3: Parameters

Figure 4: Code performing RSA decryption

The decrypted bytes are the string representation of the executable’s hex bytes, and a string-to-hex conversion is performed to finally get the LokiBot executable. The malware executes the LokiBot binary using the CreateProcessW API.

Figure 5: LokiBot binary string representation

LokiBot

LokiBot is an information stealer that has been active in the wild since 2015. It contains a rich list of applications that are used to steal data from the victim’s machine. After sending data to its C&C server, the malware receives commands to perform various actions on the victim’s machine.

Delayed Execution

The execution of LokiBot starts by examining the argument value for space-separated “-u” occurrences. The malware execution has been delayed by 10000 milliseconds for each occurrence of the value “-u”.

Figure 6: Checks process arguments

API Name Hashing

The malware uses API name hashing and resolves addresses just before invoking the APIs. To make the analysis difficult, the malware does not store the resolved API addresses, instead it loads and executes the API address from the accumulator register. If the malware needs to execute the same API more than once, it needs to resolve the API address again to invoke the API.

Hashing Algorithm

Code representation for the hashing module is in the C language and can be seen below. It generates a DWORD hash for the given array of bytes.

Figure 7: Hashing algorithm

Getting the Load Addresses of DLLs

An array of DLL names with a fixed length of 0x1A for each name is created by the malware. To resolve an API address, the malware calls a function with the index of the DLL names array and API name hash. The name of the DLL is retrieved from the DLL names array using the index value. The malware invokes the LoadLibraryW API to get the load address of the DLL, except for the kernel32 and ntdll DLLs. The malware considers kernel32 and ntdll to be already loaded into the memory and does PEB traversal to find the load address. It does this by comparing the DLL name hash with the loaded module name hashes.

Figure 8: Array of DLL names

Figure 9: Gets DLL load address

Resolving APIs Addresses

After getting the DLL load address either by calling the LoadLibraryW API or by PEB traversal, the malware enumerates the export directory of the loaded DLL and compares the requested API name hash with the exported API name hash to resolve the API address.

Single Instance Execution

The malware retrieves the MachineGUID from the registry entry “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography” to compute its MD5 string representation to the 12^th byte, which is used as a mutex name. The malware attempts to create the mutex and examines the error value ERROR_ALREADY_EXISTS to terminate the current execution and ensure a single execution of the malware process. The mutex value for my system is “06E1A66DB87D112F02F38F7C” and is expected to always be the same for a given system. It is later sent to the Command and Control (C&C) server. The mutex name can help the malware author identify whether a system is reinfected or has been infected for the first time. Some of the character sequences of the mutex name are used by the malware as dropped file names and a directory name.

Figure 10: Creates mutex using machine GUID

If the malware fails to get the mutex name using MachineGUID, then it executes its backup code to compute a random mutex name using the system time.

Figure 11: Code to create an alternative random mutex

Stealing Application Data

The malware steals data from installed applications like browsers, SSH clients, document applications, password managers, email clients and FTP clients The data it steals includes login credentials, autofill web forms, document texts and more. The malware contains a total of 101 functions to steal data from the installed applications. The malware initializes the array of function pointers with the address of stealing functions and initializes another array with the respective argument values for the stealing functions. The malware invokes the stealing functions in a loop. It invokes them from the array of function pointers with the respective argument from the arguments array. The stealer functions keep the stolen data in a structured buffer along with their sizes.

Figure 12: Calling stealing functions

Browsers

The malware contains a list of chromium-based browsers, gecko-based browsers and other browsers to steal the stored data. For a gecko-based browser, malware reads the registry entry for the respective browser to get the installation directory and sets the installation directory into the environment path variable to smoothly load the nss3.dll which is used to decrypt the gecko-based browsers data. After decrypting the data, malware restores the environment path variable. The malware reads the profiles.ini file from the browser dedicated application data directory to get the list of profile directories. The malware enumerates each profile directory and uses multiple APIs (NSS_Init, GetInternalKeySlot, Authenticate, Decrypt, FreeSlot, FreeItem, CheckUserPassword, NSS_Shutdown) of nss3.dll, to decrypt data from the files mentioned below:

• logins.json
• prefs.js
• signons.sqlite
• signons.txt
• signons2.txt

For chromium-based browsers, the malware steals data from the files “Web Data” and “Login Data” placing them into respective application data folders for the browsers. For Edge and Internet Explorer, the malware steals data from Windows Password Manager and registry entry “Software\Microsoft\Internet Explorer\IntelliForms\Storage2”. The malware enumerates and retrieves credentials from the Windows Password Manager using multiple APIs (VaultEnumerateVaults, VaultOpenVault. VaultEnumerateItems, VaultGetItem, VaultFree, VaultCloseVault) of library vaultcli.dll.

Figure 13: List of browsers

Apart from the browsers, the malware steals data from other installed applications which include SSH clients, FTP clients, email applications, document applications, password managers and more, which are mentioned in the table below:

Figure 14: List of applications to steal data

C&C Communication

The malware has an array to contain four C&C server addresses, however, in current variants, only one of the unique and valid C&C server addresses is found. After decrypting the C&C URL, the malware separates the IP address, port number, path and protocol to establish a connection.

Figure 15: Code for C&C communication

The malware compresses the stolen application data using aPLib compression library and appends into the structured buffer. The malware then prepares the HTTP post request with the user-agent “Mozilla/4.08 (Charon; Inferno)” and sends the stolen data to the C&C server. After sending the HTTP post request, the malware keeps the check sum of the data it sent into a file “C:\Users\Deepak\AppData\Roaming\DB87D1\112F02.hdb”. The directory name is taken from the mutex name’s character offsets from seven to 12, and the file name is taken from offsets 12 to 17.

Figure 16: Stolen data sent to the C&C server

An explanation of values sent by the malware to the C&C server is mentioned in the table below:

Figure 17: Description of the data sent to the C&C

After sending the stolen application data, the malware checks to see if the process is running in administrator mode to steal credentials stored in Windows Credential Manager. The malware enumerates files from the directory “%AppData%\Roaming\Microsoft\Credentials” using the APIs FindFirstFileW and FindNextFileW to read the encrypted data which is decrypted by accessing the process memory of lsass.exe.

Figure 18: Encrypted credentials in Windows Credential Manager

Decrypted credentials are compressed using aPLib compression library and appended into the structured buffer after malware variant-specific information and collected system information. It is then sent to the C&C server.

Figure 19: Decrypted credential from Windows Credential Manager

The malware creates the file “%APPDATA%\Roaming\DB87D1\112F02.lck” before attempting to decrypt credentials from Windows Credential Manager and deletes the files once the decryption routine is completed.

Figure 20: Creating the lock file

After sending the stolen data, the malware expects commands from the C&C server and spawns a separate thread to perform actions based on the received command.

Registry Entry

The malware creates a self-copy in the application data folder using a file move operation. If it fails in moving the file, then the malware uses the file copy operation. The malware creates a registry entry “HKCU\http://91.92.252.146:8015/wioy/five/fre.php\DB87D1” and sets the values as the path of the dropped file.

Figure 21: Registry entry

The malware modifies the attributes of the directory to the following values to lower the visibility:

• FILE_ATTRIBUTE_HIDDEN
• FILE_ATTRIBUTE_SYSTEM
• FILE_ATTRIBUTE_NOT_CONTENT_INDEXED

Figure 22: Modifies directory attributes

The archive file cannot be found in any of the popular threat intelligence sharing portals like VirusTotal and ReversingLabs at the time of writing this blog, which indicates its uniqueness and limited distribution.

Figure 23: File is not available on Virus Total

Evidence of the detection by our RTDMI engine can be seen below in the Capture ATP report for this file.

Figure 24: Capture report