Inside Silver Fox, Part 2: Failure Engineering and the EDR Vanishing Act

Background

At the end of Part 1, the installer had completed two key actions: running the decoy setup.exe to lower the victim’s guard, and launching men.exe in the background to place initial restrictions on Windows Defender. From Part 2 on, the chain’s goal shifts to landing the trojan core while third-party endpoint protection (EDR) is still online.

This report focuses on how men.exe bypasses EDR — through decryption and decompression of an embedded archive, BYOVD, and a malicious driver that permanently removes endpoint protection — while using DACLs to raise persistence and forensic difficulty. Through staged drops and delayed decryption, the attacker holds the most sensitive loader and drivers back until endpoint protection has failed, and chains privilege escalation with an AV killer so that the next-stage core can land and run with almost no monitoring in the way.

This report is intended only for defensive research, incident response, threat hunting, and educational purposes. The samples and tools referenced may be dangerous; test them only in isolated, restorable environments that are not connected to a production network. This report does not encourage, assist, or condone any unauthorized activity; third-party platform and product names are used only for technical description.

Second-stage analysis

This stage dissects men.exe. As the process is long and deep, here is a summary of what the program does first:

1. Stop the EDR (using bypass.exe and NVIDIA.exe)
2. Run the next-stage malware
3. Make the EDR disappear (using rwdriver.sys and main.exe)
4. Persistence and cleanup

men.exe itself is a relatively linear execution flow, but to spread the risk of its malicious payloads being detected, the attacker splits files into segments and calls several external executables — so this analysis actually spans multiple samples.

Initial sample analysis

The previous stage dropped men.exe. Before running it dynamically, a DIE (Detect It Easy) scan of the structure shows men.exe is written in C++.

An entropy analysis of the file reveals a section with markedly high entropy. High entropy usually indicates highly random data, common in encrypted or obfuscated content, so this section is likely an encrypted or obfuscated resource.

Switching to the Extractor view, the section shows ZIP archive characteristics. Dumping and attempting to extract the region prompts for a password, confirming the dump is a valid ZIP; taken together, the extraction password is very likely hardcoded inside men.exe.

(Note: DIE may sometimes misreport the Size field, so the actual region and size to dump should still be confirmed through disassembly or instruction analysis.)

For static analysis, Capa can check for characteristics. The results flag many file-operation and obfuscation capabilities:

Advanced sample analysis

Tools such as Ghidra, IDA Pro, or x64dbg can recover the real execution logic of men.exe.

Analysis shows men.exe performs a GPU device environment check before the main flow, as part of its anti-analysis. It calls Direct3D9 APIs to read the system’s adapter information and decide whether the environment might be a sandbox or virtualized. If the conditions match, it terminates. The check here targets the Microsoft Basic Render Driver (Microsoft’s built-in software renderer):

• VendorId != 5140
• DeviceId != 140

A similar GPU-interface anti-analysis technique was mentioned on the Checkpoint blog; it is long-standing but rarely abused. If your VM happens to match this condition, patch out that instruction before dynamic analysis or the main logic will not run.

After entering the main logic, the first step confirms the working directory and prevents re-execution: it checks whether C:\Users\Public\Pictures\WindowsData\me.key exists and uses that as the fixed location for later drops and persistence.

• If the path does not exist, the prior payload has not landed yet.
• If the file already exists, the program may be running again.

In either case, the program tries to restore network connectivity via WMI, then terminates immediately to reduce accumulated anomalies and detection risk.

The program then checks whether AV or EDR is running. If so, it grabs their image paths and adds them to an internal string list. The list is not used immediately — it serves as the reference path for wiping protection software in the final stage.

Landing the protection-removal module

The program maps a 0xDB307-byte section out of its own file and writes it as tree.exe (an archive), then extracts it with a default password. This file matches the content dumped earlier with DIE.

The files released by tree.exe — where me.key is itself an archive that continues to be extracted after protection is disabled:

The files tree.exe releases, used mainly for persistence and endpoint-protection removal:

• bypass.exe: privilege escalation tool, used to raise privileges for subsequent operations
• NVIDIA.exe: EDR-stopping tool, to lower the risk of detection or blocking in the chain
• X.vbe: persistence script
• me.key: archive holding the trojan core, for loading the main malicious logic later
• Kail.exe: a 7z extractor, not used in this stage

Stealthy elevation and the BYOVD combo

At this point men.exe begins operating on the EDR, using bypass.exe (elevation) and NVIDIA.exe (AV stop) to try to shut down EDR-related services.

The program first launches bypass.exe with normal user privileges via WdcRunTaskAsInteractiveUser. bypass.exe then uses the ICMLuaUtil interface for a UAC bypass to elevate, and launches NVIDIA.exe to carry out the subsequent protection-stopping operations.

Because this call chain is triggered indirectly through a system mechanism, in the EDR’s process-lineage view bypass.exe’s parent shows as taskhost.exe rather than men.exe. This design obscures the real process origin and complicates event tracing and behavioral correlation.

NVIDIA.exe acts as an AV killer (AVK), terminating endpoint protection by loading a vulnerable driver. Since this sample’s NVIDIA.exe largely matches external records, we only summarize the flow here and focus on the BYOVD usage:

During threat-intelligence activities, we identified a new ValleyRAT campaign distributing fake application installers…（source: hexastrike.com — “ValleyRAT Exploiting BYOVD to Kill Endpoint Security”)

NVIDIA.exe loads NSecKrnl.sys (a legitimately signed driver with a known vulnerability) to scan the host for specific AV or EDR. If it detects a target, it uses the driver’s vulnerability to gain kernel privileges and force-terminate the process, disabling protection. Because the driver is legitimately signed but vulnerable, it usually evades the OS’s driver-blocking mechanisms and loads successfully — this technique is BYOVD (Bring Your Own Vulnerable Driver).

The EDR scan list leans toward consumer security software common in China:

• 360 family: ZhuDongFangYu.exe, 360tray.exe/360Tray.exe, 360sd.exe, 360rp.exe, 360Safe.exe
• Kingsoft: kxecenter.exe, kxemain.exe, kxetray.exe, kxescore.exe
• HIPS family: HipsMain.exe, HipsTray.exe, HipsDaemon.exe
• Tencent QQ (Tencent PC Manager): QMDL.exe, QMPersonalCenter.exe, QQPCPatch.exe, QQPCRealTimeSpeedup.exe, QQPCRTP.exe, QQPCTray.exe, QQRepair.exe

Because ZwTerminateProcess in the driver is insufficiently validated, any program can invoke it via IOCTL 0x2248E0 to terminate any process. The highlighted region below is the instruction in NVIDIA.exe that terminates the EDR process by calling this function through DeviceIoControl:

On the NSecKrnl.sys side, when invoked it uses ZwTerminateProcess to force-terminate the specified process with Ring 0 kernel privileges.

Driver NSecKrnl.sys MD5: 80961850786D6531F075B8A6F9A756AD

Checking the EDR’s pulse

After running the AVK, men.exe keeps checking whether AV is still present, to wait for the AVK to take effect and confirm endpoint protection is off. Once it confirms all EDR on the device has stopped, it restores the infected device’s networking via WMI.

Behavior after protection is stopped

Later analysis finds the program tries to launch LetsPRO.exe, but this sample does not actually drop it. The name was used in earlier ValleyRAT loaders, suggesting the sample retains historical call logic or shares behavior with a previous version.

Per Trend Micro reporting, the executable behind that name is typically used as a trojan loader. Its non-use here may relate to the log.dll loading flow, avoiding conflicts between components — indicating the sample was designed with module interaction in mind, keeping the call logic but not actually dropping the file.

The Void Arachne group targets Chinese users, using popular software such as Simplified-Chinese Chrome, LetsVPN, and QuickVPN as lures, paired with AI tools like Deepfake, to trick users into downloading Winos…（source: trendmicro.com)

Next it decrypts the files in me.key with a password, yielding ValleyRAT’s memory loader and drivers:

The program checks and launches NtHandleCallback.exe, ValleyRAT’s memory loader for the next stage, which side-loads log.dll to launch the attack (analyzed in the next chapter).

For persistence, it uses COM to register X.vbe as a logon-triggered task with a name resembling the system component WindowsPowerShell.WbemScripting.SWbemLocator; at user logon the VBScript X.vbe runs with admin rights.

Although the persistence script looks garbled, it can be analyzed with a decoder. However, errors remain after decoding, so the script cannot complete persistence and pops an error window at each logon. Later sample analysis indicates SilverFox has fixed this, letting persistence run correctly at startup and completing the persistence and auto-run of the AVK and the trojan core.

Making the EDR disappear for good

To permanently remove EDR from the endpoint, the malware loads the malicious driver rwdriver.sys and uses main.exe to gain kernel privileges. The driver’s registered name and filename identify it as an experimental open-source project:

• https://github.com/NanoWraith/BlindEdr (main.exe)
• https://github.com/NanoWraith/rwdriver (rwdriver.sys)

In essence, it loads the MmCopyVirtualMemory function via the driver to clear the EDR programs that are notified on event triggers from the kernel callbacks — typically to blind EDR. Here, though, the goal is to prevent system calls from dereferencing pointers to the deleted EDR programs and crashing the system. It then deletes the AV/endpoint-protection files directly (the paths gathered during the initial scan), making EDR disappear completely.

Normally, developing a driver requires enabling test mode to register and start it. Here, however, the loaded driver is signed but has an expired validity date yet still loads:

This is because, under the Windows driver-signing policy, meeting any one of its conditions allows a cross-signature to be used; this signature was issued before 2015, so it satisfies the policy and can load. This technique appears at multiple points in Silver Fox operations.

Wrapping up

At the end, the program calls two functions that modify folder permissions and delete its own files, to prevent easy opening and deletion and to raise forensic difficulty.

The first function sets Hidden and System attributes on the C:\Users\Public\Pictures\WindowsData directory to reduce the chance of an ordinary user finding it in File Explorer. It then takes the directory’s DACL and adds an Everyone Deny ACE denying FILE_DELETE_CHILD (0x40) with inheritance, making child items harder to delete; it then adds Deny ACEs denying DELETE (0x00010000) on each of the 7 files inside so the files themselves are harder to delete.

The second function uses many command strings decrypted via XOR before execution. Besides hardening X.vbe’s persistence, the commands delete the files used during this run.

Finally it generates and runs del.bat, using ping to delay deleting itself so the file is not removed while still executing:

@echo off
ping -n 2 127.0.0.1 >nul          & rem delay execution
del /f /q "C:\ProgramData\WindowsData\men.exe"   & rem delete men.exe
del /f /q "%%0"                   & rem delete this batch file

That concludes the second stage. The next stage covers how NtHandleCallback.exe completes execution of the final ValleyRAT core through DLL-sideloading (white-plus-black) and several tactics.

Technique summary

men.exe’s second stage spans anti-analysis, discovery, elevation and masquerading, defense impairment, persistence, and anti-forensics. The per-technique mapping to ATT&CK is in the MITRE ATT&CK mapping table at the end of this report. A tactic-level overview:

Across long-term tracking of many samples and loader chains, the attacker swaps tools frequently: BYOVD, exploitation, persistence, and loading methods all get replaced quickly as defenders’ detection rules and public disclosures appear, often favoring freshly disclosed or still-underground techniques to compress defenders’ reaction time. Re-examining the sample through a tactic lens is what lets us recognize the stable, unchanging intent and flow across variants — even as tools and techniques keep changing, the behavioral structure still leaves observable traces.

Execution-chain file map

Charting the first and second stages together gives a clearer view of which files the loader chain uses along the way (the part after NtHandleCallback.exe is covered in the next stage):

Conclusion

This chapter analyzed how the attacker systematically removes endpoint protection during the evasion stage, completing persistence, self-protection, and anti-forensics along the way. men.exe chains a UAC bypass with an AV killer, lands a BYOVD driver, and terminates EDR processes in Ring 0; through staged drops and delayed decryption, the core modules land at a relatively safe moment; finally it adds a custom malicious driver for blinding and forensic countermeasures — clearing kernel callbacks, raising deletion difficulty with DACLs, and self-deleting to reduce on-host traces.

For defenders, the hardest part of this chain is that it is built from many combined techniques, forming an engineered flow designed to guarantee the next stage’s success. Focusing only on the trojan body or a single indicator often means endpoint-protection visibility is already lost from the start.

In the next chapter we will analyze the trojan core loaders NtHandleCallback.exe and log.dll in detail, exploring how they load more rootkits and run in memory, using advanced hiding techniques to keep the trojan core off disk throughout execution.

Sample and references

• Original article (Medium, OIS, Traditional Chinese): 《深入銀狐 Part 2：失效工程：EDR 消失術》
• Previous stage: Inside Silver Fox, Part 1: Payload Landing — the Invisible Loader Chain of Inno Setup and Pascal
• ValleyRAT Exploiting BYOVD to Kill Endpoint Security — Hexastrike Cybersecurity
• Trend Micro: Void Arachne targets Simplified-Chinese users with Deepfake and VPN lures
• BlindEdr / rwdriver open-source projects: https://github.com/NanoWraith/BlindEdr, https://github.com/NanoWraith/rwdriver
• Driver Signing Policy — Microsoft Learn
• MITRE ATT&CK — basis for the technique mapping