Une collaboratrice ouvre un lien vers un relevé. Quelques minutes plus tard, une authentification Microsoft 365 réussit, le MFA est validé et un appareil inconnu apparaît dans Microsoft Entra ID. Le lendemain matin, ce même appareil accède à Microsoft Graph et Exchange Online depuis l’Allemagne. Comment un attaquant obtient-il un jeton Microsoft valide alors que le MFA est actif ? Voici le déroulé de cet incident réel, le mécanisme exact qui l’a rendu possible et les réflexes à installer dès maintenant.
L'histoire commence par un email banal. Le message contient un lien vers un relevé à consulter. La collaboratrice pense traiter un document professionnel classique. Elle ouvre le lien.La suite se joue en quelques minutes. Une authentification Microsoft 365 aboutit. Une validation MFA suit. Puis un nouvel appareil s'enregistre dans Microsoft Entra ID. À ce stade, aucun signal ne perturbe le quotidien de l'utilisatrice.Le lendemain matin, le scénario change de dimension. L'appareil enregistré la veille réapparaît, cette fois depuis l'Allemagne, et accède à Microsoft Graph et à Exchange Online. L'attaquant ne force aucune porte : il utilise une authentification que le tenant considère comme valide.C'est la supervision des journaux Microsoft Entra qui déclenche l'alerte. Les équipes interviennent immédiatement : révocation des sessions actives, puis suppression de l'appareil frauduleux. En endurance, un incident se traite au stand, vite et sans improvisation. La même logique s'applique ici : la vitesse de réaction pèse autant que la détection.
Pendant des années, le phishing poursuivait un objectif simple : récupérer un identifiant et un mot de passe. Le MFA a fortement réduit la rentabilité de cette approche.Les campagnes actuelles ont donc changé de cible. Elles cherchent une authentification complète, validation MFA incluse. L'utilisateur ne saisit pas seulement ses identifiants sur une page piégée. Il valide aussi la demande d'authentification qui suit. De fait, l'attaquant n'a plus besoin de contourner le second facteur : il le fait valider par la personne elle-même.Ce déplacement change la nature de la menace. La question n'est plus « mon mot de passe est-il assez robuste ». Elle devient « qui détient une authentification valide sur mon tenant, et depuis quand ». Par ailleurs, ces campagnes s'appuient sur des prétextes crédibles : relevé, facture, document partagé, notification de service. Rien de spectaculaire, et c'est précisément ce qui les rend efficaces.
La question inquiète légitimement les dirigeants, et elle mérite une réponse claire. Non, Microsoft Entra ID n'a pas été percé. Aucune faille de la plateforme n'entre en jeu ici. L'attaquant obtient un jeton parce que l'authentification s'est réellement produite, avec les identifiants et la validation MFA de la personne visée.Le procédé porte un nom : l'attaque de l'intermédiaire, ou AiTM (adversary-in-the-middle). Le lien piégé n'envoie pas la victime vers une fausse page statique, mais vers un serveur relais placé entre elle et le véritable portail Microsoft.
Le déroulé se lit alors sans mystère :
1. la collaboratrice ouvre le lien et voit la page de connexion Microsoft;
2. elle saisit ses identifiants, que le relais transmet à Microsoft ;
3. Microsoft déclenche la demande MFA, qui arrive normalement sur son téléphone ;
4. elle valide, puisque tout paraît cohérent avec son action ;
5. Microsoft renvoie alors un cookie de session, que le relais intercepte au passage.
À cet instant, l’attaquant détient une session authentifiée. Du point de vue de la plateforme, rien d’anormal : les bons identifiants, un second facteur validé, une session ouverte. Le MFA n’a pas cédé techniquement. Une personne l’a validé, trompée sur la nature de sa propre action.
L’attaquant enchaîne ensuite avec l’étape décisive : il utilise cette session pour enregistrer son propre appareil dans Microsoft Entra ID. Ce geste transforme un accès temporaire en accès durable. La session volée finit par expirer, tandis qu’un appareil enregistré reste dans l’annuaire jusqu’à ce que quelqu’un le supprime.
Deux enseignements en découlent. D’une part, le MFA par notification ou par code reste vulnérable à ce type de relais. Seules les méthodes résistantes au phishing — clés FIDO2, passkeys, Windows Hello Entreprise — coupent le mécanisme à la racine, car le secret ne quitte jamais l’appareil et reste lié au domaine légitime. D’autre part, l’enregistrement d’appareil mérite un encadrement strict.
Une fois l’authentification validée, Microsoft délivre un jeton. Ce jeton représente la preuve que l’utilisateur s’est authentifié. Il ouvre l’accès aux services de l’écosystème :
Outlook ;
Exchange Online ;
Microsoft Graph ;
SharePoint ;
OneDrive.
Tant que ce jeton reste valide, certaines opérations s’effectuent sans nouvelle demande MFA. C’est le principe même du mécanisme : éviter de redemander une validation à chaque action. Pour un attaquant, ce confort devient un actif de grande valeur.
Dans cet incident, l’enquête a confirmé l’usage d’un Primary Refresh Token permettant l’accès aux services Microsoft 365. Ce type de jeton est associé à un appareil enregistré dans Entra ID. Il permet d’obtenir des accès aux applications sans repasser par une saisie d’identifiants. D’où l’importance de l’étape suivante de la chaîne d’attaque : l’enregistrement de l’appareil.
Que peut faire un attaquant avec un tel accès ? Il lit la messagerie, crée des règles de boîte aux lettres pour détourner certains messages, parcourt les espaces SharePoint et OneDrive du compte. Il prépare enfin des messages crédibles depuis une adresse légitime, notamment vers la comptabilité. Le risque financier apparaît alors très vite, sans qu’aucun logiciel malveillant n’entre en jeu.
Un mot de passe se change en trente secondes. Un jeton actif, lui, continue de fonctionner tant que personne ne le révoque. C’est pourquoi la révocation des sessions figure en tête de la liste des gestes d’urgence, avant même la réinitialisation du mot de passe.
L’enregistrement d’un appareil dans Entra ID n’a rien d’anodin. Cette opération inscrit un poste dans l’annuaire d’identités de l’entreprise, avec une existence durable, indépendante de la session initiale.
Dans ce cas précis, l’apparition d’un poste inconnu a constitué l’indicateur de compromission majeur. Le signal était net, daté et attribuable à un compte. Quelques heures plus tard, ce même appareil réapparaissait depuis un autre pays, avec des accès confirmés à plusieurs services Microsoft 365. La corrélation entre les deux événements a permis de qualifier l’incident rapidement.
Les créations d’appareils méritent donc le même niveau d’attention qu’une élévation de privilèges. Concrètement, trois questions suffisent à trier :
l’appareil correspond-il à un poste connu du parc ?
son enregistrement coïncide-t-il avec une action légitime de l’utilisateur ?
depuis quelles localisations est-il utilisé dans les heures qui suivent ?
Une équipe d’endurance ne regarde pas seulement le chronomètre. Elle lit la télémétrie en continu, car une anomalie de température annonce la panne avant la casse. Les journaux Entra jouent ce rôle sur un tenant Microsoft 365.
L’analyse des journaux Microsoft Entra a permis de confirmer une chaîne complète, sans zone d’ombre :
1. une authentification réussie avec validation MFA ;
2. l’enregistrement d’un poste dans Entra ID ;
3. la réutilisation de ce poste depuis l’Allemagne ;
4. des accès réussis à Microsoft Graph et Exchange Online ;
5. l’utilisation d’un Primary Refresh Token permettant l’accès aux services Microsoft 365.
Chaque étape s’appuie sur une trace horodatée. C’est ce qui distingue une hypothèse d’un constat.
Un point technique mérite l’attention des dirigeants. Les journaux Microsoft Entra restent consultables dans le portail sur une fenêtre limitée, de l’ordre de trente jours selon la licence. Cette fenêtre suffit pour une détection réactive comme celle-ci. Elle devient courte dès qu’une investigation remonte plusieurs mois en arrière. C’est pourquoi l’export des journaux vers Log Analytics ou Microsoft Sentinel constitue un choix structurant.
L’endiguement ne clôt pas un incident. Une fois les sessions révoquées et l’appareil supprimé, une seule question compte : qu’a fait l’attaquant pendant sa fenêtre d’accès ? Le journal d’audit unifié de Microsoft Purview y répond, car il trace les activités dans Exchange Online, SharePoint, OneDrive et Teams.
L’audit post-remédiation porte sur :
les messages consultés, envoyés ou supprimés dans la boîte compromise ;
les règles de boîte aux lettres créées, souvent utilisées pour masquer des échanges ;
les fichiers ouverts, téléchargés ou partagés depuis SharePoint et OneDrive ;
les partages externes et les consentements accordés à des applications tierces.
La recherche de contenu et l’eDiscovery de Purview complètent l’analyse. Elles identifient les documents réellement exposés, donc la portée exacte de la fuite. Cette évaluation conditionne la suite : information des personnes concernées, notification éventuelle à la CNIL, échanges avec l’assureur.
À cela s’ajoute un volet prévention. Les politiques DLP limitent en amont la circulation des informations sensibles. Les étiquettes de confidentialité protègent le document lui-même, y compris hors du tenant : un attaquant muni d’un jeton valide accède alors à un fichier chiffré qu’il ne peut pas ouvrir.
Aucun outil isolé ne couvre l’ensemble de la chaîne. La force du dispositif vient de l’articulation entre les briques.
Microsoft Defender pour Office 365 traite l’entrée du scénario : l’email et son lien. Il analyse les URL, isole les messages malveillants et retrouve les autres destinataires de la campagne. Ce dernier point compte beaucoup, car une personne a cliqué, mais combien d’autres ont reçu le message ?
Microsoft Entra ID Protection évalue le risque d’un utilisateur et d’une connexion : déplacements impossibles, adresses anonymisées, comportements atypiques. Couplé à l’accès conditionnel, il déclenche une remédiation automatique plutôt qu’une simple alerte.
Microsoft Defender for Cloud Apps apporte le contrôle de session. Il détecte les téléchargements massifs et peut bloquer une session en cours, face à un jeton encore valide.
Microsoft Intune conditionne l’accès à la conformité du poste. Un appareil inconnu et non conforme se voit alors refuser l’accès aux ressources, même muni d’un jeton.
Microsoft Defender XDR rassemble ces signaux dans une vue unique. Identité, messagerie, poste de travail et applications cloud se lisent au même endroit, d’où un temps de qualification bien plus court.
Microsoft Sentinel, enfin, joue le rôle de mémoire longue et d’automatisation. Il conserve les journaux au-delà de la fenêtre native, puis déclenche des réponses automatiques, par exemple la révocation des sessions dès la création d’un appareil suspect.
Cet incident n’appelle pas une refonte complète de l’environnement. Il appelle six réflexes, applicables dans la plupart des tenants Microsoft 365.
Basculer vers une authentification résistante au phishing
C’est la mesure qui neutralise le scénario à sa source. Une clé FIDO2, une passkey ou Windows Hello Entreprise lie l’authentification au domaine légitime et à l’appareil de l’utilisateur. Un relais malveillant ne peut alors pas rejouer le facteur. Le déploiement se prépare par population, en commençant par les comptes à privilèges.
Former les équipes aux mécanismes actuels de phishing
Les sensibilisations classiques insistent sur les fautes d’orthographe et les expéditeurs douteux. Ces critères ne suffisent plus. Une règle simple porte bien : une validation d’authentification se refuse dès qu’elle arrive sans action correspondante.
Superviser les créations d’appareils dans Entra ID
L’enregistrement d’un appareil doit générer une alerte exploitable. Encore faut-il que quelqu’un la lise et sache quoi en faire, avec un responsable identifié et une procédure écrite.
Déployer des politiques d’accès conditionnel adaptées
L’accès conditionnel encadre les conditions d’accès : conformité de l’appareil, localisation, niveau de risque, application ciblée. Ces politiques se construisent selon les usages réels de l’entreprise, notamment pour les équipes mobiles et les sites distants. Une politique trop stricte bloque le travail, une politique trop permissive laisse passer l’incident. L’équilibre se prépare, il ne s’improvise pas. [À VÉRIFIER sur Microsoft Learn : configurations d’accès conditionnel recommandées et prérequis de licence applicables au tenant concerné]
Révoquer les jetons sans attendre
Lors d’un incident, la révocation des sessions constitue le premier geste utile : elle invalide les accès en cours. La réinitialisation du mot de passe suit, tout comme la suppression des appareils non légitimes.
Contrôler les accès après toute compromission suspectée
Après l’endiguement vient la vérification, journal d’audit Microsoft Purview à l’appui : accès Exchange, SharePoint et OneDrive, puis recherche des persistances classiques — règles de boîte aux lettres, redirections, partages inhabituels, applications consenties. Un attaquant qui perd son jeton cherche souvent à conserver un point d’entrée.
La sécurité des identités ne se règle pas en une opération ponctuelle. Notre approche se déroule en trois temps, et cet incident les illustre tous les trois.
Transformer, d’abord. Il s’agit de poser le socle : politiques d’accès conditionnel cohérentes avec les usages, gestion des appareils via Intune, méthodes d’authentification résistantes au phishing, protection des données par Microsoft Purview, cloisonnement des comptes à privilèges avec PIM. Ce travail se prépare en amont, comme le réglage d’une voiture avant une épreuve d’endurance.
Former, ensuite. Un utilisateur informé des mécanismes actuels devient un capteur de détection. Il signale une demande MFA inattendue au lieu de la valider. Cette compétence s’entretient, car les scénarios d’attaque évoluent plus vite que les supports de sensibilisation.
Performer, enfin. La supervision continue transforme un journal en alerte, puis une alerte en action. Sans ce dernier maillon, les traces existent mais personne ne les exploite au bon moment. Ici, la détection est venue de cette lecture régulière des journaux Entra, pas d’un outil miraculeux.
Le pare-feu ne protège plus la donnée là où elle se trouve réellement. La frontière de l’entreprise passe désormais par les comptes, les appareils et les jetons. Même avec le MFA activé, un attaquant qui obtient une validation légitime se comporte comme un utilisateur autorisé.
Cet incident s’est bien terminé pour une raison précise : quelqu’un lisait les journaux, l’anomalie est apparue, et la réaction a suivi dans la foulée. La combinaison entre supervision, analyse des appareils Entra ID et rapidité d’intervention reste l’une des protections les plus efficaces contre ce type d’attaque.
Une question mérite d’être posée en comité de direction dès cette semaine : si un appareil inconnu s’enregistrait ce soir dans votre tenant, combien de temps s’écoulerait avant que quelqu’un le remarqu
Échangeons pendant 30 minutes sur votre environnement Microsoft 365, Copilot ou IA.
