China-nexus Threat Actor Targets Persian Gulf Region With PlugX

Introduction

On March 1, 2026, ThreatLabz observed new activity from a China-nexus threat actor targeting countries in the Persian Gulf region. The activity took place within the first 24 hours of the renewed conflict in the Middle East. The threat actor quickly weaponized the theme of the conflict, using an Arabic-language document lure depicting missile attacks for social engineering.

The campaign used a multi-stage attack chain that ultimately deployed a PlugX backdoor variant. Based on the tools, techniques, and procedures (TTPs) observed, ThreatLabz attributes this activity to a China-nexus threat actor with high confidence, and assesses with medium confidence that it may be linked to Mustang Panda.

In this blog post, ThreatLabz examines the end-to-end attack chain in depth, including Windows shortcut (LNK) and CHM-based droppers, a loader with highly obfuscated shellcode, and a PlugX backdoor.

Key Takeaways

• In March 2026, ThreatLabz observed activity by a China-nexus threat actor targeting countries in the Persian Gulf region.
• The campaign used a multi-stage attack chain to deploy a PlugX backdoor variant on infected systems.
• The shellcode and PlugX backdoor used obfuscation techniques such as control flow flattening (CFF) and mixed boolean arithmetic (MBA) to hinder reverse engineering.
• The PlugX variant in this campaign supports HTTPS for command-and-control (C2) communication and DNS-over-HTTPS (DOH) for domain resolution. 

Technical Analysis

Attack chain

On March 1, 2026, ThreatLabz identified an attack chain themed around the ongoing Middle East conflict that delivered its payloads via a ZIP archive. The archive included a Windows shortcut (LNK) file that, when opened, downloaded a malicious Windows Compiled HTML Help (CHM) file from a threat actor-controlled server. The CHM content was then leveraged to deploy a multi-stage payload, progressing from a shellcode loader to heavily obfuscated shellcode, and ultimately to the installation of a PlugX backdoor variant. The attack chain is shown in the figure below.

Figure 1: Attack chain leading to deployment of PlugX.

As part of the lure, the attack dropped a decoy PDF containing images of missile strikes. The Arabic text in the PDF translates to “Iranian missile strikes against US base in Bahrain”. The figure below shows the decoy PDF file used in this attack.

Figure 2: PDF lure referencing Iranian missile strikes against a US base in Bahrain.

The following sections summarize the observed attack flow and the files involved.

Stage 1 (ZIP, CHM, and LNK)

The ZIP archive contains an LNK file named photo_2026-03-01_01-20-48.pdf.lnk. The LNK’s target command line uses cURL to download a malicious CHM file from hxxps://www.360printsol[.]com/2026/alfadhalah/thumbnail?img=index.png. The LNK file then uses the legitimate Windows HTML Help executable (hh.exe) with the -decompile option to extract the CHM contents. The below table summarizes the files extracted from the CHM.

Table 1: Files extracted from the CHM

The Stage 1 LNK launches the Stage 2 shortcut (0.lnk).

Stage 2 (Second LNK, decoy PDF, and TAR extraction)

The Stage 2 LNK performs the following actions:

• Moves the decoy PDF from the file named 3 to photo_2026-03-01_01-20-48.pdf (in the same directory).
• Treats file 4 as a TAR archive and extracts its contents into %AppData%.
• Executes %AppData%\BaiduNetdisk\ShellFolder.exe with the argument: --path a.

The figure below shows the directory structure of the files extracted from the TAR archive.

Figure 3: Directory structure of the TAR archive.

Next, ShellFolder.exe uses DLL sideloading to load a malicious DLL named ShellFolderDepend.dll.

ShellFolderDepend.dll analysis (shellcode loader)

ShellFolderDepend.dll is a 32-bit DLL that establishes persistence, and then decrypts and executes an encrypted shellcode payload stored in Shelter.ex.

The shellcode loader stores its strings in encrypted form and decrypts them at runtime using a custom index-based XOR algorithm that incorporates an additive constant, as shown below.

    KEY_BASE = 0x34
   decrypted = []
   for i, byte in enumerate(encrypted_bytes):
       key = (i + KEY_BASE) & 0xFF
       decrypted.append(chr(byte ^ key))
   return "".join(decrypted)

To establish persistence, the DLL enumerates running processes to determine whether bdagent.exe (Bitdefender Agent) is present. Based on the result, the DLL uses one of two persistence methods:

• If bdagent.exe is running, the DLL uses reg.exe to set a Run entry pointing to the host binary (ShellFolder.exe) to start the malware when a user logs in: C:\Windows\System32\reg.exe ADD HKCU\Software\Microsoft\Windows\CurrentVersion\Run /reg:64 /v BaiNetdisk /t REG_SZ /d "\"%s\" --path a" /f.
• If bdagent.exe is not running, the DLL sets the same Run entry directly using RegSetValueExA.

Before decrypting and loading the shellcode, the shellcode loader installs two inline API hooks:

• A 6-byte inline API hook (push hook_handler; retn) is placed on GetCommandLineW to spoof the return value as the wide-character string ShellFolder.exe 701 0, making the caller believe ShellFolder.exe was launched with the command-line arguments 701 0.
• A second 6-byte inline API hook (push hook_handler; retn) is placed on CreateProcessAsUserW.The hook handler first restores the original bytes at the API entry point, then calls Sleep to pause execution indefinitely, effectively preventing any child process from being created.

The DLL calls the Windows Native API SystemFunction033 (RC4) to decrypt shellcode stored in Shelter.ex (located alongside the DLL) using the key 20260301@@@. The DLL then:

1. Allocates executable memory with VirtualAlloc.
2. Copies the decrypted shellcode into memory.
3. Transfers execution to the decrypted shellcode.

PlugX shellcode loader analysis

This stage is a 32-bit, position-independent shellcode that is heavily obfuscated with control flow flattening (CFF). The next-stage backdoor is stored, encrypted, and compressed inside this shellcode, then decrypted and decompressed at runtime. The backdoor is loaded and executed to continue the next stage of the attack.

The CFF technique used in the shellcode leverages a state machine, where a state variable determines the address of the next execution block. Each basic block updates the state variable after execution and returns control to a dispatcher, which routes execution to the next block. This is a simple yet effective implementation of CFF to make reverse engineering more time consuming.

All API names are stored encrypted in the shellcode and are decrypted at runtime using an index-based XOR decryption algorithm similar to the one used in the shellcode loader. The only change is the additive constant, which is 0x36 instead of 0x34.

In addition, the XOR operations are obfuscated using mixed boolean arithmetic (MBA), typically using the pattern (~x & K) | (x & ~K), which is equivalent to x ^ K.

The embedded payload is decrypted using the following steps:

• Initializes a PRNG with a 4-byte seed (0xc56dd7ea).
• Uses a custom PRNG to generate a key stream.
• The generated keystream is used to decrypt the embedded payload. 

The decryption algorithm can be represented as follows:

seed = 0xc56dd7ea
def prng_decrypt(encrypted_data, seed):
   state = seed
   decrypted_blob = bytearray(len(encrypted_data))
   for i in range(len(encrypted_data)):
       state = (state + (state >> 3) + 0x13233366) & 0xFFFFFFFF
       decrypted_blob[i] = encrypted_data[i] ^ (state & 0xFF)
   return decrypted_blob

The decrypted blob begins with a 16-byte header followed by a payload compressed using LZNT1 algorithm. Below is the structure of the decrypted blob.

typedef struct {
   uint32_t magic;             // 4 bytes: Magic header
   uint32_t seed;              // 4 bytes: Seed
   uint32_t decompressed_size; // 4 bytes: Decompressed size
   uint32_t compressed_size;   // 4 bytes: Compressed size
   uint8_t  payload[];         // Variable length: LZNT1 compressed payload
} DecryptedBlob;

The loader uses the Windows API RtlDecompressBuffer to decompress the LZNT1 compressed payload.

The decompressed payload contains a corrupted MZ/PE header. The IMAGE_DOS_HEADER, DOS stub, and PE signature are corrupted with randomly generated ASCII data as an anti-forensics mechanism to evade memory forensics solutions. The figure below shows the corrupted MZ/PE headers.

Figure 4: Corrupted MZ/PE headers in the decrypted PlugX backdoor.

The table below summarizes which fields are corrupted in the header and which fields are left intact.

Table 2: Summary of the various fields in the corrupted PlugX MZ/PE headers.

Reflective DLL injection

The decrypted and decompressed payload is reflectively loaded by mapping all the sections to memory allocated using VirtualAlloc, performing relocations, resolving imports, and marking the memory region as executable. The first 0x20 bytes of the image base are repurposed and used as a context structure that is passed to DllMain of the reflectively loaded DLL. The PlugX encrypted configuration is present inside the shellcode and a pointer to it is stored at offset 0x14 in the context structure. The structure is defined as follows:

typedef struct {
    uint8_t  Reserved[0x14];
    uint32_t EncryptedConfigPtr; // image_base + 0x14 - Pointer to encrypted config
    uint32_t EncryptedConfigSize; // image_base + 0x18 - Size of encrypted config
    uint8_t  Reserved[0x4];
} _CONTEXT

In this instance, the PlugX image headers serve a dual purpose. They are overwritten with junk data to evade memory forensics, and they are also reused as a context structure passed to the reflectively loaded DLL for PlugX configuration decryption.

PlugX backdoor analysis

The PlugX backdoor reflectively loaded by the shellcode is also similarly obfuscated with CFF and MBA. API strings are also encrypted using an algorithm similar to the one observed in the shellcode loader and the shellcode.

After receiving the encrypted PlugX configuration details via the context structure passed to DllMain by the shellcode, the configuration is decrypted in two stages.

Stage 1

First, the entire encrypted blob is decrypted using a custom algorithm (implemented in Python below):

import struct
from ctypes import c_uint32, c_int32
def decrypt_config(data: bytes) -> bytes:
   if len(data) > 3) - 0x69696969
       part3.value = (old_part3 >> 5) + old_part3 + 0x66666667
       part2.value = -127 * c_int32(old_part2).value + 0x65656565
       part1.value = -511 * c_int32(old_part1).value + 0x33333333
       key_byte = (old_part1 + 51 + part2.value + part3.value + part4.value) & 0xFF
       output[i] = data[i] ^ key_byte
   return bytes(output)

Stage 2 (PlugX configuration decryption)

The individual fields within the decrypted configuration are further decrypted using RC4 with the key qwedfgx202211. The table below summarizes the decrypted configuration used for this PlugX sample.

Table 3: The decrypted configuration used for this PlugX sample.

This PlugX sample supports the following C2 channels:

• TCP
• HTTPS
• DOH for domain resolution using https://dns.google/dns-query
• UDP

This PlugX sample supports the following C2 commands. These are largely similar to prior PlugX analysis, and a detailed description is available here.

Table 4: C2 commands supported by this sample of PlugX.

This sample uses the following plugins:

Table 5: Plugins used by this sample of PlugX.

Threat Attribution

ThreatLabz attributes this attack to a China-nexus threat actor with high confidence, and we assess with medium confidence that this activity could be linked to Mustang Panda based on the following factors.

• Use of PlugX: The PlugX backdoor is exclusively used by China-nexus threat actors and multiple variants of PlugX are used in-the-wild. The PlugX backdoor variant used in this attack has heavy code overlaps with the DOPLUGS campaign described in 2024.
• Decryption keys: The RC4 key qwedfgx202211 used to decrypt the PlugX configuration in this case is the same as the one used in the DOPLUGS campaign. The RC4 key 20260301@@@ used by the shellcode loader to decrypt shellcode in this attack follows a YYYYMMDD@@@ format, similar to an RC4 key used by a China-nexus threat actor in 2024 as documented here.
• Social engineering lures: China-nexus threat actors like Mustang Panda are known to very quickly weaponize themes related to current events, particularly geopolitics. ThreatLabz recently observed this behavior in the LOTUSLITE backdoor (Case Study 2), where the threat actor quickly weaponized Middle East conflict–related themes.
• Obfuscation techniques: While CFF and MBA are not unique to PlugX, the CFF implementation used in both the shellcode and the PlugX backdoor matches patterns ThreatLabz has observed multiple times in Mustang Panda activity, as noted here and here.
• Decryption routine: The PlugX configuration decryption routine closely resembles one observed in prior Exchange Server attacks attributed to the PKPLUG group (an alias of Mustang Panda).
   

Conclusion

This campaign, attributed to a China-nexus threat actor, targeted countries in the Persian Gulf region using a multi-stage attack chain that ultimately deployed a PlugX backdoor variant. Our analysis underscores how China-nexus actors, including Mustang Panda, rapidly weaponize geopolitical events, such as the ongoing Middle East conflict, to craft timely social engineering lures.

ThreatLabz urges the security community to exercise caution when opening unsolicited files or clicking links that claim to provide news or updates related to the Middle East conflict.

Zscaler Coverage

Zscaler’s multilayered cloud security platform detects indicators related to the targeted attacks mentioned in this blog at various levels with the following threat names:

• Win32.Backdoor.PlugX

Indicators Of Compromise (IOCs)

File indicators

Network indicators

MITRE ATT&CK Framework