NetamLoader Malware: What Happened in the Windows 10 Attack?
NetamLoader malware demonstrates how a Windows computer can be targeted without relying on an obviously suspicious application or a familiar malicious installer. In a recently published investigation, Kaspersky researchers described a sophisticated attack against a customized Windows 10 environment used exclusively by government organizations in an Asian country. The attackers used legitimate software components, modified configuration files and a complex .NET loading framework to execute malicious code while concealing its activity.
Kaspersky published its technical investigation on October 29, 2026, after identifying the suspicious activity through its threat monitoring network. The researchers named the previously undocumented framework NetamLoader. Their investigation identified one victim and did not attribute the activity to any known threat group.
The incident is particularly interesting because most of the files found in the initial archive appeared to be legitimate software components. This highlights a security problem that ordinary antivirus checks and basic file reputation assessments may not fully explain: a genuine program can become part of a malicious execution chain when its configuration or surrounding files are manipulated.
What Is NetamLoader Malware?
NetamLoader is a multi-stage .NET malware framework designed to load and execute additional code while attempting to hide its activity inside legitimate Windows processes. Kaspersky's analysis describes a chain involving configuration-file manipulation, .NET assembly loading, XAML payloads, encrypted data and communication with an attacker-controlled server.
Rather than behaving like a conventional executable that immediately displays suspicious activity, the framework uses several components to prepare and load its payload. It also attempts to interfere with security scanning and remove traces that could help investigators reconstruct what happened.
Kaspersky reported the following detection names for the threat: HEUR:Trojan.MSIL.NetamLoader.gen, Trojan.MSIL.Zapchast.* and Trojan.Script.Agent.*.
These names are useful for security teams reviewing alerts from Kaspersky products. They should not be treated as universal detection names across every antivirus platform.
Why Did the Attack Involve Patch My PC Components?
One of the most important details in the investigation is the presence of legitimate components associated with Patch My PC, a third-party patch management tool. The suspicious archive also contained a Microsoft-signed .NET module.
At first, most of the files did not appear to contain malicious code. The researchers later identified a modified configuration and supporting files that caused legitimate software components to load attacker-controlled instructions.
This distinction matters. Kaspersky did not establish that Patch My PC itself, its official distribution infrastructure or Microsoft had been compromised. Researchers also did not observe how the archive originally reached the victim's computer. The location and structure of the files suggested a possible software supply-chain attack, but the precise delivery method remained unknown.
In a software supply-chain attack, attackers abuse a trusted component, development process, update mechanism or distribution relationship to reach another organization. A user or administrator may recognize the software name and assume that everything associated with it is safe. However, the integrity of the configuration files, dependencies and execution environment matters just as much as the identity of the original publisher.
How the NetamLoader Infection Chain Works
Kaspersky found the suspicious archive in a Windows update download directory. The archive was stored under C:\Windows\SoftwareDistribution\Download\ and contained seven files that were extracted into an Install subdirectory.
Most of the components were legitimate Patch My PC files or Microsoft-signed software. The researchers identified Resources.resx as the file containing malicious content. The execution chain then used a configuration file to influence how the .NET application loaded additional components.
AppDomainManager injection starts the loading process
The attack used a technique known as AppDomainManager injection. In normal .NET applications, an AppDomainManager helps manage application domains, which provide runtime environments for executing code. Attackers can abuse this mechanism by modifying configuration files or related runtime settings so that a legitimate application loads an unexpected assembly.
In the NetamLoader investigation, the configuration associated with PatchMyPC-ScriptRunner.exe directed the application toward a Microsoft.HostIntegration.Connectors.dll component. That component then processed additional configuration and resource files, eventually reaching the malicious payload.
MITRE ATT&CK documents this technique as T1574.014: Hijack Execution Flow through AppDomainManager. The technique is not unique to NetamLoader; it describes a broader way attackers can manipulate .NET application loading behavior.
Multiple layers of XAML and .NET payloads
The next stages involved encoded, compressed and encrypted content. Kaspersky described a sequence of XAML payloads and .NET components that progressively loaded additional functionality.
The initial resource file contained a serialized object that triggered a deserialization chain. This led to XAML processing and further payload loading. Additional components were used to decode and decrypt the next stages, making the full execution process more difficult to understand through a quick inspection of the original archive.
Some of the later components were designed to interfere with the Antimalware Scan Interface, commonly known as AMSI. AMSI is a Windows security interface that allows supported applications and security products to inspect potentially malicious content. Interfering with this inspection process can make detection more difficult.
Execution moves into a legitimate Windows process
The later stage moved execution into a legitimate Windows process, including dllhost.exe. Running malicious functionality inside a familiar system process can make the relationship between the original loader and the final payload less obvious.
The framework also attempted to delete files and traces associated with its execution. Kaspersky described activity involving Windows update-related records, CLR usage logs and Prefetch artifacts. These behaviors are important because they can reduce the evidence available during a later investigation.
How NetamLoader Communicates With Its Command-and-Control Server
Once active, the malware framework contacts an attacker-controlled command-and-control server to Receive instructions and configuration information. The communication process described by Kaspersky includes delays that can make short monitoring sessions less effective.
In the configuration examined by researchers, the first connection was delayed by approximately 20 to 40 minutes. When the server did not return a valid response, the malware could wait approximately 22 to 28 hours before trying again. When a valid response was received, the polling interval was much shorter.
This behavior helps explain why a brief network observation might not reveal the full activity of a compromised system. Security monitoring needs to correlate endpoint behavior, file activity and network events over an appropriate period rather than relying on a single short capture.
Does NetamLoader Mean Patch My PC or Windows Update Was Hacked?
No such conclusion is established by the published investigation. Kaspersky found Patch My PC components inside the suspicious archive and identified configuration manipulation that caused those components to participate in the malicious execution chain. However, researchers explicitly said they did not observe how the archive reached the victim.
That means the report does not prove that Patch My PC's official update servers, software distribution process or Microsoft Windows Update infrastructure were compromised. The presence of a legitimate executable inside a malicious archive is not sufficient evidence of a vendor-level breach.
This distinction is important for businesses and software users. Security investigations should separate what was directly observed from what researchers believe may have happened. A possible supply-chain attack is a meaningful finding, but the exact entry point remains unresolved in this case.
What Security Teams Should Check for NetamLoader Activity
Organizations managing Windows endpoints should treat this investigation as a useful example of why trusted application behavior needs monitoring. The following indicators come from Kaspersky's technical report and MITRE's guidance on AppDomainManager injection. They are investigation clues, not proof that a machine is infected.
- Unexpected CAB archives or extracted files appearing under C:\Windows\SoftwareDistribution\Download\.
- Unexpected PatchMyPC-ScriptRunner.exe execution from a Windows update download directory.
- Unusual .exe.config files that redirect .NET application loading through AppDomainManager settings.
- Unexpected fabric.config or Resources.resx files appearing alongside executable components.
- Unusual .NET assemblies or XAML content loaded by trusted processes, including dllhost.exe.
- Unexpected changes to AMSI behavior or suspicious attempts to remove Prefetch and CLR-related records.
- Unusual outbound connections or delayed periodic communication from a process that does not normally require external network access.
Kaspersky's report also includes file hashes, file paths and network indicators that qualified security teams can use during threat hunting. Administrators should retrieve those indicators directly from the original NetamLoader technical investigation rather than relying on copied lists from unverified sources.
How Organizations Can Reduce Similar Windows Malware Risks
There is no ordinary consumer update that removes NetamLoader from every Windows computer. The published report describes a targeted incident rather than a general Windows vulnerability with a universal security patch. Organizations should therefore focus on endpoint integrity, application control and investigation.
Monitor configuration files used by .NET applications
Unexpected changes to .config files deserve attention when they alter how trusted applications load assemblies. Security teams can monitor important application directories for new or modified configuration files and correlate those changes with process creation and module loading events.
Protect software and update directories
Windows update and application-management directories should not be treated as unrestricted storage locations. Apply appropriate file-system permissions and investigate unexpected executables, configuration files or resource archives appearing in these locations.
Use application control and endpoint monitoring
Organizations can use Windows application control technologies and endpoint detection tools to restrict unapproved execution and monitor unusual process behavior. Microsoft documents application control options such as App Control for Business and AppLocker. Their effectiveness depends on correct configuration, testing and ongoing management.
Verify software components beyond their digital signatures
A valid digital signature can help establish the publisher and integrity of a signed file, but it does not prove that every configuration file, dependency or execution context around it is safe. Teams should also validate software provenance, compare files with known-good versions and monitor unexpected behavior from legitimate applications.
Preserve evidence and investigate suspicious systems
If an endpoint shows indicators associated with this type of attack, preserve relevant logs and forensic evidence before making changes that could destroy useful information. Investigate the process chain, file creation events, module loads and outbound connections. Follow the organization's incident response process and involve qualified security personnel when compromise is suspected.
What NetamLoader Teaches Us About Software Supply-Chain Security
NetamLoader is a reminder that software security cannot be judged only by looking at an application's name or publisher. Attackers can manipulate configuration files, abuse legitimate runtime behavior and use signed components as part of a malicious execution chain.
For organizations, the lesson is to monitor how software behaves after installation, not just how it arrived. Update tools, endpoint management platforms and development utilities often have access to important systems. Their directories, configuration files and execution permissions deserve the same attention as other critical infrastructure.
For ordinary Windows users, there is no evidence in this investigation that every Windows 10 computer or Patch My PC installation is affected. The reported activity was highly targeted, and Kaspersky identified one victim through its telemetry. Users should continue installing software from trusted sources, keeping security protections enabled and contacting their IT team if they notice suspicious endpoint activity.
The most important takeaway is simple: a legitimate program can be abused without the original software vendor being compromised. Strong endpoint monitoring, configuration integrity and careful investigation are essential for detecting threats that hide behind trusted software.
Official Sources and Further Reading
- Kaspersky Securelist: Unknown APT uses NetamLoader to attack a customized government Windows 10 system
- Kaspersky: NetamLoader investigation announcement
- MITRE ATT&CK: AppDomainManager injection, T1574.014
- MITRE ATT&CK: Detection strategy for AppDomainManager hijacking
- Microsoft Learn: Application and driver control in Windows
