Inside Silver Fox, Part 1: Payload Landing — the Invisible Loader Chain of Inno Setup and Pascal

Background

Since 2024 we have observed a large number of phishing sites impersonating LINE for PC, Telegram, and other messaging and office software in order to deliver remote-access trojans built on C2 frameworks such as ValleyRAT, KKRAT, and Sliver, mostly aimed at data theft, corporate espionage, and follow-on social engineering. This activity comes from the advanced persistent threat Silver Fox, an umbrella made up of multiple gray- and black-market groups across China and Southeast Asia. Its targets span China, Taiwan, Korea, Japan, India, and other Asia-Pacific countries, across a broad range of sectors — from government, critical infrastructure, healthcare, education and research, to finance, e-commerce, gaming, and the security industry itself.

We have tracked this threat entity for a long time and collected a large body of intelligence and malicious samples. Here we take one representative sample as a case study to demonstrate how to use a range of tools to analyze the malware Silver Fox delivers, reconstruct the design logic behind it, and share common questions and observations from the analysis.

The sample was collected in September 2025 from a phishing site operated by Silver Fox. It has robust core loading capabilities and a multi-stage anti-detection mechanism; at time of writing (February 2026) it is still flagged as malicious by only 13 of 70 engines on VirusTotal. Based on our long-term tracking, this family’s loader framework can be traced back to March 2025, was adopted by Silver Fox at scale from July 2025, and remained active through December 2025, undergoing repeated mutation and feature upgrades along the way. The sample analyzed here is a mid-evolution build whose overall attack flow and technology choices are already mature.

We divide this sample’s attack into four main chapters: installer landing, core control and evasion, the ValleyRAT loader, and the rootkit driver set. This chapter focuses on how, after the victim downloads and runs the installer from the phishing site, the malware completes the first stage of unpacking and landing, environment reconnaissance, and defense bypass on the endpoint, and quietly deploys the next-stage loader to a fixed location — turning a seemingly normal installation into the starting point of a persistent, expandable multi-stage attack.

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.

Sample identification

After obtaining the sample, we first compute its MD5 to confirm the hash is correct and query open-source intelligence for scan information.

File:     hysij.exe
Size:     116778195 (111 Mb)
MD5:      7979B24EC49575A1F1A3367F7B888D0E
Compiled: Sat, Oct 30 2010, 20:54:54 - 32 Bit EXE

The file’s compile time reads as 2010, clearly inconsistent with the collection date. This timestamp was deliberately forged and cannot be used to date the sample — a common obfuscation technique.

Malware analysis proceeds through static and dynamic methods, and the first step is to determine which approach the target suits. Scanning the target’s characteristics with DIE (Detect It Easy) shows, in the Installer field, that the sample is packaged with Inno Setup 5.3.10; the language is Object Pascal (Delphi), and it carries an Inno Setup Installer data overlay.

Inno Setup is an open-source installer-authoring tool that can run Pascal scripts during installation. By writing and executing a malicious Pascal script, an attacker can achieve initial obfuscation and defense evasion at install time. Using Inno Setup or NSIS as an installer dates back to at least 2010, but early cases mostly installed the malware as an ordinary file without specifically abusing Pascal’s logic capabilities. After the 2022 public disclosure of Inno Stealer’s abuse of Pascal-script execution, many malware families began adopting the technique, and abuse rose sharply.

Attack overview

This sample’s installation stage can be abstracted as follows: on launch, it requests UAC to run with administrator privileges; the installer then drops files and uses the script to break down protections, decrypts files, executes the next-stage malware, and launches a decoy document to deceive the victim.

Unpacking and script analysis

For files of this type, we can unpack the sample with InnoUnpacker (innounp) to obtain the resources and the execution script:

innounp.exe -v -m -x -dmal hysij.exe
  -m: obtain the execution script
  -x: export files
  -d: folder name

If unpacking fails, try the latest version of InnoUnpacker to handle newer Inno Setup installers.

The unpack results roughly divide into the install configuration file in the main directory, the resources under {app}, and the install-time script under the embedded directory. The SHA256 of each file is as follows:

First we examine the install configuration file install_script.iss in the main directory. The primary files funzip.b, man.dat, main.xml, and Server.log are initially dropped into C:\ProgramData\WindowsData, and no interface is shown during installation. Although this looks suspicious, the configuration itself contains no actual malicious behavior; because the files at this stage are all encrypted or encoded, scan engines cannot directly detect whether malicious logic is present.

Next we inspect CompiledCode.bin, which is the compiled bytecode of the Pascal Script. We can use ifpsdasm or the Inno Setup Decompiler to obtain the disassembly and reconstruct the script logic from it.

After analyzing the Pascal Script, we can resolve the following behavior performed during installation:

1. Read funzip.b, decode it with Base64, and output it as funzip.exe.
2. Create the directories C:\ProgramData\WindowsData\ and C:\Users\Public\Pictures\WindowsData\.
3. Check whether C:\ProgramData\WindowsData\Server.log exists, delete C:\Users\Public\Pictures\WindowsData\Server.log to avoid interference from an existing file, then move Server.log to that location.
4. Query via WMI whether Windows Defender is enabled. If it is, run powershell.exe -Command "Add-MpPreference -ExclusionPath 'C:\'" to add the entire C:\ drive to the Defender exclusion list.
5. Query via WMI whether the following processes exist: MsMpEng.exe, 360tray.exe, 360Tray.exe, QQPCRTP.exe, QQPCTRay.exe, kxetray.exe. If any is detected, set every Win32_NetworkAdapter with NetEnabled = TRUE to Disable, taking down all enabled network interfaces — presumably to break the endpoint’s real-time reporting and remote-query opportunities at install time.
6. Use funzip.exe to extract main.xml, passing the password argument -phtLcENyRFYwXsHFnUnqK; this password is composed of two substrings, and every sample under this framework uses it for protection.
7. Launch C:\ProgramData\WindowsData\setup.exe, which is the official LINE installer, to distract the victim.
8. Launch C:\ProgramData\WindowsData\men.exe, executing the next stage of the attack.

Abstracting the behavior, we reconstruct the following flow:

Among the dropped files, man.dat is unusually large and is never referenced by the install script or the subsequent flow. Given its common usage, we assess it to be a padding file used to inflate the sample’s size and reduce the likelihood of upload to online sandboxes or to delay scan processing.

At this point the installer has completed unpacking and landing, environment reconnaissance, defense bypass, and the reporting-suppression mechanism, and only then executes the decoy and the next-stage loader. Through multi-stage packaging, it prevents static-analysis tools from detecting malicious behavior in the first layer, making it look just like a normal installer.

Environment rebuild and dynamic sampling

If you want to build the “post-install” environment without executing the next-stage men.exe, run the following script in the same directory as the sample hysij.exe to build the environment:

# unpack.ps1
$MalDir = 'mal'

$XmlPath = Join-Path -Path ".\$MalDir" -ChildPath '{app}\main.xml'
$OutDir  = Join-Path -Path ".\$MalDir" -ChildPath '{app}'
$manPath = Join-Path -Path ".\$MalDir" -ChildPath '{app}\men.exe'
$logPath = Join-Path -Path ".\$MalDir" -ChildPath '{app}\Server.log'

innounp -v -m -x "-d$MalDir" hysij.exe

if (-not (Test-Path -Path 'C:\ProgramData\WindowsData')) {
    mkdir 'C:\ProgramData\WindowsData'
    mkdir 'C:\Users\Public\Pictures\WindowsData'
}

7z x -y -phtLcENyRFYwXsHFnUnqK $XmlPath "-o$OutDir"

cp $manPath 'C:\ProgramData\WindowsData\men.exe'
cp $logPath 'C:\Users\Public\Pictures\WindowsData\Server.log'

For dynamic sampling, you can use API Monitor to set a breakpoint on CreateProcess; when execution reaches men.exe, choose Skip Call to obtain the files without running the next stage. Note that Silver Fox uses different launch methods in other variants, which will prevent direct interception through the Windows API CreateProcess.

Variant observations

While tracking this sample family, we observed a number of interesting variants in the installer’s execution script, such as:

• Splitting files into two or more sub-files and merging them with repeated copy /b commands, then using a PowerShell script to replace the payload content.
• Executing tools used previously, even though the installer never deployed those tools (this phenomenon was also observed in the next stage).
• Switching to NSIS or other installer software, and using the latest versions to raise the analysis difficulty for older tools.
• Corrupting the installer format so that it still executes normally but cannot be parsed by tools.
• Changing the launch from a direct start to a scheduled task, obscuring the PPID relationship.

Technique summary

None of these techniques are new in themselves, but combined within the installation flow they form a loader-chain entry point that is hard to notice. What Silver Fox excels at is exactly this: combining multiple techniques within a single attack stage while mutating quickly and adopting emerging techniques, delaying detection and reporting. The mapping of each technique to ATT&CK is in the MITRE ATT&CK mapping table at the end of this report.

Conclusion

This chapter presents the landing stage of the Silver Fox loader chain. Even though it looks like the most easily overlooked part of an installation, it is the most important first stage: the attacker treats the installer as a scripting execution framework, completing unpacking and landing, defense bypass, and reporting suppression in one pass, and defers the real malicious core — paving the way for the next-stage payload so that the important techniques and malicious components take longer to detect. This design hides the content most likely to be caught by static scanning, makes the first layer look more like legitimate software distribution, and scatters the correlating conditions that endpoint detection relies on.

In the next chapter we will continue analyzing the control-node behavior of men.exe, along with how accompanying components such as bypass.exe and NVIDIA.exe extend the evasion and execution chain, shifting the perspective from the installer to central control and reconstructing how it establishes multiple persistently operating tools on the endpoint and maintains its attack capability.

Sample and references

• Analysis sample (tria.ge): https://tria.ge/260209-clfbsahz8g/, MD5 7979B24EC49575A1F1A3367F7B888D0E
• MITRE ATT&CK — basis for the technique mapping
• Original article (Medium, OIS, Traditional Chinese): 深入銀狐 Part 1：載荷落地，Inno Setup 與 Pascal 的隱形載入鏈