A financial-document lure, reported to have arrived over WhatsApp, carried Statement.exe into a multi-stage Windows intrusion. After unpacking, the loader screened the host, attempted elevation, and injected a downloader into the LocalSystem Task Scheduler process. The chain retrieved a deployment bundle, used a signed GoFly driver to terminate selected Baidu security processes, established a Vulkan DLL side-loading task, and launched a WebSocket remote access trojan (RAT) we track as VulcanRAT207.A, which communicates with 61[.]18[.]208[.]27:8888. This post, the first of two, traces that chain component by component. Part 2 covers a related package that leads to RomulusLoader.
The early transfer into Task Scheduler explains the privilege model: subsequent components inherit its SYSTEM token. The deployment DLL starts the RAT from memory while separately writing a persistent Vulkan package to C:\Program Files\Common Files. Its scheduled task later starts a signed VulkanInfo executable that loads the attacker-controlled vulkan-1.dll and its vulkan-1.bin sidecar.
Key findings
Delivery and injection. A financial-document lure, reportedly distributed via WhatsApp, carries Statement.exe. The loader screens the host, attempts elevation, and uses PoolParty Variant 7 to place a downloader in the Windows Task Scheduler process without relying on CreateRemoteThread.
Privilege model. Injection into the Task Scheduler service host—a LocalSystem process—grants every subsequent component SYSTEM-level authority without additional escalation. The SeDebugPrivilege enablement and CreateServiceW calls seen in later stages exercise inherited authority, not new privilege acquisition.
BYOVD via GoFly64.sys. The deployment stage drops and loads a legitimately Authenticode-signed Chinese network-filter driver, then submits Baidu security process PIDs to its kernel-mode IOCTL (0x12227A), which calls ZwTerminateProcess from ring 0. The driver hash is catalogued in the LOLDrivers project.
Immediate evasion and persistence. The deployment DLL installs the GoFly driver to terminate targeted Baidu processes, starts the RAT from memory, and separately writes the Vulkan side-loading triplet with a SYSTEM scheduled task for later re-entry.
VulcanRAT207.A. The port 8888 chain ends in a WebSocket RAT with host surveillance, remote desktop, account manipulation, process injection, WFP traffic filtering, Event Log access, and command-driven kernel driver deployment.
Attack chain overview
The port 8888 chain has eight numbered stages and a separate GoFly driver analysis. Each component inherits execution context from the preceding stage rather than independently acquiring SYSTEM authority.
Statement.exe arrives as a WhatsApp attachment inside a ZIP archive. The outer file is an NRV2E-compressed wrapper whose sole purpose is concealment - on execution it decompresses, repairs, and transfers control to the real loader entirely within process memory, writing nothing to disk. The unpacked loader then screens the host against an eight-point environment checklist, attempts COM-based privilege elevation with a ShellExecuteW runas fallback, restores a clean copy of ntdll.dll to remove user-mode hooks, and injects an import-less downloader shellcode into the Windows Task Scheduler service host using PoolParty Variant 7 - a thread-pool IoCompletion technique that bypasses CreateRemoteThread-based detections. From this point forward every component runs under the inherited LocalSystem token.
The shellcode beacons to 61[.]18[.]208[.]27:8888 via HTTP POST, validates the server's response against the 0x0207 magic header, and receives a compound bundle. The bundle's first component is a position-independent reflective loader that Huffman-decodes a header-stomped Deployment DLL and manually maps it into memory. The Deployment DLL is the campaign's logistics center and immediately forks into three simultaneous paths.
The first path drops GoFly64.sys—a legitimately signed Chinese network-filter driver—creates a kernel-mode service, and submits Baidu security process PIDs to its exposed termination IOCTL (0x12227A), killing them from ring 0 before persistence is written. The second path executes the bundled vulkan-1.bin RAT container directly from memory, loading the final WebSocket RAT DLL before any file touches disk. The third path writes the Vulkan side-loading triplet (vulkaninfo-64.exe, vulkan-1.dll, vulkan-1.bin) to C:\Program Files\Common Files\ and registers a SYSTEM scheduled task named USOPrivate Kit - ensuring that on every subsequent boot, the Intel-signed vulkaninfo-64.exe launches, side-loads the malicious vulkan-1.dll, which reads and executes vulkan-1.bin, producing the same RAT DLL independently of the original injection.
The immediate path executes the WebSocket RAT DLL directly from memory within the LocalSystem Task Scheduler host, establishing an outbound TCP connection upgraded to WebSocket v13 and beaconing to 61[.]18[.]208[.]27:8888, identified at runtime by the analplug mutex and \\.\pipe\<PID>_pipe local IPC channel. The persistent path operates independently - on every subsequent boot the SYSTEM scheduled task fires vulkaninfo-64.exe, which side-loads vulkan-1.dll, reads vulkan-1.bin from disk, and re-executes the payload from within the SYSTEM-privileged vulkaninfo-64.exe process, entirely independently of the original injection.
The analysis below follows the WhatsApp-delivered wrapper through to the port 8888 WebSocket RAT. A related port 1234 package will be covered in a later post.
Stage 1: Delivery and Unpacking — Statement.exe
Statement-846143734.exe arrives as the campaign's only user-facing artifact, distributed through WhatsApp inside a ZIP archive. The file reveals nothing about its true purpose through static analysis: its malicious core is entirely concealed through NRV2E compression. On execution, a compact stub decompresses the real loader from an embedded stream, repairs filtered relative branch encodings, processes base relocations, rebuilds the import table, and transfers control into the resulting image, all entirely within the original process's memory space.
The outer wrapper performs no host checks, makes no network connections, and writes nothing to disk. Its sole function is concealment: keeping the loader's imports, strings, and control flow hidden from inspection of the original file. The wrapping and encoding scheme uses NRV2E compression combined with filtered relative-branch encoding applied to the embedded image.
Stage 2: Initial Loader — Host Screening, Elevation, and PoolParty Injection
The unpacked loader is the campaign's most complex component, responsible for three critical actions before any network activity occurs: determining whether the host is a suitable target, acquiring the necessary privileges, and handing execution to a SYSTEM-privileged process using a non-standard injection technique.
Figure 2 - Unpacked Loader: Main Function After Deobfuscation
Host Screening
The loader evaluates the environment against a multi-point checklist before taking any aggressive action. Through DirectDraw, it reads display dimensions. It checks that the system drive holds more than 3 GiB and evaluates CPU and physical-memory thresholds against minimum values. Display-device strings and power state are reviewed, followed by confirmation of LocalSystem and administrator token state. Security event log entries are examined - specifically IDs 4624 (logon events) and 1102 (audit log cleared) - and at least five specific environment-marker Registry keys must be present, spanning .NET Framework, Hyper-V, IIS, PowerShell, Internet Settings, and virtualization. Reparse-point state on core System32 DLLs (ntdll.dll, kernel32.dll, user32.dll) is also tested, and the loader checks for Baidu security products HipsDaemon.exe and HipsTray.exe. Any failure in these checks aborts the chain.
Two 50-millisecond D3D11 timing gates serve as destructive anti-emulation mechanisms. A slow response on the first gate destroys the protected shellcode container. A slow second result clears the selected target PID and prepared payload. Either failure leaves the remaining execution path inoperable, making the loader effectively non-functional in slow virtualized, instrumented, or emulated environments.
Eight integrity-interpreter variants protect 176 function entry points by inspecting first instruction bytes against INT3 (0xCC) and common hook opcodes (0xE8, 0xE9, 0xEA, 0xEB, 0xFF). Detection routes execution to an invalid-opcode termination path.
first = *(uint8_t *)protected_function;
modified = first == 0xCC || // breakpoint
first == 0xE9 || // near jump hook
first == 0xEB || // short jump hook
first == 0xE8 || // call patch
first == 0xEA || // far jump
first == 0xFF; // indirect call/jump group
if (modified)
__ud2();
Elevation and Privilege Acquisition
If the process is not already running as administrator, the loader attempts two elevation paths. The first builds Elevation:Administrator!new: COM monikers for CLSIDs {3AD05575-8857-4850-9277-11B85BDB8E09} and {BDB57FF2-79B9-4205-9447-F5FE85F37312}, initializes a COM local-server binding, calls CoGetObject, and uses the returned elevated interface in an IFileOperation-style workflow -a well-documented auto-elevation technique. Supporting material includes cmd.exe /C start /b and bdeunlock.exe references. If the COM path fails, the loader falls back to ShellExecuteW with the runas verb. Both paths depend on the target's UAC configuration; their success is an attempt, not a guarantee.
Once an elevated token is obtained, the loader calls AdjustTokenPrivileges to enable SeDebugPrivilege. This does not grant SYSTEM authority; it enables a privilege already present in the elevated administrator token, providing the ability to open and write to protected service host processes.
Before injecting, the loader maps the on-disk System32 copy of ntdll.dll and copies its clean executable section over the loaded module's .text region, restoring original user-mode syscall stubs and removing any hooks installed by endpoint detection products.
Figure 3 - Pre-Injection Preparation: Shellcode Reconstruction, ntdll Unhooking, and Process Injection
PoolParty Variant 7 Injection into Task Scheduler
With privileges established, the loader identifies the PID of the process hosting the Windows Task Scheduler service. Rather than using CreateRemoteThread -a well-monitored injection primitive -it uses PoolParty Variant 7, which weaponizes the Windows thread pool's IoCompletion mechanism.
The loader enumerates system handles, duplicates candidate handles from the target process, and identifies an object of type IoCompletion. It writes the 3,192-byte downloader shellcode into the target's memory, constructs a remote thread-pool-direct (TP_DIRECT) callback object pointing to the written shellcode, and queues the callback using ZwSetIoCompletion. An existing worker thread inside the Task Scheduler process then picks up the callback and executes the shellcode under the service's LocalSystem token. This inherited privilege is the foundation for everything that follows -no subsequent component needs to escalate.
After confirming injection, the loader monitors bdservicehost.exe once per second. When that process disappears -indicating that the GoFly driver has terminated it -the loader executes a self-deletion sequence using MoveFileExW and DeleteFileW to remove its own executable before calling ExitProcess.
Downloader Shellcode Reconstruction
The shellcode that the loader injects is not stored in plaintext. Its recovery from the embedded container involves four sequential transformations: the raw container is copied and de-framed from approximately 3,800 to 3,630 bytes; custom Huffman decoding produces 2,654 bytes; a modified ChaCha20 transform - which zeroes every third keystream byte before XOR - decrypts to 2,617 bytes; and custom GPU-style LZ decompression expands the final shellcode to its executable form of 3,192 bytes.
Stage 3: HTTP Shellcode — Registration and Stage Retrieval
Executing inside the LocalSystem Task Scheduler process as a PoolParty callback, this position-independent shellcode contains exactly nine functions and no import table. All API functions are resolved at runtime using a combined module/export ROR13-plus-add hash applied to loaded module export tables.
C2 Registration Request
The shellcode initializes a WinINet session with INTERNET_OPEN_TYPE_DIRECT, bypassing any system proxy configuration, and sends a single POST request to 61[.]18[.]208[.]27 on port 8888. The request uses an empty User-Agent string and a Connection: close header. The body is composed of three regions: a 50-byte header XOR-protected with key 0x3A (carrying registration identifier 0x00013009, framed size 0xA98, and magic value 0x02072024); a single clear DWORD at offset 50 with value 0x40; and a configuration section encrypted with a custom RC4 variant using fixed key 01 02 03 04 05. The configuration contains four copies of the 61[.]18[.]208[.]27:8888/HTTP endpoint plus deployment metadata for the Vulkan filenames consumed by later components.
Connection and request-creation failures sleep one second before retrying; send failures retry immediately without delay.
Figure 4 - HTTP Shellcode: C2 Registration Body Construction
Response Validation and Execution
The shellcode reads the server's response in chunks, capping collection at 4 MiB. Validation checks the received bytes against five structural criteria: matching identifier and magic values, a nonzero declared stage size, a correct framing-length relationship, and a received byte count consistent with the declarations. Executable content begins 54 bytes into the HTTP body - a 50-byte malware header followed by a 4-byte stage-size field.
On passing validation, the shellcode allocates a read-write-execute memory region equal to the declared stage size, copies the executable bytes from response offset 54, calls CreateThread with the allocation base as the thread's entry point and parameter, and waits indefinitely. The compound deployment bundle is now executing in memory within the LocalSystem Task Scheduler process.
Figure 5 - HTTP Shellcode: C2 Response Validation and Bundle Execution
Stage 4: Position-Independent Reflective Loader — Bundle Unpacking and DLL Mapping
The downloaded bundle's first bytes are a 27-function position-independent shellcode loader with no import table or embedded strings. It resolves native memory and library APIs from the PEB using export hashing. The remaining bytes are organized as four length-prefixed records: the legitimate vulkaninfo-64.exe binary, the malicious vulkan-1.dll, the RAT container vulkan-1.bin, and a compressed deployment configuration.
Deployment DLL Recovery
The loader scans up to 0x80000 bytes forward from its return address for an eight-byte marker at offset 0x14F0, validating it by confirming the byte sum equals 1,800. A little-endian compressed-size field at 0x14F8 identifies a Huffman stream starting at 0x14FC. The custom Huffman format prepends 256 big-endian frequency DWORDs and one big-endian decoded-size DWORD before an MSB-first bitstream.
Figure 6 - Reflective Loader Bundle Marker and Huffman Stream
Decompression produces a PE32+ DLL whose MZ and PE\0\0 signatures were deliberately erased a header-stomping technique that defeats file-format scanners expecting these magic bytes. The loader reads the surviving PE structures directly without repairing the signatures. It allocates 0x34000 bytes, maps the headers and sections, processes base relocations, resolves imports by name and ordinal, translates section flags to PAGE_* protections, decommits discardable sections, invokes each TLS callback with DLL_PROCESS_ATTACH, and finally calls the entry point at RVA 0x5E64. The third argument passed to that entry point is the original bundle base, allowing the deployment DLL to locate all four length-prefixed component records.
Figure 7 - Bundle Marker Scan, Huffman Decompression, and Deployment DLL Recovery
Stage 5: Deployment DLL — Orchestration, Driver Abuse, and Persistence
Running inside the inherited LocalSystem Task Scheduler context, the deployment DLL is the campaign's logistics center. It validates all four bundle records (each capped at 32 MiB), decompresses the configuration record to 2,708 bytes, and simultaneously begins two execution paths: launching the final payload immediately from memory and establishing durable on-disk persistence.
Immediate Payload Execution
The DLL locates the vulkan-1.bin record within the in-memory bundle, marks its first 0x2000 bytes executable, and creates a thread at the record's base. This executes the final RAT container before any file is written to disk - the attack is operationally active at the moment the persistence steps begin.
GoFly64.sys Driver Installation and Baidu Process Termination
The deployment DLL first attempts to open \\.\GoFly. If the GoFly device is unavailable, it extracts the embedded signed driver binary, writes it to %WINDIR%\System32\drivers\tp_<GetTickCount>.tmp, creates a kernel-mode file-system driver service named tp_<GetTickCount> with SERVICE_SYSTEM_START, and starts it. Once the GoFly device is accessible, the DLL enumerates running bdservicehost.exe and bduserhost.exe processes. Each PID greater than four is submitted to DeviceIoControl with IOCTL 0x12227A and a four-byte PID input buffer. The DLL then waits until bdservicehost.exe disappears, confirming the driver has acted before the chain continues. The following section covers the driver itself.
Figure 8 - Deployment DLL: GoFly64.sys Installation and Baidu Process Termination via IOCTL 0x12227A
Vulkan Side-Loading Package and SYSTEM Scheduled Task
With the Baidu security processes neutralized, the deployment DLL writes three files to C:\Program Files\Common Files: vulkaninfo-64.exe (a legitimate Intel-signed Khronos VulkanInfo utility), vulkan-1.dll (the malicious side-loaded loader), and vulkan-1.bin (the final RAT container). To vary file hashes across deployments, the DLL appends randomized transformed overlay data to the PE files and adjusts their internal offset records. A Tencent-detection path, keyed to the presence of QQPCRTP.exe and QQPCTray.exe, changes how the DLL overlay is finalized. Task creation pauses while 360tray.exe is running.
Task Scheduler COM APIs then register vulkaninfo-64.exe to run under the SYSTEM principal, using task name strings USOPrivate Kit and USOPrivate under \Microsoft\Windows (with \Microsoft\Windows\AppID as fallback). These strings superficially resemble legitimate Microsoft update-related task metadata.
Figure 9 - Deployment DLL: SYSTEM Scheduled Task Registration (USOPrivate Kit) via Task Scheduler COM APIs
In the dllhost.exe execution branch, the deployment DLL creates the mutex Global\Admindllhost!!! to prevent duplicate deployments - a second instance finding this mutex already held exits cleanly. Inside VSSVC.exe, the DLL enables SeDebugPrivilege in the existing token and migrates the complete bundle into the Task Scheduler process using ZwCreateThreadEx with CreateRemoteThread as fallback.
Figure 10 - Deployment DLL: Duplicate-Instance Mutex (Global\Admindllhost!!!) and Bundle Migration via ZwCreateThreadEx
Stage 5A: GoFly64.sys — Signed Driver Abused for BYOVD Process Termination
GoFly64.sys is an x64 kernel driver carrying a legitimate Authenticode code-signing certificate from a Nanjing, China company. Its code, PDB path (E:\Project\SmallProject\Panda\PandaTdi\bin\GoFly64.pdb), and Windows Filtering Platform strings identify it as a GoLink/PandaSpeed proxy and network-filter product. The same binary is catalogued in the LOLDrivers project under the recorded SHA-256 and MD5.
This legitimacy is the entire point of the BYOVD technique. Rather than developing or signing a new malicious driver - which requires a valid EV certificate and on modern Windows also Microsoft co-signing - the attacker embeds this already-signed binary and exploits its exposed administrative IOCTL interface. The driver loads without triggering driver-signing enforcement because its signature is genuine.
Kernel Process-Termination Path
IOCTL 0x12227A requires a four-byte input buffer, which it reads as a target PID. The driver excludes its own calling process but performs no other validation - there is no allow-list and no process-name check. It calls ZwOpenProcess with PROCESS_TERMINATE access, invokes ZwTerminateProcess with exit status zero, and closes the resulting handle. GoFly64.sys performs the termination from ring 0, allowing the deployment chain to stop security processes from kernel context using a legitimately signed binary.
Beyond the observed termination path, the driver creates \Device\GoFly and \DosDevices\GoFly, attaches filter devices to \Device\Tcp and \Device\Udp, registers four WFP callout/filter pairs under PandaSpeed Proxy Sub-Layer for IPv4 and IPv6 traffic, and installs process-creation and image-load notification callbacks. These reflect the driver's legitimate proxy heritage. Hosts-file manipulation is a latent capability exposed through other IOCTL cases but was not activated by the observed malware path.
Stage 6: DLL Side-Loading via vulkaninfo-64.exe and vulkan-1.dll
The Side-Loading Host: vulkaninfo-64.exe
vulkaninfo-64.exe is a genuine, Intel-Authenticode-signed build of the open-source Khronos VulkanInfo utility (version 1.3.204.1, PE timestamp 2022-02-25 19:30:48 UTC), sourced from the KhronosGroup GitHub repository. The utility's normal Vulkan device-enumeration code calls LoadLibraryA("vulkan-1.dll") during initialization. Because this name is unqualified, the Windows DLL search order checks the application directory first - and finds the attacker-placed malicious DLL. The legitimate binary neither detects this substitution nor participates in the attack; it simply provides a trusted, signed process context and the routine DLL-resolution call that activates the attack chain. When the SYSTEM scheduled task fires vulkaninfo-64.exe, the process eventually calls the vkEnumerateInstanceVersion function exported by vulkan-1.dll - the specific trigger point where the malicious DLL's attack logic begins.
The Side-Loaded Loader: vulkan-1.dll
The malicious vulkan-1.dll uses CRT/TLS constructor initialization to decrypt loader strings and indirect-call descriptors, with DllMain recording only the module handle on process attach. All attack behavior begins when the legitimate VulkanInfo binary calls the expected vkEnumerateInstanceVersion export.
At that trigger, the DLL calls GetModuleFileNameW to obtain its own installed path (C:\Program Files\Common Files\vulkan-1.dll), removes the last four characters (.dll), appends the decoded extension .bin, and opens the resulting path in binary-read mode. It reads the complete vulkan-1.bin file, attempts custom Huffman decompression, and falls back to the raw file bytes if decompression produces no output. The selected bytes are copied to a newly allocated local buffer; the first 0x2000 bytes of that buffer have their protection changed to PAGE_EXECUTE_READ, and the buffer is invoked as a function - with its own base passed as the argument. The DLL then calls Sleep(INFINITE), keeping the vulkaninfo-64.exe process alive indefinitely as an inconspicuous host.
Encryption of operational strings uses two transform modes: a mode-0 RC4-like KSA/PRGA transform for API-call metadata and a mode-2 add/rotate/XOR stream cipher for other configuration data.
Stage 7: Final-Payload Container — vulkan-1.bin
vulkan-1.bin is a minimal container whose sole purpose is reflectively loading the final RAT DLL. It locates an internal marker, reads the compressed-size field, and decodes an MSB-first custom Huffman stream - the same format used by the earlier reflective loader - to reconstruct a PE32+ DLL whose MZ and PE\0\0 signatures were deliberately erased. Using the same in-memory section-mapping approach, it allocates the image, maps sections, applies base relocations, resolves imports, and calls the mapped DLL's entry point. All campaign behavior from this point belongs to the final RAT.
Stage 8: VulcanRAT207.A — The Final WebSocket RAT
VulcanRAT207.A is the campaign's interactive operator platform and the terminal payload of the primary intrusion chain. On the immediate route it executes within the LocalSystem Task Scheduler host before any file touches disk; on persistent re-entry it runs inside the SYSTEM-privileged vulkaninfo-64.exe process launched by the USOPrivate Kit scheduled task. Both routes deliver the same operator capability surface under inherited SYSTEM authority.
Initialization, Configuration, and Identity
VulcanRAT207.A decrypts its configuration using a 20-round ChaCha-derived transform with 32-byte key f5f+daefsda3f52sxzvcx0vfewfazvfc, 8-byte nonce f5f+daef, and initial counter 1. All four decoded endpoint slots resolve to 61[.]18[.]208[.]27:8888 with protocol label HTTP.
Single-instance control is enforced by constructing a mutex name from the decrypted prefix analplug concatenated with a decoded configuration suffix. A call to CreateMutexA returns ERROR_ALREADY_EXISTS on a duplicate instance, triggering cleanup and ExitProcess(123). This mutex is separate from the deployment DLL's Global\Admindllhost!!! - both exist simultaneously in a fully deployed environment, but each controls a different component.
For local inter-process communication, VulcanRAT207.A creates a named pipe at \\.\pipe\<PID>_pipe. Its SDDL grants access to World, Interactive Users, Authenticated Users, Local System, and Administrators. The pipe supports 255 simultaneous instances, 64-KiB I/O buffers, and overlapped reads backed by an I/O completion port.
WebSocket C2 Protocol
VulcanRAT207.A opens a raw TCP socket to 61[.]18[.]208[.]27:8888, performs an HTTP/1.1 upgrade to WebSocket version 13, and validates the server's 101 Switching Protocols response and Sec-WebSocket-Accept header. Application messages flow inside standard WebSocket frames, each prefixed with a 50-byte custom header carrying the 0x0207 framework magic. The dispatcher reads a 32-bit command ID at header offset 0x1E and routes the payload body to the appropriate handler or tracked worker.
Confirmed C2 Commands
| Command ID | Action |
| 1 | Collect and return a victim profile |
| 3 | Start asynchronous state/configuration exchange |
| 5 | Stop and clean a managed process/session |
| 6 | Return the active 2,708-byte configuration |
| 0x0C | Enter extended capability dispatch |
| 0x0E | Write operator-supplied file data |
| 0x0F | Delete tracked cp.cfg |
| 0x10 | Execute client lifecycle/relaunch action |
| 0x12 | Enumerate local accounts |
| 0x13 | Create a local account and add it to Administrators |
| 0x14 | Change a local account password |
| 0x19 | Replace runtime configuration and restart |
| 0x2001-0x2003 | Execute shutdown/logoff action |
| 0xF006 | Download a URL to the Windows temp directory and launch it |
| 0xF007 | Write command-carried executable bytes and launch them |
| 0x10002 | Forward operator data to \\.\GoFly |
| 0x20002 | Replace clipboard text |
| 0x22000 | Inject a payload into explorer.exe |
| (high-numbered families) | Instantiate modules for shell, file management, services, Registry, network controls, Event Logs, processes, sessions, desktop control, and generalized injection |
Surveillance and Remote Control
VulcanRAT207.A collects an extensive victim profile on demand: hostname, OS version and architecture, physical memory, foreground-window context, user accounts, Terminal Services session list, network adapters, mapped drives, network resources, TCP/UDP ownership tables, running processes, installed services, installed software, open windows, and specific files and Registry values requested by the operator. Security event logs are accessed through both the classic API (OpenEventLogA/ReadEventLogA) and modern channels (EvtQuery/EvtNext/EvtRender with publisher-message formatting); selected classic logs can be erased via ClearEventLogW.
Interactive shell access uses redirected cmd.exe sessions. Keystroke capture combines raw input registration with GetAsyncKeyState polling. Clipboard workers read and replace text. Desktop capture uses DXGI/D3D11 output duplication with a GDI BitBlt fallback and optional NVIDIA hardware encoding. Remote-control capability attaches to the active input desktop, injects synthetic keyboard and mouse events, blocks local user input, replaces system cursor graphics, and adjusts HKCU\Control Panel\Cursors\CursorBaseSize. A PrivacyScreenClass window suppresses visual output visible to a physical user during remote-control sessions.
Network and Session Control
Windows Filtering Platform modules create selective filters under session name NetstatBlockSession, build per-process/address/port filter rules from BlockAddr_Out and BlockAddr_In patterns, and can block all inbound and outbound IPv4/IPv6 traffic under BlockAllTrafficSession - all reversible by later enumerating and deleting those filters. Terminal Services modules enumerate sessions and associated user data; a console-control module enables SeTcbPrivilege, calls WTSConnectSessionW, and can execute tscon to redirect sessions to the console.
Process Injection and Security Product Targeting
VulcanRAT207.A implements six distinct injection mechanisms: remote VirtualAlloc/WriteProcessMemory and ZwCreateThreadEx into explorer.exe; CreateRemoteThread injection into winlogon.exe; injection of operator-supplied payloads into operator-specified processes; injection into processes identified by window handle; remote shellcode execution using ZwCreateThreadEx with CreateRemoteThread fallback; and thread-context hijacking via GetThreadContext/SetThreadContext/ResumeThread.
Specialized stubs target Chinese security products: VulcanRAT207.A waits for ZhuDongFangYu.exe before directing injection at 360Tray.exe, and waits for QQPCRTP.exe before targeting QQPCTray.exe. These product-specific stubs are designed to bypass each tool's self-defense mechanisms.
Command-Driven Kernel Persistence
On operator command, VulcanRAT207.A receives arbitrary driver bytes, writes them to %WINDIR%\System32\drivers\tp_<GetTickCount>.tmp, creates a system-start file-system-driver service named tp_<GetTickCount>, and starts it. This provides an independent, operator-controlled kernel persistence mechanism entirely separate from the deployment DLL's bundled GoFly path - and operates under the already-inherited SYSTEM authority.
Conclusion
This chain divides delivery, privilege acquisition, retrieval, deployment, persistence, and remote access among separate components. PoolParty Variant 7 transfers execution into the LocalSystem Task Scheduler process once; the later shellcode, reflective loader, deployment DLL, and final RAT then operate with that inherited context. GoFly64.sys supplies a distinct kernel process-termination path for the deployment DLL.
The persistent route depends on a signed VulkanInfo utility loading an attacker-controlled DLL by an unqualified name. The DLL then opens the adjacent sidecar and reconstructs the same RAT reached by the immediate in-memory route. A separate port 1234 package shares the signed host and side-loading pattern, but leads to RomulusLoader and a different RAT; we will examine that branch in the next article.
For defenders, the component boundaries matter. The deployment DLL installs GoFly and selects the PIDs; the driver performs termination. The reflective loader maps the deployment DLL; the side-loaded DLL reads and executes the sidecar. Correlating the Task Scheduler injection, GoFly device use, SYSTEM task registration, and Vulkan package is more useful than attributing every action to the final RAT.
How Morphisec can help
Morphisec Automated Moving Target Defense is designed to disrupt malicious execution in memory, where this chain performs its unpacking, injection, and reflective loading. Organizations investigating this activity should also review unexpected SYSTEM tasks, the VulkanInfo side-loading package under Common Files, and GoFly driver loading or IOCTL activity alongside network connections to the port 8888 endpoint.
Indicators of compromise for the port 8888 chain
These indicators apply to the Statement.exe and VulcanRAT207.A chain. The signed VulkanInfo host hash is shared with the separate port 1234 package.
| Indicator | Details |
| 0c418989bbc836208a087dee8fd64210f58909dddf736bc94769c269f65c26eb | Type: SHA-256 Component: Tax-202609078869.exe Context: WhatsApp-delivered outer wrapper |
| be740b05caead2fa4521f42da0653a10f53029df5455ebafe4701ab3d41afdf9 | Type: SHA-256 Component: Packed Statement.exe Context: WhatsApp-delivered outer wrapper |
| 6833b1946ac219cf6ddf6cfbde1f81352b12d9125c8735961b5256216c4fdc49 | Type: SHA-256 Component: Unpacked Statement loader Context: Stage 1 loader (analyzed image) |
| 61[.]18[.]208[.]27:8888 | Type: Network Component: HTTP shellcode + final RAT Context: HTTP stage retrieval; WebSocket C2 |
| 0x00013009 / 0x02072024 | Type: Protocol Component: HTTP shellcode Context: Registration identifier and magic |
| cbf8ffe904a030c02b9def094f609b2c05a78fa5c7745d2d371d38dd460c58be | Type: SHA-256 Component: Downloaded deployment stage Context: 2,868,701-byte compound bundle |
| Global\Admindllhost!!! | Type: Mutex Component: Deployment DLL Context: dllhost.exe single-instance control |
| analplug<config suffix> | Type: Mutex Component: Final RAT (WebSocket) Context: RAT single-instance control |
| \\.\pipe\<PID>_pipe | Type: Named pipe Component: Final RAT (WebSocket) Context: Local IPC channel |
| C:\Program Files\Common Files\vulkaninfo-64.exe | Type: Path Component: Deployment DLL / legitimate EXE Context: Scheduled-task target |
| C:\Program Files\Common Files\vulkan-1.dll | Type: Path Component: Deployment DLL / malicious DLL Context: Side-loading bridge |
| C:\Program Files\Common Files\vulkan-1.bin | Type: Path Component: Deployment DLL / sidecar Context: Final RAT container |
| USOPrivate Kit / USOPrivate | Type: Task metadata Component: Deployment DLL Context: SYSTEM scheduled-task labels |
| %WINDIR%\System32\drivers\tp_<tick>.tmp | Type: Path Component: Deployment DLL or final RAT Context: GoFly or operator-supplied driver |
| tp_<tick> | Type: Service name Component: Deployment DLL or final RAT Context: Generated kernel-driver service |
| \\.\GoFly / IOCTL 0x12227A | Type: Device/IOCTL Component: Deployment DLL; RAT can forward Context: Baidu PID submission path |
| bdservicehost.exe / bduserhost.exe | Type: Process Component: Deployment DLL Context: GoFly termination targets |
| 2fdfdd13a0c548bb68c9d5aa8599a9265d4659da3e237fe7a42ac6ac06b9a06a | Type: SHA-256 Component: GoFly64.sys Context: Embedded vulnerable signed driver |
| 360Tray.exe / QQPCTray.exe | Type: Process Component: Final RAT (WebSocket) Context: Specialized injection targets |
| PrivacyScreenClass | Type: Window class Component: Final RAT (WebSocket) Context: Remote-desktop privacy screen |
| NetstatBlockSession / BlockAllTrafficSession | Type: WFP objects Component: Final RAT (WebSocket) Context: Traffic-blocking WFP sessions |
| facf78d474b66ed821288db41fa6ad8a7b6f30650eb12127cb3e9a3cc6146116 | Type: SHA-256 Component: VulkanInfo host (both chains) Context: Primary: vulkaninfo-64.exe; Part 2: renamed invoice .exe |
References
- Proofpoint TA4922 report (June 2026):
https://www.proofpoint.com/us/blog/threat-insight/ta4922-suspected-chinese-crime-group-going-global - EmergingThreats RomulusLoader YARA:
https://github.com/EmergingThreats/threatresearch/commit/f7721c28c9f30b905a3ec0c66a0eec0edffec8cb - Check Point ValleyRAT analysis:
https://research.checkpoint.com/2025/cracking-valleyrat-from-builder-secrets-to-kernel-rootkits
Stay up-to-date
Get the latest resources, news, and threat research delivered to your inbox.
