ShadowPad: Forensic Reverse-Engineering & Architectural Dossier

ShadowPad is a modular backdoor framework utilized by Chinese state-sponsored cyber espionage clusters (APT41 / Winnti / Earth Lusca / Redfly / Bronze Silhouette). Operating as the successor to PlugX and Winnti, ShadowPad features an enterprise-grade modular architecture. Execution is typically initiated via DLL search-order hijacking (side-loading): a benign, digitally signed executable (e.g., security vendor binaries, legitimate utility engines) loads a malicious companion DLL placed in the same directory. The companion DLL unpacks an encrypted shellcode blob containing an in-memory reflective loader and the ShadowPad core coordinator. The core coordinator establishes an in-memory virtual environment, dynamically allocating virtual memory to unpack and register functional plugin modules without dropping separate files to disk.

The operator configuration console enables threat actors to compile custom encrypted payloads. The builder configures C2 transport priorities (TCP, HTTP, HTTPS, UDP, DNS), primary and secondary C2 hostnames/IPs, fallback DNS servers, beacon frequency, sleep jitter percentages (10-30%), campaign tracking markers, and the active plugin module table. The configuration block is stored in an encrypted struct within the payload; at runtime, the loader decrypts it using an 8-byte or 16-byte rolling XOR key or RC4 cipher. The structure includes magic timestamp DWORDs, communication timeout limits, and active network routing paths.

struct ShadowPad_Config {
    uint32_t magic;
    char c2_host[128];
    uint16_t port;
    char install_path[260];
    char mutex[64];
    uint8_t aes_key[32];
};

ShadowPad executes through a virtual function table (VFT) dispatch mechanism. Unlike conventional modular loaders that export named DLL functions, ShadowPad plugins are reflective memory modules stripped of standard PE export headers. Upon initialization, each plugin allocates memory and registers its functional entry points into the central coordinator's dispatch table. Each plugin is identified by a unique 32-bit Module ID: 0x64 (Root/Config), 0x65 (Network/C2), 0x66 (FileSystem/Disk), 0x67 (Process/Thread), 0x68 (Registry), 0x69 (Screen Capture), 0x6A (Shell/Cmd), 0x6B (Service Management), 0x6C (Port Forwarding/Pipe). When an operator packet arrives, the coordinator reads the target Module ID from the packet header, looks up the corresponding function pointer in the VFT, and executes the routine via indirect function calls. Inter-plugin communications (such as the FileSystem module passing directory trees to the Network module for exfiltration) execute through in-memory message buses without interacting with disk storage.

Concrete technical breakdown of functional modules implemented in the ShadowPad binary:

The ShadowPad network protocol utilizes custom binary framing prepended with a 16-byte to 24-byte packet header: [DWORD MagicSeed][DWORD PayloadLength][DWORD UncompressedLength][DWORD ModuleID][DWORD CommandID][Encrypted Payload Bytes]. Data payloads are compressed using the LZO or modified QuickLZ compression algorithm prior to encryption. Encryption applies RC4 or a rolling 32-bit XOR cipher seeded by the initial MagicSeed field combined with machine-specific volume serial numbers. In DNS mode, data is serialized into Base32 or hexadecimal character labels and dispatched via DNS TXT or A record lookups (<encoded_chunk>.<session_id>.<c2_domain>), reassembled by adversary authoritative name servers to bypass egress web proxies.

Indicators of compromise and forensic patterns recorded across laboratory triage: