Overview

SonicWall Capture Labs threat research team has observed an updated variant of StrelaStealer. StrelaStealer is an infostealer malware known for targeting Spanish-speaking users and focuses on stealing email account credentials from Outlook and Thunderbird. StrelaStealer was reported in the wild in early November 2022. StrelaStealer has been updated with an obfuscation technique and anti-analysis technique.

Technical Analysis

MD5: 1E37C3902284DD865C20220A9EF8B6A9

SHA256: F2D7CF39392D394D6CCD0F9372DB7D486D4CB2BB6C3BBFD0D8BFBB6117A5E211

This updated version of malware delivered via JavaScript comes in archive files as attachments in emails. The initial vector is JavaScript which will drop the 64-bit executable file in the %userprofile% folder and execute the malware process. We have observed that StrelaStealer is being delivered as a 64-bit exe as well as a DLL via JavaScript. We are explaining the analysis for the 64-bit executable in this blog. This 64-bit executable is a wrapper that will act as a loader for the actual payload.

In the main 64-bit executable file, the data section has an encryption key, and the size of the encryption key is 0x2714 bytes. The encoded payload is embedded in the data section at the end of the encryption key. The size of the payload is 0x1C600. A single-byte XOR encryption is performed to decrypt an encoded PE file from the data section.

Figure 1:  Encryption key started from 0x10th offset in the data section

Figure 2:  Obfuscated Jumps

Figure 3: Graph view for obfuscated function

Figure 4: Another graph view of the obfuscated function

Figure 5:  PEB parsing code fragments inside the jump code block

This obfuscation is quite effective. Anti-analysis techniques delay the execution, and the researcher has to search the code fragments inside the jump blocks, which is a tedious task.

Along with jump blocks and multiple loops, there are multiple dummy functions that are not doing anything but wasting time while analyzing the sample.

Figure 6: Dummy functions inside nested Jumps

Figure 7: Dummy functions

Figure 8: XOR decryption to decrypt the encoded payload

Once it decrypts the payload, it reads the encoded API string array at the end of the encoded payload embedded in the data section. Within the payload, the first DWORD is the size of the array and next is the API function array. This array is of size 0x52 bytes and the encryption key used earlier to decrypt the payload will also be used to decrypt the API array. The only difference between the decryption of the payload and the array  is malware uses an encryption key of size 0x52 bytes from the 4^th offset of encryption key.

Figure 9: Encoded API array

Figure 10: Malware calculates the start offset of the encoded API string and starts decrypting it

Figure 11: API array after an XOR decryption

It accesses the PEB structure and parses it to get the list of loaded modules in process memory.

The following is an example of the instructions set to parse the PEB.

Figure 11B: Instructions

Here InLoadOrderModuleList is a doubly-linked list that contains the loaded modules for the process.

The malware parses this “InLoadOrderModuleList” to get the Imagebase address of kernel32.dll with the goal of resolving the VirutalAlloc API Then the malware will parse the PE structure of kernel32.dll to get the name of each exported function and matches them with the API string that got decrypted earlier in 0x52 byte array. If the API name matches the exported function name, then the malware will read the associated function RVA from the export directory and add it to the Imagebase of kernel32.dll,. Using this method, the malware resolves each API dynamically. It will resolve 4 APIs – here VirtualAlloc,  LoadLibraryA , GetProcAddress , and MessageBoxTimeoutA. Once its finished resolving the APIs, the malware will show the error massage box and then continue execution.

Now, the malware calls the “VirtualAlloc” API to allocate memory in the process and start its task as loader to load the actual payload.

• The malware parses the PE file structure of the payload from the data section where previously it decrypted the PE file and read each section header one by one.
• To map the process as per section alignment, it reads the virtual address of each section and adds it to the image base of the injected PE and copies each section of data to this offset in memory.
• The malware will not copy the PE header to the injected PE, this has been done intentionally to evade detection from AV products.
• It reads the relocation section and does the fixup as it gets loaded at the different base address in the memory.
• It reads the import address table of the payload file from the data section region and resolves the API address dynamically using the “LoadLibraryA” and “GetProcAddress”  APIs and copies these all function pointers to the IAT of the injected payload.
• When the injected PE file is ready for execution, it will read the RVA of the address from the entry point from the PE file in the data section and add the base address of the injected payload and redirect execution to the injected code.

Figure 12: Configuration setting for the payload

The injected payload is 64-bit executable file, it will call the “GetKeyboardLayout” API and check the lower words of the return value with the hardcoded values in binary. It tries to check if the keyboard layout is from the following countries. If it is, then the malware will continue its execution, otherwise it terminates itself.

Figure 13: Call to the “GetKeyboardLayout” API and check language identifiers

Now, the payload retrieves the computer name by calling the “GetComputerNameA” API and encrypts the first 4 bytes of the computer name string using single byte XOR encryption. The encryption key is “MIR24”, which is hardcoded in binary. It will create a Mutex with the name of this partially encrypted computer name string. If a Mutex already exists, it will terminate it.

Figure 14: Creating a Mutex and executing its core functionality to steal data from the infected machine

As we can see in Figure 14, it will execute the function which will steal confidential data from the infected machine.

Here, we have found two functions in the malware. The first is used to steal data from Mozilla Thunderbird, which is a free and open-source email client software. The other function is intended to steal data from Outlook.

• It searches for the folder path “C:\Users\<username>\AppData\Roaming\Thunderbird\Profiles\”

All of your data such as messages, passwords and user preferences as well as changes made while you use Thunderbird are stored in a special folder called profile.

• If it finds this folder path on the system, it will call the FindFirstFileAand FindNextFileA APIs to search for two files in the subdirectory. The first is “logins.json” (account and password) and the second is “key4.db” (password database).
• It reads the data from both of these files and appends both files’ data one after another, starting network communication.
• It establishes a connection to its server and prepares an HTTP post request with the user-agent “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36” and then exfiltrates this data to its server.

http[:]//45[.]9[.]74.12/server.php .

• The server IP is hardcoded in binary which is “45.9.74[.]12”
• Before sending data to the server, it will encrypt it with the single byte XOR encryption. The encryption key is hardcoded in binary which is “00ca8abe-6ab2-4b10-97c8-925934cf0423”

Figure 15: Searches for the “logins.json” and “key4.db” files from the profile folder

Figure 16: StrelaStealer is expecting the response from its server

We have analysed the second function statically where it reads the windows registry key, enumerates data from it and tries to locate the ‘IMAP User’, ‘IMAP Server’ and ‘IMAP Password’ values.

The IMAP Password contains the user password in encrypted form. The malware will call the Windows “CryptUnprotectData”  API to decrypt it.

The following registry key is enumerated to steal Outlook data:

“SOFTWARE\Microsoft\Office\16.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676\”

Figure 17: Outlook registry key would have been enumerated to steal data from the infected machine

Figure 18: Network communication with server

The archive file cannot be found in any of the popular threat intelligence sharing portals like VirusTotal at the time of writing this blog.

Figure 19: File is not available on VirusTotal

This threat is detected by SonicWall Capture ATP w/RTDMI . Evidence of the detection by our RTDMI engine can be seen below in the Capture ATP report for this file.

Figure 20: Capture report

IOCs

Archive file
MD5: ca4797bf995c91864c8b290ebd4e1c7b
SHA256: 74f21472fed71aaccbd60b34615a8390725cbab6cb25bbc6a51bd723ff8bd01a

JavaScript (Initial vector)
Md5 : C235CE3765F9B1606BDA81E96B71C23B
SHA256 : E083662C896C47064FD47411D47459BF4B1CB26847B5D26AEDD7F9D701CABD43

Main 64-bit executable file
MD5 : 1E37C3902284DD865C20220A9EF8B6A9
SHA256 : F2D7CF39392D394D6CCD0F9372DB7D486D4CB2BB6C3BBFD0D8BFBB6117A5E211

Injected 64-bit Payload
MD5 : 95F51B48FB079ED4E5F3499D45B7F14E
SHA256 : C02BB26582576261645271763A17DE925C2D90D430E723204BAEC82030DC889A

Server IP : “45[.]9.74[.]12”

Overview

This week, the Sonicwall Capture Labs threat research team analyzed a new Golang malware sample. It uses multiple geographic checks and publicly available packages to screenshot the system before installing a root certificate to the Windows registry for HTTPS communications to the C2. There is currently no malware family affiliated, but the IP and URL addresses have been used by AgentTesla, GuLoader, PureLog Stealer and others.

Technical Analysis

The sample is detected as a Golang 64-bit executable with a WinAuth certificate. The timestamp has been tampered with, as it shows a creation date of December 31, 1969.

Figure 1: Sample detection with Detect It Easy

The certificate listed is issued from ‘RUNNINGWITHSCISSORS LTD’ but does not have an issuer signatory.

Figure 2: There is no signer, email or creation date with this certificate

Looking at the sample, one section included is non-standard, .symtab; this section is associated with ELF/Linux files and should not be on a Windows executable.

Figure 3: This is a Linux file-type section and would not be accessed by normal means

Because of the way Golang compiles binaries, the program had to have the gopcln table reconstructed in order to see the inner workings of the file.

Figure 4: Malware functions in cleartext

Once done, there are several items of note. Newly renamed functions list out the primary methods of . The strings show a pattern that looks to be used to send system information to the attacker – this is confirmed later. This pattern contains information for a system UUID, remote IP, username, hostname, Windows version, process ID, process name and architecture.

Figure 5: There is an ASCII pattern for information that may be sent to the attacker

Next, the packages reveal that the author is using public GitHub applications from the following repositories to generate and save screenshots:

• https://github.com/kbinani/screenshot
• https://github.com/lxn/win
• https://github.com/fogleman/gg
• https://github.com/golang/freetype

Figure 6: These GitHub packages are public and are not malicious on their own

During runtime, the malware will start by querying main system information using process injection via VirtualAlloc and running WMIC. The following two commands are run first:

• ‘SELECT UUID FROM Win32_ComputerSystemProduct’
• C:\Windows\System32\conhost.exe C:\Windows\system32\conhost.exe 0xffffffff -ForceV1

Next, these registry keys are queried for the Windows version and hostname:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
• HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters

When attempting to control/open WMIC, the sample looked in the following locations, as well as trying to find a file with an unusual name:

• C:\Users\user\Desktop
• C:\Program Files (x86)\Common Files\Oracle\Java\javapath\
• C:\Windows
  C:\Windows\system32
• C:\Windows\Wbem\

Figure 7: Sample of locations WMIC is searched for along with an unusual file

Once WMIC has been launched, both the main executable and WMIC will load, or attempt to load, the following DLLs:

Apphelp.dll
Cryptbase.dll
Winmm.dll
Powrprof.dll
Umpdc.dll
Userenv.dll
Profapi.dll
Netapi32.dll
Wkscli.dll
Netutils.dll
Samcli.dll
Samlib.dll
Iphlpapi.dll
Dhcpcsvc6.dll
Dhcpcsvc.dll
Dnsapi.dll
Mswsock.dll
Rasadhlp.dll
Fwpuclnt.dll
Msasn1.dll
Cryptsp.dll
Rsaenh.dll
Gpapi.dll
Framedynos.dll
Sspicli.dll
Kernel.appcore.dll
Wbemcomm.dll
Msxml6.dll
Urlmon.dll
Iertutil.dll
Srvcli.dll
Uxtheme.dll
Vcruntime140.dll
Vcruntime140_1.dll
Amsi.dll
Vbscript.dll
sxs.dll

The majority of these were not used during testing, which means that they may be used after initial contact is made with the C2 for further data collection or additional malware utilities.

Figure 8: Sample listing of DLLs searched for by the trojan

When the sample reaches out on the network, it attempts to get an IP using ‘ip-api.com/json’ and to make initial contact with the C2 at ‘https://daily-mashriq[.]org/goyxdrkhjilchyigflztv’ using a ping.

Once those steps are complete, the malware installs a new root certificate by overriding data in the following registry key using ‘CertGetCertificateChain’:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\3F728A35DE52B2C8994A4FB101A03B95E87B06C8

Figure 9: Previous data being overwritten by the new certificate

Although the main functions go into detail about screenshots, there are also API calls in memory for tracking other Windows events. These are monitored with SetWindowsHookExW and TrackMouseEvent. Screenshots are created using the GitHub packages previously mentioned.

Figures 10, 11: Code showing that the ‘kbinani’ takes the screenshot, then ‘fogleman’ saves it.

Network connection to ‘daily-mashriq[.]org’ is attempted with the previously discovered pattern containing information encoded with chacha20 and sent using User-Agent “AGCYRNRWWWFZZSWWFWDYDCVDN”:

Figure 12: Encoded information sent to the C2

However, after the initial message has attempted to POST, subsequent messages only include the UID and are sent every seven seconds.

Figure 13: Repeated POSTS only contain the UID

The following ports are also bound for listening: 49708-49711, 49720-49730, and 49733-49750.

As of this writing, it appears that the domain has been blocked by (CHECK THIS).

SonicWall Protections

SonicWall Capture Labs provides protection against this threat via the following signature:

• MalAgent.Go.Trojan

IOCs

• 8f4cf379ee2bef6b60fec792d36895dce3929bf26d0533fbb1fdb41988df7301
• https://daily-mashriq.org/goyxdrkhjilchyigflztv
• http://ip-api.com/json/

Overview

This week, the Sonicwall Capture Labs threat research team analyzed a ransomware calling itself Lighter Ransomware. Upon execution, it opens up a window with a countdown timer instructing the victim to reach out immediately before the timer ends – or face greater consequences.

Infection Cycle

The malware arrives as a portable executable that, once executed, immediately displays this warning window.

Figure 1: Lighter ransomware window with countdown.

It lets the user know that they have been infected with ransomware and displays instructions on how to get their files back. Interestingly, this ransomware only asks for $100.

However, most common keyboard shortcuts are blocked, which renders the system unusable once this window is displayed.

Figure 2: Functionality showing keyboard shortcuts being blocked

Common file utilities such as taskmanager, cmd, msconfig, regedit and processxp are blocked.

Figure 3. Functionality showing to kill taskmgr  

Files are then simultaneously encrypted using AES encryption, specifically, the RijndaelManaged class, and the malware adds the .L0cked extension to all encrypted files.

Figure 4: AES encryption functionality using the RijndaelManaged class

Figure 5: Encrypted files with the .L0cked file extension

This ransomware targets files with the following file extensions seen in the screenshot below:

Figure 6: File extensions targeted by this ransomware

Unless the user forces a reboot, they will be unable to do most common tasks while the warning window is displayed.

SonicWall Protections

SonicWall Capture Labs provides protection against this threat via the following signature:

• GAV: Lighter.RSM (Trojan)

This threat is also detected by SonicWall Capture ATP w/RTDMI and Capture Client endpoint solutions.

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:

• json
• js
• sqlite
• txt
• 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