Compromission par device code sur Microsoft 365 : chronologie, blocage et contrôles qui ferment le chemin

Un compte Microsoft 365 ordinaire, sans droit d’administration, suffit à un attaquant pour lire des échanges, détourner un virement et relancer une vague d’hameçonnage depuis une adresse légitime. Ce dossier reconstitue ce chemin pas à pas : le leurre, ce que vaut le compte, pourquoi changer le mot de passe ne suffit pas, les traces laissées à chaque phase, le blocage par le SOC, puis les contrôles qui ferment le chemin. Il est écrit pour un dirigeant ou un RCCI qui veut comprendre ce qui s’est passé et ce qu’il doit exiger de son prestataire.

Le leurre : un code saisi sur la vraie page Microsoft

Le flux « device code » existe pour une raison légitime : connecter un appareil sans clavier confortable, un écran de salle de réunion, une console, un client en ligne de commande. L’appareil affiche un code court, l’utilisateur ouvre la page officielle de Microsoft sur un autre appareil, saisit ce code et s’authentifie. Rien de suspect : l’URL est bien celle de Microsoft, le certificat est valide, la demande de MFA est réelle.

L’attaquant détourne ce mécanisme en quatre temps.

1. L’attaquant demande lui-même un code d’appareil pour le compte visé. Microsoft lui répond par un code court, valable quelques minutes, et son appareil se met à attendre.
2. Il envoie ce code à la cible dans un message plausible : une invitation à un document partagé, une demande de signature, un « votre session doit être renouvelée ». Le message contient le code et le lien vers la vraie page Microsoft.
3. L’utilisateur saisit le code, valide son MFA sur son téléphone. Tous les repères qu’on lui a appris à vérifier sont au vert.
4. Microsoft, qui a bien vu un utilisateur authentifié avec son MFA, délivre les jetons du compte à l’appareil qui attendait : celui de l’attaquant.

Il n’y a pas de faute de l’utilisateur à chercher ici. Le site est le bon, le MFA a répondu, aucun mot de passe n’a été tapé sur une page douteuse. Un utilisateur averti se fait piéger par ce scénario. Microsoft lui-même qualifie ce flux de méthode d’authentification à haut risque et recommande de le bloquer partout où c’est possible (voir les sources en fin d’article).

Ce que vaut un compte ordinaire

La question revient souvent : « ce compte n’avait aucun droit particulier, qu’est-ce qu’il pouvait bien se passer ? ». Quatre usages, dans l’ordre où ils apparaissent dans les cas que nous reconstituons.

Collecte

Le carnet d’adresses, les échanges des derniers mois, les documents accessibles (boîte, espace personnel, sites d’équipe partagés) sont lisibles immédiatement. L’attaquant cherche les sujets qui mènent à de l’argent : facturation, fournisseurs, notes de frais, échanges avec la banque ou l’expert-comptable. Dans une société de gestion, il cherche aussi les échanges avec le dépositaire, le valorisateur et les investisseurs.

Fraude au virement

Une règle de boîte est créée pour déplacer ou supprimer les messages d’un correspondant précis, de sorte que la victime ne voie plus la conversation. L’attaquant reprend alors un échange de facturation en cours et annonce un changement de coordonnées bancaires, ou émet une facture dont le RIB a été modifié. Le ton, la signature et l’historique de la conversation sont authentiques, puisque c’est la vraie boîte qui écrit.

Rebond

Depuis une adresse légitime et connue des destinataires, une nouvelle vague d’hameçonnage part vers les contacts : collègues, clients, partenaires. Le message reprend souvent le même leurre, un nouveau code d’appareil, et le taux de réussite est sans commune mesure avec un envoi depuis un domaine inconnu.

Persistance

Pour survivre à la découverte, l’attaquant installe des portes de retour : consentement accordé à une application tierce qui garde un accès à la boîte, ou ajout d’une méthode d’authentification, téléphone ou application, qu’il contrôle. Ce sont ces deux points qui distinguent une compromission « nettoyée » d’une compromission qui revient trois semaines plus tard. La section suivante leur est consacrée.

Pourquoi changer le mot de passe ne suffit pas

C’est le réflexe le plus répandu, et il est insuffisant. Le changement de mot de passe empêche une nouvelle connexion avec l’ancien secret. Il ne touche pas à ce qui est déjà en place.

La session déjà ouverte

Les jetons d’accès émis par Microsoft Entra ID sont valables une heure par défaut, et l’application qui les détient peut les renouveler silencieusement tant que ses sessions ne sont pas révoquées. Les applications web, elles, travaillent avec leurs propres jetons de session, que Microsoft ne peut pas révoquer directement. Autrement dit, l’attaquant qui a reçu les jetons à 9 h 10 ne perd rien quand l’utilisateur change son mot de passe à 11 h : il faut révoquer explicitement les sessions du compte, et c’est le premier geste du confinement. Les applications compatibles avec l’évaluation continue de l’accès réagissent plus vite à cette révocation, les autres attendent l’expiration du jeton en cours.

La méthode MFA ajoutée

Vingt minutes après la prise de contrôle, dans notre scénario, l’attaquant enregistre un téléphone ou une application d’authentification à lui sur le compte. Cette méthode reste enregistrée après le changement de mot de passe. Elle lui sert à deux choses : valider un MFA si l’utilisateur se laisse piéger une seconde fois, et surtout utiliser la réinitialisation de mot de passe en libre-service, quand elle est ouverte, pour choisir lui-même le nouveau mot de passe. Le compte a alors deux propriétaires, et le second ne se voit pas.

C’est précisément l’événement que nous supervisons. L’ajout d’une méthode d’authentification sur un compte déclenche une alerte, rapprochée des connexions récentes de ce compte : appareil connu ou non, lieu habituel ou non, flux utilisé. Une méthode ajoutée dans l’heure qui suit une authentification par device code depuis un appareil inconnu n’est pas une coïncidence, c’est le signal qui ouvre le ticket.

La règle de boîte et le consentement applicatif

Une règle qui déplace les réponses d’un fournisseur vers un dossier obscur n’a besoin d’aucune authentification pour continuer à fonctionner : elle vit dans la boîte, pas dans la session. Une application tierce à laquelle le compte a consenti garde son accès jusqu’à ce que le consentement soit retiré. Ces deux éléments survivent eux aussi au changement de mot de passe, et ils survivent même à la révocation des sessions. Ils se cherchent et se retirent un par un.

Chronologie et traces

La chronologie ci-dessous est reconstituée pour l’illustration. À chaque phase correspond au moins une trace exploitable, à condition que les journaux soient conservés assez longtemps et qu’ils soient lus.

Phase	Ce qui se passe	Trace à chercher
J0, matin	Réception du message contenant le code et le lien officiel	Journal de la messagerie (message entrant, expéditeur, lien)
J0, quelques minutes plus tard	Saisie du code, validation MFA, émission des jetons	Journaux de connexion : authentification de type device code, appareil et localisation inhabituels
J0, dans l’heure	Lecture de la boîte et des documents	Audit unifié : accès à la boîte, consultations et téléchargements de fichiers
J0, dans l’heure	Ajout d’une méthode d’authentification, création d’une règle de boîte, consentement applicatif	Audit des méthodes d’authentification, audit de messagerie (règles), audit des consentements
J0, deux heures plus tard	L’utilisateur, alerté par un collègue, change son mot de passe	Journal des changements de mot de passe ; la session de l’attaquant continue
J1 à J3	Reprise d’un échange de facturation, envoi d’une fausse facture	Journal des messages envoyés, destinataires, objets
J2 à J5	Vague d’hameçonnage vers les contacts, avec un nouveau code d’appareil	Volume de messages sortants, plaintes des destinataires

Deux remarques sur ce tableau. D’abord, les délais sont ceux d’un scénario type : certaines compromissions se déroulent en moins d’une heure, d’autres sommeillent plusieurs semaines. Ensuite, la trace la plus précoce et la plus nette est l’authentification par device code elle-même, suivie de près par l’ajout d’une méthode d’authentification : c’est sur ces deux événements que la détection doit se jouer, pas sur la fausse facture.

Détection et blocage immédiat par le SOC

Dans notre fonctionnement, trois signaux remontent au SOC managé sans attendre qu’un utilisateur s’en aperçoive : une authentification par device code sur un compte qui n’en a jamais fait, depuis un appareil et un lieu inhabituels ; l’ajout d’une méthode d’authentification ou d’un consentement applicatif peu après une connexion suspecte ; la création d’une règle de boîte qui déplace ou supprime des messages. La séquence de confinement est la suivante, dans cet ordre.

1. Révocation de toutes les sessions et de tous les jetons du compte : l’attaquant perd l’accès dès que les applications redemandent un jeton, en quelques minutes pour les applications compatibles avec l’évaluation continue, au plus tard à l’expiration du jeton en cours pour les autres.
2. Désactivation du compte ou réinitialisation du mot de passe, selon la décision prise avec le responsable du compte côté client, et retrait immédiat des méthodes d’authentification ajoutées pendant la fenêtre suspecte.
3. Isolation du poste de l’utilisateur si un vol de jeton local est suspecté. Le scénario device code ne passe pas par le poste, mais le doute se lève après, pas avant.
4. Ouverture du ticket d’incident et information du responsable du compte côté client, avec l’heure de détection et l’heure de confinement.

Les délais entre détection et confinement sont mesurés et conservés : ce sont des éléments de preuve pour un audit, et ils figurent dans le compte rendu d’incident remis au client.

Checklist post-blocage ITAIA

Une fois l’accès coupé, le travail commence. La liste ci-dessous est celle que nous déroulons, présentée par catégorie de contrôle. Elle ne détaille pas nos procédures internes.

• Sessions et identifiants : confirmer la révocation, vérifier qu’aucune nouvelle session n’est apparue, changer les secrets qui auraient pu être lus dans la boîte.
• Méthodes d’authentification : lister les méthodes enregistrées, retirer toute méthode ajoutée pendant la fenêtre suspecte, faire ré-enregistrer l’utilisateur, vérifier que la réinitialisation en libre-service n’a pas été utilisée.
• Règles de boîte et transferts : chercher les règles créées ou modifiées, les transferts vers l’extérieur, les déplacements vers des dossiers obscurs ; les supprimer après capture.
• Consentements applicatifs : lister les applications autorisées par le compte, révoquer celles qui sont apparues pendant la fenêtre suspecte ou qui demandent un accès à la boîte sans justification.
• Mails envoyés et destinataires touchés : reconstituer la liste des messages sortants pendant la fenêtre, identifier les destinataires internes et externes, préparer la communication.
• Documents consultés ou partagés : reconstituer les accès aux fichiers et les partages créés, révoquer les liens de partage anormaux.
• Recherche des mêmes indicateurs sur les autres comptes : adresses IP, appareils, applications et règles identiques sur l’ensemble du tenant ; un attaquant qui réussit une fois réessaie sur les voisins.
• Décision de notification : avec le responsable du compte côté client, décider qui prévenir (destinataires des faux messages, partenaires, banque), et vérifier les obligations réglementaires de notification si des envois vers des tiers ont eu lieu.
• Volet exclusion : le compte était-il exclu des politiques d’accès conditionnel ? Depuis quand ? Par qui ? Cette question est traitée plus bas.

Ce qui ferme le chemin

Deux contrôles rendent ce scénario inopérant dans notre configuration standard, sauf exception documentée.

Le premier est le blocage du flux device code par l’accès conditionnel. Un tenant d’entreprise de la finance régulée n’a presque jamais besoin de ce flux : les écrans de salle de réunion et les outils en ligne de commande, quand ils existent, se traitent par exception nominative et horodatée. Bloqué par défaut, le code que l’utilisateur saisit ne produit aucun jeton, même après un MFA réussi. La politique se pose d’abord en mode rapport seul, le temps de vérifier dans les journaux de connexion qui utilise réellement ce flux, puis elle bloque.

Le second est la restriction du consentement applicatif, avec approbation par un administrateur. Un utilisateur ne peut plus autoriser seul une application tierce à lire sa boîte : la demande remonte, elle est examinée, elle est acceptée ou refusée. La porte de persistance la plus utilisée se referme.

À ces deux contrôles s’ajoute la supervision des méthodes d’authentification décrite plus haut, qui ne ferme pas le chemin mais raccourcit la fenêtre entre la compromission et le confinement.

Nous écrivons « bloqué dans notre configuration standard, sauf exception documentée », et jamais « impossible ». Une configuration vit : elle est modifiée pour un besoin métier, un test, une migration. C’est tout l’objet de la section suivante.

Exclusions et dérives de configuration

La règle que nous appliquons, et que nous demandons au client de partager, est la suivante.

• Une exclusion d’un compte des politiques d’accès conditionnel est acceptable si elle est documentée et horodatée : justification, responsable, date d’expiration, revue périodique.
• Toute exclusion non documentée ressort comme dérive lors du contrôle hebdomadaire des configurations.
• Les comptes d’urgence sont mentionnés à part, avec leurs compensations : surveillance renforcée, alerte à chaque connexion.
• Si l’exclusion n’est pas la cause avérée du cas, elle est présentée comme hypothèse plausible, pas comme fait.
• Le contrôle des configurations est hebdomadaire. Nous ne promettons pas une détection « en temps réel » des dérives.

Dans le scénario de ce dossier, l’hypothèse la plus plausible est qu’un compte a été exclu de la politique bloquant le device code pour un besoin ponctuel, et que l’exclusion n’a jamais été levée. C’est une hypothèse : les journaux de configuration permettent de la confirmer ou de l’écarter, à condition d’avoir conservé l’historique des changements.

Ce qu’un dirigeant peut demander à son prestataire

Cinq questions, dont les réponses s’écrivent en une ligne chacune. Une réponse vague à l’une d’elles mérite une seconde question.

1. Le flux device code est-il bloqué sur notre tenant, et depuis quand ?
2. Un utilisateur peut-il autoriser seul une application tierce à lire sa boîte ?
3. Qui est prévenu, et en combien de temps, quand une méthode d’authentification est ajoutée sur un compte ?
4. Quelles exclusions aux politiques d’accès existent aujourd’hui, et qui les a signées ?
5. En cas de compromission, qui a le droit de révoquer les sessions d’un compte à trois heures du matin, et où ce droit est-il écrit ?

Limites : ce que les journaux établissent et n’établissent pas

Il faut être honnête sur la portée des traces.

• L’audit unifié trace les actions effectuées (connexion, création de règle, consentement, envoi), pas la livraison des messages reçus par la victime : savoir qui a lu quoi côté destinataire relève d’autres sources.
• L’accès au carnet d’adresses et aux contacts n’est pas toujours tracé finement : un attaquant peut avoir lu des contacts sans que l’audit le dise explicitement.
• Les téléchargements de documents sont tracés, mais un contenu affiché à l’écran et photographié ne l’est pas.
• La durée de conservation des journaux dépend des licences du tenant : un incident découvert tard peut avoir perdu ses premières traces.

Pour ces raisons, nous écrivons dans un compte rendu « les journaux n’établissent pas l’exfiltration » plutôt que « il n’y a pas eu d’exfiltration ». La nuance compte pour le dirigeant qui décide d’une notification, et pour le RCCI qui documente l’incident.

Conclusion : prévenir, maintenir, détecter, contenir, prouver

Le chemin décrit ici se ferme avec deux contrôles connus. Il reste ouvert dans beaucoup d’organisations parce que la configuration a dérivé, parce qu’une exception n’a pas été levée, ou parce que personne ne lit les journaux de connexion. Prévenir ne suffit donc pas : il faut maintenir la configuration dans le temps, détecter l’authentification anormale et la méthode ajoutée, contenir vite en révoquant les sessions plutôt qu’en changeant un mot de passe, et pouvoir prouver chacune de ces étapes.

Le risque résiduel existe et nous l’assumons : aucune configuration ne garantit zéro compromission. Ce que nous garantissons, c’est que le chemin le plus fréquent est fermé par défaut, que les exceptions sont connues, et qu’une ouverture non prévue ressort au contrôle suivant.

Je m’arrête ici, sur la chronologie et le confinement. La suite, le plan de durcissement de Microsoft 365 couche par couche et le contrôle des dérives dans le temps, je la laisse à Evan, qui tient ce socle au quotidien : c’est la deuxième partie de ce dossier : poser le standard, mesurer face au marché, comparer posé et souhaité.

Sources

• Microsoft Learn, Authentication flows as a condition in Conditional Access policy : le flux device code qualifié de méthode à haut risque, la recommandation de le bloquer partout où c’est possible, le mode rapport seul.
• Microsoft Learn, Revoke user access in an emergency in Microsoft Entra ID : durée de vie d’une heure des jetons d’accès, jetons de session des applications, révocation des sessions, évaluation continue de l’accès.