NetamLoader cible Windows 10 personnalisé de gouvernements asiatiques

NetamLoader cible Windows 10 personnalisé de gouvernements asiatiques

Ajoutez CyberWorldOpsà vos sources préférées sur Google
NetamLoader cible Windows 10 personnalisé de gouvernements asiatiques
Malware

Image d’illustration générée par IA

Des attaquants ont déployé un framework de chargement d'assemblies .NET jusqu'alors non documenté, baptisé NetamLoader, contre une build personnalisée de Windows 10 réservée aux entités gouvernementales d'Asie. The Hacker News a rapporté l'information en citant des travaux que Kaspersky a détaillés cette semaine. Le framework permet aux attaquants de récupérer et d'exécuter d'autres charges utiles au sein de processus Windows, tout en supprimant fichiers et traces d'exécution.

La télémétrie de Kaspersky a identifié une victime en Asie. L'activité n'a pas été attribuée à un acteur de menace connu, et l'on ignore encore si l'intrusion s'est étendue au-delà d'un seul système ou si des informations sensibles ont été volées.

Le pays visé n'a pas été divulgué. The Hacker News a évoqué la Chine comme possibilité probable, car Microsoft propose Windows 10 China Government Edition aux administrations et entités d'État chinoises. Il s'agit toutefois de l'hypothèse du média, et non d'une identification confirmée de la victime.

Une archive du répertoire de mises à jour lance la chaîne

Kaspersky a détecté l'artefact au cours du premier semestre 2026 dans une archive Windows cabinet, ou fichier CAB, stockée dans un répertoire utilisé pour les paquets de mise à jour du système d'exploitation :

C:\Windows\SoftwareDistribution\Download\e4537a1762fcafd2fd96bfc825bad34f9db9a24

Le contenu de l'archive a été extrait dans C:\Windows\SoftwareDistribution\Download\Install\. Son mode de livraison reste inconnu. Une compromission de la chaîne d'approvisionnement impliquant un fournisseur tiers de confiance est soupçonnée, mais non établie.

Le fichier CAB contenait sept fichiers : fabric.config, Microsoft.HostIntegration.Connectors.dll, PatchMyPC-Enum.dll, PatchMyPC-Models.dll, PatchMyPC-ScriptRunner.exe, PatchMyPC-ScriptRunner.exe.config et Resources.resx. Quatre d'entre eux étaient des composants légitimes de Patch My PC, un produit de gestion des terminaux. Seul Resources.resx contenait du code malveillant.

L'exécution commençait par PatchMyPC-ScriptRunner.exe. La chaîne exploitait une injection AppDomainManager, qui détourne le mécanisme du .NET Framework chargé d'initialiser les domaines d'application au lancement d'une application. Comme le DLL sideloading, elle permet à du code malveillant de s'exécuter dans le processus d'une application légitime.

Dans ce cas, l'exécutable analysait PatchMyPC-ScriptRunner.exe.config, ce qui provoquait l'exécution de Microsoft.HostIntegration.Connectors.dll. Ce composant localisait et analysait le fichier voisin fabric.config, puis chargeait Resources.resx.

Le fichier de ressources contenait plusieurs couches de contenus encodés, compressés ou chiffrés, dont des fichiers XAML, des assemblies .NET et des données JSON. Chaque composant décodait et chargeait le suivant, ce qui faisait passer l'exécution par une chaîne en deux étapes.

Des charges utiles en couches contournent l'analyse et effacent les traces

Le premier chargeur XAML, nommé XAML-1 par les chercheurs, charge une charge utile intégrée appelée XAML-2. Celle-ci initialise la seconde étape en chargeant deux fichiers XAML compressés et encodés en Base64 : XAML-2-1 et XAML-2-2. XAML-2-1 fournit un contournement de l'Antimalware Scan Interface, ou AMSI.

XAML-2-2 contient un module .NET appelé .NET 1 Loader et une charge utile JSON appelée JSON-1. Les données JSON se divisent en deux composants : JSON-1-c stocke la configuration du serveur de commande et de contrôle, tandis que JSON-1-p contient un assembly .NET encodé en Base64, appelé .NET 2 Plugin, ainsi que des modèles XAML compressés et chiffrés servant à construire XAML-3.

Après que XAML-2-2 a chargé .NET 1 Loader, ce module déchiffre, assemble et charge XAML-3. Il transmet aussi son état au serveur de commande et de contrôle, puis supprime les fichiers malveillants extraits de l'archive CAB, les journaux d'utilisation du CLR et les fichiers de cache Prefetch de Windows, afin de dissimuler les traces d'exécution.

XAML-3 s'exécute dans dllhost.exe, où il décode, décompresse et charge .NET 2 Plugin. Le plugin charge sa configuration de commande et de contrôle, collecte des informations système dans le registre Windows et vérifie si son processus hôte actuel est dllhost.exe.

Une cible propre aux gouvernements et des communications différées

La cible est une build de Windows réservée aux gouvernements. Dans un contexte politique connexe, The Hacker News cite un article de Bloomberg publié en août, selon lequel le ministère chinois de la Sécurité d'État avait ordonné à certaines administrations de remplacer « Government Edition » de Windows par des distributions Linux fabriquées en Chine, afin de réduire la dépendance à la technologie étrangère. Bloomberg attribue cette instruction à des préoccupations en matière de sécurité des données, en citant des personnes au fait du dossier.

Selon l'évaluation plus générale de Kaspersky, les pays qui développent leurs propres systèmes d'exploitation et autres plateformes essentielles gagnent le contrôle sur le développement, l'exploitation et les mises à jour, mais assument aussi la responsabilité de la protection de l'écosystème qui les entoure. La société affirme que parvenir à maîtriser leur exploitation et leur maintenance demande du temps.

Pour les analystes qui examinent cette chaîne, le comportement de communication documenté comporte des délais importants. Dans l'échantillon détecté au premier semestre 2026, .NET 2 Plugin attendait un délai aléatoire de 20 à 40 minutes avant d'envoyer sa première requête à openaigpt4v[.]com. Il récupérait ensuite périodiquement un fichier XAML et l'exécutait dans un AppDomain isolé.

Une réponse valide du serveur de commande et de contrôle déclenchait une pause de 5 à 6 minutes avant la requête suivante. Dans le cas contraire, le plugin attendait de 22 à 28 heures, en vérifiant toutes les 10 minutes si cet intervalle s'était écoulé.

Dossiers sécurité

À lire aussi

Sources

Retour à l'accueil

Dernières actualités cybersécurité

Toutes les actualités cybersécurité →