Mustang Panda Using New DLL Side-Loading Technique to Deliver Malware


In recent weeks, cybersecurity analysts have observed a resurgence of the Mustang Panda threat actor deploying a novel DLL side-loading approach to deliver malicious payloads.

Emerging in June 2025, this campaign leverages politically themed lures targeting Tibetan advocacy groups.

Victims receive a ZIP archive containing a decoy executable named Voice for the Voiceless Photos.exe alongside a hidden dynamic-link library, libjyy.dll, marked with system and hidden attributes to evade casual inspection.

When executed, the decoy loads this concealed library via LoadLibraryW, triggering the obscure malware routine beneath the guise of legitimate software.

Mustang Panda’s attack chain begins with a phishing email carrying the ZIP container. Once opened, Explorer hides the malicious DLL due to its combined “hidden” and “system” flags.

Hidden DLL in the directory (Source – 0x0d4y.blog)

The decoy executable then dynamically loads libjyy.dll by resolving the ProcessMain entry point and invoking it.

google

At this stage, 0x0d4y Malware Researcher noted that this loader employs dynamic API resolution and string decryption routines to obscure its behavior, making static detection far more challenging.

After initializing, the malicious DLL decrypts its core payloads, sets up persistence via multiple techniques (registry run keys and scheduled tasks), and finally extracts shellcode for execution.

The persistence logic first renames both the decoy and the loader to %SystemRoot%Adobelicensinghelper.exe and registers a run key named AdobeLicensingHelper under HKCUSoftwareMicrosoftWindowsCurrentVersionRun.

ProcessMain (Source – 0x0d4y.blog)

It then creates a scheduled task, executed every two minutes, to relaunch the loader with the required Licensing argument.

Infection Mechanism

Mustang Panda’s infection mechanism hinges on the DLL side-loading T1574.006 technique, dubbed “ClaimLoader.”

The loader executable contains minimal import references, instead dynamically decrypting API names at runtime.

A simple XOR routine with key 0x19 decodes encrypted strings before invoking LoadLibraryW and GetProcAddress.

For example:-

mov edx, 
mov ecx, 
; XOR decryption loop
decrypt_loop:
  mov al, [ecx]
  xor al, 0x19
  mov [ecx], al
  inc ecx
  dec edx
  jnz decrypt_loop
; After decryption, load API dynamically
push 
call decryptstrloadapi
call eax  ; resolved API call

This code snippet illustrates how the loader avoids static imports and hides its true intentions until execution.

Once the real payload library is loaded, it uses a secondary custom XOR algorithm—cycling through a four-byte key array [0x01, 0x02, 0x03, 0x04]—to decrypt a Schtasks command string in memory.

The decoded command schedules the loader to run periodically:-

schtasks /Create /TN AdobeExperienceManager /SC MINUTE /MO 2 /TR "C:WindowsAdobelicensinghelper.exe Licensing" /F

Following these steps, the loader allocates executable memory via VirtualAlloc, copies shellcode, and abuses the EnumFontsW callback mechanism to execute it.

The shellcode then performs API hashing to resolve network functions and exfiltrate system data to a command-and-control server.

Through these layered techniques, Mustang Panda remains especially elusive, blending well-known Windows APIs with dynamic loading and obfuscation to thwart traditional endpoint defenses.

Follow us on Google News, LinkedIn, and X to Get More Instant UpdatesSet CSN as a Preferred Source in Google.

googlenews



Source link

About Cybernoz

Security researcher and threat analyst with expertise in malware analysis and incident response.