Recently, we investigated a highly sophisticated malware campaign that combines multiple layers of obfuscation, endpoint security tampering, and kernel-level tricks. The operators hide behind repackaged installers for popular tools such as Telegram, WinSCP, Google Chrome, and Microsoft Teams. On the surface, victims see a normal installer. In the background, the malware stages files, deploys drivers, tampers with defenses, and finally launches a ValleyRat beacon that keeps long-term access to the system.

Our analysis attributes the described operation to the China-aligned APT commonly referred to as Silver Fox, active since at least 2022. The campaign matches previous Silver Fox activity in its use of archive-based staging, DLL sideloading, abuse of Chinese security products, and Bring Your Own Vulnerable Driver (BYOVD) techniques.

This post follows the full infection chain from the first malicious installer to the final ValleyRat payload and then focuses on detection and hunting strategies. THOR’s role is highlighted throughout, as it detects several key stages out of the box and provides strong leads for incident responders.

Infection Chain Overview

At a high level, the infection chain proceeds through a series of well-defined phases. The victim first executes a trojanized Telegram installer. This installer sets a dangerous Microsoft Defender exclusion, stages a password-protected archive together with a renamed 7-Zip binary, and then extracts a second-stage executable. That second-stage orchestrator, men.exe, deploys additional components into a folder under the public user profile, manipulates file permissions to resist cleanup, and sets up persistence through a scheduled task that runs an encoded VBE script. This script in turn launches a vulnerable driver loader and a signed binary that sideloads the ValleyRat DLL.

The following sections take each stage in turn and examine what happens on the system.

A Telegram Installer That Isn’t

The campaign begins with a Windows installer named tg.exe, with SHA-256 hash 9ede6da5986d8c0df3367c395b0b3924ffb12206939f33b01610c1ae955630d1. The binary is unsigned, approximately 49.7 MB in size, and uses a Telegram icon. When executed, it displays a genuine-looking Telegram Desktop installer interface, and its settings identify it as Telegram Desktop 6.0.2 (x64), the then-current version.

Closer analysis reveals some inconsistencies. The PE header timestamp is 2019-02-11 18:13:16 UTC, whereas the first VirusTotal submission occurred on 2025-08-29 08:13:04 UTC. A six-year gap between compilation and first public sighting is atypical for a mainstream, frequently updatedapplication. At the time of analysis, only a small number of antivirus engines on VirusTotal flagged the file as malicious.

Distribution is achieved via spear-phishing and malvertising. Victims are pushed toward download links or attachments that promise the Telegram installer.

Staging in ProgramData and Silencing Defender

Once the victim executes tg.exe, the installer immediately begins to prepare the environment for further payloads. First, it creates the directory C:\ProgramData\WindowsData\ and drops several files there. Among those files are funzip.exe, which is a renamed 7-Zip command-line binary, and main.xml. The latter name suggests a configuration file, but the file’s magic bytes clearly identify it as a password-protected ZIP archive. Its high entropy further supports that classification.

Second, the installer uses PowerShell to add a Microsoft Defender exclusion for the entire C:\ drive.

It then extracts files from the ZIP archive main.xml by executing "C:\ProgramData\WindowsData\funzip.exe" x -y -phtLcENyRFYwXsHFnUnqK -o"C:\ProgramData\WindowsData" "C:\ProgramData\WindowsData\main.xml".

The arguments mirror 7-Zip-style semantics: x extract, -y assume yes, -p<password>, and -o<output>. One artifact dropped out particularly: the password htLcENyRFYwXsHFnUnqK. Extraction results in two further files written to C:\ProgramData\WindowsData\ which are men.exe and setup.exe, a legitimate Telegram version 6.0.2 installer. Both are finally executed.

men.exe Orchestrating the Infection

men.exe is the main control component for this campaign. Once running, it performs environmental reconnaissance, deploys additional files, establishes persistence, and coordinates driver loading and ValleyRat execution.

As an initial step, men.exe enumerates running processes to identify endpoint security related processes. This includes Microsoft Defender’s MsMpEng.exe and processes belonging to Chinese security products such as ZhuDongFangYu.exe and 360tray.exe. This behaviour confirms both awareness of installed defenses and a focus on regions where these products are prevalent. Similar campaigns and strategies have been observed in the past as well.

men.exe then drops additional password-protected archives with misleading file extensions tree.exe and me.key into %PUBLIC%\Documents\WindowsData\ and decrypts them at runtime using embedded passphrases (Server8888 and killstartup). After extraction, this directory contains a collection of binaries and data files including both encrypted archives as well: tree.exe, bypass.exe, kail.exe, me.key, X.vbe, NVIDIA.exe, log.dll, main.exe, NtHandleCallback.exe, rwdriver.sys, and rwdriver.cat. Each file serves a particular role in the chain, ranging from further decompression and privilege escalation to driver deployment and loader functionality.

men.exe also prepares long-term persistence and makes remediation harder by creating a scheduled task named WindowsPowerShell.WbemScripting.SWbemLocator, a name carefully chosen to resemble legitimate Windows components. The task triggers at user logon, runs with the Administrator principal and highest available privileges, and executes the encoded script file X.vbe using the configured default VBE handler, in our case WScript.exe. At the same time, men.exe modifies the access control list on %PUBLIC%\Documents\WindowsData\ to include a deny entry that prevents even administrators from deleting files and directories under that path.

Components and Capabilities

The components dropped by men.exe implement the key capabilities required for this campaign. The most relevant ones for defenders are summarized here.

UAC Bypass

bypass.exe provides UAC bypass and privilege escalation. It performs runtime unpacking by overwriting one of its sections in memory, complicating static analysis, and abuses the ICMLuaUtil elevated COM interface, part of the long-standing CMSTPLUA UAC COM class bypass family. The code uses elevation monikers referencing CLSIDs such as

• 3E5FC7F9-9A51-4367-9063-A120244FBEC7,
• 6EDD6D74-C007-4E75-B76A-E5740995E24C,
• D2E7041B-2927-42FB-8E9F-7CE93B6DC937,
• 0A16D195-6F47-4964-9287-9F4BAB6D9827,

and ultimately launches C:\Windows\SysWOW64\DllHost.exe /Processid:{<CLSID>}.

Persistence via Scheduled Task (X.vbe)

X.vbe is an encoded VBScript and forms the main persistence mechanism. The scheduled task WindowsPowerShell.WbemScripting.SWbemLocator executes this script at logon via the configured default VBE handler. After decoding the file contents, the script contains numerous Chinese-language strings and comments and is responsible for launching both NVIDIA.exe and NtHandleCallback.exe.

Callback Manipulation and Logging Interference

main.exe manages the custom driver rwdriver.sys (with catalog rwdriver.cat). The driver is used to circumvent user-mode hooks employed by EDR products and to interfere with certain logging mechanisms, for example by overloading log forwarding pipelines so that events never reach a SIEM. It also ensures that disabled network interfaces are re-enabled when needed, supporting both command-and-control and lateral movement. To install the driver, main.exe issues a command equivalent to sc create rwdriver binPath="C:\\Users\\Public\\Documents\\WindowsData\\rwdriver.sys" type=kernel start=demand.

BYOVD Resulting in Security Process Termination

NVIDIA.exe is a loader for the vulnerable but signed driver NSecKrnl64.sys. It drops the driver into %LOCALAPPDATA%\Temp under a random name and loads it as a kernel-mode driver, grantingring 0 access. This driver exposes an IOCTL interface, using code 0x2248E0, that allows arbitrary process termination, which the malware uses to repeatedly kill security solution processes.

The driver is then registered under HKLM\SYSTEM\CurrentControlSet\Services\<RandomName>.

Finally, NtHandleCallback.exe is a legitimately signed executable abused for DLL sideloading. Placed together with a malicious log.dll in the same directory, and executed without an explicit DLL path, it loads log.dll from its working directory in line with the Windows DLL search order. In this campaign, log.dll implements the ValleyRat beacon and establishes command and control.

At that point, ValleyRat is running with persistence backed by the VBE script and with two drivers working to weaken defenses and logging.

Detection and Prevention

This malware infection chain is complex, multi-layered and still active. We continue to observe infected hosts, not only via trojanized Telegram installers but also via other repackaged productivity tools. The good news is that even highly advanced campaigns like this one offer numerous, reliable detection opportunities throughout the entire chain.

In this chapter, we walk step by step through the infection chain and map concrete detection options to each phase. Where useful, we include Sigma-style examples. Throughout the chapter, you will see that this campaign can be uncovered with relatively simple custom rules and is also comprehensively covered by THOR.

Malvertising and Phishing Leading to Infection

The infection chain starts with very traditional initial access vectors: phishing and malvertising. Users are lured to download and execute fake installers for Telegram, Chrome, WinSCP, Microsoft Teams and other popular tools.

At this stage, detection is mostly about hygiene and policy rather than specific signatures. Ideally, local administrator rights are tightly restricted so that users cannot install arbitrary software in the first place. Application control technologies such as AppLocker or equivalent solutions should block unknown or unsigned installers by default.

From a hunting perspective, EDR or inventory systems can be queried for unsigned or oddly signed installers whose product name or description claims to be Telegram, Teams or similar but whose publisher does not match the vendor. THOR can support this by flagging suspicious PE metadata and unsigned installers in high-value locations.

First-Stage Execution

The first clearly observable host-side indicator is the creation and use of the directory C:\ProgramData\WindowsData\. Under normal circumstances, this folder does not exist. Its creation, combined with executable content inside it, is therefore a valuable early hunting lead.

By default, writing into C:\ProgramData requires administrative privileges, which already tells you something about the user context in which the initial dropper runs. In this campaign, the trojanized installer tg.exe stages the orchestrator men.exe there and later deletes that executable. Detection based purely on the presence of men.exe is therefore unreliable. However, the existence of C:\ProgramData\WindowsData\ containing only a single “legitimate” installer such as Telegram, Chrome, WinSCP or Microsoft Teams is a strong anomaly that should trigger further investigation.

To capture these events, file system activity must be logged. This can be achieved with Sysmon event ID 11 (file creation) or via native file system auditing combined with an appropriate SACL on C:\ProgramData\WindowsData\ and usage of a detection rule such as the following example:

title: File Creation In WindowsData ProgramData Folder
description: Detects file creation events in C:\ProgramData\WindowsData
detection:
	selection:
		EventID: 11
		TargetFilename|startswith: 'C:\\ProgramData\\WindowsData\\'
	condition: selection

THOR uses this kind of telemetry to flag suspicious content in that directory and to correlate it back to its parent processes.

Second-Stage Extraction

Before dropping the second stage files from the encrypted main.xml archive, tg.exe modifies Microsoft Defender for Antivirus configuration and adds a path exclusion for the entire system drive C:\. This change is logged as Microsoft Defender Operational event ID 5007. While there are legitimate use cases for exclusions, broad exclusions such as a full drive are extremely suspicious and should be closely monitored. THOR detects this kind of Defender configuration tampering out of thebox and will highlight it as a high severity finding. SigmaHQ maintains a public rule that also covers this scenario: https://github.com/SigmaHQ/sigma/blob/43b6fae2a001d3af9a53984167dd39d2319fbb40/rules/windows/builtin/windefend/win_defender_config_change_exclusion_added.yml.

Once the exclusion is in place, the initial installer extracts the second stage from main.xml using the password htLcENyRFYwXsHFnUnqK. This string is a strong hunting artifact and can be searched in process creation logs such as Sysmon event ID 1 or Security event ID 4688. In addition, THOR heuristics detect funzip.exe as a renamed 7-Zip component based on the original file name and metadata.

A generic Sigma rule to detect password-protected archive extraction via 7-Zip utilities could look like this:

title: Password Protected Compressed File Extraction Via 7-Zip
description: Detects usage of 7zip utilities (7z.exe, 7za.exe and
7zr.exe) to extract password protected zip files.
logsource:
	category: process_creation
	product: windows
detection:
	selection_img:
		- Description|contains: '7-Zip'
		- OriginalFileName:
			- '7za.exe'
	selection_password:
		CommandLine|contains|all:
			- ' -p'
			- ' x '
			- ' -o'
			- ' -y'
	condition: all of selection_*

Public Folder Staging (%PUBLIC%\Documents\WindowsData)

The use of %PUBLIC%\Documents\WindowsData\ as a staging directory is one of the strongest anomalies in this campaign. The public user profile is intended for shared user data, not for executablesand drivers. Under normal circumstances, one should not observe .exe, .dll, .sys or .vbe files created and executed from this location.

Tracking file creation under %PUBLIC%\Documents\WindowsData\ using Sysmon event ID 11 or file system auditing SACLs provides high-value hunting leads. THOR detects this stage of the infection chain in several ways. It first flags the types of files located in %PUBLIC%\Documents\WindowsData\, then detects the files themselves using YARA and heuristic rules that cover suspicious PE signatures, known malicious or suspicious signers, typical password-protected ZIP artefacts and encoded VBE script content. Among others, the following THOR rule families are triggered in our testing:

• EXT_SUSP_PE_Signed_by_Suspicious_Entitiy_Mar23
• MAL_CobaltStrike_Apr18_1_CSharp_Powershell_Combo
• SUSP_ZIP_PasswordProtected_Content_Phishing_Sep22
• EXT_Winnti_Rootkit
• SUSP_Encoded_VBE

In addition, any execution of binaries from %PUBLIC%\Documents\WindowsData\ should be treated as suspicious. A process creation correlation rule like the one for C:\ProgramData\WindowsData\ can be used here to highlight executions where Image or CommandLine begins with C:\Users\Public\.

Scheduled Task Persistence

Like most real-world intrusion sets, this campaign uses a relatively simple but reliable persistence mechanism: a scheduled task. As we have described in previous work, a small set of persistence mechanisms (registry run keys, services, scheduled tasks, WMI event consumers) covers the majority of observed intrusion cases. Scheduled tasks in particular are heavily abused and should therefore be monitored very closely.

In this case, persistence is implemented via the script file X.vbe, which is already detected by THOR based on VBE encoding and other heuristics. The scheduled task itself is also clearly visible. THOR’s ScheduledTask module highlights the task name WindowsPowerShell.WbemScripting.SWbemLocator and the command pointing to the short VBE script file in %PUBLIC%\Documents\WindowsData\. The naming is chosen to blend in with legitimate Windows components, but the path clearly reveals its malicious nature.

Creation of the scheduled task generates Security event ID 4698 and contains the full XML task definition. Building on this telemetry, you can use a dedicated correlation rule such as:

title: Scheduled Task Creation With Command In Users Public Directory
description: Detects creation of a scheduled task whose action command
points to \Users\Public
detection:
	selection:
		EventID: 4698
		TaskContent|contains:
			- '\\Users\\Public\\'
			- '\\\\Users\\\\Public\\\\'
	condition: selection

In a strictly controlled environment, any scheduled task creation not explicitly whitelisted can serve as an early investigation lead. The rule above can be easily extended with more suspicious directories if needed.

UAC Bypass with ICMLuaUtil

The UAC bypass used in this campaign can be detected very reliably by its COM interface usage and CLSIDs. The technique abuses the ICMLuaUtil elevated COM interface, resulting in command lines like C:\Windows\SysWOW64\DllHost.exe /Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}.

Both Security event ID 4688 and Sysmon event ID 1 can be used to detect such invocations by focusing on dllhost.exe combined with specific CLSIDs. The following Sigma rule provides an example:

title: UAC Bypass via ICMLuaUtil
id: 49f2f17b-b4c8-4172-a68b-d5bf95d05130
status: test
description: Detects the pattern of UAC Bypass using ICMLuaUtil Elevated COM interface
references:
	- https://www.elastic.co/guide/en/security/current/uac-bypass-via-icmluautil-elevated-com-interface.html
author: Florian Roth (Nextron Systems), Elastic (idea), Maurice Fielenbach (Hexastrike Cybersecurity)
date: 2022-09-13
modified: 2025-10-01
tags:
	- attack.defense-evasion
	- attack.privilege-escalation
	- attack.t1548.002
logsource:
	category: process_creation
	product: windows
detection:
	selection_proc:
		- ParentImage|endswith: '\dllhost.exe'
		- ParentProcessName|endswith: '\svchost.exe'
	selection_child_cmd:
		CommandLine|contains:
			- '/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}'
			- '/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}'
	selection_parent_cmd:
		ParentCommandLine|contains:
			- '/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}'
			- '/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}'
	filter_werfault:
		NewProcessName|endswith: '\WerFault.exe'
	condition: selection_proc and (selection_child_cmd or selection_parent_cmd) and not filter_werfault
falsepositives:
	- Unknown
level: high

THOR detects this behaviour through its process creation analysis and specific heuristics for UAC bypass techniques, including CMSTPLUA/ICMLuaUtil.

Driver Registration and Loading

Driver loading activities are relatively rare and therefore stand out when they deviate from expected paths. New drivers are normally registered from SystemRoot\System32\drivers\Name.sys (expandable form) or \??\C:\Windows\System32\drivers\Name.sys (native form). Any driver path outside these locations is suspicious. Loading a driver from %PUBLIC% or temporary directories is particularly indicative of malicious activity.

During the infection chain, multiple drivers are used and registered. One of them, C:\Users\Public\Documents\WindowsData\rwdriver.sys, is installed as a kernel service and generates Security event ID 4697, “A service was installed in the system”. Service installations from suspicious locations can be detected with a simple Sigma rule such as:

title: Service Creation In Users Public Directory
description: Detects creation of a service running from \Users\Public
detection:
	selection:
		EventID: 4697
		ServiceFileName|contains:
			- '\\Users\\Public\\'
			- '\\\\Users\\\\Public\\\\'
	condition: selection

Beyond service creation events, registry modifications under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ provide additional detection opportunities. Sysmon event ID 13 (registry value set), or native registry auditing combined with a SACL on that key, generates Security events 4663 followed by 4657. By correlating these events with suspicious file paths in %PUBLIC% or %LOCALAPPDATA%\Temp, defenders can quickly uncover driver-based infection stages.

THOR detects these drivers via YARA signatures (for example, EXT_Winnti_Rootkit in related tooling), driver location checks and generic service analysis, and clearly flags kernel services loaded from user-writable directories.

C2 Activity

The final stage of the campaign is the ValleyRat command-and-control activity. In our analysis, the C2 endpoint used was the domain keepmasterr[.]com with traffic observed to 161[.]248[.]15[.]144[:]9000. Connections can be inspected with tools such as netstat -naob, but more importantly, THOR’s ProcessCheck module highlights the responsible process. In this case, THOR points directly to NtHandleCallback.exe, which is signed but suspicious and detected by the YARA rule EXT_SUSP_PE_Signed_by_Suspicious_Entitiy_Mar23, based on the file signature. From there, analysts can pivot into memory analysis or process dumping to recover the sideloaded beacon log.dll.

DNS logging provides another reliable angle. Sysmon event ID 22 records DNS queries, including those issued by C:\Users\Public\Documents\WindowsData\NtHandleCallback.exe. Detection rules that combine unusual process paths under %PUBLIC% with DNS requests to previously unseen or suspicious domains offer a powerful way to surface C2 communications, even if IP-based indicators change over time.

THOR can be used both to detect the suspicious process and to dump it for further offline analysis, which ultimately leads to the discovery of the ValleyRat beacon and a complete understanding of the C2 protocol and infrastructure.

Appendix

Indicators

Droppers

00CA4CC46E7E6FC5351CC211D6D23A2310EA743C7A17A79723CCCDCFA08291D3
E774704B4E45FAFCD0F8344F61DFD67177EF14DE664D5610E7047D8E42621845
9EDE6DA5986D8C0DF3367C395B0B3924FFB12206939F33B01610C1AE955630D1
E122FF1369A2A229B8342C5688E49F627C29708353F8851DDA5787F51B64E3C0
3C5354F43B9D8BDF26B613B947BFAC4E6598BCDAD3063449551017A5C0939FA1
2EF1C67DE60E77B61219E7B653F3C5AA838912138196CF049A1D7A07FBBBA3A4
789A0DA3F438C01A8CBACADDA3977F9CD878B4EE8B0F88D317AB3AF85CA166AA
6DD391BB10499681F406744962230BF176454A073955913A6278058E41BC02B2
7E42401B9983CD3B090AE97A9C723A46C9ECEE04BBB5F55D0BDA60226F043131
ABAE8AD8577E2BCB7389769BE60D60F6D230E5827A9FF7ADFE92C62A38E99D64
FCCA326A15C217825A055D95AC672900286F3889E27AF91FE6789430BFC08A45
F1BDE45AC4A34B8EC885FB5FB07F5E47F89F97B257CC38A1EB37FC0C308C4A04
6B75596830DA05B93CD2F514DA7369A7766C3C8A9F42729E9D87E483ED52613B
A8C5B9FD1A97C0057834E3E3C6FC7A218A10212883CE4E8947C06F3ACFB282A7
1ABBE524C98A788301FC7AC6DD401FFA79CA2E24C2FFC112954C3B0463ABDA8E
7D193400C53F895672577CFBD6B21AE20A204FA0C07BB68A8207BD4DF47AE02A
6D72056A797E39D234432F98E651DE996B09E829AE389221ACD993239600F13E
B70434F49FBD5E87C23030711647BB77FBC59986656DBBFD9481A3C376217772
7B5B05580C96E9AA8DD7A7410DA67CEC720BA8ACB5CA073473D46C2C01248583

Second Stage

funzip.exe:
1EB33D7A653E4A05B1575357029A826661429DE77F8EAE5CBBD8EC6C6AD22FB1
main.xml:
B67A14305B802ED9F9039CE5C8F49B2BC3075CA3EFD7F6BB63E0AAAB993E594B
men.exe:
9D3BAF43AC52740895E50E3D5E4C8D6618AC1DDB4B54955AD7493366C63DEEB2
setup.exe:
DA1056565881DA22BA1E87CE776184A300727A918519111F975331CBDD136ADE
bypass.exe:
F330E21CF670DA67160937525DD5CA80B1F26C9B3DDDD34ADB2F175D85C485F1
kail.exe:
72C33F24FB5853D2EF70ADECE5C7CACEDD8E568A9025F7A82FD5EF5C2F9967C5
me.key:
4EB84EE6B19B7AC124063A5AFD2B21BA3A41B6EF13348E2A2EE0D94433D82A87
X.vbe:
73526196AC0F863BD46F1BD0653CE42C429064E24FAF2AD917FF935E9BBDFFB5
NVIDIA.exe:
B4AC2E473C5D6C5E1B8430A87EF4F33B53B9BA0F585D3173365E437DE4C816B2
log.dll:
567760CCA4E5B0590D7ED5C7CA61F75ADD6FFAB199B351CE93E7429DF988D046
main.exe:
FB249BFF9449BBD715D936E6BCE4CE2354434DC9EB305E352FFADBC82562252F
NtHandleCallback.exe:
C027CF868757BABAB33686BF4C41192339E04FA89AD868409A5CD4ED90A1F71E
rwdriver.cat:
E90B505E3B31E15E608F2F9FB1C0FABDFF29B91988EB6A61A73556E05E182D4C
rwdriver.sys:
1C763AF41B74C7502D70093763723939A8025199E0AC7E39C04B5CF992F9E273
NSecKrnl64.sys:
206F27AE820783B7755BCA89F83A0FE096DBB510018DD65B63FC80BD20C03261

C2

ydbao8[.]cyou
zbj22[.]zbj888uul[.]com
keepmasterr[.]com
knoeyyrt[.]com
ax[.]iuu8888[.]top