In January 2026, a new variant of the PlugX malware was used in targeted attacks. Based on our analysis, this variant appears to be linked to the threat actor group UNC6384, which is believed to be connected to Chinese cyber espionage operations. UNC6384 has strong affiliations with the APT group known as Mustang Panda (also referenced as TEMP.Hex), and has previously conducted campaigns targeting government agencies and diplomatic personnel in Southeast Asia.

This overview explains how this PlugX variant is executed, how its configuration is structured, and key implementation details.

---

Execution Flow

The infection chain for the PlugX variant we observed in January 2026 runs as follows:

1. A file named Browser_Updater.exe is executed by the victim.
2. When run, the file displays a fake web browser update dialog with “Install” and “Cancel” buttons. Regardless of which button is clicked — or even if no button is clicked — the malicious code continues. At execution time, this component automatically connects to a server controlled by the attacker and downloads a malicious MSI installer.
3. This behavior matches the known STATICPLUGIN downloader that has been reported by the Google Threat Intelligence Group (GTIG) as part of UNC6384’s malware toolkit. Based on the similarity in functionality and user interface, this downloader is believed to be a newer iteration of STATICPLUGIN.
4. The STATICPLUGIN executable was found signed with a code-signing certificate issued to a Chinese company (“山西荣升源科贸有限公司”). This certificate has since been revoked, and many signed files are flagged as malicious on VirusTotal.
5. The downloaded MSI places three files under %LOCALAPPDATA%\pZhozR:
   • Avk.exe
   • Avk.dll
   • AVKTray.dat
     These components are required for executing the PlugX payload.
6. The file Avk.exe is a legitimate binary from a G DATA antivirus product. The malware abuses this binary by using DLL side-loading to load the malicious Avk.dll. This sideloaded DLL is the PlugX loader.
7. Once loaded, Avk.dll resolves important Windows native API functions dynamically (using API hashing) — such as NtCreateFile and NtReadFile. It then uses routines like RtlRegisterWait to execute shellcode that was dropped in AVKTray.dat.
8. The embedded shellcode first XOR-decodes the main PlugX malware payload and then runs it in memory.

---

Configuration Information and Decoding

After the initial execution, the PlugX malware decodes its internal configuration, which includes command-and-control (C2) server addresses and other operational settings:

• The configuration data is stored in the .data section of the malware binary, and it’s both encoded and RC4-encrypted.
• Within the configuration structure, the first DWORD indicates the length of the RC4 key, followed by the key bytes and encrypted data.
• For the sample analyzed in this report, the RC4 key was derived from the data at offset 0x04, and the rest of the encrypted block (starting at 0x10) contained the actual encrypted PlugX configuration.
• A Python script can be used to implement this decode routine (key setup and XOR processing), allowing extraction of plaintext configuration such as C2 server hosts and other metadata.

---

Summary of Observed Behaviors

• Downloader: Uses a fake update UI to fetch an MSI payload without user-driven consent.
• Side-loading: Leverages a signed, legitimate executable to load malicious DLL.
• Execution: Malicious shellcode is run directly in memory after decompression/XOR decode.
• Configuration Handling: Contains encoded and encrypted C2 configuration requiring custom decode logic.

This variant clearly demonstrates advanced techniques typical of PlugX families — including loader side-loading, in-memory execution, and obfuscated configuration — and indicates ongoing use by sophisticated actors like UNC6384 in targeted espionage campaigns.