A trusted patch tool became the delivery vehicle
Kaspersky's researchers found NetamLoader riding inside a CAB file sitting in a Windows update download directory, bundled alongside genuinely legitimate components from Patch My PC, a widely used third-party patching utility. The pairing is deliberate: a CAB file full of real patch-management binaries looks exactly like the kind of artifact an endpoint protection tool, or a human analyst doing a quick triage, would wave through without a second look. The exact delivery vehicle that got the CAB file onto the target system in the first place remains unconfirmed, though the article's framing points to a supply-chain-style insertion rather than a direct phishing lure.
The target was narrow and specific: a custom Windows 10 build used exclusively by government organizations in Asia. Microsoft does produce a China Government Edition of Windows 10, and Kaspersky's telemetry showed a single confirmed victim, which fits a tightly scoped espionage operation rather than a mass campaign. The artifact itself was first detected in the first half of 2026, meaning it sat in the wild, or at least in Kaspersky's collection pipeline, for months before this public writeup.
AppDomainManager injection is the technique to know
The infection chain runs in two stages. First, a renamed executable, PatchMyPC-ScriptRunner.exe, abuses AppDomainManager injection, a legitimate .NET Framework feature that lets a configuration file redirect an application to load an arbitrary assembly at startup. That loads a malicious DLL disguised with a Microsoft-sounding name, which in turn reads a configuration file and pulls in a resource file containing the next stage. The technique, tracked by MITRE as T1574.014, produces an effect functionally identical to DLL sideloading: attacker code runs inside a process your security tooling already trusts.
The second stage unpacks multiple layers of encoded, compressed, and encrypted payloads, including XAML files and additional .NET assemblies, and executes them inside dllhost.exe rather than the original process. The final plugin waits a random 20 to 40 minutes before beaconing to its command server, a deliberate delay built to defeat the kind of behavioral detection rules that flag immediate post-execution network activity. It then polls for further XAML-based instructions to run in isolated AppDomains, and cleans up its own tracks on the way out.
The attribution gap is itself a signal
Kaspersky has not named a threat actor, and that absence is worth sitting with rather than rushing past. AppDomainManager injection has shown up in multiple espionage toolsets over the past two years precisely because it is effective and still under-detected, which means this technique is now common enough across different operators that a single sample no longer points cleanly to one group's tradecraft fingerprint. It has, in effect, become shared infrastructure for espionage tooling generally, available to any operator with enough skill to adapt the public research describing it.
That matters operationally more than it matters for headlines. If your threat model still organizes defenses primarily around named adversary groups and their known, catalogued tools, you will miss techniques like this one that have become shared tradecraft across unrelated actors rather than the signature of any single group. The right response is to detect the underlying behavior directly: unusual AppDomainManager configuration entries, unexpected child processes spawned inside dllhost.exe, and CAB files appearing in update directories outside your normal patch cadence, rather than waiting for attribution research to tell you which adversary to worry about this quarter.
Your patch pipeline is a trust boundary, treat it that way
Most enterprise security programs grant implicit trust to anything flowing through sanctioned patch-management and software-deployment tooling, because flagging every update as suspicious would quickly make the tools unusable for day-to-day operations. NetamLoader exploits precisely that implicit trust: a CAB file with genuinely real Patch My PC components inside it is engineered to pass the sniff test that both automated scanning tools and human reviewers naturally apply to anything arriving through a trusted update channel.
The sensible fix is not to distrust your patching vendor wholesale. It is to add integrity verification at the point of ingestion into your patch pipeline, hash-checking downloaded packages against vendor-published manifests, logging and alerting on any file written to an update directory outside your expected deployment schedule, and extending EDR behavioral rules to cover AppDomainManager configuration changes specifically, since the technique is now common enough across espionage toolsets to warrant a dedicated detection rule rather than relying on generic anomaly scoring to catch it eventually.
What this means for the roadmap
If you operate in a regulated sector, a government-adjacent supply chain, or any environment where nation-state-grade persistence is a realistic threat model, add AppDomainManager injection detection to your EDR tuning backlog this quarter rather than letting it sit behind higher-profile items. The technique has filtered well beyond the most sophisticated operators by now, into tooling that smaller, less resourced groups can replicate with modest effort once the underlying research is public, which it already is.
More broadly, ask your endpoint security vendor directly whether their product ships a specific detection rule for this technique, beyond generic sideloading heuristics that may not catch the AppDomainManager configuration path at all. The answer will tell you something real and current about how actively your vendor's detection engineering team tracks published espionage tradecraft, and it is a fair, pointed question to put in front of them at your next renewal conversation rather than taking their marketing material at face value.
