Vol de jetons Microsoft 365 : pourquoi la MFA seule n'arrête pas le token spraying

Une expérience montre que la MFA n'empêche pas le vol de sessions : plus de 200 000 tentatives de connexion échouées, 497 connexions réussies, et des e-mails sur les salaires et les primes qui disparaissent dans des règles masquées. L'article explique comment reconnaître ce type de vol de jetons Microsoft 365, pourquoi la large diffusion de la plateforme rend l'attaque rentable et quoi faire en priorité en cas d'urgence.

Ce qu'est le token spraying

Le token spraying dans Microsoft 365 désigne une technique que l'éditeur de sécurité Huntress a observée lors d'une campagne. Les attaquants ne devinent pas de mots de passe. Ils volent des jetons de session après qu'un employé s'est connecté correctement avec son mot de passe et l'authentification multifacteur (MFA), puis rejouent ces jetons peu après depuis leur propre infrastructure. Le nom fait référence au password spraying, où un mot de passe est testé sur de nombreux comptes. Ici, des identifiants volés sont diffusés largement et réutilisés.

Les informations sur la campagne proviennent de Huntress et d'un article de The Hacker News. Elles reposent sur des observations chez les clients d'un seul éditeur de sécurité et ne disent rien de l'ensemble des tenants.

Vol de jetons Microsoft 365 : ce que Huntress a observé

Huntress décrit la campagne dans le rapport Token Replay and Spray. La date exacte de publication du rapport n'est pas établie ; la période d'observation, du 14 juillet 2026 au 22 septembre 2026, est en revanche documentée. Durant cette période, Huntress a constaté des attaques contre 79 organisations, plus de 200 000 tentatives de connexion échouées et 497 connexions réussies. Au moins 48 faux appareils ont été créés dans des annuaires Entra. Dans 19 organisations, les méthodes MFA existantes ont été supprimées et remplacées par une nouvelle.

À ce jour, le chiffre de 97 comptes compromis n'est cité que par The Hacker News. Il n'a pas pu être confirmé dans le rapport de Huntress et est donc présenté ici comme une indication de cet article. Les chiffres des différentes vagues d'attaques divergent en outre légèrement dans l'exposé de Huntress. Pour situer l'affaire, l'ordre de grandeur suffit : avec 79 organisations touchées, 497 connexions réussies et plusieurs vagues d'attaques sur environ dix semaines, il ne s'agissait pas d'un cas isolé, mais d'une série.

En quoi le token spraying diffère du password spraying

Le password spraying produit de nombreux échecs, car la plupart des mots de passe sont faux. Avec le token spraying, les identifiants sont valides. Selon Huntress, les tentatives échouées de la campagne provenaient des réseaux des attaquants, dont une grande partie d'un hébergeur en Allemagne. Cela ne dit rien des autres clients de ce fournisseur. Bloquer des adresses isolées n'aide d'ailleurs guère, car les attaquants changeaient d'adresses par vagues, avec une à deux semaines de calme entre les vagues.

Comment le rejeu de jetons contourne la MFA

La technique est aussi appelée rejeu de jetons (token replay), c'est-à-dire la relecture d'un jeton volé. Le déroulement se décrit en quatre étapes.

1. Appât : un employé reçoit un e-mail d'hameçonnage ou est dirigé vers un site tiers par ingénierie sociale. La manière dont de tels e-mails gagnent la confiance est décrite dans l'article sur l'authenticité des messages électroniques.
2. Interception : un relais adversary-in-the-middle (AiTM) se place entre l'employé et la vraie page de connexion Microsoft. Le mot de passe et la demande MFA passent par le relais, qui enregistre ensuite le jeton. Dans le device code phishing, la victime est plutôt amenée à saisir un code sur la vraie page Microsoft, code avec lequel l'attaquant obtient un jeton.
3. Rejeu : quelques minutes à environ une heure plus tard, l'attaquant utilise le jeton depuis ses propres serveurs. Il ne lui faut ni mot de passe ni seconde demande MFA.
4. Persistance : l'attaquant enregistre sa propre application d'authentification, supprime les méthodes MFA existantes ou crée un faux appareil. Les deux survivent à un changement de mot de passe.

L'essentiel est le suivant : la MFA n'a pas été cassée. L'employé l'a exécutée correctement. Ce qui est volé, c'est le résultat, le jeton. La MFA ne peut donc être contournée ici que si le jeton fonctionne aussi en dehors de l'appareil de l'employé. Les codes, les SMS et les validations push protègent contre la devinette de mots de passe, mais pas contre ce type de vol.

Huntress a identifié deux familles d'outils. L'une est un script qui s'annonce avec l'agent utilisateur « node » et demande des jetons via les applications Office et Authentication Broker. L'autre rejoue des sessions de navigateur. Les connexions de ce second type ressemblent à des accès ordinaires par navigateur et sont donc moins visibles.

Monoculture Microsoft : pourquoi Microsoft 365 est la cible la plus rentable

Microsoft 365 est utilisé dans d'innombrables entreprises, en Allemagne comme dans le monde. Du point de vue des attaquants, c'est un argument économique : une attaque construite une fois peut être répétée contre un très grand nombre de tenants. Les pages de connexion se ressemblent partout, les identifiants d'application sont les mêmes, tout comme les codes d'erreur. Ce qui marche dans une entreprise marche, avec de petites adaptations, dans beaucoup d'autres.

La campagne illustre ce passage à l'échelle. Les jetons volés ont été utilisés de manière automatisée et en quelques minutes, répartis sur 79 organisations. Selon Huntress, les attaquants n'ont pas priorisé d'après le nombre de tentatives échouées, mais d'après les endroits où des identifiants valides existaient. C'est le fonctionnement d'une activité de masse, pas celui d'une opération ciblée contre une seule entreprise.

La diffusion est un amplificateur, pas la seule cause

Ce n'est pas une condamnation globale. Microsoft fournit lui-même les contre-mesures : l'accès conditionnel, les Security Defaults et Token Protection. Le risque apparaît lorsque ces outils ne sont pas utilisés, ou seulement en partie. Les attaquants adaptent leur automatisation aux paramètres par défaut, car ceux-ci s'appliquent à la plupart des tenants. Chaque écart, comme une connexion liée à un appareil ou un flux de code d'appareil bloqué, coûte des efforts aux attaquants et supprime la base de l'exploitation de masse.

La diffusion de Copilot et d'autres services derrière les mêmes comptes accroît aussi l'effet de levier d'un compte compromis. Une analyse critique est proposée dans l'article Copilot sous la loupe. Dans Microsoft 365, un seul compte ouvre en même temps la messagerie, les fichiers, l'agenda et le chat.

La fraude aux salaires comme objectif : ce qui se passe après la prise de contrôle

Après la prise de contrôle, les attaquants de la campagne ont créé des règles de boîte de réception masquées. Elles déplaçaient ou supprimaient les e-mails contenant des termes liés aux paiements, comme salaire, versements ou prime. Les dossiers de destination portaient des noms discrets, par exemple « RSS Feeds » ou « Conversation History ». Dans un cas, un e-mail sur un salaire a été envoyé à un conseiller fiscal externe. Les réponses étaient marquées comme lues et écartées afin que la victime ne les remarque pas.

Derrière cela se trouve la compromission de messagerie professionnelle (BEC) : il s'agit de détourner des virements ou de faire modifier des comptes de salaire. Dans un autre cas, une boîte aux lettres a été utilisée pour envoyer du spam à des centaines de destinataires externes, jusqu'à ce qu'Entra ID Protection classe le compte comme à risque élevé.

Pour les petites entreprises, c'est particulièrement sensible. La comptabilité et les ressources humaines ne comptent souvent que quelques personnes. Un compte modifié est repéré tard, et la paie est fréquemment confiée à des tiers. La direction décide alors du rappel des paiements et de l'information de la banque, du conseiller fiscal et du bureau de paie. Cela relève du plan d'urgence, pas seulement de la crise.

Traces typiques : nouvelle application d'authentification, appareils Entra inconnus, règles de boîte de réception

La campagne laisse des traces dans Microsoft Entra ID, la gestion des utilisateurs derrière Microsoft 365, qui peuvent être vérifiées sans outil spécialisé. Le tableau suivant résume les plus importantes. Les modèles de noms proviennent du rapport de Huntress et peuvent changer.

Le code d'erreur 53003 mérite l'attention. Un blocage par l'accès conditionnel est généralement vu comme un succès de la politique. Mais il montre aussi qu'une personne extérieure à l'entreprise détient des identifiants valides ou un jeton valide. Une telle entrée est une raison de contrôler le compte. Les règles de boîte de réception créées via une API n'apparaissent pas toujours dans l'interface. Elles deviennent visibles via le centre d'administration Exchange ou PowerShell.

Les petites entreprises sans surveillance des journaux ne voient souvent les choses qu'après coup. La durée de conservation des journaux de connexion dépend de la licence et doit être clarifiée à l'avance, car sans journaux, l'ampleur d'un incident reste inconnue.

Accès conditionnel : bloquer le flux de code d'appareil et exiger la MFA pour tous les types de clients

Le flux de code d'appareil (device code flow) est une méthode de connexion pour les appareils sans clavier ni navigateur. Les attaquants en abusent dans le device code phishing en amenant les utilisateurs à saisir un code sur un autre appareil. Dans sa documentation sur le blocage des flux d'authentification, Microsoft recommande de s'approcher le plus possible d'un blocage complet et de n'autoriser le flux que dans des exceptions bien documentées, par exemple pour des outils anciens impossibles à mettre à jour.

La politique se crée dans le centre d'administration Entra sous Entra ID, Accès conditionnel, Politiques. La condition est « Flux d'authentification » avec la sélection « Flux de code d'appareil », et le contrôle d'accès est « Bloquer l'accès ». Microsoft recommande de laisser d'abord la politique en mode « Rapport seul » et de ne l'activer qu'ensuite. Deux comptes d'accès d'urgence sont exclus, et leur liste doit être vérifiée régulièrement.

Licence : accès conditionnel ou Security Defaults

Selon Microsoft Learn, l'accès conditionnel exige au moins Microsoft Entra ID P1 (prérequis selon la documentation sur les forces d'authentification). Les entreprises sans cette licence disposent des Security Defaults, qui, selon Microsoft, ne nécessitent aucune licence. Les mesures de protection qui y figurent comprennent l'enregistrement MFA pour tous les utilisateurs, le blocage des protocoles hérités et le blocage du flux de code d'appareil. Microsoft indique en outre qu'à partir du 1er juillet 2026, tous les nouveaux tenants Entra bloquent le flux de code d'appareil dans le cadre des Security Defaults. D'après Microsoft, les Security Defaults ne peuvent pas être personnalisés, seulement activés ou désactivés. Qui a besoin d'exceptions ou de règles plus fines a besoin de l'accès conditionnel.

MFA pour tous, sans exceptions pour les applications ou les clients

Une politique de base devrait exiger la MFA pour tous les utilisateurs, toutes les ressources et tous les types de clients, ou bloquer l'accès. C'est exactement ce que demande le rapport de Huntress, et les failles naissent souvent d'exceptions bien intentionnées comme « portails d'administration uniquement » ou « navigateur uniquement ». Les protocoles hérités tels qu'IMAP, POP3 et l'authentification SMTP ne prennent pas en charge la MFA et doivent être bloqués.

Les méthodes résistantes au hameçonnage, comme les clés de sécurité FIDO2 ou Windows Hello Entreprise, protègent bien mieux contre l'interception AiTM que les codes, les SMS ou les validations push. Microsoft cite, comme caractéristique de la force « MFA résistante au hameçonnage », une interaction entre la méthode d'authentification et la surface de connexion (forces d'authentification). Cette page ne contient aucune déclaration explicite sur l'AiTM ; cette appréciation est donc une conclusion de l'auteur. La création d'une politique de base avec force d'authentification est décrite sur la page MFA pour tous les utilisateurs. Il est judicieux de commencer par les administrateurs.

Token Protection et ses limites

Token Protection est un contrôle de session de l'accès conditionnel. Il n'accepte que les jetons de connexion liés cryptographiquement à un appareil enregistré. Un jeton volé ne fonctionne alors pas sur un autre appareil. Selon Microsoft Learn (page à l'état d'août 2026), la fonction est disponible de manière générale pour les applications natives sous Windows, iOS, iPadOS et macOS et s'applique à Exchange Online, SharePoint Online et Teams. Windows 365 et Azure Virtual Desktop s'y ajoutent sous Windows. La page ne contient aucune information de licence propre ; l'exigence de licence doit donc être clarifiée séparément. En tant que fonction de l'accès conditionnel, Token Protection requiert au moins Entra ID P1, selon la déduction de l'auteur. Ce n'est pas une citation de Microsoft.

Les limites sont clairement indiquées. Les applications basées sur un navigateur ne sont prises en charge qu'en préversion et seulement pour certaines applications web utilisant Azure Resource Manager. Outlook sur le web n'est donc pas couvert. De plus, les appareils doivent être enregistrés, joints ou joints en mode hybride à Entra. Les appareils Apple doivent être des appareils gérés avec l'extension d'authentification unique. Pour les entreprises avec des appareils personnels, c'est un vrai obstacle.

Token Protection réduit le rejeu de jetons, mais n'élimine pas le risque. Microsoft recommande un groupe pilote, le mode « Rapport seul » et l'évaluation des journaux de connexion avant un déploiement large. Un appareil conforme comme condition d'accès, la restriction du consentement aux nouvelles applications et le contrôle régulier des nouvelles applications d'entreprise aident aussi. Une MFA résistante au hameçonnage et un accès basé sur l'appareil réduisent le risque ; la surveillance détecte ce qui passe malgré tout.

Procédure d'urgence : révoquer les sessions, nettoyer les appareils et les méthodes MFA

La séquence suivante est une recommandation de l'auteur, dérivée de la documentation Microsoft sur la révocation des accès et du rapport de Huntress. Ce n'est pas une exigence officielle. La marche à suivre générale après une attaque réussie est décrite dans l'article Ransomware : plan d'action pour les 60 premières minutes, dont certaines parties sont transposables ici.

1. Bloquer le compte et révoquer les sessions : dans le centre d'administration Entra, sous Utilisateurs, on désactive « Compte activé » et on choisit « Révoquer les sessions », ou via PowerShell avec Revoke-MgUserSignInSession. Cela empêche l'émission de nouveaux jetons.
2. Réinitialiser le mot de passe : dans les environnements hybrides, Microsoft recommande de réinitialiser le mot de passe deux fois dans l'Active Directory local. Les sessions sont ensuite révoquées de nouveau.
3. Vérifier les méthodes MFA : les méthodes inconnues, en particulier une nouvelle application d'authentification, sont supprimées. Le véritable utilisateur ne configure ses méthodes qu'ensuite, idéalement avec une confirmation par rappel téléphonique.
4. Vérifier les appareils : les appareils enregistrés inconnus sont désactivés et supprimés. Ils sont un signe de persistance.
5. Nettoyer la boîte aux lettres : les règles, les redirections, les délégations et les règles de transport sont vérifiées et supprimées. Les éléments envoyés et supprimés sont examinés à la recherche d'anomalies.
6. Vérifier les applications : les applications d'entreprise inconnues et les consentements d'application sont supprimés.
7. Déterminer l'ampleur : les journaux de connexion sont analysés à partir du premier moment suspect. D'autres comptes du même service doivent aussi être envisagés, car la campagne touchait souvent plusieurs comptes par organisation.
8. Évaluer les conséquences pour l'entreprise : des coordonnées bancaires, des données de salaire ou des factures ont-elles été modifiées ? La banque, le conseiller fiscal et le bureau de paie sont informés, les paiements sont suspendus et les demandes de modification sont confirmées par téléphone. C'est à la direction de décider.
9. Évaluer l'obligation de notification : la nécessité d'une notification à l'autorité de contrôle dépend du risque. Le délai est de 72 heures après la prise de connaissance (article 33 du RGPD). Ceci ne constitue pas un conseil juridique.

Pourquoi la révocation ne prend pas effet immédiatement

Selon Microsoft, les jetons d'accès sont valables une heure par défaut. La révocation bloque les nouveaux jetons et invalide les jetons d'actualisation, mais les jetons d'accès déjà émis restent valables jusqu'à leur expiration. Pour les applications dotées de leurs propres cookies de session, c'est l'application elle-même qui doit mettre fin à l'accès. L'évaluation continue de l'accès (Continuous Access Evaluation, CAE) réduit ce délai à quelques minutes pour Exchange Online, SharePoint Online et Teams, avec selon Microsoft un retard pouvant atteindre 15 minutes. Huntress rapporte que des jetons d'accès sont restés valables jusqu'à environ 90 minutes et qu'une réinitialisation de mot de passe seule ne supprime ni les faux appareils ni les méthodes MFA. Les deux vont ensemble : cliquer sur « Révoquer les sessions » est un début, pas une fin.

Ce que les administrateurs et les dirigeants peuvent vérifier cette semaine

• Le flux de code d'appareil est-il bloqué, ou les Security Defaults sont-ils activés ?
• Une politique exige-t-elle la MFA pour tous les utilisateurs, toutes les ressources et tous les types de clients, sans exceptions d'applications ?
• Les protocoles hérités comme IMAP, POP3 et l'authentification SMTP sont-ils bloqués ?
• Existe-t-il deux comptes d'accès d'urgence exclus des politiques et sécurisés séparément ?
• Les méthodes d'authentification, les appareils et les règles de boîte de réception de la comptabilité et des ressources humaines ont-ils été examinés ?
• Est-il clair qui décide en cas de soupçon et quel prestataire est joignable en dehors des heures de bureau ?

Chez le prestataire informatique, ce qui compte, ce sont le temps de réaction, l'accès aux journaux, la connaissance des politiques et une documentation écrite des exceptions. Un regard extérieur sur la configuration peut être utile, par exemple avec les contrôles de sécurité. Le site web de l'entreprise et son domaine de messagerie font aussi partie de la surface d'attaque. Le contrôle de site web examine le site vu de l'extérieur, mais ne vérifie pas les paramètres Entra.

Sa large diffusion fait de Microsoft 365 la cible par défaut. Qui renforce les paramètres par défaut, garde un œil sur les appareils et les méthodes et discute de l'urgence à l'avance retire à l'automatisation sa base. Vu avec sobriété, c'est moins une question de panique que de configuration et de routine.