Microsoft a publié cette semaine une chaîne d'attaque en neuf étapes : un message Teams d'un faux helpdesk, une session Quick Assist, un chargement latéral de DLL via un binaire éditeur signé, WinRM sur le réseau, Rclone vers un stockage cloud contrôlé par l'attaquant. Huit des neuf étapes exigent que le système d'exploitation hôte soit un vrai bureau. Un onglet de navigateur tournant dans une VM jetable n'en est pas un.

Le 20 avril 2026, l'équipe d'analyse des menaces de Microsoft a publié le décorticage d'une chaîne d'attaque en neuf étapes que plusieurs affiliés de rançongiciels utilisent désormais en production. Le premier mouvement est social : un message arrive dans Microsoft Teams depuis un tenant externe, de la part de quelqu'un qui prétend être l'informatique, et demande à la cible de démarrer une session d'assistance à distance pour régler « un problème de compte » ou « installer une mise à jour de sécurité ». Le dernier mouvement est financier : Rclone, un utilitaire légitime de synchronisation cloud, qui déverse le serveur de fichiers vers un stockage objet contrôlé par l'attaquant pendant que le rançongiciel chiffre ce qu'il reste.

La formulation de Microsoft mérite d'être citée telle quelle : « threat actors are increasingly abusing external Microsoft Teams collaboration to impersonate IT or helpdesk personnel and convince users to grant remote assistance access » — les attaquants abusent de plus en plus de la collaboration Teams externe pour se faire passer pour l'informatique et convaincre les utilisateurs d'accorder un accès à distance. La nouveauté ici n'est pas l'ingénierie sociale — se faire passer pour le helpdesk est aussi vieux que le helpdesk — c'est la surface de livraison. Teams est le client de collaboration qui trône sur chaque bureau d'entreprise, connecté en permanence, se lançant automatiquement au démarrage, avec une API de notifications qui fait qu'un message externe ressemble en tous points à un message interne. C'est, en 2026, un meilleur canal de phishing que l'e-mail.

La chaîne, de bout en bout.

Voici ce que les neuf étapes font réellement sur une machine Windows. Les numéros sont ceux de Microsoft ; les descriptions en langage clair sont les nôtres.

La chaîne documentée par Microsoft. L'étape 1 est un message d'un inconnu à l'intérieur du client de messagerie de l'entreprise. Les étapes 2 à 9 sont une séquence d'opérations sur l'hôte Windows — Quick Assist, reconnaissance PowerShell, une DLL chargée par un binaire Adobe ou Autodesk légitimement signé, Windows Remote Management sur les machines jointes au domaine, et Rclone qui exfiltre le serveur de fichiers. Le chiffrement par le rançongiciel intervient après que les données sont sorties.

La chaîne est efficace et ennuyeuse, ce à quoi ressemble un bon savoir-faire de rançongiciel en 2026. Rien ici n'est un 0-day. Quick Assist est un outil d'assistance à distance maison de Microsoft livré avec Windows. PowerShell est un shell d'administration maison. Le chargement latéral de DLL — déposer une bibliothèque contrôlée par l'attaquant à côté d'un programme légitimement signé de sorte que le programme signé charge le code malveillant — a deux décennies. WinRM est la façon dont les administrateurs de domaine sont censés gérer des parcs Windows. Rclone est un utilitaire open-source de synchronisation cloud qu'on installe depuis Homebrew. L'attaque est faite de primitives supportées, signées, bénies par l'IT. C'est ce qui la rend difficile à détecter avec les outils endpoint traditionnels : chaque étape individuelle ressemble à quelque chose que l'équipe IT fait exprès.

La thèse positive : décapiter la chaîne à la première étape.

Imaginons maintenant à quoi ressemble cette même chaîne si l'étape 1 n'est pas une notification qui surgit dans un client de bureau Windows natif, mais une notification qui surgit à l'intérieur d'un onglet de navigateur. À l'intérieur d'un onglet Bromure. À l'intérieur d'une VM Linux jetable qui n'a pas de disque persistant, pas de jointure au domaine, pas de binaires Windows, pas d'écouteur WinRM, pas de Rclone, pas d'Adobe Reader dans lequel faire du side-loading, pas de système de fichiers partagé avec l'hôte, et qui sera détruite à la fermeture de la fenêtre.

L'étape 1 atterrit toujours. Le tenant Teams externe peut toujours envoyer le DM. L'utilisateur voit toujours le message. La pression de l'ingénierie sociale est toujours là. Rien dans Bromure n'empêche un inconnu prétendant être le helpdesk de taper « J'ai besoin d'installer une mise à jour de sécurité sur votre machine, laissez-moi démarrer une session Quick Assist » dans une fenêtre de chat.

Mais c'est à l'étape 2 que ça s'arrête. L'onglet de navigateur ne peut pas lancer Quick Assist, parce que Quick Assist est un binaire Windows natif et que l'onglet est une fenêtre Chromium à l'intérieur d'une VM Linux qui n'a pas de Quick Assist installé, aucune capacité d'en installer un, et aucun canal IPC vers la machine Windows de l'autre côté du périphérique qui exécute Bromure. Et parce que la chaîne est strictement séquentielle — chaque étape suivante a besoin de l'artefact de l'étape précédente — décapiter à la deuxième étape signifie que les étapes 3 à 9 n'ont jamais lieu.

La même chaîne, vue au travers de deux habitudes d'utilisateur. En haut : Teams comme client de bureau natif sur l'OS hôte — chaque étape a ce dont elle a besoin. En bas : Teams ouvert sur teams.microsoft.com dans un onglet Bromure — l'étape 1 atterrit dans la VM éphémère, chaque étape qui suit est quelque chose que la VM est structurellement incapable de faire.

Il y a une lecture tentante de ce schéma qui va trop loin : « utilisez Bromure, soyez immunisé contre le rançongiciel ». Ce n'est pas la prétention. La prétention est plus étroite, et la version plus étroite est plus honnête et plus utile.

Ce qu'est réellement la frontière.

Ce qui fait le travail ici n'est pas un filtre malin spécifique à Teams. C'est une propriété structurelle de la manière dont Bromure exécute le contenu web. Chaque onglet dans Bromure tourne à l'intérieur de sa propre VM Linux jetable sur votre Mac. Le navigateur que voit l'utilisateur est Chromium, tournant à l'intérieur de cet invité Linux. L'onglet est borné par la VM. L'hôte est borné par l'hyperviseur. Quand vous fermez l'onglet, la VM est détruite. Quand vous ouvrez un nouvel onglet, une nouvelle VM est créée à partir d'une image disque vierge.

Où se situe la frontière. L'imposteur helpdesk peut taper dans la fenêtre de chat (étape 1). Chaque étape qui suit exige une action sur l'hôte macOS — un binaire natif à lancer, un système de fichiers où persister, un LAN sur lequel pivoter. La frontière de l'hyperviseur se trouve entre l'attaquant et tout cela. La fenêtre de chat est d'un côté ; la boîte à outils helpdesk que l'attaquant veut utiliser est de l'autre.

Quand l'attaquant à l'étape 2 dit acceptez ma session Quick Assist, le mécanisme qu'il demande à invoquer n'existe pas de l'autre côté de la frontière. Il n'y a pas de Quick Assist dans un invité Linux. Il n'y a aucun moyen pour une page web, même une à laquelle l'utilisateur fait pleinement confiance, de sortir de l'invité vers l'hôte pour lancer un binaire natif macOS ou Windows. Il n'existe aucun pont pour cela ; cela saboterait le principe même de l'architecture. La chaîne de l'attaquant dépend d'un ensemble de capacités — lancer une app native, écrire sur un système de fichiers persistant, charger une DLL à côté d'un binaire éditeur signé, ouvrir une session WinRM, lire les identifiants de l'hôte — et la VM d'onglet n'en a aucune, par construction.

Ce n'est pas une fonctionnalité que nous avons ajoutée spécifiquement pour la menace helpdesk Teams. C'est la même propriété qui rend Bromure utile contre les 0-days de navigateur, les extensions malveillantes et les infostealers en général. L'étape 1 est la seule partie de la chaîne qui se préoccupe de ce sur quoi l'utilisateur a cliqué. Chaque étape suivante a besoin du bureau de l'utilisateur. Mettez le navigateur dans un ordinateur différent de celui du bureau, et la chaîne cesse de tourner autour des décisions de l'utilisateur pour se mettre à tourner autour de l'architecture de la machine.

Ce que cela ne résout pas.

Si le même utilisateur a Microsoft Teams installé comme client de bureau natif — le Microsoft Teams.app sur macOS, ou le client Windows de bureau, tous deux tournant hors de Bromure, tous deux connectés au même compte utilisateur — alors le DM du tenant externe atterrit sur l'hôte. À ce moment-là, nous retournons sur la rangée A du schéma. L'étape 1 est une notification native. L'étape 2 est l'utilisateur qui accepte une session Quick Assist sur son vrai bureau. La VM d'onglet n'entre jamais dans l'histoire. Bromure ne peut pas protéger ce qui ne tourne pas dans Bromure.

De même : si la politique IT de l'organisation est de bloquer les DM Teams externes au niveau du tenant — ce que le writeup de Microsoft recommande — l'étape 1 n'atteint jamais l'utilisateur dans aucun des deux mondes, et la discussion d'architecture devient sans objet. C'est le bon premier correctif. Bromure est une défense pour le cas où le premier correctif n'a pas été appliqué, ou l'utilisateur est sur un appareil personnel, ou la politique a une exception, ou l'attaquant a trouvé un tenant qui ne l'imposait pas.

Ce que change l'habitude du navigateur

Ouvrir Teams sur teams.microsoft.com dans un onglet Bromure déplace l'étape 1 dans une VM Linux éphémère sur votre Mac. Si vous cliquez sur le lien « accepter l'assistance » que l'imposteur envoie, l'outil qu'il voulait n'est pas là où le clic atterrit. La demande échoue parce que la capacité n'est pas présente.

Ce que le client natif ne change pas

Si vous avez déjà l'app Teams de bureau installée et connectée, le DM y arrive et l'hôte est exposé exactement comme Microsoft le décrit. Retirer le client de bureau, ou le reléguer à une machine de travail dédiée, est le changement de comportement que Bromure permet — pas un qu'il impose.

Ce que Bromure n'arrête pas

Un utilisateur qu'on a convaincu de taper son mot de passe d'entreprise dans un formulaire à l'intérieur de l'onglet Bromure perd toujours ce mot de passe. Le balayage anti-phishing du navigateur essaiera d'attraper le formulaire, mais une cible d'ingénierie sociale déterminée peut déjouer n'importe quelle garde de ce type. Le phishing d'identifiants et la défense par frontière de VM sont des problèmes différents.

La forme honnête de la revendication

Pour un utilisateur dont l'habitude de travail est Teams dans le navigateur, Bromure transforme une intrusion en neuf étapes en une conversation en une étape. Pour un utilisateur dont l'habitude de travail est le client natif, Bromure ne change rien à cette attaque. C'est tout l'intérêt de publier ce billet plutôt qu'un autre, plus court et plus bruyant.

Pourquoi l'habitude du navigateur vaut la peine d'être défendue.

La plupart des clients de chat d'entreprise — Teams, Slack, Discord, Zoom — sont livrés à la fois comme app de bureau native et comme app web à la même URL. La version web est fonctionnellement complète pour la très grande majorité de ce que la plupart des gens y font : lire des messages, écrire des messages, chercher, joindre des fichiers, prendre des appels. La version web ne se lance pas automatiquement au démarrage. La version web ne maintient pas un processus persistant sur l'hôte que les attaquants peuvent sonder. La version web n'embarque pas un canal de mise à jour qui a, par le passé, été le vecteur d'incidents de chaîne d'approvisionnement qui lui sont propres. Et, de façon unique si le navigateur en question est Bromure, la version web vit à l'intérieur d'un ordinateur qui ne partage pas de système de fichiers avec la vraie machine de l'utilisateur.

L'argument ici n'est pas que chaque utilisateur devrait désinstaller l'app Teams de bureau demain. C'est que l'option « web d'abord » existe, est tranquillement acceptable depuis des années, et — à la lumière de ce que Microsoft a décrit le 20 avril — est désormais matériellement la plus sûre pour tout utilisateur qui n'a pas spécifiquement besoin d'une fonctionnalité que seul le client de bureau propose. Bromure donne du sens à ce choix. Une session Teams web dans une fenêtre Chrome classique reste une session qui partage un système de fichiers avec tous les autres programmes de votre Mac. Une session Teams web dans un onglet Bromure, non.

Une histoire, et ce qu'elle change.

Le writeup en neuf étapes de Microsoft ne sera pas le dernier de son genre. La forme — canal social externe → outil d'accès à distance → reconnaissance → persistance par binaire signé → mouvement latéral → exfiltration — est la forme que prennent désormais la plupart des intrusions rançongiciels pilotées par des humains, quel que soit le client de chat dans lequel elles commencent. Le client de collaboration est la nouvelle boîte e-mail. Le « cliquez pour accepter la session d'assistance » est le nouveau « cliquez pour activer les macros ». Le travail au clavier qui suit, c'est l'attaque proprement dite.

Si le travail quotidien de l'utilisateur se déroule sur une machine où le client de chat et le serveur de fichiers partagent un système d'exploitation, l'attaquant n'a besoin que de mettre un pied dans ce système d'exploitation pour faire les huit autres étapes. Si le travail quotidien de l'utilisateur se déroule dans un navigateur qui tourne dans une VM dont le client de chat ne peut pas s'échapper, l'attaquant a besoin de toute une autre panoplie de primitives pour achever le boulot, des primitives que la génération actuelle des playbooks de rançongiciel n'a pas.

Ce n'est pas de l'immunité. C'est une décapitation à la première étape. Installez Bromure, utilisez-y teams.microsoft.com à la place du client natif pour les parties de votre chat de travail que vous pouvez, et laissez la prochaine chaîne en neuf étapes être le problème de l'attaquant.