NetamLoader Targets Customized Government Windows Builds

A newly documented malware framework shows how attackers can turn trusted operating-system components, signed .NET assemblies and administrative tooling into stages of a carefully concealed intrusion. Securelist, Kaspersky’s research publication, has analyzed NetamLoader, a multi-layer loader used against a customized Windows 10 environment reportedly reserved for government entities in Asia.

The research describes a technically complex chain built around configuration abuse, XAML, embedded .NET components and encrypted payloads. The framework also attempts to interfere with antimalware scanning, remove forensic traces and move execution into dllhost.exe, separating later activity from the original process.

Several aspects of the campaign remain unresolved. Securelist did not observe how the initial archive reached the victim, identified only one victim through Kaspersky Security Network telemetry, and found no reliable link to an established advanced persistent threat group. The findings therefore support a focused assessment of the malware and its execution design, but not a broad conclusion about the campaign’s scale or sponsor.

What Securelist confirmed

The investigation began with a Kaspersky Security Network alert involving a configuration file that used .NET AppDomainManager injection to load an assembly. The file was inside a CAB archive stored under the Windows update-download directory:

C:\Windows\SoftwareDistribution\Download\e4537a1762fcafd2fd96bfc825bad34f9db9a24d

After extraction, the archive placed files in an Install subdirectory and included a legitimate-looking Patch My PC component. Securelist observed PatchMyPC-ScriptRunner.exe running with an update-package argument. The researchers did not establish how the CAB file was delivered, so the initial access vector is unknown.

Most archive contents did not contain malicious code. The abuse instead depended on the interaction between the executable, its adjacent configuration files and a resource file. A configuration setting caused a Microsoft-signed assembly to load before the host program’s normal entry point. That assembly’s configuration handling was then used to instantiate a type that processed Resources.resx.

The resource file contained a serialized object encoded in Base64. When parsed, it invoked .NET BinaryFormatter deserialization and a TypeConfuseDelegate-based execution path. Securelist reports that this path invoked XamlReader.Parse(), loading an embedded XAML stage. The result was a loader chain in which successive components unpacked, decrypted or decoded the next layer in memory.

A staged loader built from trusted components

The first XAML stage derived an AES key from the lowercase command line of the Patch My PC host process. It decoded an embedded data block, used its first 16 bytes as an initialization vector, and decrypted the remainder into another XAML stage. If decryption failed, the process exited silently, a behavior designed to avoid visible errors.

The next stage contained two compressed XAML components. One focused on weakening scanning defenses. Securelist says it reconstructed fragmented strings, located an AMSI-related COM object and altered memory so that subsequent scans returned a clean result. The implementation also modified a legitimate method’s initial bytes and redirected an AMSI scan function through a virtual-method-table change. These actions represent confirmed behavior in the analyzed sample, not evidence that every NetamLoader deployment uses identical values or code.

The second XAML component loaded a .NET assembly and supplied it with a JSON configuration. That configuration carried additional payloads, encryption material, timing values and C2-related settings. Before proceeding, the loader checked configuration integrity and verified that the current user had administrator rights. A failure could stop the chain and generate an execution-status report.

The loader also performed cleanup. Securelist observed deletion of malicious staging files, CLR usage logs and Windows Prefetch entries associated with the host process. It filtered selected entries from logs under a path containing CmitUpdateAgent, which the researchers considered potentially related to the customized Windows build. The malware additionally removed registry keys used for exception-state tracking.

Process separation and payload execution

NetamLoader’s later stages were designed to move execution away from the initial Patch My PC process. The chain used RPC to create a remote COM object and abused an unknown binary-object deserialization vulnerability together with TypeConfuseDelegate. Securelist reports that this resulted in XAML execution inside dllhost.exe.

The .NET plugin created a COM registration-related entry with an empty DllSurrogate value and used object locking to keep the surrogate process alive. It also checked whether the current process was dllhost.exe, behavior that the researchers interpreted as anti-analysis and process-control logic.

Inside the surrogate process, the plugin loaded another XAML payload and a .NET assembly. Downloaded XAML was executed in a separate .NET AppDomain. The framework copied configuration into that isolated domain, invoked the payload through delegate manipulation, and later unloaded the domain. This design kept the downloaded material out of the principal application domain and allowed the framework to remove the isolated execution context after use.

Securelist also observed an environment change intended to prevent the CLR from registering its .NET ETW provider. Combined with AMSI interference, AppDomain isolation and process separation, this gave the framework several layers of defense evasion. These capabilities should be treated as sample-specific confirmed findings; the report does not establish the full operational history of the campaign.

Long delays make time a defensive signal

NetamLoader was not designed to communicate immediately. The analyzed configuration specified a random initial delay of 20 to 40 minutes before the first C2 request. It also included an approximately 28-hour execution limit after which the process would exit. If a C2 response was valid, subsequent polling occurred after a shorter five-to-six-minute pause. If the server did not respond, the framework waited roughly 22 to 28 hours and periodically checked whether that interval had elapsed.

These timing values are important for defenders because a short sandbox observation window may miss network activity entirely. Endpoint investigations should therefore consider delayed behavior and correlate events over longer periods rather than treating the absence of immediate outbound traffic as evidence of benign execution.

Encrypted communications and proxy awareness

The plugin gathered the .NET Framework version and Windows build information from the registry, along with proxy-related status. It attempted to discover proxy settings through WinHTTP, the configuration associated with explorer.exe, and the .NET default proxy property.

Network traffic used HTTPS and an AES-128-CBC construction combined with HMAC-SHA256. The framework derived separate encryption and authentication keys from a configured master key, generated a random IV, encrypted the data and authenticated the IV-plus-ciphertext result. It then Base64-encoded the complete value.

The reported C2 domain was openaigpt4v[.]com, and the sample used the path /model_v4/ followed by a malware instance identifier. Securelist reports that the domain and associated address were hosted through Cloudflare infrastructure. Because the address belongs to shared CDN infrastructure, network teams should avoid treating the IP alone as a definitive indicator without additional context.

The malware sent encrypted system information and configuration-related data, then retrieved XAML from the server. It could update its configuration and execute the returned content in an isolated AppDomain. The report does not document the ultimate objectives or additional commands delivered during a successful intrusion.

Victim scope and attribution

Securelist identified one victim through Kaspersky Security Network telemetry. The sample was designed for a specially customized, government-only Windows version, leading the researchers to infer that Asian government entities were the intended targets. That is an assessment based on the operating-system environment and malware design, not confirmation of a wider victim set.

Securelist was unable to associate the activity with a known APT group after reviewing tactics, code similarities and infrastructure. NetamLoader should therefore be discussed as an unattributed campaign framework rather than assigned to a named actor.

Detection and investigation priorities

Organizations operating customized Windows builds should monitor update directories for unexpected CAB archives, configuration files or executables that do not match approved update workflows. Particular attention is warranted for activity involving PatchMyPC-ScriptRunner.exe, adjacent .config, fabric.config or Resources.resx files, and unusual loading of Microsoft-signed assemblies.

Endpoint telemetry should record changes to AMSI-related memory, attempts to alter virtual method tables, CLR ETW configuration, creation of COM surrogate registrations and unusual dllhost.exe launches associated with RPC or administrative processes. File and registry deletion involving CLR usage logs, Prefetch data, Windows update logs or exception-tracking keys should also be investigated rather than dismissed as routine maintenance.

Network monitoring should account for long delays, encrypted HTTPS query data, proxy discovery and periodic access to openaigpt4v[.]com. Security teams should correlate domain activity with process lineage, destination timing and the presence of the host and staging artifacts. Hash-based detection can supplement behavioral rules, but it should not replace them because the framework’s layered payloads and configuration-driven design may allow future variants to change file content.

What organizations should do now

• Review customized Windows images and update workflows for unapproved CAB files or unexpected content under C:\Windows\SoftwareDistribution\Download\.
• Enable detailed process, module-load, script, .NET, registry and network telemetry, including events associated with dllhost.exe and administrative COM activity.
• Hunt for the reported file paths, the defanged domain openaigpt4v[.]com, and the file hashes listed in the source report.
• Investigate attempts to disable or bypass AMSI, suppress CLR ETW registration, modify COM surrogate settings or delete forensic artifacts.
• Extend sandbox and detonation observation periods so delayed execution and delayed C2 polling are not missed.
• Restrict outbound access from sensitive government or administrative hosts to only necessary destinations, while accounting for approved proxy infrastructure and shared CDN services.
• Preserve affected systems for forensic review before deleting suspicious files or logs, because the malware attempts to remove evidence during execution.

Conclusion

NetamLoader demonstrates a high degree of engineering around a narrow target environment. Its significance lies less in a single novel payload than in the combination of trusted signed components, XAML-based staging, encrypted configuration, AMSI interference, process separation, long timing delays and forensic cleanup. Securelist’s findings establish a focused intrusion against a customized government Windows build, but the delivery method, campaign scale and responsible actor remain unknown. Defenders should prioritize behavioral visibility across update directories, .NET execution, COM surrogates, delayed network activity and evidence-removal operations.

Sources

Securelist: “Unknown APT uses NetamLoader to attack a Win10 OS customized for governments in Asia”