Illustration du rejeu de jeton que décrit l’article : une connexion approuvée avec la MFA, le jeton de session qui en découle, et ce jeton rejoué par un attaquant pendant environ 10 semaines, selon Huntress. Image conceptuelle, pas un vrai journal ni une capture d’écran.
Des attaquants ont volé des sessions qui avaient déjà passé la MFA, les ont rejouées depuis des serveurs loués, puis ont remplacé les méthodes MFA des victimes. Voici comment cela fonctionne et ce qu’il faut vérifier.
Une session qui a déjà passé la MFA n’a plus besoin de la MFA
Si un attaquant vole la session que l’authentification multifacteur vient d’approuver, la MFA n’a plus rien à vérifier.
C’est ce que décrit l’entreprise de sécurité Huntress dans un rapport sur une campagne visant des comptes Microsoft 365. Entre le 14 juillet et le 22 septembre 2026, elle a observé plus de 200 000 tentatives de connexion échouées et au moins 497 connexions réussies dans les environnements de ses clients. L’activité a touché 79 organisations.
Cet article s’adresse aux personnes qui administrent ou prennent en charge Microsoft 365 : administrateurs, équipes de sécurité et responsables informatiques. Il explique ce qu’est un jeton, comment les attaquants s’en sont emparés, ce qu’ils ont fait ensuite et quels contrôles Microsoft sont utiles. Il précise aussi où ces contrôles s’arrêtent, car c’est la partie qu’on oublie facilement.
Ce qu’est un jeton et ce que signifie le rejeu
Lorsque vous vous connectez à Microsoft 365, vous prouvez votre identité avec un mot de passe et un second facteur. Microsoft remet ensuite à votre appareil un jeton, c’est-à-dire un petit laissez-passer numérique qui dit « cet utilisateur a déjà été vérifié ». Vos applications présentent ce laissez-passer à Exchange, SharePoint et Teams pour que vous n’ayez pas à vous reconnecter à chaque clic.
Le rejeu de jeton consiste à utiliser le laissez-passer de quelqu’un d’autre. Si un attaquant copie un jeton valide et le présente depuis une autre machine, le service voit un laissez-passer qui a l’air authentique. Le mot de passe et le second facteur ont déjà été vérifiés plus tôt, ils ne sont donc pas redemandés.
C’est pour cela que l’attaque est difficile à repérer. Lors des connexions réussies, rien n’a été deviné et rien n’a échoué. Le laissez-passer a simplement été utilisé par la mauvaise personne.
Ce que Huntress a observé
Selon Huntress, la campagne a duré environ dix semaines. Outre les chiffres ci-dessus, l’entreprise a trouvé 48 faux appareils enregistrés dans les annuaires Entra des victimes. Dans au moins 19 organisations, les méthodes MFA existantes des victimes ont été supprimées et de nouvelles ajoutées dans les trois heures suivant la première connexion.
Les attaquants opéraient sur deux niveaux. Un premier ensemble de serveurs capturait les sessions des victimes. Un ensemble distinct de serveurs loués, dans la plage d’adresses d’un hébergeur allemand, rejouait ces sessions. Huntress appelle cette étape de rejeu le « token spraying », par analogie avec le password spraying.
Comme les deux niveaux sont séparés, bloquer l’un n’arrête pas l’autre.
La vitesse a compté. Huntress a mesuré 12 minutes entre une demande MFA et une session détournée le 21 juillet, et quatre minutes le 22 septembre. The Hacker News, qui a rapporté ces conclusions le 26 octobre, ne nomme aucun acteur malveillant, et Huntress non plus. Considérez toute attribution que vous verriez ailleurs comme non confirmée.
Une remarque sur les chiffres : ils proviennent uniquement des environnements des clients de Huntress. L’ampleur réelle est au moins aussi grande, et probablement plus. La page de Huntress donne par ailleurs deux chiffres différents pour un même pic d’activité en septembre, c’est pourquoi nous ne citons ni l’un ni l’autre.
Comment les attaquants ont obtenu les jetons
Huntress et The Hacker News décrivent trois voies.
La première est l’hameçonnage de type adversary-in-the-middle, abrégé en AiTM. La victime arrive sur une fausse page de connexion placée entre elle et la vraie page Microsoft. Cette page transmet son mot de passe et son code MFA à Microsoft, et garde le jeton qui revient.
La victime voit une connexion normale. L’attaquant détient une session fonctionnelle.
La deuxième est l’hameçonnage par code d’appareil. Certains appareils, comme un téléviseur ou un outil en ligne de commande, ne peuvent pas afficher une page de connexion complète ; Microsoft leur permet donc de se connecter en affichant un code court que l’utilisateur saisit sur un autre appareil. Un attaquant peut lancer ce processus, envoyer le code à la victime avec une histoire crédible, et recevoir le jeton quand la victime l’approuve.
La troisième est une simple ingénierie sociale pendant une connexion légitime. Les rapports donnent peu de détails sur ce point, nous ne savons donc pas comment elle a fonctionné en pratique.
Ce que les attaquants ont fait une fois entrés
Huntress a constaté un schéma constant après le premier rejeu. Les attaquants ajoutaient leur propre application d’authentification, ou effaçaient les méthodes MFA de la victime et en enregistraient une nouvelle. Dans un cas, le 21 juillet, une méthode ajoutée par l’attaquant et nommée « iPhone 13 » était active environ 50 minutes après que le relais avait capturé la session.
Ils ont aussi enregistré de faux appareils dans Entra, qui restent dans l’annuaire jusqu’à ce que quelqu’un les supprime. Ils ont en outre créé des règles de boîte de réception cachées, portant des noms comme un simple point ou « sss », qui déplaçaient ou supprimaient les messages concernant la paie, les virements et les primes. Lors d’un incident, l’attaquant a écrit à un comptable externe au sujet de la paie et a masqué les réponses, ce qui correspond au schéma de la compromission de messagerie professionnelle (business email compromise). Lors d’un autre, une boîte aux lettres a servi à envoyer du spam à des centaines de destinataires externes, jusqu’à ce qu’Entra ID Protection signale le compte comme à haut risque.
Chaque étape rend l’intrus plus difficile à déloger. Une nouvelle méthode MFA permet à l’attaquant de se reconnecter plus tard. Un faux appareil a le même effet. Une règle cachée empêche la victime de voir les réponses.
Pourquoi la MFA seule n’a pas suffi
La MFA protège le moment de la connexion. Dans une attaque AiTM, c’est la victime qui accomplit cette partie pour l’attaquant. Le vrai code part vers le vrai service Microsoft en passant par le relais de l’attaquant, et l’attaquant garde le résultat.
Certaines méthodes MFA résistent mieux que d’autres. La documentation de Microsoft sur les forces d’authentification (authentication strengths) place Windows Hello for Business, les clés de sécurité FIDO2 et l’authentification par certificat dans un groupe « résistant à l’hameçonnage ». Elle les définit comme des méthodes qui exigent une interaction entre la méthode et la surface de connexion. La connexion par téléphone avec Microsoft Authenticator est une méthode sans mot de passe, mais elle ne fait pas partie de ce groupe, et les codes comme les approbations par notification push n’appartiennent à aucun des deux.
Notre lecture de cette définition est qu’une page relais, qui n’est pas la vraie surface de connexion, a beaucoup plus de mal à mener ces méthodes à bien. C’est notre inférence, et non une déclaration de Microsoft sur l’AiTM, car la page de Microsoft ne mentionne pas du tout l’AiTM. Nous ne savons pas non plus quelles méthodes MFA utilisaient les victimes de Huntress, nous ne pouvons donc pas dire si des méthodes résistantes à l’hameçonnage auraient arrêté cette campagne.
Ce que couvrent les contrôles de Microsoft, et où ils s’arrêtent
Plusieurs contrôles aident contre le vol de jetons. Aucun n’est à lui seul une réponse complète. Le tableau indique ce que fait chacun d’après la documentation actuelle de Microsoft, ainsi que la limite qui compte.
| Contrôle | Ce qu’il fait | Limite à connaître |
|---|---|---|
| Forces d’authentification résistantes à l’hameçonnage | Exige des clés FIDO2, Windows Hello for Business ou l’authentification par certificat pour les connexions choisies. | Conditional Access est évalué après la première étape d’authentification : un utilisateur peut donc encore saisir un mot de passe avant que l’exigence ne s’applique. |
| Protection des jetons (Token protection) | Lie les jetons de session de connexion à l’appareil, si bien qu’un jeton volé ne devrait pas fonctionner depuis un autre appareil. Microsoft indique qu’elle « tente de réduire » le rejeu. | Couvre certaines applications natives, comme Exchange Online, SharePoint Online et Teams, sur les plateformes prises en charge. La prise en charge des navigateurs est en préversion et limitée à certaines applications web qui accèdent à Azure Resource Manager. Vérifiez sur la page l’état actuel de chaque plateforme. |
| Évaluation continue de l’accès (continuous access evaluation) | Permet à Exchange, SharePoint et Teams de rejeter un jeton avant son expiration après des événements comme une réinitialisation de mot de passe, un compte désactivé, une session révoquée ou un risque utilisateur élevé. | Ne fonctionne qu’avec les applications prises en charge. Les vérifications d’emplacement ne couvrent que les emplacements nommés basés sur l’adresse IP. Microsoft signale que des délais de traitement des événements allant jusqu’à 15 minutes peuvent se produire. |
| Bloquer le flux de code d’appareil | Une stratégie Conditional Access qui bloque la connexion par code d’appareil pour les utilisateurs qui n’en ont pas besoin. | Microsoft recommande d’auditer d’abord l’usage existant, et les comptes que vous excluez échappent à la stratégie. Les principaux de service ne sont pas couverts par les stratégies visant les utilisateurs. |
D’après la page de Microsoft, les sessions ouvertes dans un navigateur vers Outlook sur le web ou SharePoint ne figurent pas dans la liste de la protection des jetons. Nous en déduisons qu’il s’agit d’une faille face aux attaques AiTM, qui capturent couramment des sessions de navigateur. La page de Microsoft ne le dit pas : considérez-le comme un point à tester dans votre propre locataire (tenant), et non comme un fait.
Huntress recommande également des stratégies Conditional Access qui exigent la MFA ou bloquent l’accès pour tous les utilisateurs, toutes les applications cloud et tous les types d’applications clientes, sans condition. C’est le conseil de l’éditeur, et il est logique comme socle de base. Il ne remplace pas les contrôles ci-dessus.
Que faire si vous soupçonnez le vol d’une session
Huntress est clair sur un point : une réinitialisation du mot de passe ne suffit pas à elle seule. Les méthodes MFA et les faux appareils de l’attaquant restent en place, et un jeton d’accès peut continuer à fonctionner jusqu’à son expiration, que Huntress situe à environ 90 minutes (la valeur par défaut de Microsoft est de 60 à 90 minutes). Suivez ces étapes dans l’ordre.
- Révoquez les sessions de l’utilisateur, puis réinitialisez le mot de passe. Dans cette campagne, les tentatives ultérieures de l’attaquant pour rejouer des sessions qui n’étaient plus valides, par exemple après un changement de mot de passe, ont échoué avec l’erreur Microsoft « SsoArtifactRevoked » (AADSTS50133).
- Examinez les méthodes MFA de l’utilisateur. Recherchez les méthodes ajoutées ou effacées peu après une connexion, surtout dans les quelques heures qui suivent.
- Auditez les appareils enregistrés dans Entra. Assurez-vous qu’un appareil n’est pas légitime avant de le supprimer. Huntress a noté que les faux appareils portaient des noms commençant par « DESKTOP- » suivi de huit caractères hexadécimaux, ce qui diffère du format par défaut de Windows, et cite aussi les préfixes « Device- » et « Work Pc » suivis de huit caractères hexadécimaux.
- Vérifiez les règles de boîte de réception et les nouvelles applications d’entreprise. Les noms très courts ou composés uniquement de ponctuation, ainsi que les règles qui touchent aux messages de paie ou bancaires, méritent un examen attentif.
- Recherchez l’impact à l’extérieur. Vérifiez les messages envoyés à des tiers externes et toute coordonnée de paiement approuvée ou modifiée.
Pour la chasse aux menaces, Huntress liste les schémas de connexion exacts, les identifiants de client (client IDs) et les adresses qu’elle a observés. Reportez-vous à son rapport pour ces éléments, car ils changent vite et servent davantage aux équipes de chasse qu’au grand public.
Ce que nous savons, et ce que nous ignorons
| Catégorie | Affirmation |
|---|---|
| Fait | Huntress fait état d’une activité du 14 juillet au 22 septembre 2026, avec au moins 497 connexions réussies et 48 faux appareils Entra chez ses clients. |
| Rapport de chercheurs | Les attaquants ont utilisé des relais AiTM, l’hameçonnage par code d’appareil et l’ingénierie sociale pour obtenir des jetons, puis les ont rejoués depuis des serveurs loués. |
| Rapport de chercheurs | Dans au moins 19 organisations, les méthodes MFA ont été remplacées dans les trois heures suivant la première connexion. |
| Notre inférence | Les méthodes résistantes à l’hameçonnage et les jetons liés à l’appareil rendent cette attaque plus coûteuse. Les sessions de navigateur peuvent rester exposées à l’AiTM même là où la protection des jetons est activée. |
| Inconnu | Qui a mené la campagne. Si une victime utilisait une MFA résistante à l’hameçonnage. Combien d’organisations hors du champ de vision de Huntress ont été touchées. La propre évaluation de la campagne par Microsoft. |
Jusqu’où faut-il approfondir le sujet ?
Connaître : Chaque utilisateur et chaque responsable de Microsoft 365 devrait comprendre une idée : la MFA protège la connexion, pas la session qui la suit. Si un message vous demande de saisir un code sur une page que vous n’avez pas ouverte vous-même, arrêtez-vous et signalez-le.
Utiliser : Les administrateurs et le personnel du support informatique devraient savoir révoquer des sessions, examiner les méthodes MFA et les appareils enregistrés, trouver les règles de boîte de réception cachées et lire une stratégie Conditional Access. Vous devriez savoir pourquoi une simple réinitialisation du mot de passe n’est pas une réponse complète.
Maîtriser : Les architectes sécurité et les responsables de l’identité devraient concevoir en tenant compte du vol de jetons. Cela signifie choisir les forces d’authentification, déployer la protection des jetons en la testant d’abord en mode rapport seul (report-only), décider qui a vraiment besoin du flux de code d’appareil, et transférer les journaux de connexion vers un emplacement qu’un intrus ne peut pas modifier.
Ce que vous pouvez ignorer pour l’instant
Inutile de mémoriser les adresses IP, les user agents ou les identifiants de client du rapport de Huntress. Ce sont des indicateurs destinés aux équipes de chasse, et ils deviendront obsolètes. Ce qui dure, c’est le schéma : une connexion normale, un changement de MFA peu après, un nouvel appareil et une règle de messagerie cachée.
Une étape concrète pour la suite
Ouvrez vos journaux de connexion et cherchez tout compte qui a enregistré une nouvelle méthode MFA dans les quelques heures suivant une connexion depuis un lieu inhabituel. Vérifiez ensuite si votre locataire autorise le flux de code d’appareil. Si vous n’en avez jamais eu besoin, créez d’abord la stratégie de blocage en mode rapport seul et lisez les résultats avant de l’activer.
Pour aller plus loin
Rapports et couverture médiatique
- Token spray and replay in Microsoft 365, Huntress, Andrea Hatcher, Susannah Matt, Matt Poto et Andrew Schwartz, 22 octobre 2026, la chronologie complète, les outils et les indicateurs.
- The Hacker News sur les conclusions de Huntress, The Hacker News, Ravie Lakshmanan, 26 octobre 2026, un résumé plus court.
Documentation Microsoft
- Token protection in Conditional Access, Microsoft Learn, plateformes prises en charge et étapes de déploiement.
- Continuous access evaluation, Microsoft Learn, événements, durées de vie et limites.
- Block device code flow, Microsoft Learn, les étapes de la stratégie.
- Authentication strengths, Microsoft Learn, le groupe résistant à l’hameçonnage.
Les faits de cet article ont été vérifiés le 26 octobre 2026. Les fonctionnalités de Microsoft et le rapport de Huntress peuvent évoluer : vérifiez-les auprès des sources ci-dessus avant d’agir.
Cet article distingue ce qu’affirment Huntress et Microsoft de nos propres inférences.
À lire aussi sur TechiesJournal
- Les attaques par hameçonnage (en anglais), TechiesJournal, les bases.
- Quand une application cloud de confiance devient un vecteur d’attaque (en anglais), TechiesJournal, un autre risque d’identité dans Microsoft 365.