Mustang Panda is using a fake “Browser Updater” and a multi‑stage LNK–PowerShell loader to sideload PlugX through a legitimate G DATA antivirus binary, ultimately beaconing over HTTPS to a hard‑coded C2 while hiding configuration and strings behind layered encryption and API hashing.
Mustang Panda is a China‑nexus APT group, long associated with PlugX remote access trojans, in espionage operations targeting government and diplomatic targets.
PlugX is a modular RAT that supports plugin‑based extensions, reflective loading, and encrypted configuration blobs, making it highly adaptable across campaigns.
In the observed intrusion chain, the attacker first weaponizes a Windows shortcut (LNK) that launches PowerShell in hidden mode, staging payloads into a user‑writable path such as %LOCALAPPDATA%.
PowerShell unpacks an archive (for example, a ZIP or similar compressed file masquerading as a benign document), drops a fake browser update program (Browser_Updater.exe), and presents the victim with a spoofed UI to legitimize execution.
This “browser update” theme has been documented as a recurring Mustang Panda group lure, often paired with meeting invitations or policy‑themed phishing content.
When the user clicks Install in the fake updater, Browser_Updater.exe issues an HTTP GET request to a staging server, retrieving a payload served under a misleading name such as iis.jpg even though the content is an MSI installer.
Blue Cyber said in a report shared with GBhackers, reporting shows the group continually rotating delivery mechanisms, including LNK files, PowerShell, DLL sideloading, and fake software updaters.
The MSI then drops a three‑file set into a per‑user directory under %LOCALAPPDATA%, consisting of a legitimate signed executable, a malicious DLL, and an encrypted .dat payload that will become the PlugX core.
Mustang Panda Uses LNK
To evade scrutiny, Mustang Panda relies on DLL sideloading, a long‑standing PlugX tradecraft pattern. The dropped executable is a legitimate G DATA antivirus component (Avk.exe) with an intact digital signature, used purely as a loader host rather than as the core implant.
Avk.exe locates and loads a companion DLL (Avk.dll) from the same directory and calls one of its exported entry points, giving the malicious library full control while keeping the outer process chain superficially benign.
Avk.dll implements only the minimal logic required to continue the chain: it resolves Windows APIs via DJB2‑style hashing at runtime, reads an obfuscated path to an adjacent .dat file, and loads that file into a buffer with read‑write‑execute permissions.
Avk.exe (Source : Blue Cyber).Instead of directly invoking the buffer, the DLL registers it as a thread‑pool callback via RtlRegisterWait and then signals an event, causing ntdll’s worker thread to jump into attacker‑controlled code and obscuring the true origin of the RWX execution.
The AVKTray.dat file is an encrypted shellcode container, a common PlugX pattern where a .dat “data” file actually holds the next‑stage loader. Its initial stub decrypts the bulk of the file with a single‑byte XOR key before transferring execution into a more complex routine protected by control‑flow flattening, making static decompilation difficult.
That routine performs additional transformations on the embedded payload, using combinations of hashing and simple operations like rotate‑left to resolve helper functions without revealing imports or strings in clear text.
The configuration and C2 strings are not stored as plaintext in the mapped image but encoded in a dedicated blob that is decrypted only at runtime.
Inside fn_worker_thread_entry_10001290, the malware obtains the current command line, splits it into argv/argc, then selects an execution branch based on the number of arguments.
Analysts observed an RC4‑encrypted configuration region keyed with a short ASCII passphrase; after the RC4 layer, individual wide‑string fields undergo another XOR pass, so even memory scans after initial decoding will not immediately show domains, mutex names, or installation paths.
The core PlugX loader behaves as a manual PE mapper, replicating the Windows loader’s responsibilities in user‑space.
It locates its own in‑memory PE image by scanning backward from the current return address for the MZ and PE signatures, allocates a new region, copies headers and sections, resolves imports, applies relocations, and finally invokes the mapped entry point twice with different reasons to transition into runtime.
To further complicate analysis, this stage switches from DJB2 hashing to a rotate‑left‑19‑based hash for resolving KERNEL32, NTDLL, and critical APIs, breaking simple signature‑based detection of the earlier hashing scheme.
The allocated region is intentionally larger than the actual image size, which can frustrate heuristics that look for tightly sized executable mappings.
After mapping, the loader flushes the instruction cache and establishes a worker thread that becomes the long‑lived controller responsible for persistence and C2 communication.
The first time the mapped PlugX payload runs, it checks the process command‑line arguments and, when started from the staging directory with a single argument, copies its three‑file set into a more stable path under %PUBLIC%\GData.
Using the G DATA brand name for this folder leverages “living‑off‑the‑namespace” tradecraft: an administrator performing a quick review may assume the folder is associated with legitimate antivirus software.
After installation, the malware writes a Run key under HKCU\Software\Microsoft\Windows\CurrentVersion\Run with a value name matching the G DATA branding.
The command points to the relocated Avk.exe in %PUBLIC%\GData with two extra numeric arguments, ensuring that subsequent auto‑starts follow a different execution branch than the initial installer run while avoiding duplicate self‑installation.
On logon, the implant also creates a mutex to enforce a single running instance and patches SetUnhandledExceptionFilter to blunt external exception‑handling or monitoring mechanisms.
Before contacting its controller, the PlugX runtime initializes a client identifier stored in an HKCU\Software\Classes subkey, reusing the value to maintain a stable victim ID across sessions.
It then reads the user’s proxy configuration from HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings to mirror existing network settings and reduce anomalies.
When building outbound connections, the implant crafts a modern Edge/Chrome‑like User‑Agent string and opens a WinHTTP session to a hard‑coded C2 domain over HTTPS.
In this campaign, analysts observed repeated connections to fruitbrat[.]com over port 443, with the implant retrying after delays if the C2 is unreachable.
Each request carries a cookie parameter that serves as a beacon or session identifier, derived from the stored client ID and per‑request data so the raw registry value does not appear directly in network traffic.
The C2 response is parsed and dispatched to handlers that support file download and execution, process spawning with output capture, file system operations, and modular plugin loading, aligning with PlugX’s well‑documented remote access capabilities.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
