Un malware brésilien vient de redéfinir les standards du banktrojan moderne. KREMLIN ne vole pas des mots de passe avec un keylogger bas de gamme — il forge les vérifications d'intégrité de Chrome, utilise la blockchain Ethereum comme infrastructure de commande et contrôle, et installe silencieusement une extension malveillante sans déclencher la moindre alerte dans les outils de sécurité standard. Ce que Elastic Security Labs a documenté sous le nom REF9334 n'est pas juste une menace pour les banques brésiliennes — c'est une démonstration de ce que les malwares financiers de prochaine génération ressembleront en Europe.

Qu'est-ce que KREMLIN et d'où vient-il ?

KREMLIN est un toolkit de malware bancaire développé et opéré par un acteur baptisé "Kr3mlin4rt1st" — un nom délibérément trompeur qui ne reflète aucun lien avec la Russie. Elastic Security Labs l'a documenté en septembre 2026 dans une analyse publiée sous le code de tracking REF9334. L'opération est active depuis au moins mai 2025, avec sept campagnes distinctes identifiées depuis le 16 juin 2025.

La cible principale est le secteur bancaire brésilien. L'acteur utilise des leurres imitant une douzaine de banques brésiliennes pour inciter les victimes à télécharger le composant initial du malware. Sur les 1 515 systèmes infectés identifiés via un domaine canary par Elastic, plus de 98 % sont géolocalisés au Brésil. Mais la sophistication technique de KREMLIN dépasse largement ce que justifierait un ciblage géographique limité — et c'est précisément ce qui devrait préoccuper les équipes de sécurité en Europe.

L'opération a connu une évolution significative en 2026 avec l'introduction d'une infrastructure basée sur des smart contracts Ethereum. Ce changement architectural distingue KREMLIN des centaines de banktrojans ordinaires qui circulent en parallèle. Ce n'est plus un outil opportuniste — c'est une plateforme criminelle construite pour la résilience et la durée.

Architecture technique : trois niveaux d'ingéniosité combinés

Ce qui rend KREMLIN remarquable, c'est l'empilement délibéré de trois techniques offensives avancées qui se renforcent mutuellement. Comprendre chacune d'elles séparément ne suffit pas — c'est leur combinaison qui crée un malware particulièrement difficile à détecter et à éradiquer.

Niveau 1 : le déploiement furtif de l'extension de navigateur

La plupart des malwares qui tentent d'installer une extension de navigateur malveillante échouent sur le même obstacle : les navigateurs modernes vérifient l'intégrité de leurs extensions via un fichier "Secure Preferences" et alertent l'utilisateur ou bloquent les extensions non autorisées. Chrome et Edge ont renforcé ces contrôles précisément pour contrer ce vecteur d'attaque.

KREMLIN contourne ce mécanisme en modifiant directement le fichier Secure Preferences de Chrome puis en régénérant les hachages d'intégrité utilisés pour détecter les modifications non autorisées. Le résultat est saisissant : l'extension malveillante apparaît dans Chrome comme si elle avait été installée légitimement par l'utilisateur. Aucune alerte, aucun bandeau d'avertissement. Un audit visuel de la liste des extensions installées est le seul moyen de la détecter sans outil spécialisé, et encore — son nom et son icône peuvent imiter une extension légitime connue.

Cette technique représente une évolution directe des méthodes de contournement de Manifest V3 observées depuis 2024. Le passage de Chrome à Manifest V3 devait justement rendre ce type d'attaque beaucoup plus difficile. KREMLIN démontre que les attaquants ont trouvé un contournement fonctionnel au niveau système, en dehors du périmètre de contrôle du navigateur lui-même.

Niveau 2 : le vol de sessions bancaires actives

Une fois installée, l'extension KREMLIN opère en silence dans le contexte du navigateur. Elle dispose d'un accès natif à toutes les pages web visitées par l'utilisateur, y compris les sessions bancaires authentifiées. Elle extrait en temps réel les cookies de session, les tokens d'authentification, et les identifiants saisis dans les formulaires bancaires.

L'utilisation d'une extension de navigateur plutôt qu'un injectable ou un proxy transparent présente un avantage majeur du point de vue de l'attaquant : l'extension opère dans un contexte de confiance totale du point de vue du système d'exploitation. Les solutions EDR qui inspectent les communications réseau au niveau système voient du trafic HTTPS légitime vers les domaines bancaires réels, pas vers une infrastructure malveillante.

Dans un contexte de double authentification généralisée, voler les cookies de session actifs est souvent plus efficace que voler les mots de passe statiques, car ces cookies transportent l'authentification complète, y compris les facteurs additionnels déjà résolus. L'attaquant obtient une session bancaire prête à l'emploi sans avoir à contourner le MFA.

Niveau 3 : Ethereum comme infrastructure de commande et contrôle

C'est la dimension la plus novatrice de KREMLIN. Traditionnellement, un malware contacte des serveurs C2 à des adresses IP ou des domaines prédéfinis. Ces points de contact sont la faiblesse structurelle de toute infrastructure criminelle : ils peuvent être bloqués par les opérateurs réseau, saisis par les forces de l'ordre, ou intégrés dans des listes de blocage en quelques heures après détection.

KREMLIN résout ce problème en utilisant des smart contracts Ethereum comme "dead-drop resolvers". Le principe : au lieu de coder en dur des adresses de serveurs C2 dans le malware, l'acteur publie les adresses d'infrastructure sur un smart contract Ethereum déployé sur la blockchain publique. Le malware interroge ce contrat pour récupérer dynamiquement les adresses C2 courantes avant chaque connexion.

Les implications sont considérables. La blockchain Ethereum est décentralisée, accessible publiquement et immuable dans ce qui y est écrit. Un smart contract ne peut pas être "saisi" par les forces de l'ordre — il peut être identifié et surveillé, mais pas supprimé. L'acteur peut mettre à jour les adresses C2 en publiant une simple transaction Ethereum, permettant une rotation d'infrastructure quasi instantanée. Un blocage réseau de l'infrastructure C2 actuelle est contourné par une mise à jour du contrat, invisible pour les défenseurs jusqu'à leur prochaine analyse.

Cette technique, qualifiée de "blockchain-based dead-drop resolution" dans la littérature de threat intelligence, avait été théorisée depuis plusieurs années mais son utilisation dans un malware bancaire opérationnel à cette échelle constitue une première documentée. Elle signale l'adoption par le cybercrime financier de techniques jusqu'alors réservées aux acteurs étatiques les plus sophistiqués.

La chaîne d'infection complète

Elastic Security Labs a reconstruit la chaîne d'infection complète de KREMLIN en cinq étapes :

Étape 1 — Leurre et téléchargement initial : la victime reçoit un email ou visite une page web imitant une banque brésilienne et télécharge un installateur présenté comme une mise à jour de sécurité ou un plugin requis pour accéder au service bancaire. Les leurres imitent actuellement une douzaine d'établissements bancaires brésiliens, mais la structure est adaptable à n'importe quel marché géographique.

Étape 2 — Loader multi-stage JavaScript : l'installateur exécute un premier chargeur JavaScript qui contacte l'infrastructure C2 (via la résolution Ethereum) pour télécharger le stage suivant. Ce loader implémente des techniques d'anti-analyse pour ralentir le travail des analystes malware, notamment des délais et des vérifications d'environnement.

Étape 3 — Installateur C++ personnalisé : le composant C++ compilé sur mesure réalise les modifications système : modification du fichier Secure Preferences de Chrome, injection des clés de registre pour la persistance, et installation de l'extension malveillante dans le profil navigateur de la victime avec régénération des hachages d'intégrité.

Étape 4 — Extension de navigateur active : l'extension s'active et commence à surveiller la navigation bancaire de la victime, extrayant sessions et credentials en temps réel, de façon invisible pour l'utilisateur.

Étape 5 — Exfiltration via C2 résolu par Ethereum : les données volées sont envoyées vers l'infrastructure C2 courante, dont l'adresse est dynamiquement récupérée depuis le smart contract Ethereum à chaque cycle d'exfiltration.

Ce que les chiffres révèlent sur l'opération

Les 1 515 systèmes identifiés via le domaine canary ne représentent qu'une fraction de la réalité — les domaines canary ne captent que les infections qui les contactent, pas l'intégralité du parc infecté. Sept campagnes en quinze mois suggèrent un acteur organisé avec une cadence opérationnelle soutenue. La concentration à 98 % au Brésil indique un ciblage géographique précis pour cette phase — les acteurs malveillants testent généralement leurs outils dans un premier marché cible avant de les adapter à d'autres géographies.

Le coût d'entrée pour reproduire l'infrastructure KREMLIN est significativement plus bas que ce que la sophistication technique pourrait laisser supposer. Les smart contracts Ethereum sont accessibles à tout développeur disposant d'ETH pour couvrir les frais de transaction (gas fees). Les bibliothèques permettant de modifier les préférences de Chrome sont documentées dans des travaux de recherche publics. Les extensions de navigateur malveillantes sont développables par n'importe qui maîtrisant les bases du développement web. KREMLIN n'est pas une opération qui requiert des capacités étatiques — il requiert de la méthodologie et de la patience.

Les angles morts de la détection standard

KREMLIN est délibérément conçu pour échapper à plusieurs couches de détection standard. Comprendre ces angles morts est essentiel pour adapter les contrôles de sécurité avant que des variantes ne ciblent les marchés européens.

EDR et comportement système : la modification du Secure Preferences de Chrome est une opération fichier que de nombreux EDR ne signalent pas par défaut, car ce fichier est régulièrement modifié par Chrome lui-même lors des mises à jour d'extensions. La création d'entrées de registre pour la persistance est similaire à ce que font de nombreux logiciels légitimes. Le ratio signal/bruit est défavorable à la détection automatique sans règle spécifique.

Proxy et inspection TLS : le trafic de l'extension vers les sites bancaires est indiscernable du trafic légitime de l'utilisateur. L'inspection TLS ne voit pas l'exfiltration des sessions car elle se produit dans le contexte navigateur, pas via une connexion réseau distincte vers une infrastructure tierce.

Threat intelligence C2 : les flux CTI qui bloquent les IoCs C2 connus sont contournés par la résolution Ethereum. Les adresses C2 changent à la discrétion de l'acteur via de simples transactions blockchain ; elles ne sont jamais dans les listes de blocage au moment où elles entrent en service.

Mon avis d'expert

KREMLIN illustre une tendance structurelle que j'observe depuis 18 mois dans les rapports de threat intelligence : les techniques offensives avancées migrent du domaine des APT étatiques vers le cybercrime financier avec une accélération inédite. La blockchain comme C2, la forge des vérifications d'intégrité navigateur, les loaders multi-stage — des approches qui auraient qualifié un attaquant de tier-1 APT en 2022 se retrouvent en 2026 dans un malware bancaire ciblant des PME et des particuliers. Ce qui me préoccupe davantage que KREMLIN lui-même, c'est ce que son existence signale sur ce qui arrive dans les 12 prochains mois en Europe. Les adaptations de ce toolkit pour cibler les banques françaises, allemandes ou néerlandaises ne requièrent qu'une réécriture des leurres et une connaissance superficielle du secteur bancaire local. Nos SOC doivent développer des règles de détection sur la modification du Secure Preferences de Chrome et sur les requêtes vers des nœuds Ethereum depuis des endpoints enterprise — maintenant, pas quand l'incident se produira.

Recommandations pour les équipes sécurité européennes

Même si KREMLIN cible actuellement le Brésil, les contrôles suivants permettent de se préparer à des variantes locales :

Monitorer le fichier Secure Preferences de Chrome et Edge : créer une règle FIM (File Integrity Monitoring) ou EDR sur toute modification de ce fichier sur les postes de travail. Toute modification par un processus autre que le navigateur lui-même doit déclencher une alerte immédiate et une investigation.

Déployer une politique de gestion des extensions navigateur : Chrome Enterprise et les solutions MDM modernes permettent de définir une liste blanche des extensions autorisées et de bloquer automatiquement toute extension non approuvée. Ce contrôle doit être implémenté à l'échelle de l'organisation, pas seulement sur les postes sensibles.

Bloquer les requêtes vers des nœuds Ethereum publics : les endpoints enterprise n'ont aucune raison légitime de contacter des nœuds Ethereum publics (ports 8545, 443 vers Infura, Alchemy, ou tout RPC Ethereum public). Une règle de proxy ou de pare-feu bloquant ces requêtes réduit significativement l'efficacité du mécanisme de résolution C2 de KREMLIN et de toute variante utilisant la même technique.

Intégrer les IoCs Elastic dans les SIEM : Elastic Security Labs a publié les indicateurs de compromission de KREMLIN sur son dépôt GitHub public (labs-releases/indicators/kremlin). Les intégrer dans les SIEM et les solutions de threat intelligence permet de détecter les éventuelles infections existantes et les variantes futures qui réutilisent la même infrastructure.

Conclusion

KREMLIN n'est pas un malware de plus dans une liste déjà longue. C'est un marqueur : la ligne entre les outils des groupes APT étatiques et les malwares du cybercrime financier continue de s'effacer. L'utilisation d'Ethereum comme infrastructure C2 résistante à la censure, la forge des mécanismes d'intégrité de Chrome, et la structuration en toolkit modulaire multi-stage sont des indicateurs d'une professionnalisation croissante des acteurs criminels financièrement motivés.

Les équipes sécurité qui attendent que ces techniques apparaissent dans leur secteur et leur géographie avant d'adapter leurs contrôles prendront systématiquement du retard. La bonne posture est d'étudier ce que KREMLIN fait aujourd'hui au Brésil et de décider maintenant quels contrôles déployer pour que la prochaine itération — en France, en Allemagne, aux Pays-Bas — rencontre des défenses adaptées plutôt que des architectures conçues pour les menaces d'avant-hier.

Besoin d'évaluer la maturité de vos défenses face aux menaces avancées ?

Discutons de votre contexte spécifique et des contrôles à prioriser face aux techniques émergentes documentées par la threat intelligence.

Prendre contact