In March 2020, ThreatLabz observed several Microsoft Office PowerPoint files being used in the wild by a threat actor to spread AZORult and NanoCore RAT. The malicious files in this campaign used an interesting payload delivery method that distinguishes it from the common malware delivery methods observed on a daily basis. The infection chain is modular, with multiple stages involved before the final payload is executed on the machine.

Since the last week of March 2020, we observed a few changes in the encoding method and the macro code used in the loader, which we will also describe in this blog.

This campaign is active in the wild at the time of this writing.

We provide a technical description of the infection chain and the unique indicators found in the files, which we used to categorize the loader with a specific name. We also used the unique delivery method used in this campaign, along with other attributes, to correlate this threat actor to the Aggah campaign, which was documented in April 2019 by Unit 42.

The older instances of the campaign in 2019 were used to spread the Revenge RAT. In the new instances, we have observed a few changes in the campaign in addition to the type of final payload delivered.

Email delivery method

The malware delivery method in this campaign involves sending Microsoft Office PowerPoint files as attachments to the users. An example of the email is shown in Figure 1.

Email sent to users in Indonesia

Figure 1: An email targeting users in Indonesia.

Figure 2 shows two more email samples that show the threat actor targeting users in South Korea.

Email targeting South Korean users

Figure 2: An email targeting South Korean users with an analysis report theme.

Figure 3: An email targeting South Korea users with a business proposal theme.

Based on the analysis of the email content and email headers, we concluded that this threat actor has been actively targeting users in the Asian subcontinent, specifically South Korea and Indonesia. The content of the emails varies from business proposals to product price negotiations.

Technical analysis of the multistage loader

We will take a Microsoft Office PowerPoint file as an example to demonstrate the infection chain and the various steps involved in it.

The MD5 hash for this is: 0b0b570451b699d96c70ebf400628caa.

Macro-based downloader [Stage 1]

The PowerPoint file contains a macro that leverages mshta to download the next stage payload from Pastebin. Auto_Close() in the macro ensures that the malicious code is executed only when the file is closed.

All the instances we observed in March 2020 were using j.mp as the shortened URL service to download the next stage payload.

The relevant macro code is shown in Figure 4.

Macro code in MS Office file used to download next stage.

Figure 4: The macro code in the Microsoft Office file used to download the next stage.

The shortened URL redirects to the Pastebin URL: hxxps://pastebin[.]com/raw/rsbLNHJg, which contains the encoded next stage. We can see in Figure 5 that this Pastebin account belongs to the username LUNLAYLOO.

pastebin1

Figure 5: The encoded content of the next stage hosted on Pastebin.

Figure 6 shows a screenshot of the Pastebin account hosting this content. All the content hosted by this user on Pastebin is set to private.

pastebin2

Figure 6: All the pastes under the username Lunlayloo on Pastebin are set to private.

Among all the samples we analyzed in this campaign, the Pastebin accounts that were used to host the multiple stages belonged only to three individuals (listed below) and they were re-used across all the samples.

lunlayloo
redcobalt
gogga7

JavaScript loader [Stage 2]

With the help of a macro, it downloads an encoded VBScript from Pastebin as shown in Figure 7.

stage1_encoded

Figure 7: The obfuscated JavaScript downloaded by the macro.

The encoding method used was consistent across all the samples we observed in March 2020. In the newer variants seen in the wild, we observed a few changes in the encoding method, which we will describe later in this blog.

The URL-encoded text was decoded using the unescape() function.

The decoded script is a VBScript as shown in Figure 8.

stage1_decoded

Figure 8: The decoded VBScript used to download the next stage and start the infection chain.

The main operations performed at this stage are:

It creates a scheduled task with the name Pornhub. This task leverages mshta to download the next stage payload from Pastebin as well. We observed the scheduled task name set to Pornhub in all the samples used in this campaign, which is another indicator we used to correlate the samples.
The same command that was scheduled in step 1 is also immediately executed to start the infection chain.
It creates the following three Windows registry keys for persistence (used for the backup plan as the name indicates) to ensure that the infection chain begins once the machine is restarted.

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\BACKup2
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\BACKup3
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\

The fact that this VBScript ensures that a scheduled task is created and three backup Windows Registry keys are created for persistence indicates that the attacker took extra measures to ensure that the infection chain starts on the machine.

VBScript leverages PowerShell [Stage 3]

In Stage 3, another encoded VBScript is fetched from Pastebin as shown below.

stage2_encoded

Figure 9: The encoded VBScript downloaded in Stage 3.

This VBScript, once decoded, looks as shown in Figure 10.

stage2_decoded

Figure 10: The VBScript uses PowerShell to load .NET assemblies.

As we can see in the decoded VBScript, it leverages PowerShell to continue the infection chain.

Below are the main operations performed by the PowerShell command line:

Set the TLS version to 1.2 by setting SecurityProtocolType to 3072.
Download a Base64 encoded blob from Pastebin. This Base64 encoded blob decodes to another PowerShell script as shown in Figure 11. The script is executed by calling IEX (Invoke Execution). We will describe this script in more detail later.

PowerShell code

Figure 11: The PowerShell code that is used to decompress the .NET loader.

It then downloads another payload from Pastebin. This payload contains the hex representation of the binary code with the characters “K_E” instead of “0x” as shown in Figure 12. By performing a simple replace operation, this payload is passed as a byte array to the function: [Givara]::FreeDom(). We will refer to this payload as payload2.

Encoded Loader Download

Figure 12: The encoded malicious binary downloaded from Pastebin.

The MD5 hash of the payload is: 60221d709e0ad65bb23bd00a3977c55d

This corresponds to the AZORult Delphi binary file. We will not be describing the functionality of this binary in detail in this blog since it is a well-known infostealer. The strings are available in plain text and the screenshot in Figure 13 shows the strings corresponding to information it steals (Skype, Telegram, Steam, cryptocurrencies, Pidgin and others).

AZORult Infostealer

Figure 13: The Unicode strings in the binary file that corresponds to the information stolen.

Across all the samples we observed in this campaign, the final payload varied between AZORult and NanoCore infostealer binaries.

We observed that the function name [Givara]::FreeDom() in the loader was consistent across all the samples.

The function name appears to be a reference to Che Guevara who is remembered as a freedom fighter by many.

PowerShell starts the FreeDom loader [Stage 4]

Let's take a look at the PowerShell script, which was downloaded in step 2 of stage 3. This PowerShell script contains a GZip compressed .NET binary, which will be decompressed and stored in the variable $decompressedByteArray

Stage 3 will reference the variable $decompressedByteArray to load it as a .NET assembly using the method [System.Reflection.Assembly]::Load().

The MD5 hash of the loader is: c726636d2b7f8c838f7f882071181c95.

The method [Givara]::FreeDom() is defined in the .NET loader and it is used to load the infostealer malicious binary (in this case, AZORult).

So the payload execution is triggered using the following syntax:

Guevara_Loader. [Givara]::FreeDom(‘notepad.exe’, infostealer_binary)

Here, Guevara_Loader refers to the .NET binary used to load and inject the final infostealer binary in the notepad.exe process.

It is important to note that there were no changes made to the loader binary by the threat actor throughout the campaign.

FreeDom .NET loader analysis

The .NET loader binary is protected using the Confuser Ex 1.0.0 obfuscator.

On VirusTotal, the first instance of the loader was observed on January 16, 2020.

After removing the Confuser Ex 1.0.0 protection, we can decompile the binary successfully.

The [Givara]::FreeDom function, which is passed the string, notepad.exe and the AZORult binary, is shown in Figure 14.

Main function of FreeDom loader

Figure 14: This is the main function of the FreeDom loader.

The parameters for FreeDom function are as follows:

FTONJ – A string called notepad.exe

Coco – The byte array corresponding to the AZORult binary

The HeHe class checks for the presence of notepad.exe in different system paths on the machine. Once it locates the file, it passes that to the tickleme() function along with the AZORult byte array as shown in Figure 15.

HeHe Class

Figure 15: It check for the presence of notepad.exe and injects the AZORult binary into it.

The tickleme() function, in turn, calls a function called FUN(), which is responsible for starting a new instance of the notepad.exe process and injecting the AZORult binary into it using the process hollowing method.

Macro code changes in new variants

The newer variants in this campaign updated the encoding method and the macro used.

As an example, let us look at a macro-based PowerPoint file with MD5 hash: 7db36d502e4a1d35873c8a0c51bafbbf

The newer variant of the macro is as shown in Figure 16.

Macro code new variant

Figure 16: The macro code in the new variant.

In this new variant, the macro creates a Windows persistence key in the location: HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\ and adds the command line to leverage mshta to download the malicious next stage payload.

As a result, the infection chain does not start unless the machine is rebooted.

Also, we observed the macro using the bit.ly URL shortening link directly instead of the j.mp URL shortening link observed in the previous variant.

Encoding changes in the new variant

The other key change we observed in the new variant is in the script encoding used for each stage. In the previous variant, the encoding method was simple because it just involved URL encoding and the unescape() function was called to decode it.

An example of the new encoding method is as shown in Figure 17.

encoding new variant

Figure 17: The JavaScript code using a new encoding method for multiple stages.

This method calls eval() two times. The first eval() call corresponds to the JavaScript function, which is responsible for XOR decryption. The second eval() call corresponds to executing the script decrypted by the first eval() call.

The XOR decryption stub is as shown in Figure 18.

XOR Decryption Routine

Figure 18: The XOR decryption script.

Changes in the final payload

The final payload downloaded in the newer variants is a NanoCore RAT unlike AZORult or Revenge RAT observed in previous instances of the campaign. In this specific example, the MD5 hash of the NanoCore payload is: 35de5c352023db9d406a835ef7f318e5.

We mention briefly how the NanoCore RAT is encrypted here.

The .NET assembly contains a bitmap image in the resource section as shown in Figure 19.

encrypted resource

Figure 19: The bitmap resource inside the .NET binary.

The bitmap image is accessed from the resource with the name “WinForms.Library.Properties.Resources”. The encrypted .NET assembly is extracted from the pixels of the bitmap image. This encrypted assembly is decrypted using an XOR decryption routine and finally loaded using the Assembly.Load() method.

The relevant code sections are shown in Figure 20.

Nanocore stage1 decryption

Figure 20: Extracting, decrypting and loading the .NET assembly.

The next stage .NET assembly is a loader that is used to decrypt the final .NET assembly, which is injected into another process and executed.

Figure 21 shows the configuration of the next stage .NET assembly.

Main configuration of next stage

Figure 21: The main configuration of the .NET loader.

The final payload is encrypted and stored inside a resource with the name “OSkRTM8”. This payload is decrypted as shown in Figure 22.

Payload Decryption

Figure 22: Payload decryption.

This decrypted payload is injected as shown in Figure 23.

Code injection invocation

Figure 23: The code injection invocation.

The MD5 hash of the injected payload is: 7679fec5f6bf7206635b96efa52d1d07.

Below are relevant strings from the binary which indicate it is NanoCore.

00000000FEF5 000000411CF5 0 NanoCore Client

00000000FF05 000000411D05 0 NanoCore Client.exe

And the configuration used by this instance of the NanoCore RAT is shown in Figure 24.

Nanocore Configuration

Figure 24: The NanoCore RAT configuration file.

The C&C server is listening on port 54932 at the IP address 216.170.114.4.

Cloud Sandbox detection

Figure 25 shows the Zscaler Cloud Sandbox successfully detecting this PowerPoint-based threat.

Cloud Sandbox detection

Figure 25: Zscaler Cloud Sandbox detection.

In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels.

Conclusion

This threat actor combines multiple stages in the infection chain to make detection difficult over the network. The tactics, techniques and procedures (TTPs) used by this threat actor are also evolving with time.

As an extra precaution, users should not enable macros for Microsoft Office files that are received from untrusted sources since these macros have the capability to run malicious code on your machine.

The Zscaler ThreatLabZ team will continue to monitor this campaign, as well as others, to help keep our customers safe.