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

Extracted Components

Decrypted Payload

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.

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:

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

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:

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

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

Payload and Dropped File IOCs

Persistence IOCs

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.