Angreifer setzten ein bisher undokumentiertes .NET-Framework zum Laden von Assemblies namens NetamLoader gegen ein angepasstes Windows-10-Build ein, das für Regierungsstellen in Asien vorgesehen ist. berichtete The Hacker News unter Berufung auf Forschungsergebnisse, die Kaspersky diese Woche veröffentlichte. Das Framework ermöglicht es Angreifern, weitere Payloads innerhalb von Windows-Prozessen abzurufen und auszuführen und dabei Dateien und Ausführungsspuren zu löschen.
Telemetriedaten von Kaspersky identifizierten ein Opfer in Asien. Die Aktivität wurde keinem bekannten Threat Actor zugeordnet. Ob sich der Eindringversuch auf ein einzelnes System beschränkte oder ob sensible Informationen gestohlen wurden, ist unklar.
Das angegriffene Land wurde nicht genannt. The Hacker News hielt China für eine wahrscheinliche Möglichkeit, weil Microsoft die Windows 10 China Government Edition für chinesische Behörden und staatseigene Unternehmen anbietet. Dabei handelt es sich um eine Schlussfolgerung der Redaktion und nicht um eine bestätigte Identifizierung eines Opfers.
Ein Archiv im Update-Verzeichnis startet die Angriffskette
Kaspersky entdeckte das Artefakt in der ersten Jahreshälfte 2026 in einem Windows-Cabinet-Archiv bzw. einer CAB-Datei. Die Datei lag in einem Verzeichnis für Betriebssystem-Updatepakete:
C:\Windows\SoftwareDistribution\Download\e4537a1762fcafd2fd96bfc825bad34f9db9a24
Der Inhalt des Archivs wurde nach C:\Windows\SoftwareDistribution\Download\Install\ extrahiert. Die Zustellungsmethode ist unbekannt. Ein Supply-Chain-Angriff über einen vertrauenswürdigen Drittanbieter wird vermutet, ist aber nicht belegt.
Die CAB-Datei enthielt sieben Dateien: fabric.config, Microsoft.HostIntegration.Connectors.dll, PatchMyPC-Enum.dll, PatchMyPC-Models.dll, PatchMyPC-ScriptRunner.exe, PatchMyPC-ScriptRunner.exe.config und Resources.resx. Vier davon waren legitime Komponenten von Patch My PC, einem Endpoint-Management-Produkt. Nur Resources.resx enthielt schadhaften Code.
Die Ausführung begann mit PatchMyPC-ScriptRunner.exe. Die Kette nutzte eine AppDomainManager-Injection aus. Dabei wird der Mechanismus des .NET-Frameworks gekapert, der beim Start einer Anwendung die Application Domains initialisiert. Ähnlich wie beim DLL-Sideloading kann schadhafter Code so im Prozess einer legitimen Anwendung laufen.
In diesem Fall las die ausführbare Datei PatchMyPC-ScriptRunner.exe.config ein, woraufhin Microsoft.HostIntegration.Connectors.dll ausgeführt wurde. Diese Komponente suchte die daneben liegende Datei fabric.config, las sie ein und lud anschließend Resources.resx.
Die Ressourcendatei enthielt mehrere Schichten kodierter, komprimierter oder verschlüsselter Inhalte, darunter XAML-Dateien, .NET-Assemblies und JSON-Daten. Jede Komponente dekodierte und lud die nächste, sodass die Ausführung über eine zweistufige Kette lief.
Geschichtete Payloads umgehen Scans und entfernen Spuren
Der erste XAML-Loader, von den Forschern XAML-1 genannt, lud einen eingebetteten Payload namens XAML-2. Dieser initialisierte die zweite Stufe, indem er zwei komprimierte, Base64-kodierte XAML-Dateien lud: XAML-2-1 und XAML-2-2. XAML-2-1 lieferte eine Umgehung des Antimalware Scan Interface (AMSI).
XAML-2-2 enthielt ein .NET-Modul namens .NET 1 Loader sowie einen JSON-Payload namens JSON-1. Die JSON-Daten bestanden aus zwei Teilen: JSON-1-c enthielt die Konfiguration für Command-and-Control, während JSON-1-p eine Base64-kodierte Assembly namens .NET 2 Plugin sowie komprimierte, verschlüsselte XAML-Vorlagen enthielt, mit denen XAML-3 erstellt wurde.
Nachdem XAML-2-2 .NET 1 Loader geladen hatte, entschlüsselte, assemblierte und lud dieses Modul XAML-3. Außerdem meldete es den Status an den Command-and-Control-Server. Zudem entfernte es die aus dem CAB-Archiv extrahierten schadhaften Dateien, CLR-Nutzungsprotokolle und Windows-Prefetch-Dateien, um Ausführungsspuren zu verbergen.
XAML-3 lief innerhalb von dllhost.exe. Dort dekodierte, dekomprimierte und lud es .NET 2 Plugin. Das Plugin las seine Command-and-Control-Konfiguration ein, sammelte Systeminformationen aus der Windows-Registrierung und prüfte, ob sein aktueller Hostprozess dllhost.exe war.
Ein Ziel speziell für Regierungen und verzögerte Kommunikation
Das Ziel ist ein Windows-Build, das ausschließlich für Regierungen bestimmt ist. Im politischen Kontext verwies The Hacker News auf einen Bericht von Bloomberg aus dem August. Demnach hatte das chinesische Ministerium für Staatssicherheit einige Regierungsbehörden angewiesen, Windows „Government Edition“ durch in China hergestellte Linux-Distributionen zu ersetzen, um die Abhängigkeit von ausländischer Technologie zu verringern. Bloomberg führte die Anweisung laut Personen mit Kenntnis der Sache auf Bedenken hinsichtlich der Datensicherheit zurück.
Kaspersky kam in einer breiteren Bewertung zu dem Schluss, dass Länder, die eigene Betriebssysteme und andere zentrale Plattformen entwickeln, die Kontrolle über Entwicklung, Betrieb und Updates gewinnen, aber auch die Verantwortung für den Schutz des gesamten Ökosystems übernehmen. Den Betrieb und die Wartung solcher Plattformen auszureifen, brauche Zeit, so das Unternehmen.
Für Fachleute, die diese Kette analysieren, ist das dokumentierte Kommunikationsverhalten von erheblichen Verzögerungen geprägt. In der im ersten Halbjahr 2026 entdeckten Probe wartete .NET 2 Plugin zufällig 20 bis 40 Minuten, bevor es die erste Anfrage an openaigpt4v[.]com stellte. Danach rief es periodisch eine XAML-Datei ab und führte sie in einer isolierten AppDomain aus.
Eine gültige Antwort des Command-and-Control-Servers löste eine Pause von 5 bis 6 Minuten vor der nächsten Anfrage aus. Andernfalls wartete das Plugin 22 bis 28 Stunden und prüfte alle 10 Minuten, ob dieses Intervall verstrichen war.
