Overview

Our previous investigation traced a WhatsApp-delivered lure through Statement.exe to VulcanRAT207.A, a port 8888 WebSocket RAT running with SYSTEM privileges. Continued analysis of the recovered workspace identified a related Vulkan package that uses the same signed host but follows a different loader, installation, command-and-control (C2), and kernel-driver path. The second chain executes RomulusLoader and ultimately retrieves VulcanRAT207.B over TCP port 1234. Shared artifacts include the signed VulkanInfo host, package layout, endpoint IP address, ntdll.dll restoration behavior, and the 0x0207 protocol prefix.

The original delivery vector for this second package remains unconfirmed. In particular, neither the WhatsApp delivery mechanism nor the Statement.exe stage documented in the first investigation can be assumed for VulcanRAT207.B. The distinction is essential when correlating evidence and defining incident scope.

A Related Package, a Distinct Execution Chain

In our earlier analysis, “From WhatsApp to SYSTEM: Inside the VulcanRAT207.A Intrusion Chain” (https://www.morphisec.com/blog/vulcanrat207-a_intrusion-chain_explained/), we documented the Statement.exe-to-port-8888 WebSocket RAT path. The package examined here begins, as far as the available evidence establishes, with the same signed VulkanInfo executable. It loads an adjacent vulkan-1.dll, which reads vulkan-1.bin. The subsequent shellcode matches all four blocks of Proofpoint’s published RomulusLoader_Shellcode YARA rule and leads to VulcanRAT207.B. These are related packages, not evidence of identical initial access.

Stage 1: Reusing the Signed VulkanInfo Host

The host is byte for byte identical to the Intel signed VulkanInfo binary in the port 8888 chain, with the same SHA-256 and size. Here it has an invoice themed filename with a February 24, 2026 date. Its initialization calls LoadLibraryA(“vulkan-1.dll”), which resolves to the adjacent attacker placed DLL. The shared host and launch pattern connect the two posts; the DLL and sidecar contents must be analyzed separately.

Stage 2: Obfuscated DLL Launcher and Anti-Analysis

Unlike the simpler DLL in the port 8888 chain, this side loaded DLL contains extensive anti analysis logic. DllMain only caches the module handle; behavior starts when VulkanInfo calls vkEnumerateInstanceVersion.

At that trigger, the export generates randomized callback bytecode seeded from GetTickCount64 and hides the real payload callback among a crowd of generated decoy task graphs. Before execution proceeds, it runs a battery of environment checks: IsDebuggerPresent, the PEB BeingDebugged flag, NtGlobalFlag & 0x70, NtQueryInformationProcess(ProcessDebugPort), software breakpoint opcodes (0xCC) in its own detection code, and whether a 10,000-iteration timing loop exceeds 10 milliseconds. Detection can divert execution into randomized failure paths using delays, process exit, message-box prompts, or memory-protection changes. API calls are routed through randomized wrapper/lookup structures with XOR-decoded target names.

When the environment is accepted, the DLL resolves the adjacent sidecar path by removing the last four UTF-16 characters from its own path and appending .bin, reads the complete file, interprets the first little-endian DWORD (0xF98 = 3,992) as the shellcode length, allocates execute-read-write memory, and copies the shellcode bytes from file offset four. It then initializes COM, obtains the current object context with CoGetObjectContext, and uses an indirect COM-context callback to transfer execution to the shellcode before entering Sleep(INFINITE).

Stage 3: RomulusLoader Shellcode and Embedded Controller

The sidecar opens with a position-independent x64 shellcode at offset 4 (the first DWORD, 0xF98, declares the shellcode length). The shellcode reads the embedded controller length (0x47400) from offset 0xF9C, copies the encrypted blob starting at 0xFA0 into newly allocated read-write memory, and decrypts it using a modified-RC4 transform: an inline key block precedes the encrypted data, and the PRGA XORs each data byte with two permutation-table entries (S[i] ^ S[j]) rather than one – a deliberate deviation from standard RC4 that alters the keystream.

The resulting bytes form a header-stomped PE32+ DLL – the RomulusLoader controller. The shellcode maps it reflectively: allocating its preferred or fallback base, copying headers and sections, processing x86 and x64 base relocations, resolving imports, executing TLS callbacks, applying per-section memory protections, and freeing discardable sections. It calls the entry point as DllMain(image_base, DLL_PROCESS_ATTACH, package_base) and, on success, resolves the exported name run and calls run(package_base), passing the controller the complete package context needed to consume the appended configuration.

Figure 1  RomulusLoader shellcode

The encrypted configuration appended to the package (at offset 0x483A4) decodes to four identical endpoint records: 61[.]18[.]208[.]27:1234/TCP with campaign ID 0903 and a 300,000-millisecond connection timeout. The shellcode matches all four blocks of Proofpoint’s published RomulusLoader_Shellcode YARA rule.

The configuration is 2,696 bytes at package offset `0x483A4`, encrypted using the modified RC4 variant with key `01 02 03 04 05` :

• C2 endpoints: 61[.]18[.]208[.]27:1234/TCP ×4
• Campaign ID: 0903
• Connection timeout: 300,000 ms (5 minutes)
• Enabled: true
• Executable: 444.exe
• Loader DLL: vulkan-1.dll
• Package: vulkan-1.bin
• Common files path: C:\Program Files\Common Files

Stage 4: RomulusLoader Controller — Installation, Injection, and C2

The reflectively mapped controller is the installer, persistence coordinator, and first-stage downloader for the port-1234 branch. It exposes a single meaningful export – run – which the shellcode loader calls after mapping the DLL. On invocation it performs the complete top-level initialization sequence: parsing the supplied package, decrypting the embedded configuration, restoring a clean copy of ntdll.dll, initializing Winsock, building the C2 controller object, and selecting the appropriate install, persistence, injection, or C2 path based on the name of the hosting process.

Configuration Parsing and Decryption

The controller walks the package metadata to locate a fixed configuration block and decrypts it using a modified-RC4 primitive with static five-byte key 01 02 03 04 05. The modification is deliberate and analytically significant: after updating and swapping permutation entries, the keystream byte is computed as S[i] ^ S[j] rather than standard RC4’s single indexed permutation byte. A standard RC4 implementation will therefore fail to decrypt the configuration even when supplied with the correct key. The same transform is applied symmetrically to re-encrypt configuration data before passing it to the next stage.

The recovered configuration decodes to four identical endpoint records pointing to 61[.]18[.]208[.]27:1234/TCP, with campaign ID 0903, a 300,000-millisecond connection timeout, and an install directory of C:\Program Files\Common Files. The installed files are named 444.exe (the relocated executable), vulkan-1.dll, and vulkan-1.bin. The controller also attempts to reload an optional install.cfg from the install directory at runtime – accepting it only when its size is exactly 0xA88 bytes and applying the same modified-RC4 transform to read it over the active configuration.

Figure 2  RomulusLoader configuration

ntdll.dll Restoration 

Before installation, injection, or network activity, the controller maps a clean copy of ntdll.dll from disk and overwrites the loaded executable section. This removes user mode hooks before sensitive operations. The port 8888 chain also restores ntdll.dll, making this a shared behavior without implying identical code.

Figure 3  ntdll restoration

Installation and Privilege

The controller queries its own process image and branches its behavior accordingly. When running in a standard user process and the installed 444.exe is absent, it installs itself. Under an administrator token it relocates the current executable to 444.exe in C:\Program Files\Common Files, moves vulkan-1.dll and vulkan-1.bin beside it, and applies read-only, hidden, and system file attributes to all three files to hinder manual discovery and removal. It then registers 444.exe as a boot-triggered SYSTEM scheduled task named Microsoft Compatibility system, which fires immediately after registration to provide LocalSystem authority on all subsequent activations.

Without administrator privileges the controller attempts an RPC-based elevation path. The implementation is heavily obfuscated behind a multi-way encoded dispatch machine with flattened control flow, asynchronous RPC state management, token and process-attribute operations, and debug-event handling. The specific RPC endpoint targeted and whether this constitutes a known or novel elevation technique remain unresolved in the current analysis.

When hosted by the Windows Task Scheduler service host, the controller checks the Schedule service context and either launches the C2 worker, terminates the installed 444.exe process, or enters retry-and-injection logic. When hosted by the Volume Shadow Copy service, it repeatedly executes a spawn-and-inject workflow while monitoring the child process result – providing an additional migration route into the intended execution environment.

Figure 4  Persistent installation

Injection Framework

The controller builds an internal dispatch object that exposes nine dispatch entries spanning execution, injection, architecture inspection, and kernel-driver communication: injection into an existing process; creation of a suspended process followed by injection; process creation in a selected session; process creation under a user or supplied token; remote-thread injection; thread-context hijacking; embedded PE architecture detection; and kernel driver IOCTL dispatch. Before opening any C2 connection, the controller invokes the IOCTL dispatch slot with code 0x22E008 and the selected endpoint port number, registering the active C2 port with the associated kernel component at \\.\{F8284233-48F4-4680-ADDD-F8284233} before the first outbound packet is sent.

Figure 5  Injection framework

C2 Transport Architecture 

The controller implements three C2 transports selected by the protocol label in its decrypted configuration. All four endpoint records in this sample select TCP; UDP/KCP and HTTP/WebSocket are supported by the code but were not enabled in the observed configuration.

Direct TCP uses overlapped Winsock send and receive operations with caller-supplied timeouts. The UDP option implements a reliable stream using an embedded KCP library over a connected datagram socket, with a custom outer handshake carrying magic value 0xBB4F and version 1. The HTTP option embeds a complete libwebsockets client stack – including context creation, connection management, WebSocket upgrade, and frame writing – operating independently of the Windows HTTP stack.

C2 Frame Structure

All three transports share the same 50-byte application header:

Offset	Size	Field
0x00	0x0E	Random per-message header key
0x0E	4	Header-key length (4-14 bytes)
0x12	0x0C	Reserved / protected header area
0x1E	4	Command
0x22	4	Plain payload size
0x26	4	Wire / compressed payload size
0x2A	4	Sequence or status value
0x2E	4	Protocol magic (0x02072024)

The controller uses a 50 byte application header. Its magic value 0x02072024 appears at offset 0x2E and shares the 0x0207 prefix observed in the first post. After connecting, it sends command 0x13000 in a 50 byte initial request to trigger stage delivery. The common prefix links the packages at the protocol level, while the transport and later payload behavior remain distinct.

Outbound message bodies are compressed with an embedded zlib implementation and protected using the same modified-RC4 primitive with static key f5f+daefsda3f52sxzvcx0vfewfazvfcdsafd4169. A separately generated random key protects each message header tail. The receive path reverses header protection, validates frame sizes, applies the static-key transform, decompresses the result, and dispatches the decoded packet to the command handler.

Command Handling and Stage Execution 

Two command codes were confirmed in the packet handler. Command 0x13000 triggers next-stage execution: the controller re-encrypts the active configuration, appends it to the received package, allocates a fresh memory region for the complete bundle, reads the leading shellcode-length field from the package, allocates a separate executable memory region for the shellcode alone, copies the shellcode bytes from package offset 4, and launches a new thread with the shellcode as its entry point and the full package buffer as its parameter – then sleeps indefinitely. Control transfers entirely to the received shellcode, which locates its own appended configuration using the same package-parsing convention established by the earlier stages. This is how VulcanRAT207.B arrives and executes. Command 0x18000 repeatedly exhausts process memory; its operational purpose remains unresolved.

Stage 5: VulcanRAT207.B — The C2-Delivered RAT

VulcanRAT207.B is the feature-complete operator platform for the port-1234 branch, delivered by the RomulusLoader controller on successful C2 check-in. It is not a loader or a downloader – it is the hands-on-keyboard layer of the intrusion, implementing the full operator command protocol, three interchangeable C2 transports, host surveillance, interactive remote desktop, file transfer, command execution, service and Registry administration, process manipulation, keylogging, TCP relaying, WMI queries, Event Log access, window management, and dual kernel-driver-assisted evasion paths.

On initialization the DLL parses the loader-supplied package, decrypts its runtime configuration, restores a clean copy of ntdll.dll from disk to remove user-mode hooks, initializes Winsock, and builds a central dispatch object containing function pointers for every major capability. It then inspects the name and command line of the hosting process and selects a role accordingly – the same DLL can behave as a process-concealment hook, a service supervisor, a launch-and-monitor loop, or a full C2 worker depending on where it is placed.

Process-Role Dispatch

The role selection is operationally significant because it reveals the malware’s expectation of running as a coordinated multi-process deployment. When hosted by Task Manager, the payload installs a hook around the Windows process-information API and exits the worker thread – leaving the host process running normally while silently filtering its output to hide selected PIDs from the visible process list. When hosted by the Windows Task Scheduler service host, it creates and supervises the surveillance and C2 workers, restarting them on failure. The Schedule execution mode stops an existing installed image and repeatedly relaunches the configured process, treating exit code 123 as a controlled stop signal – the same exit code used by VulcanRAT207.A’s mutex-collision path. When hosted by the Volume Shadow Copy service it executes a similar retry loop before terminating the current process. The default path constructs the configured installation path, checks whether the image exists, and either uses service-side injection on a native 64-bit system or launches the configured component directly.

C2 Protocol

VulcanRAT207.B inherits the four-record 61[.]18[.]208[.]27:1234/TCP configuration (campaign ID 0903, 300,000-millisecond timeout) from the loader package – the C2 endpoint is not a static string in the binary but is materialized at runtime from the decoded configuration, which is why it does not appear in the DLL’s ordinary string table. Frame structure uses a 50-byte header with magic 0x020721A4, predictable 4-14-byte per-message header keys, optional zlib-compressed bodies, and command-11 heartbeats. Named-pipe IPC for cross-session data uses the template \\.\Pipe\<PID>_Local_<session>. A delayed reinjection command creates a mutex from the active endpoint address concatenated with the port number – with the current configuration the concrete mutex name is 61[.]18[.]208[.]271234.

C2 Transport Architecture

The RAT independently implements TCP, reliable UDP through KCP, and HTTP/WebSocket transport behind a common interface. This is a capability identified in the payload; the supplied configuration selects TCP.

Direct TCP uses overlapped send and receive operations with event-based cancellation and caller-supplied timeouts. The reliable UDP transport wraps ordinary UDP datagrams in an embedded KCP implementation: incoming datagrams are fed into the KCP parser, which validates segment headers, processes acknowledgements and window updates, reorders segments, and delivers reassembled data to the normal C2 byte buffer; outbound data is divided into KCP segments, placed on a send queue, and periodically flushed with retransmission logic. Network observers may therefore see ordered C2 traffic over UDP – detection logic that assumes a reliable protocol must use TCP will miss this transport. The HTTP transport embeds a complete libwebsockets client stack, operating entirely independently of the Windows HTTP APIs, with its own context creation, connection management, WebSocket upgrade negotiation, and frame writing.

The two-level command dispatch model selects a capability family first (remote desktop, service management, file manager, and so on), then creates a dedicated channel for that family with its own transport connection, registration frame, byte buffer, and opcode dispatcher. This explains the large number of small frame-dispatch functions in the binary – they are per-capability channel adapters, not redundant network clients.

Identified C2 Command Handlers

Command	Action
1, 3, 4	Registration/public-IP handling, per-session IPC routing, transport control
5-9	Uninstall; return/update configuration; enumerate WTS sessions; start TCP proxy
12-16	Replace installed payload; configure/append/clear clipboard rules; migrate loader
18-20, 22	Enumerate users; create local administrator; set password; update registration token
0x1000	Dynamic C2-supplied payload registration, execution, inventory, and removal
0x2001-0x2003	Logoff, reboot, or shutdown
0x3000	File manager: drives/directories, upload/download, search, copy/move/delete/rename, ShellExecute, RAR, Telegram collection
0x4000	Session activity/telemetry and remote-desktop routing
0x5000	Process inventory/control/injection; driver-assisted termination (TrueSight installer)
0x6000, 0x7000, 0x9000	Service manager; interactive shell; Registry browser
0xB000, 0xD000, 0xE000	TCP relay/pivot; TCP/UDP connection inventory; keylog retrieval/deletion
0xF005	Download URL to disk and execute
0x10001, 0x10002	Install/configure PoisonX-style driver; terminate PID via PoisonX and TrueSight
0x11000, 0x12000	Windows Event Log read/export/clear; enumerate/show/hide windows
0x13000	Inject an updated supplied stage into the active session
0x14000, 0x15000	Installed-software inventory; operator-supplied WMI query
0x18000	Intentionally exhaust process memory (operational purpose unresolved)
0x20001-0x20003	Display message box; replace Unicode clipboard; delayed self-reinjection

Surveillance and Host Reconnaissance

VulcanRAT207.B collects an extensive host profile: process inventory including parent PIDs and executable paths, Windows version and architecture, WTS session and account data, installed-software enumeration from Registry locations, service configuration and state, Registry content across all five standard hive roots, TCP and UDP connection ownership tables, top-level and child window inventory, and arbitrary WMI query results. The WMI serializer contains localized Chinese state labels – 未知状态 (unknown status), 已禁用 (disabled), 排队中 (queued), 已准备 (ready), and 运行中 (running) – embedded in the binary, suggesting Chinese-language development or localization artifacts, without independently establishing developer identity or attribution. Camera-device enumeration reads the friendly name of each DirectShow video-capture device, confirming device discovery capability; image capture from those devices was not confirmed in the analyzed path.

Interactive Remote Desktop

The remote-desktop implementation is a full interactive operator capability rather than a screenshot feature. It creates GDI device contexts and DIB-backed pixel buffers, captures complete frames or changed pixel strips using delta encoding, transmits cursor position and cursor imagery separately, and accepts keyboard and mouse events that are translated to the active desktop coordinate system. The worker attaches its thread to the current input desktop before injecting input events.

To reduce interference from the local user, VulcanRAT207.B can block local keyboard and mouse input, hide the system cursor, replace all system cursors with transparent versions, and disable desktop wallpaper and visual effects. A privacy-screen mechanism suppresses visual output visible to the physical user during remote-control sessions – the same PrivacyScreenClass pattern observed in VulcanRAT207.A. All changes are reversed during teardown.

For session-aware injection, the remote-desktop module targets winlogon.exe with a small embedded stub launched via remote thread, and falls back to explorer.exe or ctfmon.exe for operator-supplied desktop payloads. A third path constructs a cmd.exe process on the WinSta0\Winlogon desktop, providing a command session in the Winlogon desktop context separate from the normal redirected shell channel.

Security Product Targeting and Process Concealment

VulcanRAT207.B monitors for ZhuDongFangYu.exe and QQPCRTP.exe before injecting x86 stubs into 360Tray.exe and QQPCTray.exe respectively. These stubs are designed to repeatedly terminate the targeted security processes using product-aware interaction. When placed in Task Manager, VulcanRAT207.B hooks the Windows process-information API in memory to filter SystemProcessInformation output, hiding selected PIDs – including the Task Scheduler service host and its svchost.exe and dllhost.exe descendants – from any tool that calls this API, including Task Manager itself. Before selected termination paths the payload marks the current process as critical using the Windows process-termination-on-exit mechanism, making forced termination of the malware trigger a system crash.

Dual Kernel-Driver Evasion Paths

Two distinct kernel-driver interfaces are available through operator command and must not be confused with the primary chain’s GoFly64.sys path. The PoisonX-style path opens \\.\{F8284233-48F4-4680-ADDD-F8284233}. Command 0x10001 installs operator-supplied driver bytes using the same tp_<GetTickCount> service-creation mechanism and sends IOCTL 0x22E008 with the active C2 port in decimal ASCII to register the port with the driver. Command 0x10002 sends IOCTL 0x22E010 with the target PID in decimal ASCII, requesting kernel-mode process termination.

The TrueSight path opens \\.\TrueSight. The same 0x10002 handler sends IOCTL 0x22E044 with a four-byte PID; if the TrueSight device is absent, VulcanRAT207.B first writes operator-supplied driver bytes and creates the tp_<tick> service before reopening the device. These device paths, IOCTLs, and PID-encoding formats are all distinct from GoFly64.sys (\\.\GoFly, IOCTL 0x12227A, four-byte raw PID) – cross-variant misattribution of driver capabilities is a concrete analytical risk.

Figure 6  Driver evasion paths in the port 1234 RAT compared with GoFly

Conclusion

VulcanRAT207.B demonstrates that a shared signed execution host can lead to materially different post-exploitation behavior. As in the previously documented VulcanRAT207.A chain, the attacker-controlled package uses VulkanInfo DLL side-loading. Here, however, an obfuscated launcher executes RomulusLoader shellcode; the reflectively mapped controller installs 444.exe, establishes SYSTEM-task persistence, and requests a separate RAT over port 1234. The resulting payload provides interactive remote control, process concealment, and PoisonX-style and TrueSight driver interfaces, distinct from the GoFly64.sys path analyzed in the port 8888 chain.

The identical host hash, common file layout, shared endpoint IP, ntdll.dll restoration pattern, and 0x0207 protocol prefix support a relationship between the packages. They do not establish identical delivery or pre-Vulkan execution stages. The initial delivery vector of this second package remains unconfirmed. For defenders, the distinction matters: detection and incident-scoping decisions should preserve both the common artifacts and the branch-specific loader, persistence, protocol, and driver behaviors.

How Morphisec can help

The chain combines a trusted signed executable, DLL side-loading, in-memory shellcode execution, reflective PE loading, and kernel-driver-assisted evasion. Morphisec Automated Moving Target Defense (AMTD) is designed to disrupt malicious execution in memory, including classes of activity represented by shellcode execution and reflective loading. During investigation, defenders should examine unexpected executions of the signed VulkanInfo host, adjacent vulkan-1.dll and vulkan-1.bin files, the “Microsoft Compatibility system” scheduled task, traffic to the port 1234 endpoint, and the PoisonX-style and TrueSight device interfaces. These indicators should be kept distinct from the GoFly artifacts described in the first post.

Indicators of compromise

These indicators apply to the RomulusLoader and VulcanRAT207.B branch. The signed VulkanInfo host hash is also present in the port 8888 chain.

Indicator	Details
facf78d474b66ed821288db41fa6ad8a7b6f30650eb12127cb3e9a3cc6146116	Type: SHA-256 Component: VulkanInfo host (both chains) Context: Primary: vulkaninfo-64.exe; Part 2: renamed invoice .exe
61[.]18[.]208[.]27:1234	Type: Network Component: Part 2 RomulusLoader Context: Separate port-1234 branch C2
7a0d05caf79d3a5939a536756c2b32347daa200d82f979fdf8590e41e04d6da7	Type: SHA-256 Component: Part 2 vulkan-1.dll Context: Anti-analysis sidecar launcher
7c0bc95d83263c0644420d4df9486ee47dc07c70455e6abb1c99996f370d3579	Type: SHA-256 Component: Part 2 vulkan-1.bin Context: RomulusLoader shellcode package
442f5c7249459a26ba055cda56c1b89cbe1cbf1d875eaf0567896ef4906e32d4	Type: SHA-256 Component: Part 2 RomulusLoader controller Context: Analyst-repaired 291,840-byte PE
C:\Program Files\Common Files\444.exe / install.cfg	Type: Files Component: Part 2 controller Context: Persistent installation artifacts
Microsoft Compatibility system	Type: Task Component: Part 2 controller Context: Part 2 SYSTEM boot task
\\.\{F8284233-48F4-4680-ADDD-F8284233} / 0x22E008	Type: Device/IOCTL Component: Part 2 controller + C2 RAT Context: PoisonX-style port notification
\\.\{F8284233-48F4-4680-ADDD-F8284233} / 0x22E010	Type: Device/IOCTL Component: Part 2 C2-returned RAT Context: PoisonX kernel PID termination
\\.\TrueSight / 0x22E044	Type: Device/IOCTL Component: Part 2 C2-returned RAT Context: TrueSight kernel PID termination
f0a02ebd2edc6b708dd7c43c1a830453aadf028594e0d3b9d851eb38bf560b93	Type: SHA-256 Component: Part 2 C2-returned full RAT Context: 428,032-byte operator platform

References

1. Proofpoint TA4922 report (June 2026):
   https://www.proofpoint.com/us/blog/threat-insight/ta4922-suspected-chinese-crime-group-going-global
2. EmergingThreats RomulusLoader YARA:
   https://github.com/EmergingThreats/threatresearch/commit/f7721c28c9f30b905a3ec0c66a0eec0edffec8cb
3. Check Point ValleyRAT analysis:
   https://research.checkpoint.com/2025/cracking-valleyrat-from-builder-secrets-to-kernel-rootkits

About the author

Shmuel Uzan

Security Researcher

Shmuel Uzan is a skilled security researcher with nearly a decade of experience. Shmuel holds a Bachelor of Software Engineering from Shamoon College of Engineering.