medium🎣Phishing

investigatedMarch 16, 2026publishedMarch 16, 2026

SilverFox Deploys VM-Obfuscated RAT with ChaCha20 Encryption and RPC-Based C2 Disguised as Trend Micro

#phishing#social-engineering#credential-theft#c2#exploit#reverse-engineering#spearphishing

Published: 2026-03-16 | Author: BGI | Investigation Date: 2026-03-16

TL;DR

A SilverFox campaign variant tagged bg[qtsc] dropped a 2.1MB RAT on MalwareBazaar on March 16 disguised as a Trend Micro Titanium installer. The binary hides its entire logic inside a custom virtual machine with a binary search tree dispatcher, encrypts code regions and C2 payloads with ChaCha20, and communicates with its operators over Windows MSRPC -- a protocol so deeply embedded in corporate networks that most security stacks will never flag it. This is the second SilverFox campaign we have documented in 48 hours, and it represents a measurable escalation in obfuscation sophistication over the ValleyRAT/Winos4.0 cluster we reported on March 14.

The Discipline File That Isn't

The filename tells you everything about who this is for and why they will click it:

2026第一季度违纪人员内部调查信息.exe

Translated: "2026 Q1 Internal Investigation Information on Disciplinary Personnel."

This is a fear lure. It implies the recipient is either the subject of an internal disciplinary investigation or is responsible for handling one. In Chinese corporate and government environments -- where disciplinary reviews carry career-ending weight -- this kind of document demands immediate attention. The victim will not stop to wonder why an internal investigation file arrived as a .exe. They will open it. The PE manifest requests requireAdministrator privileges, which the fake "Trend Micro installer" context makes feel routine.

The social engineering is precise. The technical execution behind it is several orders of magnitude more sophisticated than the lure suggests.

Two SilverFox Campaigns in 48 Hours

This investigation lands two days after we published The SilverFox Den, which documented a five-sample ValleyRAT cluster distributed through GFW bypass tools, fake HR documents, and trojanized Chinese-language utilities. That cluster operated on the Winos4.0 framework -- essentially modernized Gh0st RAT -- with KCP transport and XOR-encrypted DLL payloads.

The sample analyzed here shares the SilverFox attribution but represents a different operational tier:

Characteristic	March 14 Cluster (ValleyRAT)	March 16 Sample (bg[qtsc])
Obfuscation	XOR-encrypted DLLs, MPRESS packing	Full custom VM with binary search tree dispatcher
Encryption	Single-byte and cyclical XOR	ChaCha20/Salsa20 stream cipher
C2 Protocol	KCP reliable UDP, Winos4.0 binary protocol	Windows MSRPC (`NdrAsyncClientCall`)
Anti-Analysis	PEB debugger check, process enum, date window	CPUID VM detection, NtRemoveProcessDebug, DbgUiSetThreadDebugObject, self-modifying code
Masquerade	Chinese screenshot tools, VPN apps	Trend Micro Titanium 17.9 installer
Framework	Winos4.0 (Gh0st RAT evolution)	Custom VM-based RAT

Two simultaneous SilverFox campaigns using entirely different toolchains, targeting the same victim population, within the same week. This is not one operator with one tool. This is an active operation with a diversified arsenal.

Sample Identification

Field	Value
SHA256	`e6d8944deced4b6ec228cb1af210eb19d527107af2688b401de5503174bc1fbe`
MD5	`443a741c1cdde875e8bc0307d9a657c7`
SHA1	`a46c59be8e82cb05d49f288cb28df2333ee53b2b`
Imphash	`03178db0411f49be0e26499ca1def241`
File Type	PE32+ executable (GUI) x86-64
File Size	2,212,864 bytes (2.11 MB)
First Seen	2026-03-16 10:03:24 UTC
Reporter	CNGaoLing (MalwareBazaar)
Tags	SilverFox, Trojan/SilverFox.bg[qtsc]
Compile Timestamp	2070-09-03 00:58:13 UTC -- FORGED

The compilation timestamp is set 44 years in the future. This is not accidental. It is a deliberate anti-forensics measure designed to break timeline correlation in incident response -- if every file in an investigation timeline sorts by last-modified or compile time, a date in 2070 becomes invisible noise. This timestamp forgery pattern has been documented in multiple prior SilverFox samples.

Fake Identity: Impersonating Trend Micro

The PE version info block is entirely fabricated:

CompanyName:      Trend Micro Inc.
FileDescription:  Trend Micro Installer
FileVersion:      17.9.0.1089
InternalName:     7zsfx.exe
LegalCopyright:   Copyright (C) 2025 Trend Micro Incorporated. All rights reserved.
ProductName:      Trend Micro Titanium
ProductVersion:   17.9
PrivateBuild:     Build 1089 - None

This accomplishes three things simultaneously. First, it provides cover for the UAC elevation prompt -- users expect security software installers to request administrator privileges. Second, it may trigger AV whitelisting heuristics that give known security vendor binaries a pass on behavioral analysis. Third, the 7zsfx.exe internal name mimics a 7-Zip self-extracting archive, a legitimate installer format used by many software vendors including Trend Micro.

There is no Authenticode signature on this binary. It relies entirely on the version info strings and filename to maintain its disguise. A trivial detection: any PE claiming to be Trend Micro without Trend Micro's code signing certificate is malicious.

The Virtual Machine: Obfuscation at an Architectural Level

This is where the sample distinguishes itself from the broader SilverFox ecosystem. The entire malware logic has been compiled into a custom virtual machine's bytecode. Native x86-64 instructions serve only as the VM runtime. There are no readable function calls, no recoverable control flow, and no strings -- everything meaningful is buried in thousands of opaque handler stubs that only the VM dispatcher can navigate.

How the VM Dispatcher Works

The VM operates through three components: a state computation layer, a binary search tree dispatcher, and atomic handler fragments.

State Computation. Two 8-byte constants are loaded from the stack and XOR'd together to produce a virtual program counter:

movabs rax, 0x978c3bc608009495   ; first constant
movabs rax, 0x535a1c1468c4c665   ; XOR mask
xor    rax, [rsp+0x28]           ; compute virtual PC
; Result: 0xC4D627D260C452F0     ; initial VM state

Binary Search Tree Dispatch. The virtual PC is matched against a tree of compare-and-branch instructions:

cmp rax, 0xc4d627d260c452f0     ; compare virtual PC
je  handler_at_0x140009cd2       ; jump to matching handler

All comparison targets share the upper 32-bit prefix 0xC4D627D2, with varying lower halves encoding thousands of unique VM states. This structure makes static analysis catastrophically expensive -- you cannot determine what the malware does without either running the VM or manually tracing every branch of a multi-thousand-node binary tree.

Handler Execution. Each handler performs a single atomic operation -- a load, a store, an arithmetic operation, an API call -- then updates the virtual stack with the next-state value and jumps back to the dispatch trampoline at 0x140010A10. The functional code never executes linearly. It bounces.

The VM Constant Table

The .data section contains 2,816 entries in a rigid 6-byte format: four bytes of data followed by two 0xCC sentinel bytes. These encode VM constants including string fragments (like "XenO" for hypervisor detection), configuration parameters, and runtime state values. The 0xCC padding is deliberate -- 0xCC is the x86 int3 (breakpoint) opcode, meaning any attempt to execute this data section triggers a debug exception. It is an anti-analysis trap baked into the data layout itself.

[4 bytes: data][0xCC][0xCC]  <-- repeating, 2816 entries

For reverse engineers: the VM entry point is 0x140010A30, the main dispatcher body spans from 0x140007140 (16KB+), and the dispatch trampoline sits at 0x140010A10. The .text section is 1.5MB -- almost all of it is handler stubs.

ChaCha20: Not Just for C2

The sample uses ChaCha20 (or its closely related variant Salsa20) for two distinct purposes: decrypting code sections in memory and protecting C2 payloads in transit.

We identified two ChaCha20 initialization sites through stackstring analysis. Both construct the standard ChaCha20 constant "expand 32-byte k" on the stack before loading encrypted key material:

Site 1 -- Code Decryption (0x14000B4B1):

mov DWORD PTR [rsp+0xa10], 0x61707865   ; "expa"
mov DWORD PTR [rsp+0xa14], 0x3320646e   ; "nd 3"
mov DWORD PTR [rsp+0xa18], 0x79622d32   ; "2-by"
mov DWORD PTR [rsp+0xa1c], 0x6b206574   ; "te k"
movabs rax, 0xacc3b70678316565          ; encrypted key [0:7]
movabs rax, 0x5cc7197fd5676f18          ; encrypted key [8:15]

Site 2 -- C2 Payload Decryption (0x14000D438):

mov DWORD PTR [rsp+0x9d4], 0x3320646e   ; "nd 3"
mov DWORD PTR [rsp+0x9d8], 0x79622d32   ; "2-by"
mov DWORD PTR [rsp+0x9dc], 0x6b206574   ; "te k"
movabs rax, 0xfb2a0535896f968d           ; encrypted key [0:7]
movabs rax, 0x0b2eab4c0ee05174           ; encrypted key [8:15]

The key material is itself obfuscated -- XOR'd with a runtime-derived value before passing to the ChaCha20 routine. This double indirection means that even extracting the key bytes from the binary is insufficient; you need to trace the VM execution to recover the actual decryption key.

High-entropy regions at file offsets 0x18E000-0x19C000 and 0x1BB000-0x1C6000 within the .rsrc section correspond to encrypted payload blobs masquerading as Windows BITMAP resources. Section entropies appear moderate at the aggregate level (5.08 for .rsrc), but these localized zones hit 7.5-7.95 -- consistent with ChaCha20-encrypted ciphertext.

The Kill Chain: Five Stages to Full Compromise

DELIVERY ──> EXECUTION ──> VM INIT ──> DECRYPTION ──> INJECTION ──> C2

  Spearphish     UAC prompt     CPUID check     ChaCha20       Shellcode     MSRPC
  attachment     (fake Trend    IsDebugger      decrypts       VirtualProtect  NdrAsync
  .exe lure      Micro)         NtRemove        code in-place  (RWX)          ClientCall
                                ProcessDebug                   Process hollow
                                DbgUiSet                       CreateProcess
                                ThreadDebug                    AsUserW

Stage 1 -- Delivery

Spear-phishing email or messaging platform delivers the binary as an attachment or download link. The Chinese-language filename exploits HR/compliance anxiety.

Stage 2 -- Anti-Analysis Gauntlet

Before any payload execution, the VM runs a comprehensive environment validation:

Check	Method	Purpose
Debugger detection	`IsDebuggerPresent`	Basic PEB flag check
Debug port check	`NtQueryInformationProcess(ProcessDebugPort)`	Catches kernel-level debuggers
Debug object removal	`NtRemoveProcessDebug`	Strips debug object from process
Thread anti-debug	`DbgUiSetThreadDebugObject(NULL)`	Nullifies debugger thread's debug object
Handle inheritance	`NtDuplicateObject`	Verifies no debugger handle inheritance
Hypervisor detection	CPUID leaf `0x40000000` -> "XenO"	Detects Xen-based sandboxes
CPU validation	CPUID -> "GenuineIntel"	May fail on emulators with imprecise CPUID
Process enumeration	`CreateToolhelp32Snapshot`	Checks for analysis tools

The NtRemoveProcessDebug call is particularly aggressive. Rather than simply detecting a debugger and exiting, it actively removes the debug object from the process. A reverse engineer attached to the process will find their debugging session silently disconnected -- the process continues running, but the debugger can no longer receive events. Combined with DbgUiSetThreadDebugObject(NULL), which nullifies the debug object on the current thread, this creates a two-layer defense that defeats both user-mode and kernel-mode debugging without triggering the typical "debugger detected, exit" behavior that analysts look for.

Stage 3 -- Self-Modifying Code Decryption

The VM reads a payload dispatch table at 0x140010E2E and makes two VirtualProtect calls (at 0x14000B607 and 0x14000C179) to mark code regions as PAGE_EXECUTE_READWRITE (0x40). ChaCha20 then decrypts the code segments in place. After decryption, the memory permissions are presumably tightened back to PAGE_EXECUTE_READ -- though the RWX window is the detection opportunity.

Stage 4 -- Shellcode Execution

Decrypted shellcode is executed through indirect calls at 0x14000CB72 and 0x14000E6BF. The dual execution paths suggest either redundancy (two payloads for different purposes) or a staged injection where the first shellcode prepares the environment for the second.

Stage 5 -- Process Injection and Privilege Escalation

The RAT achieves persistence and privilege escalation through several mechanisms:

CreateProcessAsUserW: Spawns a child process under a different (elevated) token
NtDuplicateObject: Shares handles across process boundaries
WaitForDebugEvent / ContinueDebugEvent: The classic process hollowing pattern -- create a suspended process, hollow its memory, inject payload, resume
CreateFileMappingW / MapViewOfFile: Shared memory sections for inter-process communication between the hollowed process and the controller

Stage 6 -- RPC-Based C2

This is the sample's most operationally significant design choice.

The C2 Protocol Nobody Is Watching

Most RATs communicate over HTTP or HTTPS. Some use DNS tunneling. A few use custom TCP protocols. This sample uses Microsoft Remote Procedure Call (MSRPC) -- the same protocol that Active Directory domain controllers use to replicate, that Group Policy uses to push configurations, and that every Windows workstation uses for dozens of legitimate administrative functions every hour of every day.

The RPC call sequence recovered from import analysis:

RpcStringBindingComposeW(
    objUUID,
    "ncacn_ip_tcp",        // TCP transport
    <C2_HOST>,             // encrypted in ChaCha20
    <C2_PORT>,             // encrypted in ChaCha20
    options
)
  -> RpcBindingFromStringBindingW(binding_string)
  -> RpcBindingSetAuthInfoExW(binding, auth_svc, authn_level, identity)
  -> RpcAsyncInitializeHandle(async_state, sizeof(state))
  -> NdrAsyncClientCall(stub_desc, proc_format, async_state, ...)

This design provides several operational advantages that HTTP-based C2 cannot match:

Protocol whitelisting. RPC traffic over TCP is expected and broadly permitted on corporate networks. Blocking it would break Windows administration.
Traffic blending. RPC packets from the RAT are structurally identical to legitimate Windows RPC traffic. Without deep packet inspection correlating specific RPC interface UUIDs to known-malicious definitions, there is nothing to flag.
Bidirectional async messaging. NdrAsyncClientCall supports full asynchronous request-response patterns, giving the operator interactive control without the polling overhead of HTTP beacons.
Authentication layer. RpcBindingSetAuthInfoExW allows the C2 channel to use Windows authentication mechanisms, potentially borrowing the victim's domain credentials for the connection.

The C2 host and port are encrypted with ChaCha20 and decrypted only at runtime within the VM. No plaintext network indicators were recoverable from static analysis. Based on SilverFox family behavior, the C2 infrastructure likely sits on Chinese cloud providers (Alibaba Cloud, Tencent Cloud, Baidu Cloud) within AS4134, AS4837, or AS4812, communicating on ports 8888, 9999, or custom high ports.

Dynamic analysis in a sandbox with FakeNet-NG or INetSim is required to extract the actual C2 endpoint. We will update this report if sandbox results become available.

PE Section Analysis

Section	VirtualSize	RawSize	Entropy	Analysis
`.text`	0x1703CB	0x170400	5.11	1.5MB of VM dispatcher + handler stubs. The moderate entropy masks the obfuscation -- it is not packed, it is virtualized.
`.rdata`	0x1382E	0x13A00	5.20	Import table and CRT data. Contains the RPCRT4.dll imports that reveal the C2 protocol.
`.data`	0x53C4	0x4200	5.47	VM constant table: 2,816 entries in 6-byte format with 0xCC sentinels.
`.pdata`	0x468C	0x4800	6.46	Exception directory. Elevated entropy suggests some structured data is packed here.
`.rsrc`	0x8F6A0	0x8F800	5.08	Resources including PNG icons and -- critically -- encrypted BITMAP resources containing ChaCha20-encrypted payload blobs at offsets 0x18E000-0x19C000 and 0x1BB000-0x1C6000 (localized entropy: 7.5-7.95).

MITRE ATT&CK Mapping

Tactic	Technique	ID	Evidence
Initial Access	Spearphishing Attachment	T1566.001	Chinese-language HR/disciplinary lure
Execution	User Execution: Malicious File	T1204.002	Requires user to execute disguised EXE
Execution	Shared Modules	T1129	Runtime API loading via GetProcAddress
Defense Evasion	Obfuscated Files or Information	T1027	VM obfuscation, stackstrings, junk bytes
Defense Evasion	Software Packing	T1027.002	ChaCha20 in-memory code decryption
Defense Evasion	Indicator Removal: Timestomp	T1070.006	PE timestamp forged to 2070
Defense Evasion	Masquerading	T1036.005	Fake Trend Micro version info
Defense Evasion	Virtualization/Sandbox Evasion	T1497.001	CPUID Xen detection, process tool checks
Privilege Escalation	Access Token Manipulation	T1134	CreateProcessAsUserW, CreateWellKnownSid
Discovery	Process Discovery	T1057	CreateToolhelp32Snapshot enumeration
Command and Control	Application Layer Protocol	T1071	MSRPC/ncacn_ip_tcp C2
Command and Control	Encrypted Channel	T1573	ChaCha20-encrypted C2 payloads
Execution	Process Injection	T1055	VirtualProtect(RWX) + shellcode injection
Execution	Process Hollowing	T1055.012	WaitForDebugEvent + child process manipulation

Attribution

Attribute	Assessment	Confidence
Language	Chinese (Simplified)	HIGH -- lure filename, targeting context
Actor	Chinese-aligned, SilverFox operator	HIGH -- family TTP match, campaign tag
Model	Malware-as-a-Service (MaaS)	MEDIUM-HIGH -- consistent with SilverFox distribution model
Targeting	Chinese-speaking orgs, HR/compliance staff	HIGH -- lure theme, language, social engineering
Motivation	Espionage / credential theft	MEDIUM -- inferred from RAT capabilities and targeting
Sophistication	High	HIGH -- VM obfuscation, ChaCha20, RPC C2

OPSEC Mistakes

Even sophisticated actors leave fingerprints.

The campaign tag is an artifact. The bg[qtsc] variant tag preserved in the MalwareBazaar classification is an operator-assigned campaign identifier. Whether "qtsc" refers to Quang Trung Software City (a major Vietnamese tech hub), a Chinese organizational abbreviation, or an internal campaign codename, it is a trackable string that links this sample to future submissions by the same operator.
The timestamp forgery is a signature. Setting PE timestamps to 2070 is a documented pattern across multiple SilverFox samples. It has become a family-level behavioral indicator -- the very thing it was designed to prevent.
ChaCha20 constants survive obfuscation. Despite the VM architecture hiding all functional code, the "expand 32-byte k" constant must be constructed at runtime to initialize ChaCha20. The stackstring construction is detectable via YARA rules targeting the specific mov DWORD sequence that builds the constant on the stack.
The Trend Micro masquerade is specific and traceable. Claiming to be "Trend Micro Titanium 17.9.0.1089" creates a precise detection rule: any PE with this version info that lacks a valid Trend Micro Authenticode signature is malicious. The specificity of the lie is the weakness.

IOC Summary

File Indicators

Type	Value
SHA256	`e6d8944deced4b6ec228cb1af210eb19d527107af2688b401de5503174bc1fbe`
MD5	`443a741c1cdde875e8bc0307d9a657c7`
SHA1	`a46c59be8e82cb05d49f288cb28df2333ee53b2b`
Imphash	`03178db0411f49be0e26499ca1def241`
Filename	`2026第一季度违纪人员内部调查信息.exe`
Fake ProductName	`Trend Micro Titanium`
Fake FileVersion	`17.9.0.1089`
Fake InternalName	`7zsfx.exe`
Forged Timestamp	`0xBD28ECA5` (2070-09-03)

Code Pattern Indicators

Pattern	Context
`65 78 70 61 ... 6e 64 20 33 ... 32 2d 62 79 ... 74 65 20 6b`	ChaCha20 "expand 32-byte k" stackstring construction
`c7 84 24 ?? 0? 00 00 61 70 78 65`	Stackstring setup for ChaCha20 constant
`?? ?? ?? ?? cc cc` (2816 entries)	VM constant table with 0xCC sentinel padding
`48 b8 ... 48 89 44 24 40 48 b8 ... 48 89 44 24 38 48 33 44 24 38`	VM state XOR + compare dispatch pattern
`41 b8 40 00 00 00 ff 15 ?? ?? ?? ??`	`mov r8d, 0x40` + `call VirtualProtect` (PAGE_EXECUTE_READWRITE)

Network Indicators

Type	Value	Confidence
Protocol	MSRPC / ncacn_ip_tcp	HIGH (confirmed from imports)
C2 Host	Encrypted (ChaCha20)	Requires dynamic analysis
C2 Port	Encrypted (ChaCha20)	Requires dynamic analysis
C2 Method	NdrAsyncClientCall	HIGH (confirmed from imports)
Likely ASN	AS4134, AS4837, AS4812	MEDIUM (SilverFox family pattern)

Detection Guidance

YARA Rule

rule SilverFox_ChaCha20_VM_RAT {
    meta:
        author = "GHOST - Breakglass Intelligence"
        date = "2026-03-16"
        description = "SilverFox bg[qtsc] VM-obfuscated RAT with ChaCha20 encryption"
        hash = "e6d8944deced4b6ec228cb1af210eb19d527107af2688b401de5503174bc1fbe"
        tlp = "WHITE"
        reference = "https://intel.breakglass.tech"

    strings:
        // ChaCha20 stackstring: "expand 32-byte k" built via mov DWORD
        $chacha_expa = { c7 84 24 ?? 0? 00 00 65 78 70 61 }  // "expa"
        $chacha_nd32 = { c7 84 24 ?? 0? 00 00 6e 64 20 33 }  // "nd 3"
        $chacha_2by  = { c7 84 24 ?? 0? 00 00 32 2d 62 79 }  // "2-by"
        $chacha_tek  = { c7 84 24 ?? 0? 00 00 74 65 20 6b }  // "te k"

        // VM dispatcher: XOR-based state computation pattern
        $vm_dispatch = { 48 b8 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 44 24 40
                         48 b8 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 44 24 38
                         48 33 44 24 38 }

        // VirtualProtect PAGE_EXECUTE_READWRITE setup
        $rwx_protect = { 41 b8 40 00 00 00 ff 15 }

        // VM constant table sentinel pattern (0xCC 0xCC padding)
        $vm_const_table = { ?? ?? ?? ?? cc cc ?? ?? ?? ?? cc cc
                            ?? ?? ?? ?? cc cc ?? ?? ?? ?? cc cc }

        // Fake Trend Micro version info
        $fake_tm = "Trend Micro Titanium" wide ascii
        $fake_7z = "7zsfx.exe" wide ascii

        // Anti-debug API strings
        $api_ntremove = "NtRemoveProcessDebug" ascii
        $api_dbgui = "DbgUiSetThreadDebugObject" ascii

    condition:
        uint16(0) == 0x5A4D and
        filesize > 1MB and filesize < 5MB and
        (
            (2 of ($chacha_*) and $vm_dispatch) or
            (all of ($chacha_*)) or
            ($vm_dispatch and $rwx_protect and $vm_const_table) or
            ($fake_tm and $fake_7z and 1 of ($api_*))
        )
}

Suricata Rules

# SilverFox RPC C2 - External MSRPC bind from non-system process
alert tcp $HOME_NET any -> $EXTERNAL_NET ![135,139,445] (
    msg:"BGI - SilverFox Potential MSRPC C2 Bind to External Host";
    flow:established,to_server;
    content:"|05 00 0b|"; offset:0; depth:3;
    content:"|10 00 00 00|"; distance:0;
    threshold:type limit, track by_src, count 1, seconds 300;
    reference:url,intel.breakglass.tech;
    classtype:trojan-activity;
    sid:9000050; rev:1;
)

# SilverFox RPC C2 - NdrAsyncClientCall pattern on non-standard port
alert tcp $HOME_NET any -> $EXTERNAL_NET [8888,9999,8080,4443,5555,6666,7777] (
    msg:"BGI - SilverFox MSRPC C2 on Known SilverFox Port";
    flow:established,to_server;
    content:"|05 00|"; offset:0; depth:2;
    reference:url,intel.breakglass.tech;
    classtype:trojan-activity;
    sid:9000051; rev:1;
)

Behavioral Detections for EDR/SIEM Teams

High-Fidelity Alerts:

VirtualProtect RWX from GUI application. Any process running as a GUI subsystem that calls VirtualProtect with PAGE_EXECUTE_READWRITE (0x40) on its own code sections is exhibiting self-modifying code behavior. Legitimate applications almost never do this.
NtRemoveProcessDebug from user-mode process. This API exists for niche debugging scenarios. Its use from a non-development, non-security application is a strong indicator of active anti-debugging.
MSRPC connections to external IPs from user-context processes. RPC traffic should flow between domain-joined machines on internal subnets. A user-launched application opening RPC bindings to external IP addresses on non-standard ports is anomalous.
PE files with Trend Micro version info but no Trend Micro signature. Trivial to implement, high-confidence detection. Query your endpoint telemetry for any executable where VersionInfo.CompanyName contains "Trend Micro" and Authenticode.SignerName does not.

Threat Hunting Queries:

// KQL - Defender for Endpoint
DeviceProcessEvents
| where FileName endswith ".exe"
| where ProcessVersionInfoCompanyName has "Trend Micro"
| where not(FolderPath has_any("Trend Micro", "TrendMicro"))
| where not(ProcessVersionInfoOriginalFileName in~ ("TMBMSRV.exe", "PccNTMon.exe"))

// KQL - Unsigned PE claiming Trend Micro identity
DeviceFileEvents
| where FileName endswith ".exe"
| where InitiatingProcessVersionInfoCompanyName has "Trend Micro"
| where SignerType == "None" or SignatureState != "SignedAndTrusted"

So What? Why This Matters for Defenders

Three things make this sample operationally significant beyond its SilverFox family attribution.

The VM obfuscation sets a new floor for analysis cost. Analyzing a packed binary takes hours. Analyzing a binary protected by a custom VM with a binary search tree dispatcher, XOR-keyed state machine, and 2,816-entry constant table takes weeks. Most SOC teams and even most malware analysts will not invest this level of effort. The attackers know this. The VM is not there to prevent analysis entirely -- it is there to make analysis more expensive than most organizations are willing to pay. This is economic warfare applied to reverse engineering.

RPC-based C2 is a blindspot in most detection stacks. Network security monitoring is built around HTTP/HTTPS, DNS, and known-malicious protocols. MSRPC is broadly trusted, broadly permitted, and poorly inspected. A RAT that communicates over the same protocol as Active Directory replication and Group Policy distribution will blend into the noise floor of any enterprise network. If your organization is not monitoring for outbound MSRPC connections to external IP addresses, you have a detection gap that this threat actor is specifically designed to exploit.

Two simultaneous campaigns means active operations. The March 14 ValleyRAT cluster and this March 16 VM-obfuscated sample are different tools from the same ecosystem, targeting the same victim population, deployed within the same operational window. This is not a one-off. SilverFox operators are actively conducting a multi-pronged campaign against Chinese-speaking organizations. If your organization has Chinese-speaking employees, offices in mainland China or Southeast Asia, or business relationships with Chinese entities, you are in the target set.

The C2 endpoints for this sample remain encrypted. When sandbox results produce the decrypted C2 infrastructure, we will publish an update. In the meantime, the YARA rules, Suricata signatures, and behavioral detections above provide coverage for the delivery and execution phases.

Hunt accordingly.

This investigation was conducted by GHOST at Breakglass Intelligence. IOCs, YARA rules, and STIX bundles are available at intel.breakglass.tech. For questions, threat sharing, or to report related samples, reach out at @BreakGlassIntel.