BazarLoader Mocks Researchers in December 2020 Malspam Campaign

Preface

Our Inbox Detection and Response (IDR) team has observed a new BazarLoader campaign targeting the information technology, aeronautic and financial industries. The IDR team has successfully blocked over 550 thousand BazarLoader malspam emails throughout this campaign alone.

GoSecure researchers received a sample from the IDR team which was suspected of being BazarLoader, named Report Preview15-10.exe, on 2020-10-06. Shortly after, GoSecure researchers received yet another BazarLoader sample on 2020-10-08 named Document2-85.exe, which exhibited similar behavior.

Analysis

The initial infection vector, which has been observed by our Inbox Detection and Response Team (IDR), is via malspam containing fake employment termination notices and anonymous surveys. The threat actor(s) primarily use Google Drive and Google Docs to distribute their malicious payloads. The employment termination malspam was observed on October 6, 2020 and the anonymous survey malspam was observed on October 8, 2020. This can be seen in Figure 1 and Figure 2.

We will firstly analyze the employment termination malspam.

Once the user clicks the link, they will be redirected to
hxxps://docs[.]google[.]com/document/d/e/2PACX-1vR_9tGGWDcS1ZyIuiGpMQg2Sv9nRWempyUKuQ1iyJp_HHt1C87OPirnO7EImnOW6ILbrmHXUpl_OIxQ/pub to download an executable.

The executable Review_Report15-10.exe (3c27fca6d9cf1379eee93e6fea339e61) will appear as a
PDF document to users who do not have extensions enabled in Windows, as seen in Figure 3.

To help obfuscate its purpose, BazarLoader appears to be bound or obfuscated with legitimate resources from YUVPlayer (A Lightweight YUV player which supports various YUV formats). An example of this can be seen in Figure 4.

Once completed, it will then call kernel32.VirtualALloc to prepare injecting a PE executable for the next stage. To build the PE header, it will use the routine shown in Figure 7.

Once PE header has been partially copied (excluding MZ magic value), it will start to copy the .text section using the routine shown in Figure 8.

Once the .text section is copied, it will start resolving many different Windows APIs using kernel32.GetProcAddress.

When the additional APIs have been resolved, it will then make the .text section it copied earlier executable using kernel32.VirtualProtect, as seen in Figure 9.

NOTE: On different debugging sessions the virtual addressing changed during analysis.

Interestingly, the Portable Executable (PE) BazarLoader is copied into memory (without the MZ
header) and will start execution at the end of the .text section using a direct call. This can make unpacking the next stage confusing for reverse engineers as this is not where code in a PE file is supposed to begin. This code at the end of the .text section is solely responsible for making a call to the real Original Entrypoint (OEP) of the PE. It is important to note that this is simply used as shellcode and not as a PE in memory. The other benefit of this technique is no calls to thread related APIs are required, making it more challenging for Endpoint Detection and Response (EDR) solutions to detect. This can be seen in Figure 10.

After the previous trickery in the new memory space, it will start creating another PE in memory, but this time the header does start with the MZ magic value. After building the headers, it will copy each PE section one at a time, as seen in Figure 11.

Once the PE has been extracted to memory, it will make a direct call instead of using Threading APIs (same trickery as before). This can be seen in Figure 12.

BazarLoader’s stage 2 shellcode will make use of encrypted stack strings for many purposes
throughout the rest of its code.

Before it continues with its malicious activity, it will check if the locale is Armenian (0x2b). Interestingly, instead of shutting down gracefully when the Armenian locale is detected, it will execute a jmp instruction to an invalid address, causing an access violation exception. We have seen Russian crimeware checking for the Armenian keyboard layout previously in malware such as KPot, we hypothesize this could be similar behavior.

To avoid running more than one instance of itself, BazarLoader will create a mutex with a hard-coded UUID, then use kernel32.GetLastError to check for the error ERROR_ALREADY_EXISTS. If the mutex already exists, it will exit the process. The call to kernel32.CreateMutexA can be seen in Figure 13.

Interestingly, BazarLoader will check for mutexes twice.

Once completed, it will decyrpt its C2 configuration, as seen in Figure 14.

This HEAD request can be seen in Figure 16.

The C2 server will respond with a 200 OK message.

BazarLoader will also check if it is connected to the internet by making a request to microsoft[.]com, as seen in Figure 17.

Once completed, it will make a POST request to the second domain in its configuration, as seen in Figure 18.

Once completed, it will make a HTTP GET request in order to obtain the next stage, as seen in Figure 19.

Differences Between Versions

There are a few notable differences between the first version of BazarLoader sent on 2020-10-06 (Employment Termination Malspam) and the one sent on 2020-10-08 (Survey Malspam). The main difference between the two versions is the malware author(s) now include the string Stupid Defender to mock researchers, the shellcode that was stored in the .data section is now stored in the .rsc section, the functionality to get a pointer to the encrypted shellcode and to decrypt it have been broken out into their own separate functions. This can be seen in Figures 20 and 21.

Indicators of Compromise

Researchers

• Lilly Chalupowski
• Paul Neuman