• Skip to primary navigation
  • Skip to main content
  • Skip to footer
lab52

lab52

The threat intelligence division of S2 Grupo

  • Home
  • Faq
  • Blog
  • About
  • Contact

Let’s talk about the malware used by Mustang Panda

May 05, 2023

In the last post, Lab52 covered the new Mustang Panda’s campaing against Australia.  Now is time to talk about the malware used by the APT group Mustang Panda in said campaing. 

Indeed, the malware used to commit the attack is not enterely new; there are previous reports from TrendMicro and Talos where similar tactics and procedures are detailed. However, some parts highlighted below differ and should be known in order to prepare our detection systems. 

Summarizing, this post covers the following aspects:

  • Continues the previous post, from a “malware” perspective, detailing the piece of malware used in this campang.
  • The encryption algorithm using during the Stage 2 is different from those observed in similar reports.
  • Both shellcodes for Stage 2 and 3 are considered new artifacts.
  • There are two commands used by the shellcode in Stage 3 identified during the analysis.

Stage 1: Execution and persistence

This analysis starts with a zip file called “Biography of Senator the Hon Don Farrell.zip”. As mentioned in the previous article, Hon Don Farrell is the current Secretary of State for Trade and Tourism of Australia.

The zip file contains two files. On one hand, there is a legitimate application for processing PDF files called Solid PDF Creator, renamed as “Biography of Senator the Hon Don Farrell/Biography of Senator the Hon Don Farrell.exe”. On the other hand, we have identified a malicious payload named SolidPDFCreator.dll. The artifact is executed using the Dll Side Loading technique.

FileHash
Biography of Senator the Hon Don Farrell/Biography of Senator the Hon Don Farrell.exee2acbc36c2cce4050e34033c12f766fea58b4196d84cf40e979fac8fed24c942
SolidPDFCreator.dll3c4671b4a0c3e7da186bd356e07cf0daca7267addde668044b1ded42c6dbe09b
Files used by the malware

Once executed, the payload will check if it is located in the path “C:\Users\Public\Libraries\PhotoTvRHD“. If not, it will create the folder and copy the contents of the zip file into it.

Check for the binary
Operation to write the file in the path

Furthermore, the following command is executed, which adds persistence, copies the DLL to the correct path, and creates a scheduled task that executes the payload every minute in that location.

C:\Windows\SysWOW64\cmd.exe /C copy SolidPDFCreator.dll C:\Users\Public\Libraries\PhotoTvRHD\SolidPDFCreator.dll & reg add “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run” /v SolidPDF /t reg_sz /d “C:\Users\Public\Libraries\PhotoTvRHD\SolidPDFCreator.exe” /F & schtasks /F /Create /TN SolidPDF /SC minute /MO 1 /TR C:\Users\Public\Libraries\PhotoTvRHD\SolidPDFCreator.exe
Command executed

In the event that it is located in the correct path, the payload will decrypt a shellcode and execute it. During the realization of this investigation, this shellcode has not been found published.

Hash of the first shellcode (used during stage 2)
8059E00CFB899B5BCDE4607AFB6858A922C71AEA1D744EFBE93D922868C34489

Stage 2: Downloader disguised as Microsoft update

The shellcode employs well-known anti-analysis techniques, such as using the ror13 hashing algorithm to resolve DLLs and functions.

Hashing algorithm ror13 used by the malware

Moreover, it uses the kernel32 functions GetProcAddress and LoadLibraryA, and gets the addresses for a list of functions listed at the end of this post.

GetProcAddress and LoadLibrary

The shellcode will create a socket to port 80 of the malicious IP address 123.253.35[.]231. It will then send an HTTP request that uses legitimate headers, attempting to impersonate common Microsoft update communications.

Extract of the communication with the C2

The body of the message contains a base64-encoded string. It uses a protocol identical to the one seen in the TrendMicro report. It is as follows:

17 03 03 + <payload size> + <payload>
Protocol used by shellcode

The above protocol will be present in all base64-encoded strings exchanged between the victim and the C2. In this particular request, the payload being sent contains the following information.

<tick count> + <computer name> + <username>
Packet information sent by the first shellcode
Contents of the payload before encryption

Next, the payload content will be encrypted with the following key:

78 5a 12 4d 75 14 14 11 6c 02 71 15 5a 73 05 08 70 14 65 3b 64 42 22 23 20 00 00 00 00 00 00 00

It should be noted that although this key is identical to the one used in the Talos report, the algorithm used is different. An implementation of the protocol in Python can be found at the end of this post. In this case the algorithm used for encryption is based on applying XOR four times. In this algorithm, the XOR operation is used to encrypt the data in the “original” array with the data in the “key” array in a four-step iterative process. Each step is performed using a different position in the “key” array, making it harder to decipher.

XOR-based Encryption algorithm

Note that the previous algorithm has some similarity with the RC4 encryption, which is also a symmetric stream cipher. Both ciphers use the XOR operation to combine the data with a sequence of bytes generated from a shared secret key.

However, there are some significant differences between the algorithm analyzed in this report and the RC4 encryption. In the algorithm under consideration, four iterative cycles are used to combine the data with the secret key, while in the RC4 encryption, a single iterative cycle is used. Additionally, RC4 encryption is a stream cipher algorithm that generates a pseudo-random byte sequence using an internal state table, while in the algorithm you shared, the byte sequence is obtained directly from the secret key.

Using the above information, the C2 will return a second shellcode.

Payload sent by the C2

During the realization of this investigation, this shellcode has not been found published.

Hash of the second shellcode (used during stage 3)
E184F099957C27A04ADF2F5F46772D0FD86B27084CBDDCDEAC5EB7CFA23604F7

Stage 3: Communication with the C2

This second shellcode is very similar to the first one and also uses the same hashing algorithm to resolve functions.

API hashing used by the malware

Analogous to the TrendMicro report, this variant has several functionalities.

Function in charge of executing the commands received from c2

Most of the commands identified correspond to those listed in this TrendMicro report from March, with the exception of 0x05 (keep alive) and 0x20 (close shell). The following table summarises a list of commands used by the shellcode.

ValueDescriptionTrendMicro report
0x05Keep Alive*–
0x03UnknownUnknown
0x01UnknownUnknown
0x1bBegin uploadUploadBegin error: %d!
0x1DData uploadUploadData error:%d!
0x1AUnknownUnknown
0x1Ecmd startCmdStart error:%d!
0x1Fcmd writeCmdWrite error:%d!
0x30cmd readCmdWrite error:%d!
0x20Close shell*Unknown
List of shelcode commands. *: found during this research

The shellcode is used to obtain a shell on the victim’s computer. It uses pipes to read and write commands from it. To achieve this, it uses the CreatePipe function.

Creation of pipes

Unlike the previous stage, the shellcode no longer impersonates www.asia.microsoft.com. Instead it uses www.download.windowsupdate.com.

HTTP request for this stage

On each request the last 25 characters of the URL are changed to random characters using a call to CryptGenRandom.

Algorithm used to generate random URLs

Conclusions

Since there were already different articles that extensively detailed similar malware to that used in the targeted campaign, it was desired to verify if the malware samples used in the new campaign significantly varied their operation compared to the previous reports. During the analysis, it was observed that the malware authors have changed the encryption algorithm and some aspects slightly, without drastically modifying the malware or improving its operational security. This has several implications, but at least the most immediate ones are: (1) cybercriminal groups can still cause impact with samples that should be identified by detection systems, and (2) sometimes slight modifications are enough to make detection and analysis more complicated. Through this post, we aim to minimize the second point.

Summary of functions used in the shellcodes

First shellcode (stage 2)

Kernel32User32Ws2_32advapi
VirtualAllocMessageBoxAWSAStartupGetUserNameA
VirtualProtectwsprintfAgethostbyname 
VirtualFree inet_ntoa 
Sleep WSAGetLastError 
GetComputerNameA socket 
GetVolumeInformationA closesocket 
GetTickCount shutdown 
  htons 
  inet_addr 
  recv 
  send 
  connect 
  setsockopt 

Second shellcode (stage 3)

Kernel32User32Ws2_32advapi
CloseHandleMessageBoxAWSAStartupCryptAcquireContextA
GetLastErrorMessageBoxWgethostbynameCryptGenRandom
VirtualAllocwsprintfAinet_ntoaCryptReleaseContext
VirtualFreewsprintfWWSAGetLastErrorRegOpenKeyExA
VirtualAllocEx socketRegQueryValueExA
VirtualFreeEx closesocketGetUserNameA
VirtualProtect shutdown 
Sleep htons 
CreateMutexA inet_addr 
OpenMutexA recv 
WriteProcessMemory send 
CreateFileA connect 
CreateFileW setsockopt 
GetFileSize   
SetFilePointerEx   
ReadFile   
WriteFile   
DeleteFileA   
DeleteFileW   
GetFileAttributesA   
GetFileAttributesW   
GetModuleFileNameA   
GetModuleFileNameW   
GetModuleHandleW   
CreateToolhelp32Snapshot   
Process32FirstW   
Process32NextW   
OpenProcess   
CreateProcessA   
CreateProcessW   
CreateThread   
CreateRemoteThread   
WaitForSingleObject   
GetDriveTypeA   
GetDiskFreeSpaceExA   
GetLogicalDriveStringsA   
GetNativeSystemInfo   
GetComputerNameA   
GlobalMemoryStatusEx   
Wow64DisableWow64FsRedirection   
Wow64RevertWow64FsRedirection   
OutputDebugStringA   
OutputDebugStringW   
TerminateProcess   
LocalAlloc   
LocalFree   
lstrcmpW   
CreatePipe   
PeekNamedPipe   

Indicators of Compromise (IOCs)

Hash DescriptionAccess
e2acbc36c2cce4050e34033c12f766fea58b4196d84cf40e979fac8fed24c942Legitimate exePublic
3c4671b4a0c3e7da186bd356e07cf0daca7267addde668044b1ded42c6dbe09bMalicious dllPublic
8059E00CFB899B5BCDE4607AFB6858A922C71AEA1D744EFBE93D922868C34489First ShellcodePrivate
E184F099957C27A04ADF2F5F46772D0FD86B27084CBDDCDEAC5EB7CFA23604F7Second ShellcodePrivate
DomainsStage
www.asia.microsoft.comStage 1
www.download.windowsupdate.comStage 2

Python helper functions for protocol decryption and encryption

import base64
import struct

key=bytearray([0x78, 0x5a, 0x12, 0x4d, 0x75, 0x14, 0x14, 0x11, 0x6c, 0x02, 0x71, 0x15, 0x5a, 0x73, 0x05, 0x08, 0x70, 0x14, 0x65, 0x3b, 0x64, 0x42, 0x22, 0x23, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00])

def cipher_xor(message, key):
    key_length = len(key)
    length = len(message)

    for i in range(length):
        message[i] ^= key[(i + 1) % key_length] ^ 0xff

    for i in range(length):
        message[i] ^= key[(i + 9) % key_length] ^ 0xff

    for i in range(length):
        message[i] ^= key[(i + 4) % key_length] ^ 0xff

    for i in range(length):
        message[i] ^= key[i % key_length] ^ 0xff
    
    return message

def decipher_payload(message):
    msg=bytearray(base64.b64decode(message))[5:]
    
    return cipher_xor(msg,key)

def cipher_payload(message):
    header=bytearray([0x17, 0x03, 0x03])
    size=len(message)

    return base64.b64encode(header + struct.pack('>H',size) + cipher_xor(bytearray(message),key))

3722304989

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Related

Mustang Panda’s PlugX new variant targetting Taiwanese government and diplomats
December 11, 2023
Tags: MustangPanda, PlugX, SmugX
New Mustang Panda’s campaing against Australia
May 03, 2023
Tags: MustangPanda
DLL Side Loading through IObit against Colombia
May 28, 2024
Tags: AsyncRAT, Colombia

Footer

Copyright &copy Lab52 2019 by S2 Grupo | Legal notice | Cookie policy | Privacy policy