One of our German clients was recently informed by an administrator from another company that invoice emails containing malware were being sent using our client’s email templates.

Upon initial investigation, it was discovered that the customer and invoice numbers in the malicious emails belonged to a legitimate customer of our client. This indicates that the threat actor likely obtained an original email through the compromise of a customer’s email account and used its content to launch their malicious campaign.

The reporting administrator provided us with the entire email, including the malicious attachment, for further analysis.

Through this, we were able to thoroughly investigate and uncover the infection chain.

First stage (initial loader)

The phishing email closely mimicked the legitimate invoice email of our client, with one key difference: the attachment was a ZIP file instead of a PDF.

The ZIP file contained a single obfuscated JavaScript file: 1599224702180799937.js.

The JavaScript file employed obfuscation through variable substitution. By using a script to replace all variables with their respective string values, we could reveal that the loader targeted Windows systems.

When the user clicks on the .js file, it is executed by wscript.exe, the default interpreter for such files in Windows.

Actions Performed by the Loader

1. Locale Check: The loader examines the victim’s system language by querying the registry key HKEY_CURRENT_USER\Control Panel\International\Locale. If the locale does not match a German-speaking LCID (as defined by Microsoft's Documentation), the loader terminates.
2. Fake Invoice Display: A fake invoice is downloaded to the user’s temporary directory and opened with the default PDF viewer. The blurred appearance of the document simulates a "still loading" effect.
3. WebDAV Connection: The loader mounts a WebDAV share at http://193.143.1.205:8888/ using the net use command.
4. DLL Execution: A malicious DLL (54281035428258.dll) is loaded from the WebDAV share using regsvr32.

Second stage: DLL

Looking at the entropy of the .dll, one can obviously see that the .dll is a packer and drops the actual payload.

After loading the DLL, regsvr32 calls the entrypoint DllRegisterServer. The binary resolves function addresses by iterating over the InLoadOrderModuleList of the PEB.
By putting a breakpoint on VirtualAlloc one can get the memory where the decrypted payload is written to.

However, the packer seems to write the payload in two steps:

1. it first writes all sections, starting with the .text section to the RWX memory
2. then, writes the PE header to it

But it also substitutes the decrypted bytes of the payload in the .data section with the decrypted ones. Thus, one is able to dump the PE by putting a breakpoint below the decryption loop.

After dumping the unpacked PE from memory. We uploaded it to Virustotal where the sample matches on the Strela signature.

Third Stage: Strela Stealer variant

Analyzing the dropped PE, it is obvious that the malware is a packed variant of the Strela Infostealer, which is a malware designed to steal sensitive information, mostly mail accounts from Thunderbird or Microsoft Outlook.

Campaigns using Strela are typically targeting specific countries. Hence, we took a look at the beginning of the malware to find out which countries the threat actor has targeted.

It fetches the user's default locale and then checks wether it is AU or UA.

It only continues when the victim seems to be either in Australia or Ukraine. The C2 server is located in russia it leads us to the conclusion, that the threat actor is in connection with the russian war of aggression against Ukraine. Hence, we suppose that the threat actor only checks for AU because the actor is not sure about the endianess.

Since Strela usually sends the stealed information to a single hardcoded server using HTTP POST, we firstly searched for the upload routine and the strings.

The upload routine obviously connects to the IP which is found in the region containing the strings:

All stealed information gets uploaded to http://193.143.1.205:80/up.php with POST requests using the Windows Internet API wininet.

The server seems to be located at Proton66 OOO, a russian bulletproof hosting service.

Looking at the core logic, the malware will

1. fetch mail accounts from Thunderbird by looking for logins.json and the key4.db files and upload them to the server
2. fetch Outlook IMAP accounts by iterating over all potential registry keys and upload them to the server
3. finally fetch information of the victim's computer using systeminfo.exe and upload it to the server

The Campaign

The threat actor's campaign seems to be still active since the server (193.143.1.205) still delivers the second stage payload and our client got an phishing mail yesterday containing a variant of Strela which connects to the same server.

We recommend to

1. block ZIP-attachments containing .js-files
2. blacklist the threat actor's server at 193.143.1.205

IOCs