PlugX DLL Sideloading via MSI Installer: Complete Malware Analysis of a KorPlug Campaign

PlugX (KorPlug) is a modular remote access trojan delivered in this campaign through an MSI-based DLL sideloading chain. In this sample,The installer drops a legitimate G DATA executable, a malicious AVK.dll sideloader, and an XOR-encrypted AVKTray.dat payload that ultimately loads a reflective PlugX DLL and establishes persistence.

Key Takeaways

• This campaign uses a spoofed MSI installer to deploy a legitimate AVKTray.exe, a malicious AVK.dll, and an encrypted AVKTray.dat payload.
• Next, the attack relies on DLL sideloading through a trusted G DATA binary to execute malicious code under a signed process.
• At the loader stage, the sideloader uses dynamic API resolution, XOR-obfuscated strings, and RtlRegisterWait thread-pool callback abuse to execute the payload.
• After decryption, the PlugX DLL recovers an operator C2 at dalerocks.com:443, uses RC4 configuration decryption, and sets Run-key persistence.
• Finally, the campaign drops a decoy document, includes process execution and cleanup logic, and is supported by multiple YARA rules and IOCs.

Introduction

A PlugX DLL sideloading campaign was submitted for analysis inside a Windows Installer (MSI) file carrying a spoofed “Microsoft Corporation” author field and a future-dated 2026 creation timestamp. The package installs three files: a legitimate G DATA AVK antivirus binary, a malicious replacement DLL that hijacks the AVK import path, and an XOR-encrypted PlugX payload blob. Together, these elements form a classic abuse of Windows DLL search-order hijacking, a technique APT actors have used for more than a decade.

This campaign matters because it combines several well-established PlugX tradecraft patterns in one chain: trusted executable sideloading, encrypted payload staging, reflective DLL execution, RC4-protected configuration, and Run-key persistence. It is not just a loader trick. Instead, it delivers a full delivery path for a mature remote access trojan.

What Is KorPlug/PlugX?

KorPlug, also known as PlugX, is a modular remote access trojan first documented around 2008. Chinese-nexus APT groups including APT41, APT10, and Mustang Panda have used it extensively in campaigns targeting government, defense, technology, and healthcare organizations worldwide.

The most consistent PlugX delivery pattern is DLL sideloading. Attackers package a legitimate signed executable together with a malicious DLL that uses the same name as a DLL the legitimate binary imports. As a result, When Windows resolves the import, it loads the attacker’s DLL from the application directory before checking normal system paths. That behavior gives the malicious code execution cover under a trusted signed process.

This sample follows that model precisely. The G DATA AVK security product binary is abused because it imports AVK.dll!ModuleMain. By placing a malicious AVK.dll in the same directory, the attacker forces Windows to load the fake DLL instead of the legitimate one.

Why This Matters

PlugX is not notable only because it is old. It is notable because attackers still use it successfully by wrapping it in trusted binaries and delivery chains that continue to work on modern Windows systems.

Sample Metadata

MSI Installer

Field	Value
File	91af8218c450d18ce231b2a2604f1fae68c825d04203fd312efc45263847ad5c
File Type	Windows Installer (OLE2 / CFBF compound document)
File Size	532,480 bytes (520 KB)
MD5	939D984F39AEBD02DB16FF3FCDE165B1
SHA1	BF184EAE8F069E5E9B76E3C65A88B38583385E61
SHA256	91AF8218C450D18CE231B2A2604F1FAE68C825D04203FD312EFC45263847AD5C
Magic Bytes	D0 CF 11 E0 (OLE2 signature)
MSI Title	Installation Database
MSI Author	Microsoft Corporation (spoofed)
MSI Created	2026-05-07 02:55:10 UTC

Extracted Components

CAB Filename	Final Name	Type	Size	SHA256
tgelzmrbxf	AVKTray.exe	Legitimate PE EXE (G DATA AVK)	943,696 B	8421E7995778FAF1F2A902FB2C51D85AE39481F443B7B3186068D5C33C472D99
vypqzxo	AVK.dll	Malicious DLL sideloader	5,632 B	9B3CD542D2C1D51D57A31502B69DDFCD5888FF94BCED69A13AC0CB90CA2B6644
mdbzylxweq	AVKTray.dat	Encrypted dll	628,131 B	A1EB722EEA6FE8F55FDB08286491388DEB3217E1E0D0F48E75008F6BFD9492C5

Decrypted Payload

Field	Value
Decrypted from	AVKTray.dat (XOR key 0xA8, 616,448 bytes from offset 6)
File Type	PE32 DLL (reflective)
MD5	018D9690087273E3BABBE616D761FA88
SHA256	1399A3C3567940678911262F45E8E6DF4E08508DEB44FCA4FE47FC1F35B0FAA5
ImageBase	0x10000000
Entry Point RVA	0x81CDB
Export	cuxHeaSmzkjm (single randomly-named export)
Compiler	MSVC (vcruntime140.dll / mfc140u.dll referenced)
Timestamp	0x6968642E = 2026-01-15

How This PlugX MSI Sideloading Chain Works

The malware begins as an MSI installer with an embedded MSCF cabinet archive. Inside are three files with randomized extensionless names, which weakens filename-based detection. After extraction, the installer extracts and renames them into a working set composed of a legitimate AVK executable, a malicious AVK.dll, and an encrypted AVKTray.dat payload.

When AVKTray.exe starts, Windows resolves its DLL imports from the local application directory. Because the attacker-controlled AVK.dll is present, the legitimate process loads the malicious DLL. From there, DLL then resolves APIs dynamically, decodes the staged payload path, loads the encrypted blob from disk, marks memory executable, and dispatches the payload through a thread-pool callback using RtlRegisterWait.

The staged payload is then XOR-decoded into a reflective PlugX DLL, which maps itself in memory, decrypts its internal RC4-based configuration, recovers its operator C2 endpoint, and establishes persistence through a Run key. Meanwhile, the DLL also drops and opens a decoy document as part of the broader execution chain.

Why This Matters

This is a complete multi-stage delivery chain, not just a malicious DLL. Each stage is designed to reduce suspicion, delay detection, and preserve the operator’s ability to run PlugX under the cover of a legitimate process.

Technical Analysis

The MSI Installer and File Staging

The malware is an MSI installer exe with embedded MSCF (Cabinet) archive that contains three files, all with randomized extensionless names that defeat filename-based signatures.

Extracted File	Magic	Final Name	Role
tgelzmrbxf	4D 5A (MZ PE)	AVKTray.exe	Legitimate AVK loader
vypqzxo	4D 5A (MZ PE)	AVK.dll	Malicious sideloader DLL
mdbzylxweq	F8 E8 (shellcode)	AVKTray.dat	Encrypted PlugX payload

Files are only renamed at extraction time by the installer.

Why This Matters

Using a legitimate antivirus binary as the visible launcher gives the campaign a strong trust anchor. The malicious activity starts only after Windows resolves the sideloaded DLL locally.

The Malicious Sideloader (AVK.dll)

AVK.dll is the most technically sophisticated component in the chain.

It contains a complete shellcode loader that resolves Windows APIs dynamically, decodes the payload filename, loads the payload blob from disk, and executes it via an RtlRegisterWait thread pool callback.

fn_0x100013e2: Module resolver (walks PEB InMemoryOrderModuleList)

Algorithm:
  PEB → Ldr → InMemoryOrderModuleList
  For each loaded module:
    Convert module name to lowercase (UTF-16 wide chars)
    Compute djb2: h = 0x1505; for each wchar: h = (h * 0x21) + wchar
    Compare against target hash → return module handle if match

fn_0x100014b4: Export resolver (walks PE export table)

Algorithm:
  Parse export directory of target module
  For each named export:
    Compute djb2: h = 0x1505; for each byte: h = (h * 0x21) + byte
    Compare against target hash → return function address if match

This is the djb2 hash algorithm (initial value 0x1505 = 5381 decimal, multiplier 0x21 = 33). Module names are hashed case-insensitively (lowercased before hashing); function names are case-sensitive. This implementation is identical to documented KorPlug/PlugX loader tradecraft.

Resolved API Hash:

kernel32.dll (module), ntdll.dll (module), GetModuleFileNameW, VirtualAlloc, VirtualFree, CreateEventW, SetEvent, Sleep, NtCreateFile, NtQueryInformationFile, NtClose, NtReadFile, NtTerminateProcess, NtProtectVirtualMemory, RtlRegisterWait, RtlDeregisterWait

XOR-Encoded Payload Path

The payload filename \AVKTray.dat is stored as an XOR-obfuscated UTF-16LE string.

At runtime, the loader decodes it, prepends the NT device namespace prefix \??\, and combines it with the DLL’s own directory path. As a result, the full NT object path to the staged payload.

Payload Loading and Execution / RtlRegisterWait Technique

1.  NtCreateFile(\??\<dir>\AVKTray.dat)                  → file handle
2.  NtQueryInformationFile(FileStandardInfo)              → get file size
3.  VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE)  → RW buffer
4.  NtReadFile(handle, buffer)                            → load entire file into buffer
5.  Validate: size >= 1000 bytes                          → NtTerminateProcess(-1) if fail
6.  NtProtectVirtualMemory(−1, buffer, PAGE_EXECUTE_READWRITE)
7.  CreateEventW(NULL, FALSE, FALSE, NULL)                → auto-reset event
8.  RtlRegisterWait(&hWait, event, callback=buffer, NULL, INFINITE, WT_EXECUTELONGFUNCTION=8)
        ← registers buffer as EVENT WAIT CALLBACK in thread pool
9.  Sleep(500 ms)
10. SetEvent(event)    ← FIRES callback from thread pool worker → buffer[0] executes
11. Sleep(500 ms)
12. RtlDeregisterWait(hWait)
13. Infinite Sleep(1000 ms) loop ← keeps loader DLL in memory while PlugX runs

Using RtlRegisterWait to dispatch shellcode is a thread pool execution abuse technique (T1055). Notably, the callback fires from ntdll!TppWorkerThread, not from the loader’s own thread. Therefore, the spawned activity appear to originate from a legitimate system thread pool, which is less suspicious in EDR telemetry than CreateThread / CreateRemoteThread.

The WT_EXECUTELONGFUNCTION flag (value 8) tells the thread pool that the callback is expected to run indefinitely, appropriate since the PlugX payload never returns.

Why This Matters

This is a stealthier execution path than a direct thread creation pattern. Thread-pool callback abuse helps the payload blend into normal Windows worker-thread behavior.

Encrypted Payload Blob (AVKTray.dat)

The blob is a two-layer construct: a shellcode bootstrap followed by an XOR-encrypted PE DLL.

0x96806 basically XOR decrypts the entire DLL with key 0xa8

PlugX Core DLL (Decrypted Payload)

The decrypted payload exports a single randomly named function: cuxHeaSmzkjm. That export acts as a reflective loader, not the final RAT loop. Instead, it maps a fresh copy of the DLL in memory, resolves imports, applies relocations, sets memory protections, and then calls the mapped image’s DllMain.

The sample also uses control-flow flattening, which makes reverse engineering harder.

Why This Matters

Reflective loading gives the final PlugX stage another layer of execution stealth, because it does not simply run as a standard DLL loaded from disk.

Configuration Decryption

The embedded configuration is stored encrypted in .data. The decoder copies the encrypted blob, clears the original region, and decrypts it using RC4. Recovered values include:

Field	Value
Key material	AcLgMFAEHtAq
RC4 key	AcLgMF
Default/fallback port	5000
Beacon interval	60000 ms

However, RC4 decryption does not produce one plain-text string. Instead, the sample keeps a structured binary configuration, and some fields use additional transforms. For example, the first C2 record starts at post-RC4 config offset 0x6A0; its host field starts at record +0x12 (0x6B2) and is 26 bytes long:

Why This Matters

Even after RC4 decryption, the configuration still requires deeper analysis. That extra protection slows simple config extraction and automated parsing.

Command and Control

The recovered operator C2 in this sample is:

dalerocks.com:443

The domain www.bing.com:443 also appears in the network logic, but it is used as a probe / connectivity-check host, not as the operator C2.

Recovered Network Properties

Property	Value
Operator C2	dalerocks.com:443
Probe host	www.bing.com:443

The network path dynamically resolves WinHTTP APIs and builds request state on the stack.

Confirmed WinHTTP Artifacts

Confirmed artifacts include:

• WinHttpOpen
• WinHttpConnect
• WinHttpOpenRequest
• WinHttpSendRequest
• WinHttpReceiveResponse
• WinHttpReadData
• WinHttpQueryHeaders
• WinHttpAddRequestHeaders
• WinHttpCloseHandle
• HTTP method: POST
• content type: application/octet-stream
• Chrome-like user agent

Why This Matters

Using HTTPS on port 443, WinHTTP, and a mainstream browser-style user agent helps PlugX traffic blend into legitimate outbound web activity.

Persistence

Run-key persistence is confirmed in the DLL stage. The malware writes a REG_SZ value under:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Value name: G Data

The Run-key path is not stored as a normal string. Instead, the malware builds it on the stack in encoded wide-character form and decodes it in place immediately before the registry write.

Recovered path decoder:

decoded[i] = encoded[i] ^ (((i + 0x5DFD) & 0xFFFF) ^ 0x5DFD)

The DLL also writes COM/CLSID-related registry data:

Root	Type	Purpose
HKCU	REG_BINARY	Software\CLASSES\ms-pu / CLSID-related data
HKLM	REG_BINARY	Software\CLASSES\ms-pu / CLSID-related data

Why This Matters

Persistence is not only present. It is intentionally obscured. Even the registry path is encoded until the moment it is written, which reduces static visibility.

Dropped Decoy Document

The malware drops a decoy document during execution. The document is appended to the DLL as a raw DOCX / ZIP overlay and extracted by a dedicated helper.

Decoy Artifact

Field	Value
Decoy filename	TIN BUỒN.docx
Magic	PK 03 04
Extracted DOCX SHA256	646d66bf421ed11f57ec726dd11324e1394741e6bbc8c63dc50b2de8a5709b00

Why This Matters

Decoy documents give the victim a plausible visible result while the actual malware chain continues silently in the background.

Process Execution and Defense Evasion

The DLL contains helper-level evidence for process execution, process termination, and cleanup. Confirmed strings/APIs include:

Why This Matters

These helper routines show that the chain is built for more than simple loading. It includes execution control, cleanup logic, and evasion behaviors that support longer-lived operation.

Indicators of Compromise (IOCs)

File Hashes

Network IOCs

Type	IOC
Domain	dalerocks[.]com
IPs	172.67.137.209 104.21.81.33

Payload and Dropped File IOCs

Type	IOC	Notes
Path	%PUBLIC%\Lzgluu\Avk.exe	Main staged executable
Path	%PUBLIC%\Lzgluu\Avk.dll	Sideloader DLL
Path	%PUBLIC%\Lzgluu\AVKTray.dat	Encrypted Payload DLL
Filename	TIN BUỒN.docx	Decoy document dropped/opened
Path	%TEMP%\TIN BUỒN.docx	Decoy document location

Persistence IOCs

Type	IOC
Registry value	HKCU\Software\Microsoft\Windows\CurrentVersion\Run\G Data
Registry value	HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run\G Data

Yara Rules

YARA Rule 1 – Installer Chain

rule Windows_RAT_Korplug_Installer
{
    meta:
        description = "Korplug/PlugX MSI Installer and Dropper Chain"
        author      = "Dark Atlas; @ELJoOker"
        date        = "2026-05-14"

    strings:
        $h1         = { D0 CF 11 E0 A1 B1 1A E1 }

        $s1         = "pcalua -a [%PUBLIC]\\" ascii
        $s2         = "Avk.exe" ascii
        $s3         = "AVKTray.dat" ascii
        $s4         = "Avk.dll" ascii

    condition:
        (
            uint32(0) == 0xE011CFD0 or
            $h1 at 0
        ) and
        filesize < 2MB and
        (
            ($s1 and 1 of ($s2,$s3,$s4)) or
            2 of ($s2,$s3,$s4)
        )
}

YARA Rule 2 – Final DLL Payload

rule Windows_RAT_Korplug_Final_DLL
{
    meta:
        description = "Korplug/PlugX Final DLL Payload"
        author      = "Dark Atlas; @ELJoOker"
        date        = "2026-05-14"

    strings:
        $h1         = {
            41 63 4C 67 4D 46 41 45 48 74 41 71
            FC E9 5F B9 97 22 55 AC
        }

        $h2         = {
            FC E9 5F B9 97 22 55 AC 1F A3 BC 23 AB 81 07 36
            10 D7 93 0C A5 FC D2 06 98 EC 69 AE BF AA B3 18
        }

        $h3         = { 57 6A 6C 45 78 7B 7E 46 78 6E 64 }
        $h4         = { 3D 02 70 00 00 }
        $h5         = { 3D 03 70 00 00 }
        $h6         = { 3D 05 70 00 00 }

    condition:
        uint16(0) == 0x5A4D and
        uint32(uint32(0x3C)) == 0x00004550 and
        uint16(uint32(0x3C) + 4) == 0x014C and
        uint16(uint32(0x3C) + 6) == 4 and
        filesize < 1MB and
        (
            ($h1 and $h3) or
            ($h1 and 2 of ($h4,$h5,$h6)) or
            ($h2 and $h3 and 1 of ($h4,$h5,$h6))
        )
}

YARA Rule 3 – Encoded AVKTray.dat

rule Windows_RAT_Korplug_Encoded_AVKTray
{
    meta:
        description = "Korplug/PlugX XOR-Encoded AVKTray.dat Staged Payload"
        author      = "Dark Atlas; @ELJoOker"
        date        = "2026-05-14"

    strings:
        $h1         = { F8 E8 00 68 09 00 E5 F2 40 A8 A8 A8 A8 F3 FA ED FD 23 44 29 }
        $h2         = {
            E9 CB E4 CF E5 EE E9 ED E0 DC E9 D9
            54 41 F7 11 3F 8A FD 04
        }
        $h3         = { FF C2 C4 ED D0 D3 D6 EE D0 C6 CC }
        $h4         = { 95 AA D8 A8 A8 }
        $h5         = { 95 AB D8 A8 A8 }
        $h6         = { 95 AD D8 A8 A8 }

    condition:
        filesize < 1MB and
        uint16(6) == 0xF2E5 and
        (
            ($h1 at 0 and 1 of ($h2,$h3)) or
            ($h2 and 1 of ($h4,$h5,$h6)) or
            ($h3 and 2 of ($h4,$h5,$h6))
        )
}

FAQ

What is PlugX / KorPlug?

PlugX, also known as KorPlug, is a modular remote access trojan widely used in long-running APT campaigns. It is especially known for sideloading delivery chains that abuse trusted signed binaries.

How does this campaign deliver PlugX?

This campaign uses a spoofed MSI installer to drop a legitimate G DATA executable, a malicious AVK.dll, and an XOR-encrypted AVKTray.dat payload. The legitimate executable then loads the malicious DLL through DLL sideloading.

What is the operator C2 in this sample?

The recovered operator C2 is dalerocks.com:443.

How does the malware persist?

The DLL stage sets a Run-key value named G Data and also writes additional COM / CLSID-related registry data.

Conclusion

This sample demonstrates a multi-stage KorPlug / PlugX RAT chain delivered through an MSI installer. The attack starts with staged installation and DLL sideloading under a trusted G DATA binary, then loads an XOR-encrypted payload that decrypts into a reflective PlugX DLL with RC4-protected configuration, recovered command-and-control, and persistence.

What makes this campaign important is not just the use of PlugX. More importantly, the surrounding delivery chain combines spoofed installer metadata, trusted executable abuse, dynamic API resolution, thread-pool callback execution, encoded registry paths, and decoy document handling. Together, these layers show a mature tradecraft pattern built to preserve stealth while reliably delivering a known RAT family.

The key takeaway is simple: this is not just a PlugX DLL. It is a complete sideloading workflow that shows how older malware families remain effective when wrapped in modern execution and staging techniques.