L'appel vient d'un numéro affiché comme "support informatique". L'interlocuteur connaît votre nom, votre employeur, et parle d'une enquête interne de satisfaction initiée par les ressources humaines. Le seul problème : l'appel n'est pas passé par téléphone. Il passe par Microsoft Teams, depuis un compte externe dont l'adresse se termine par Progressive936.onmicrosoft[.]com, et Teams affiche bien l'avertissement "External unfamiliar" sous le nom de l'interlocuteur. Si l'employé continue la conversation, accorde le contrôle de son écran, installe deux outils de bureau à distance, et télécharge un fichier MSI depuis un domaine inconnu, il aura installé EtherRAT sur sa machine.
L'analyse a été publiée par Palo Alto Networks Unit 42. EtherRAT est un outil d'accès distant basé sur Node.js qui utilise des smart contracts Ethereum pour récupérer l'adresse de son serveur de commande et contrôle, une architecture conçue pour rendre l'outil résistant aux blocages de domaines et d'adresses IP. La campagne documentée représente l'une des premières utilisations publiquement confirmées d'EtherRAT distribué via des appels vocaux Teams frauduleux.
La campagne débute par un email de phishing présentant un PDF intitulé "Employee Survey", une enquête de satisfaction employé. Le document est conçu pour établir un contexte légitime et préparer psychologiquement la victime à l'étape suivante : un appel de suivi du département RH ou du support informatique.
L'appel arrive sur Teams. L'identité de l'appelant affiche le compte externe helpdesk@Progressive936.onmicrosoft[.]com. Microsoft Teams affiche bien l'indication "External unfamiliar" pour les comptes provenant d'organisations Teams tierces non reconnues par l'organisation cible. Cet avertissement, que beaucoup d'utilisateurs ignorent ou considèrent comme informatif plutôt qu'alarmant, est la seule indication visible que l'appelant n'est pas un collègue interne.
L'opérateur demande à la victime d'activer le partage d'écran Teams pour l'aider à remplir l'enquête ou à résoudre un problème technique fictif. Une fois le contrôle de l'écran accordé, l'opérateur guide la victime vers l'installation de deux outils légitimes de bureau à distance : HopToDesk et AnyDesk. Ces deux outils sont des logiciels commerciaux légitimes, présents dans de nombreux environnements d'entreprise pour le support technique, et rarement bloqués par les solutions de sécurité sur la seule base de leur présence.
Avec HopToDesk et AnyDesk installés et actifs, l'opérateur dispose d'un contrôle persistant de la machine indépendant de la session Teams. Il peut alors télécharger le fichier v7.msi depuis le domaine camorreado[.]click. Ce fichier MSI exécute la chaîne finale : il télécharge le runtime Node.js, déchiffre les charges utiles EtherRAT embarquées, et lance le RAT qui établit une connexion persistante vers son infrastructure C2.
La caractéristique technique distinctive d'EtherRAT est son mécanisme de résolution de commande et contrôle. Plutôt que d'encoder en dur une adresse IP ou un domaine, EtherRAT interroge la blockchain Ethereum. L'adresse du serveur C2 est stockée dans un smart contract Ethereum déployé sur le réseau public. Le malware effectue une requête vers ce smart contract, récupère l'adresse actuelle du C2, et s'y connecte.
Cette architecture présente un avantage opérationnel significatif pour l'attaquant : la blockchain Ethereum est un réseau public distribué que les défenseurs ne peuvent pas bloquer ou perturber unilatéralement. Bloquer l'adresse IP d'un serveur C2 traditionnel force l'attaquant à mettre à jour son malware pour pointer vers une nouvelle adresse. Avec le smart contract, l'attaquant met simplement à jour la valeur stockée dans le contrat, et tous les clients déployés récupèrent automatiquement la nouvelle adresse lors de leur prochaine interrogation. Le malware sur les machines infectées n'a pas besoin d'être mis à jour.
EtherRAT est construit en Node.js, un environnement d'exécution JavaScript côté serveur qui peut s'exécuter sur Windows, Linux et macOS. Les binaires Node.js sont rarement bloqués par les solutions de sécurité car l'environnement est utilisé par de nombreuses applications légitimes. Le MSI installeur inclut le runtime Node.js complet, ce qui signifie qu'EtherRAT peut s'exécuter même sur des machines où Node.js n'est pas préinstallé.
L'analyse de l'infrastructure par Unit 42 a révélé un répertoire ouvert sur le serveur de distribution contenant des versions v1 à v9 du fichier MSI installeur, ce qui indique un développement actif avec des mises à jour régulières de l'outil depuis au moins plusieurs mois avant la publication de l'analyse.
La campagne EtherRAT s'inscrit dans une tendance documentée d'abus croissant de Microsoft Teams pour des attaques de vishing, une forme d'ingénierie sociale par appel vocal. En mars 2026, une campagne similaire avait distribué A0Backdoor via le même vecteur : appel Teams depuis un compte externe, demande de contrôle d'écran, installation de logiciel malveillant. Cette campagne ciblait les secteurs financier et de la santé. En avril 2026, Microsoft avait publié une alerte formelle avertissant d'une multiplication des campagnes d'usurpation de support informatique via Teams depuis des comptes onmicrosoft.com externes.
L'architecture qui rend ces attaques efficaces est inhérente à Microsoft Teams lui-même. Par défaut, Microsoft Teams autorise les communications avec des utilisateurs extérieurs à l'organisation, y compris les appels vocaux avec partage d'écran. Cette fonctionnalité est légitime et utile pour la collaboration interentreprises. Mais elle signifie que n'importe qui disposant d'un compte Microsoft 365 gratuit peut appeler les employés d'une organisation via Teams, et que ces appels apparaissent dans la même interface que les appels internes. La seule différence visuelle est l'indication "External unfamiliar", que les utilisateurs qui reçoivent régulièrement des appels de partenaires ou de clients externes ont appris à ignorer.
Microsoft Teams offre des contrôles administratifs qui permettent de réduire ce vecteur d'attaque. Dans le centre d'administration Teams, les organisations peuvent désactiver entièrement les communications entrantes depuis des locataires Teams externes, ou les restreindre à une liste d'organisations approuvées. Elles peuvent également désactiver le partage d'écran et le contrôle de bureau à distance pour les sessions avec des participants externes.
La mesure la plus efficace pour ce vecteur d'attaque spécifique est de désactiver la fonctionnalité de prise de contrôle à distance dans Teams pour les appels avec des participants externes non vérifiés. Cette fonctionnalité, qui permet à un participant de prendre le contrôle de l'écran d'un autre, est rarement nécessaire dans les communications avec des partenaires externes légitimes, et son désactivation bloque l'étape clé de la chaîne d'attaque EtherRAT sans impacter significativement les flux de travail légitimes.
Du côté de la sensibilisation des utilisateurs, la règle la plus simple à communiquer est celle-ci : aucun support informatique interne légitime n'appellera un employé depuis un compte Teams affichant "External". Si un appel prétend venir du support IT mais affiche ce label, l'employé doit raccrocher et vérifier directement auprès de son équipe IT interne via un canal séparé. Cette vérification simple brise la chaîne d'ingénierie sociale avant que l'installation du logiciel malveillant n'ait lieu.
Les indicateurs publiés par Unit 42 incluent le domaine de distribution camorreado[.]click, les noms de fichier v1.msi à v9.msi, et les hachages des versions capturées. L'adresse du smart contract Ethereum utilisé pour la résolution C2 est également documentée dans l'analyse complète. Pour les équipes de sécurité qui utilisent des outils d'analyse de trafic réseau, les requêtes sortantes vers les noeuds publics Ethereum (infrastructure Infura, Alchemy, ou connexions directes aux noeuds du réseau) depuis des machines ne faisant pas partie d'un workflow blockchain légitime constituent un signal de détection pertinent.
La présence simultanée de HopToDesk et AnyDesk sur une machine qui ne les utilisait pas auparavant est un indicateur comportemental à surveiller dans les logs d'installation de logiciels. Les deux outils sont légitimes individuellement, mais leur installation conjointe lors d'une même session, en particulier sur une machine dont l'utilisateur n'a pas soumis de ticket de support IT, mérite une investigation.
La technique d'utilisation de la blockchain pour la résolution du serveur C2 mérite une explication technique précise, car elle change fondamentalement la réponse des défenseurs. Quand un logiciel malveillant traditionnel communique avec un serveur C2 dont l'adresse est codée en dur ou résolue via un algorithme de génération de domaines (DGA), les défenseurs peuvent bloquer cette adresse IP ou ce domaine au niveau du pare-feu ou du DNS resolver. L'attaquant doit alors mettre à jour son malware pour pointer vers une nouvelle infrastructure, ce qui nécessite un accès à l'ensemble des machines infectées, ou utiliser un mécanisme de mise à jour secondaire.
Avec EtherRAT, le logiciel malveillant ne stocke pas directement l'adresse du C2. Il stocke l'adresse d'un smart contract déployé sur la blockchain Ethereum. Pour obtenir l'adresse de son C2, EtherRAT fait une requête vers ce smart contract via un noeud Ethereum public. Le smart contract retourne l'adresse IP ou le domaine actuel du C2. Si ce C2 est bloqué, l'attaquant met simplement à jour la valeur dans le smart contract, une opération qui coûte quelques centimes en frais de transaction Ethereum et qui prend moins d'une minute. Toutes les instances EtherRAT déployées utilisent automatiquement la nouvelle adresse lors de leur prochaine interrogation.
Bloquer les requêtes vers les noeuds Ethereum publics est théoriquement possible mais pratiquement difficile pour les organisations qui utilisent des applications web3, des outils de finance décentralisée, ou qui développent des applications blockchain. Les adresses IP des services d'infrastructure Ethereum comme Infura et Alchemy sont partagées avec de nombreuses applications légitimes. Une approche plus ciblée consiste à détecter les requêtes vers des smart contracts spécifiques une fois leurs adresses publiées dans des rapports comme celui d'Unit 42, et à bloquer ces adresses de contrat spécifiques dans les outils d'analyse de trafic réseau qui peuvent inspecter le contenu des appels JSON-RPC vers les noeuds Ethereum.
La réponse administrative la plus importante pour les organisations ciblées par cette catégorie d'attaque est la révision de leurs politiques de fédération Teams. Dans le centre d'administration Microsoft Teams, sous "Utilisateurs externes et réunions" puis "Accès externe", les administrateurs peuvent contrôler avec précision qui peut contacter les utilisateurs de l'organisation via Teams. Les options disponibles vont de l'ouverture complète (toute organisation Teams peut contacter vos utilisateurs) à la restriction totale (seules les organisations explicitement approuvées peuvent le faire), en passant par des configurations intermédiaires.
Pour la plupart des organisations qui n'ont pas de raison légitime de recevoir des appels Teams d'entreprises arbitraires inconnues, la configuration recommandée est de restreindre l'accès externe aux organisations partenaires identifiées et listées explicitement. Cette configuration bloque les comptes *.onmicrosoft.com non reconnus qui constituent le vecteur d'attaque documenté. Elle n'empêche pas les communications avec les partenaires légitimes dont le domaine est sur la liste d'approbation.
La formation des utilisateurs est complémentaire aux contrôles techniques mais ne les remplace pas. Dans la campagne EtherRAT documentée, l'indicateur visible d'alerte, le label "External unfamiliar", était présent et visible. Des utilisateurs correctement sensibilisés à ne jamais accorder de contrôle d'écran à un contact Teams externe non préalablement vérifié via un canal indépendant auraient bloqué la chaîne à cette étape. La combinaison des deux mesures, restriction de l'accès externe au niveau de l'administration et sensibilisation ciblée sur ce scénario spécifique, est le niveau de protection minimum approprié pour cette menace documentée.
L'utilisation de la blockchain Ethereum pour la résolution du serveur de commande et contrôle d'EtherRAT n'est pas la première tentative d'exploitation d'infrastructures décentralisées pour la résilience des C2, mais elle représente une mise en oeuvre plus mature et plus pratique que les précédentes. Les tentatives antérieures d'utilisation de DNS pair-à-pair ou de réseaux de partage de fichiers décentralisés comme Bittorrent pour la distribution de configurations C2 avaient des limitations pratiques : complexité de mise en oeuvre, latence élevée, ou nécessité de maintenir une infrastructure supplémentaire.
Ethereum offre un avantage pratique significatif : les smart contracts sont des programmes qui s'exécutent sur la blockchain de façon déterministe et transparente. Déployer un smart contract qui stocke une adresse IP ou un domaine et permet au propriétaire du contrat de la mettre à jour est une opération techniquement simple, nécessitant quelques dizaines de lignes de code Solidity, quelques heures de développement pour un programmeur expérimenté, et quelques centimes en frais de transaction ETH. Une fois déployé, ce contrat est permanent et immuable dans sa structure, tout en étant modifiable dans son contenu via des fonctions de mise à jour protégées par clé privée.
L'adresse du smart contract lui-même peut être codée en dur dans le malware, ou récupérée via un mécanisme de recherche sur la blockchain si plusieurs versions du contrat sont déployées. Les défenseurs qui blocken une adresse de contrat spécifique (ajout d'un filtrage sur les appels JSON-RPC vers cette adresse) forcent l'attaquant à déployer un nouveau contrat et à mettre à jour le malware pour pointer vers la nouvelle adresse. C'est un avantage pour les défenseurs, mais un avantage modéré : le redéploiement d'un contrat Ethereum coûte quelques euros et prend quelques minutes. La résistance aux blocages n'est pas absolue, mais le coût de contournement pour l'attaquant est très faible par rapport au coût de détection et de blocage pour le défenseur.
La campagne EtherRAT exploite une tension spécifique dans la culture de travail contemporaine. Le passage au travail hybride a normalisé les appels de support technique par vidéoconférence. Les employés sont habitués à recevoir de l'aide de membres de leur équipe IT qu'ils n'ont jamais rencontrés en personne, via des outils de collaboration auxquels ils font confiance. La distinction entre un appel légitime et un appel frauduleux repose sur des signaux qui sont présents dans l'interface Teams, comme l'indication "External unfamiliar", mais que les utilisateurs ont appris à ignorer dans leur flux de travail quotidien.
L'étape d'ingénierie sociale qui précède l'appel Teams, l'email de fausse enquête de satisfaction employé, est conçue pour établir un contexte plausible. Un employé qui reçoit un email d'une initiative RH, puis un appel de suivi de quelqu'un qui se présente comme le support de cette initiative, est dans un cadre narratif cohérent. Le scepticisme normal qu'un employé appliquerait à un appel téléphonique d'un inconnu est atténué par ce contexte préalable. C'est la séquence précise que les attaquants utilisent parce qu'elle fonctionne : l'email crée l'attente, l'appel Teams exploite cette attente.
La demande de contrôle d'écran Teams est l'étape clé de la chaîne d'attaque. Une fois le contrôle accordé, l'attaquant peut naviguer librement sur le poste de la victime sans que cette dernière puisse observer et arrêter chaque action individuelle. La formation des utilisateurs sur ce point spécifique, ne jamais accorder le contrôle de son écran à un appelant Teams externe sans vérification préalable par un canal indépendant, est la mesure préventive la plus directement efficace contre cette campagne.
La campagne EtherRAT soulève une question de politique de sécurité qui va au-delà de Teams : comment les organisations gèrent-elles l'accès des équipes de support IT à distance ? L'installation d'outils comme HopToDesk et AnyDesk sur des postes de travail d'entreprise est une action qui devrait déclencher une alerte dans un système de gestion des configurations. Ces outils sont légitimes et couramment utilisés par les équipes de support internes, ce qui signifie qu'ils sont souvent présents dans les listes blanches des solutions de sécurité endpoint.
La différence entre une installation légitime de HopToDesk ou AnyDesk par le département IT et une installation initiée par un vishing Teams est souvent invisible aux solutions de sécurité : dans les deux cas, c'est l'utilisateur qui lance l'installation, avec ses propres droits, sur sa propre machine. La détection repose sur le contexte : l'installation a-t-elle été précédée d'un ticket de support IT ? L'installation a-t-elle été initiée par un utilisateur qui venait de recevoir un appel Teams depuis un compte externe ? Ces corrélations, entre les événements d'installation endpoint et les événements de communication Teams, nécessitent une visibilité sur les deux flux de données simultanément, une capacité que peu d'organisations ont construite de façon proactive.
Les organisations qui veulent réduire leur exposition à ce vecteur d'attaque spécifique peuvent définir une politique claire : les outils de bureau à distance ne peuvent être installés sur les postes de travail que par les administrateurs IT, et non par les utilisateurs finaux eux-mêmes. Cette politique, appliquée via des contrôles UAC et des politiques de groupe Windows, bloque la chaîne d'attaque EtherRAT à l'étape de l'installation de HopToDesk et AnyDesk, car ces outils ne peuvent pas être installés sans les droits administrateur si la politique est correctement configurée. Elle crée une friction opérationnelle pour les équipes de support légitimes, qui doivent coordonner l'installation avec un administrateur, mais cette friction est précisément ce qui distingue un accès de support légitime d'un accès frauduleux initié par vishing.
Les acteurs étatiques, les outils d'accès distant distribués sur mesure et les techniques d'exfiltration physique représentent des menaces que les seuls outils de protection de poste ne suffisent pas à contenir. Defendis surveille en continu la surface d'attaque exposée de votre organisation : services accessibles sur Internet, identifiants compromis circulant dans les marchés clandestins, et indicateurs de compromission associés aux groupes documentés dans cet article. Quand un acteur hostile cible votre secteur ou que des données propres à votre organisation apparaissent dans un nouveau canal d'exfiltration, votre équipe reçoit le signal avant que l'attaquant ait pu agir. Découvrez comment la détection précoce change les résultats d'un incident, ou demandez un briefing personnalisé pour votre organisation.
