A Deep Dive into Strela Stealer and how it Targets European Countries

Infostealers have dominated the malware landscape due to the ease of threat operations maintenance, and a wide group of potential victims. In this blog, we take a closer look at a unique infostealer designed to precisely target a narrow data set on systems located in chosen geographic locations.

The Strela Stealer (rus. Cтрела, lit. 'Arrow') is an infostealer that exfiltrates email log-in credentials and has been in the wild since late 2022. Strela Stealer is a precisely focused malware, targeting two email clients — Mozilla Thunderbird and Microsoft Outlook — on systems located in chosen European countries.

Through the years, attackers have delivered Strela Stealer to thousands of email users through a number of large-scale phishing campaigns, primarily targeting Spain, Italy, Germany, and Ukraine. The social engineering techniques used in the phishing campaigns have evolved. Recently, the threat actor behind Strela Stealer started forwarding legitimate emails containing invoices, but instead of the original invoice attachment, a ZIP archive containing the Strela Stealer malware loader was sent to unwitting victims.

As reported by IBM X-Force, it is believed Strela Stealer is operated by a single threat actor dubbed ‘Hive0145’. Notably, technical reports point to Strela’s command-and-control (C2) infrastructure belonging to Russian bulletproof hosting providers.

Aside from advances in the use of social engineering, Strela Stealer’s code and infrastructure have also undergone an evolution. Strela Stealer’s samples include custom multi-layer obfuscation and code-flow flattening to complicate its analysis. It has been reported that the threat actor potentially developed a specialized crypter called ‘Stellar loader’, specifically, to be used with the Strela Stealer.

In the next section, we take a deep technical dive into a sample of the newest Strela Stealer version that we identified during a recent phishing campaign targeting users in German-speaking countries. The phishing campaign took place at the turn of January and February this year.

Technical Analysis

Figure 1. Execution chain of Strela Stealer. Source: SpiderLabs.

Delivery

As previously mentioned, the sample was collected from a targeted phishing campaign. A crafted phishing email written in German was designed to resemble an invoice for a recent product purchase. The email encourages recipients to open the attached ZIP file under the pretense of verifying or processing a transaction.

Figure 2. Example of a phishing email with Strela Stealer attached. Source: nospamproxy.de

First stage

The ZIP archive contains a script file written in the JScript language. By default, once the script file is double-clicked, it will be read and executed by the Windows Script Host (wscript.exe) program on Windows-based systems.

Figure 3. ZIP archive with Strela Stealer loader. Source: SpiderLabs.

As seen in Figure 4, the script file is obviously obfuscated. The obfuscation technique is based on creating a set of variables with each holding a single character, then concatenating variables in a sequence to form the actual JScript payload and passing it into the eval() function.

Figure 4. Obfuscated JScript. Source: SpiderLabs.

Figure 5 depicts the same script after deobfuscation is performed by substituting eval() with the WScript.Echo()function. The actual script logic begins with definition of an array holding hardcoded values of the chosen Windows language code identifiers (LCIDs) — each language configurable on the Windows system is assigned with a unique numerical value. The array holds identifiers of German-speaking countries (except Belgium) i.e., Germany, Austria, Liechtenstein, Luxembourg, and Switzerland.

Then, the registry key HKCU\Control Panel\International\Locale is queried to retrieve the LCID of the local system. This value is matched against elements of the previously defined array inside a FOR loop (Figure 5: lines 13-18). Then, the conditional statement ensures that the script continues only if the system’s locale matches one of the array values or if the system is located in a German-speaking country.

Figure 5. Deobfuscated JScript. Source: SpiderLabs.

After a successful LCID verification, the script performs its main functionality, which is to execute the second-stage payload from the C2 server:

Figure 6. Hosted file 1909835116765.dll

The system connects to a public WebDAV file share and runs a hosted file, 1909835116765.dll, with regsvr32 utility without saving it on a disk. At the same time, a blurred PDF decoy is downloaded and displayed to allay the victim’s suspicions.

Second stage

This malware stage involves a packed DLL with no imports and a single exported function DllRegisterServer, which is invoked by the regsvr32 utility. The DLL is obfuscated with large blocks of unnecessary arithmetic operations that contain embedded meaningful instructions. Additionally, the control-flow flattening technique has been employed as there are no subroutines defined within the DLL; the code is contained in a single large function with multiple jump instructions.

Together, these techniques can significantly hinder the identification and analysis of actual loader logic. Given the size and complexity of the obfuscated assembly, Ghidra’s decompiler could not effectively decompile the code. Moreover, navigating the function graph proved impractical due to its sheer magnitude.

Figure 7. Binary obfuscation— a block of redundant arithmetic operations. Source: SpiderLabs.

Once run with regsvr32, the DLL steps over the process environment block structure to find the address of the kernel32.dll and two of its exported functions: GetProcAddress and LoadLibraryA. These two can be subsequently used to dynamically resolve any API function. This is a commonly used method for defense evasion, as no malware-indicative imports can be statically identified.

The program locates and calls VirtualAlloc to allocate memory for unpacking the final stage. The DLL’s .data section starts with the size of the final stage, followed by a decryption key that is over two thousand bytes long, and the encrypted final stage payload. The decryption key consists of byte values that map to ASCII characters, forming a lengthy string; however, it is not used in a text-processing context, and may mislead an analyst.

Figure 8. Final stage size and decryption key. Source: SpiderLabs.

The code and data of the final stage are XOR-decrypted and written to the previously allocated buffer with a stripped PE-header. Later, the import address table of the final-stage payload is reconstructed. Once the unpacking process is completed, the second stage DLL forwards execution to the original entry point in the allocated memory with a CALL RCX instruction.

Final stage

Similar to the previous stage, the actual Strela Stealer code is highly obfuscated. In addition to unnecessary arithmetic operations and control-flow flattening, the code is obfuscated with opaque predicates and redundant fiber manipulation to complicate analysis, especially with a debugger.

At several points, the code follows the same pattern of iterating over a table of addresses while consecutively loading them to a RAX register and executing with a JMP RAX instruction. This hampers the analysis of the execution order, decompilation, as well as outlining of the cross-reference relationships between functions. Additionally, it stretches analysis time since such tables may be lengthy and include pointers to junk code.

Figure 9. Final stage size and decryption key. Source: SpiderLabs.

A notable anti-analysis technique in the analyzed sample involved the use of fibers and a fiber local storage (FLS) index. A fiber is a unit of execution that runs in the context of the thread that schedules it. A thread may switch between fibers; however, it may only run one fiber at a time. FLS provides an index with values that are unique for each fiber. To initiate an index, one needs to call FlsAlloc() with an optional parameter being an address of a callback function. According to Microsoft’s documentation: “[…] FlsCallback is called on fiber deletion, thread exit, and when an FLS index is freed”. This sample repeatedly allocates FLS index with the address of a junk subroutine as a callback, and later on, it frees up the index (FlsFree) that invokes the callback. This leads to multiple threads executing redundant code, which hinders the analysis.

Interestingly, the SetUnhandledExceptionFilter API function, which is commonly used to detect whether a running process is being debugged, was called but not effectively used to exit from the debugged process. The stealer passed a redundant subroutine as the lpTopLevelExceptionFilter parameter, which did not affect program flow in a meaningful way.

In the final stage, Strela Stealer performs an additional verification of the system’s locale. It retrieves the installed input locales with the GetKeyboardLayoutList and GetLocaleInfoA APIs. The program then compares the retrieved LCIDs against hardcoded values. If there is a match, it continues to the subroutine responsible for data exfiltration; otherwise, it terminates. Figure 9 presents the assembly code from the sample that performs LCID verification. This particular sample is intended to run in Spain, Germany, Italy, Poland, and Ukraine.

Figure 10. Input locale verification. Source: SpiderLabs.

After successfully confirming the locale, the program initiates its information-stealing activities. It first searches the contents of Mozilla Thunderbird’s profiles subfolders, which are located at %APPDATA%\Thunderbird\Profiles, for the files key4.db and logins.json. If these files are found, their contents are encrypted and sent via an HTTP POST request to the endpoint at hxxp://193[.]143[.]1[.]205/up.php. The user-agent for this request is set to a unique identifier for the host, specifically the volume GUID of the system’s folder. Strela Stealer waits for a server response, checking with InternetReadFileA() in a loop, and pausing for one second with Sleep() between attempts.

Subsequently, the program queries the system’s registry to check if one of the following keys holding Microsoft’s Outlook profile data is present:

• HKCU\Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
• HKCU\Software\Microsoft\Windows Messaging Subsystem\Profiles\9375CFF0413111d3B88A00104B2A6676
• HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676"

If found, the program reads "IMAP User", "IMAP Server", and "IMAP Password" registry values and decrypts them with the use of the CryptUnprotectData API function. This data is exfiltrated to the C2 server in the same way as above.

Figure 11. Hardcoded strings used to search for email clients’ profile data. Source: SpiderLabs.

Next, the stealer gathers information about the local system by running systeminfo with ShellExecuteExA with the following command:

Figure 12. command used to run systeminfo with ShellExecuteExA.

It also utilizes SHGetKnownFolderItem to retrieve the list of installed applications from the "AppsFolder" on the machine. All of this information is exfiltrated in the same fashion as discussed above.

Figure 13. Exfiltration of the list of locally installed apps. Source: SpiderLabs.

IoCs

• Filename: 1692630503222433608.js
• Filename: 1909835116765.dll
• SHA256: f5c54fce6c9e2f84b084bbf9968c9a76d9cd74a11ccf4fcba29dbe2e4574e3d7
• SHA256: 9c49266e315eb76ce73cbe542cfd2bbf28844689944ac8776daecbdcdecd8cf8
• SHA256: 31389cb2f067020f181462bab3519c22fd88da084012729e9edf79d15427b86f
• IP: 193.143[.]1.205
• URL: hxxp://193.143.1.205/invoice.php
• URL: hxxp://193.143.1.205/up.php

Infrastructure

In line with findings from other technical examinations of Strela Stealer, this sample's C2 server is part of a Russian bulletproof hosting network. Specifically, it belongs to the notorious Proton66 OOO autonomous system (AS 198953), which is an anonymous network based in Saint Petersburg used in various malware campaigns, not just those related to Strela Stealer.