Reconstructing a Loader’s Architecture From Structure Alone

At a glance

Both samples are tagged on MalwareBazaar as Silver Fox / ValleyRAT. Sample B was compiled roughly twenty-four hours before it was analysed.

The engine reconstructed the role each binary plays inside a documented multi-stage campaign, from static structure, with no knowledge of the campaign. And among the engines that returned Undetected on Sample B is ZoneAlarm by Check Point — the vendor whose own researchers published the definitive analysis of this loader architecture.

The campaign, as publicly documented

Check Point Research and others have described the Silver Fox APT's delivery architecture in detail. The group's loaders are self-contained packages combining anti-analysis checks, embedded vulnerable drivers, EDR/AV killer logic and a ValleyRAT downloader in a single binary.

The killer routine abuses a signed but vulnerable driver — Bring Your Own Vulnerable Driver — to terminate protected security processes, iterating over a Base64-encoded list of target process names. The loader then decodes and injects the downloader module into memory, which retrieves the final ValleyRAT (Winos) backdoor. Reporting places the command-and-control infrastructure in China.

This background is drawn from third-party publications and reproduced as context. Dekeneas does not perform actor attribution and made no attribution claim about either sample.

Sample B — the capability map

Sample B is the fuller build, and its capability output maps onto the published architecture component by component. The left column is the campaign as described in public reporting; the right is what Dekeneas reported from the binary.

Every row on the right was produced from static structure, with each capability reported at its virtual address with disassembly attached. The engine did not know it was looking at a Silver Fox loader. It described what the binary was built to do, in enough detail that the correspondence is checkable line by line.

The synthesis, not just the inventory

A list of sixty-three capabilities and their addresses is evidence. It is not yet an assessment, and turning one into the other is the work an analyst normally does by hand.

The analyst note performs that step. From the same structural evidence, without external reference, it reports:

It disables Windows Defender features and other system protections via registry modifications. It also uses techniques like encoding data with XOR and encrypting with RC4, which are common in obfuscating malicious payloads. The sample creates and modifies registry keys, likely to establish persistence, and interacts with system services. It also checks for virtual machine environments, which may indicate anti-analysis measures.

And it reaches the functional classification directly:

Based on the observed behaviors, this sample is likely a backdoor or a loader. The focus on persistence, system manipulation, and potential payload delivery mechanisms aligns with these types. However, without more specific indicators, the exact family cannot be definitively determined.

That is the correct role, identified by the engine — not inferred afterwards by a reader with the campaign literature to hand.

The note also maps the findings to MITRE ATT&CK automatically: T1562.001 (Impair Defenses: Disable or Modify Tools), T1547.001 (Registry Run Keys / Startup Folder), T1543.003 (Windows Service), T1569.002 (Service Execution), T1497.001 (Virtualization/Sandbox Evasion), alongside the discovery techniques T1007, T1012, T1033, T1057, T1082, T1087 and the obfuscation technique T1027.

Those technique IDs are directly consumable — they go into a detection backlog, a threat report or a control-coverage review without an analyst first having to derive them from a capability list. For an organisation without a reverse engineer on staff, this is the difference between a result that must be interpreted and a result that can be used.

Two independent confirmations

Where other vendors did detect Sample B, their labels corroborate the reconstruction rather than merely agreeing on the verdict.

ESET-NOD32 names it Win64/KillAV.FK. The AV-killer function is exactly what Dekeneas derived from Disable AntiVirus, Disable Firewall, the service-control set and the driver IOCTL — arrived at independently, from structure.

VirusTotal tags the file signed, the popular threat label is trojan.malcert, and VBA32 returns SigCompromised. Abused code signing is a defining element of this campaign's tradecraft, and the artefact list's contains references to security software sits alongside it consistently.

Knowing a campaign is not the same as detecting it

The most instructive entry in Sample B's VirusTotal results is not among the detections.

ZoneAlarm by Check Point: Undetected.

Check Point Research produced the reference analysis of this exact loader architecture. Their researchers identified the vulnerable signed driver, documented the Base64-encoded list of security processes targeted for termination, described the in-memory injection of the ValleyRAT downloader, and traced the command-and-control infrastructure. No organisation understands this campaign better.

Their scanning engine did not detect this sample.

This is not a criticism of the research, which is excellent and which this case study relies on. It is a demonstration of something structural about how detection works. Knowledge of a campaign does not transfer to detection of its artefacts when detection depends on having seen the specific file. Silver Fox ships new builds; hashes change; signatures and reputation data describe samples already collected. A build compiled yesterday is outside that coverage no matter how thoroughly the campaign has been studied.

What does transfer is capability. The driver IOCTL interaction, the service control sequence, the AV and firewall disabling, the four anti-VM checks, the XOR and RC4 staging — these are the loader's function, and the operator cannot remove them without removing the loader's purpose. They persist across rebuilds, recompilations and repacking, because they are what the binary is for.

That is the whole of the argument for capability analysis, and the vendor best placed to refute it is the one that illustrates it.

Also returning Undetected on Sample B: BitDefender, Sophos, TrendMicro, Fortinet, WithSecure, SentinelOne (Static ML), Avira, DrWeb, Emsisoft, GData, Ikarus, Sangfor, Skyhigh, Tencent, VIPRE, Webroot, Xcitium, Trapmine, TEHTRIS, Arctic Wolf, Cynet and SecureAge.

Sample A — a different stage, a different profile

Sample A carries a markedly thinner capability set: 20 code capabilities against Sample B's 63, and 5 artefacts against 22.

What it does contain is a coherent first-stage profile — victim profiling (get hostname, get session user name, get disk size, get system information), evasion (anti-VM strings for VMware and VirtualBox, GetSystemPowerStatus for the absent-battery check, and a long-sleeps tag on VirusTotal indicating timeout evasion), staging (XOR, RC4 PRGA, reference Base64 string), manual API resolution, and persistence via registry and scheduled task.

What it does not contain is the defence-evasion machinery: no driver interaction, no service control, no AV or firewall disabling, no privilege acquisition for protected-process termination.

Its metadata also carries an obvious tell. The compile timestamp reads 2082-05-19 — fifty-six years in the future, an unambiguous forgery, surfaced directly in the PE metadata panel.

Why the scores differ

Sample A scores 58.2. Sample B scores 62.8.

The Dekeneas risk score is not a confidence value. Classification is performed by an ensemble of ten independent models, each trained on a separate and deliberately non-overlapping family of signals, with a further model aggregating their outputs. The score expresses how far those independent views agree — how many orthogonal perspectives on the file carry malicious signal — rather than how strongly any one of them believes.

Read that way the ordering is a statement about the two binaries. Sample B carries signal in families that Sample A leaves quiet: service control, driver interaction, defence disabling, privilege manipulation. Sample A concentrates its signal in evasion, staging and recon. More views agreeing produces the higher score.

Neither file is a complete weapon, and neither scores as one. A loader's purpose is to reach a payload that is not present in it. The ransomware in Case Study 03 scored 97.08 because a complete extortion mechanism leaves evidence in nearly every signal family at once. These two are components, and the scores say so — while still landing decisively on the malicious side of the boundary.

What this case demonstrates

Capability output is detailed enough to establish role, not just verdict. The distinction between a first-stage profiler and a defence-evasion loader is visible in the output without any external reference.

No prior knowledge was required. No signatures, no family database, no reputation service. Sample B was one day old.

Campaign knowledge does not substitute for capability analysis. The vendor that published the reference research on this loader architecture returned Undetected on a sample of it.

The reconstruction is verifiable. Each capability carries a virtual address and disassembly, so the mapping table above can be checked against the binary rather than taken on trust.

Score ordering reflects file structure. Two builds from the same campaign, correctly ranked by how much of the operation each one contains.

Verify this yourself

Both hashes are public. The Dekeneas free tier includes malware analysis at no cost, and both results can be reproduced directly.

Scope of the comparison

The engine identified both samples as malicious and classified Sample B's functional role as a backdoor or loader. What it did not do is name Silver Fox: it performs no actor attribution, and the campaign context in this case study comes from third-party reporting. The mapping table aligns the engine's capability output with that published research, and the alignment was checked by a reader — but the role identification, the technique mapping and the behavioural summary are the engine's own output, not a reader's interpretation of it.

Several major vendors did flag Sample B, including CrowdStrike, Kaspersky, Microsoft, ESET, Palo Alto, Elastic, Trellix, Malwarebytes and Symantec. The observation about Check Point concerns what its engine returned on this file; the vendors listed as undetected are recorded as VirusTotal reported them at the time of analysis.