Le malware KREMLIN réécrit les données de confiance de Chromium pour détourner des sessions bancaires brésiliennes

Une opération malveillante motivée par des intérêts financiers installe des extensions Chrome et Edge non autorisées en recréant les données d’intégrité que Chromium utilise pour protéger les profils de navigateur. Ces extensions peuvent récupérer des identifiants bancaires brésiliens, des jetons de session et d’autres informations sensibles.

Elastic Security Labs suit cette opération sous le nom de REF9334 et désigne l’écosystème malveillant sous le nom de KREMLIN, choisi par son auteur, Kr3mlin4rt1st. La campagne est active depuis mai 2025 et couvre sept campagnes observées, ainsi que des leurres usurpant l’identité de 12 banques brésiliennes.

Elastic a publié son analyse technique de KREMLIN le 14 septembre 2026. L’opération a ensuite été mentionnée dans une synthèse de Security Affairs consacrée aux malwares publiée le 20 septembre 2026.

Malgré son nom, la campagne n’a pas été attribuée à la Russie. Les messages en portugais et les commentaires dans le code source, associés à des transactions en Ethereum concentrées pendant les heures de travail à São Paulo, indiquent plutôt une opération ciblant le Brésil.

Un faux document déclenche une infection Windows en plusieurs étapes

Les infections par KREMLIN commencent lorsqu’un utilisateur exécute manuellement un fichier JavaScript déguisé en document bancaire, en facture ou en fichier lié à l’entreprise. Le loader utilise une obfuscation limitée, notamment des noms de fonctions génériques, des tables de chaînes indexées, la notation entre crochets et plusieurs étapes JavaScript successives.

L’un des loaders initiaux analysés présente le hash SHA-256 suivant :

106eac79396a3ff77b8f375c391260ce422be2ae4d55d3aa75b2635cbdc0fa42

Le script affiche d’abord un faux message d’erreur, afin de faire croire à la victime que le document supposé n’a tout simplement pas pu s’ouvrir. Il crée un script temporaire qui appelle shell.Popup, puis le supprime. Le nom du fichier suit le modèle suivant :

popup_{date}_{random}.js

Un autre échantillon associé à cette étape présente le hash suivant :

5ece7fd3766b0b7f8aadefa562313cea6c3c94f9398658dd389910e5be44f552

Avant de poursuivre, le loader vérifie son environnement. Il compte les fichiers présents sur le bureau et interroge Windows Management Instrumentation afin de déterminer le nombre de processus en cours d’exécution. L’exécution s’arrête lorsque le bureau contient moins de cinq fichiers ou que le système compte moins de 50 processus, des conditions couramment associées aux environnements d’analyse nouvellement créés.

Le loader signale ces vérifications infructueuses via :

/api/log_loader?hash=

L’échantillon analysé a contacté :

hxxps://connection[.]upgradeonline[.]site

Si l’hôte passe l’inspection, la première étape télécharge un runtime Node.js. Elle utilise également l’utilitaire certutil de Microsoft pour décoder et extraire une autre étape JavaScript, mêlant ainsi la chaîne d’infection à des outils Windows et de développement légitimes.

La persistance se dissimule derrière une tâche de mise à jour Node.js

La deuxième étape extrait une tâche planifiée d’une archive CAB intégrée. Elle enregistre cette tâche sous le nom plausible suivant :

MicrosoftNodeRuntimeUpdater

La description de la tâche fait référence au runtime Node.js V8 et au moteur V8 de Google, donnant à l’entrée une apparence cohérente avec un logiciel légitime. Elle s’exécute une minute après l’ouverture de session de l’utilisateur et lance :

conhost.exe --headless node.exe

La commande s’exécute depuis le répertoire contenant le script malveillant.

Cette étape interroge également un smart contract Ethereum qui joue le rôle de résolveur dead drop :

0xCD7360A83E5cdbBbbbcEB0e78748babA6740d07b

Au lieu d’intégrer des serveurs de téléchargement fixes dans chaque loader, les opérateurs peuvent modifier les informations d’infrastructure stockées par l’intermédiaire du contrat. KREMLIN demande trois paramètres :

• main-v2, qui identifie l’installateur principal de l’extension de navigateur.
• sub-module, qui pointe vers un fichier JPEG contenant un kit d’injection .NET RunPE.
• sentinel, qui fournit un fichier JPEG contenant une archive CAB et un exécutable SentinelOne.

L’emplacement observé de l’installateur principal était :

hxxps://granderevolucao[.]store/5c92d3b8734b4f498752f735a1ca0987/{campaignId}

Les autres composants étaient hébergés via Archive.org :

hxxps://archive[.]org/download/hotelmoskva/hotelmoskva.jpg
hxxps://ia601808[.]us[.]archive[.]org/5/items/sentinel_20260722_0435/Sentinel.jpg

Elastic n’a pas observé l’utilisation de l’injecteur .NET dans l’activité analysée. Sa présence montre néanmoins que le framework de distribution peut fournir des capacités allant au-delà de l’extension de navigateur.

Les payloads bénéficient d’un camouflage supplémentaire. Le module principal est encodé en Base64 inversé, tandis que les fichiers JPEG contiennent des données Base64 entre les marqueurs du fichier. Un fichier items.json présent dans l’archive liée à SentinelOne définit les éléments qui doivent apparaître dans le répertoire d’installation et permet le remplacement ultérieur de fichiers.

Des valeurs d’intégrité Chromium falsifiées autorisent l’extension

Le binaire KREMLIN central est un exécutable C++ x64 d’environ 2,10 Mo :

c8c38634dd44d7c6162c66174a6ee23ee404265125166e8d757681bdd66a4268

Son objectif principal est d’installer des extensions malveillantes dans Google Chrome et Microsoft Edge. KREMLIN ne se contente pas de copier les fichiers de l’extension dans un profil de navigateur. Il modifie les données de préférences de Chromium et recrée les valeurs qui permettraient normalement de détecter des changements non autorisés.

L’installateur manipule :

• Les Secure Preferences de Chromium.
• Les valeurs d’intégrité HMAC requises.
• Les hashes chiffrés App-Bound.

L’extension semble ainsi avoir été approuvée par l’utilisateur, ce qui lui permet de franchir les contrôles d’intégrité du profil Chromium. Une fois chargée, elle peut cibler les identifiants bancaires, les jetons de session du navigateur et les sessions bancaires authentifiées.

Le vol d’un jeton de session valide peut permettre à un attaquant d’exploiter un état de navigateur déjà authentifié, plutôt que de s’appuyer uniquement sur un mot de passe récupéré. Le comportement précis visant chaque banque usurpée n’a pas été communiqué.

Aucune version affectée de Chrome, d’Edge ou de Windows n’a été identifiée. Il n’existe pas non plus de CVE, de score CVSS, de correctif éditeur ou de version logicielle corrigée associés à cette opération. Il s’agit d’une technique de déploiement de malware, et non d’une vulnérabilité de navigateur divulguée avec un processus de mise à jour conventionnel.

Le sideloading de SentinelOne et les appels système indirects compliquent l’analyse

KREMLIN exécute un composant légitime de SentinelOne :

SentinelMemoryScanner.exe

Ce programme charge une bibliothèque malveillante non signée se faisant passer pour :

SentinelAgentCore.dll

Ce dispositif de sideloading de DLL permet au payload de s’exécuter dans le contexte de processus d’un exécutable de confiance. Les équipes de défense ne doivent pas supposer que la présence d’un nom de fichier SentinelOne légitime garantit la sécurité du répertoire environnant ou des bibliothèques chargées.

Lors de son initialisation, le malware localise LdrpLoaderLock et LdrpWorkInProgress dans ntdll.dll. Il libère le verrou du loader et efface l’état indiquant qu’une opération est en cours, ce qui permet à son thread de travail de démarrer avant le retour de DllMain. Ce comportement contourne la synchronisation normale du loader Windows et évite un deadlock qui se produirait autrement si le code d’initialisation attendait le thread nouvellement créé.

KREMLIN utilise également des appels système indirects. Il met en correspondance les exports de ntdll.dll avec les entrées RUNTIME_FUNCTION classées par adresse dans .pdata, déduit les System Service Numbers en comptant les exports Zw* précédents et effectue les appels via une séquence syscall; ret existante. Un stub intégré fournit une solution de secours.

Elastic a établi un lien entre cette implémentation et le projet open source PigSyscall. La manipulation du verrou du loader présente de même des similitudes avec la technique publique LdrLockLiberator.

Le binaire n’est pas fortement obfusqué et le débogage reste activé dans l’installateur comme dans l’extension. Ces signes d’immaturité du développement contrastent avec une infrastructure de distribution et de configuration relativement élaborée.

Des contrôles anti-analyse interrompent les exécutions suspectes

Le payload natif examine les noms de processus, la mémoire, les propriétés du disque et son processus hôte à la recherche d’indices révélant la présence d’outils de sécurité ou d’un environnement virtualisé. Les premières étapes JavaScript ajoutent leurs propres vérifications du nombre de fichiers présents sur le bureau et du nombre de processus.

KREMLIN recherche de nombreux programmes d’analyse, notamment :

procmon.exe
processhacker.exe
systeminformer.exe
wireshark.exe
windbg.exe
x32dbg.exe
x64dbg.exe
ida64.exe
ghidra.exe
fiddler.exe
frida-helper-64.exe

Il recherche également des noms génériques associés aux sandbox, tels que malware.exe, sandbox.exe, test.exe, joeboxcontrol.exe et fakenet.exe.

Pour de nombreuses détections positives, le malware tente délibérément d’accéder à :

0x1337

Cette adresse invalide provoque une violation d’accès et interrompt l’exécution d’une manière pouvant ressembler à un crash. Elastic n’a pas observé de contrôles explicites visant les débogueurs ou les hooks d’API, même si certains résultats environnementaux collectés n’entraînent pas nécessairement l’arrêt de l’exécution.

Le kill switch d’Elastic a perturbé plus de 1 500 infections

Elastic a enregistré un domaine canary utilisé par la campagne, le transformant en kill switch temporaire. Cette intervention a perturbé plus de 1 500 infections, tandis que d’autres systèmes affectés étaient encore en cours de recensement au moment de la publication de l’enquête.

Le domaine canary lui-même n’a pas été communiqué et la perturbation est présentée comme temporaire. Les organisations doivent donc rechercher des éléments présents localement plutôt que considérer cette intervention comme une remédiation définitive.

Les vérifications prioritaires comprennent :

• Localiser la tâche planifiée MicrosoftNodeRuntimeUpdater.
• Examiner conhost.exe --headless node.exe, en particulier lorsque le processus est lancé depuis des répertoires accessibles en écriture par les utilisateurs.
• Rechercher les trois hashes SHA-256 fournis dans la télémétrie des terminaux et du réseau.
• Examiner les profils Chrome et Edge à la recherche de modifications inattendues des Secure Preferences, des valeurs HMAC, des hashes App-Bound ou des extensions.
• Identifier les fichiers SentinelAgentCore.dll non signés chargés par SentinelMemoryScanner.exe.
• Signaler les binaires SentinelOne exécutés en dehors des répertoires d’installation approuvés.
• Examiner les activités suspectes de certutil impliquant des fichiers JavaScript ou des payloads extraits.
• Rechercher les connexions vers les domaines répertoriés et l’adresse du contrat Ethereum.
• Inspecter les fichiers JavaScript à thème bancaire reçus sous forme de factures, de documents ou de contenus professionnels.

Les utilisateurs dont les systèmes sont susceptibles d’être infectés doivent invalider leurs sessions bancaires actives et leurs identifiants via des canaux de confiance, après isolement et examen de la machine affectée. La simple suppression de l’extension visible peut laisser la tâche planifiée, le loader et les composants chargés par sideloading en place.