Vol de jetons Microsoft 365 : pourquoi la MFA ne suffit plus contre les attaques AiTM

La MFA peut réussir et la session être compromise quand même

La MFA protège très bien contre un mot de passe volé utilisé seul. Elle ne garantit toutefois pas que le navigateur affiché à l’utilisateur parle directement à Microsoft. Dans une attaque adversary-in-the-middle — souvent abrégée AiTM — un site malveillant agit comme mandataire entre la victime et la vraie page de connexion Microsoft 365.

L’utilisateur saisit son mot de passe et approuve la MFA sur l’infrastructure légitime de Microsoft. Le service émet ensuite une session authentifiée. Le mandataire malveillant capture l’artefact de session qui transite par lui et peut le rejouer. Du point de vue de Microsoft 365, la MFA a bel et bien été satisfaite; l’attaquant ne tente pas de la deviner, il réutilise le résultat de la connexion.

C’est pourquoi le bon message n’est pas « la MFA ne sert plus ». Elle reste essentielle, mais il faut compléter la MFA traditionnelle avec une authentification résistante à l’hameçonnage, des appareils gérés, des jetons liés au matériel, des signaux de risque et un processus de révocation réellement testé.

• Microsoft — Guide d’intervention contre le vol de jetons ↗
• Microsoft — Protéger les jetons dans Microsoft Entra ↗

Ce que le mandataire AiTM intercepte réellement

Un jeton n’est pas le mot de passe. C’est un artefact limité par une audience, des permissions et une durée de vie, utilisé par un client ou une application après l’authentification. Une session Microsoft 365 peut en contenir plusieurs : cookie de connexion Entra, cookie propre à l’application, jeton d’accès, jeton d’actualisation et, sur un appareil Windows joint, Primary Refresh Token (PRT).

Le type capturé détermine la portée et la réponse. Un jeton d’accès donne accès à une ressource jusqu’à son expiration ou son rejet. Un jeton d’actualisation peut demander de nouveaux jetons. Un cookie d’application peut rester valide selon les règles de cette application, même après une action dans Entra. Microsoft rappelle qu’Entra ne peut pas directement révoquer un cookie créé et contrôlé par une application tierce.

• Microsoft — Révoquer l’accès d’un utilisateur en urgence ↗
• Microsoft — Comprendre le Primary Refresh Token ↗

MFA traditionnelle et MFA résistante à l’hameçonnage ne sont pas équivalentes

Une notification push, un code TOTP, un SMS ou un appel confirme qu’un deuxième facteur a été présenté. Dans un flux AiTM, le site malveillant peut transmettre cette étape en temps réel vers Microsoft et récupérer la session qui en résulte. La correspondance de numéro réduit les approbations aveugles, mais elle ne lie pas cryptographiquement l’authentification au vrai domaine visité.

Les passkeys FIDO2, les clés de sécurité et Windows Hello for Business utilisent une clé associée au domaine du service. L’authentificateur ne produit pas une réponse valide pour un faux domaine. Microsoft classe aussi l’authentification par certificat configurée comme multifacteur dans sa force intégrée Phishing-resistant MFA.

Cette résistance protège la cérémonie de connexion. Elle n’empêche pas un logiciel malveillant installé sur un poste déjà connecté de tenter d’extraire un jeton ou de piloter la session locale. Il faut donc associer identité résistante, santé de l’appareil et protection contre le rejeu.

• Microsoft — Forces d’authentification Conditional Access ↗
• Guide connexe — Déployer les passkeys avec Microsoft Entra ID →

Les sept contrôles qui changent réellement le risque

Aucun de ces contrôles ne couvre tout seul le navigateur, les clients natifs, les appareils personnels et les applications tierces. La priorité dépend de la population : commencez par les administrateurs, la finance, les ressources humaines, les personnes visibles publiquement et les comptes ayant accès à de grandes quantités de courriels ou de fichiers.

• Exiger une force d’authentification résistante à l’hameçonnage pour les administrateurs et les applications sensibles.
• Autoriser les données sensibles seulement depuis des appareils conformes ou Microsoft Entra hybrid joined lorsque le scénario le permet.
• Activer Token Protection par vagues pour les plateformes, applications et ressources prises en charge.
• Déployer Microsoft Defender for Endpoint, la protection réseau, la protection infonuagique et la protection contre les altérations.
• Utiliser les politiques de risque d’Entra ID Protection et exporter les journaux de connexion, de risque et d’audit vers un SIEM.
• Conserver Continuous Access Evaluation et comprendre quelles applications ne réévaluent pas encore les événements critiques.
• Tester la réponse : blocage du compte, révocation, isolement du poste, recherche de persistance et restauration contrôlée.

Imposer la bonne force d’authentification avec Conditional Access

Créez une politique Conditional Access pour les rôles d’administration et ciblez All resources. Dans Grant, choisissez Require authentication strength, puis Phishing-resistant MFA. Excluez uniquement les comptes d’urgence prévus et testés. Microsoft recommande de commencer en Report-only et d’examiner les connexions avant de passer la politique à On.

Ne bloquez pas l’inscription avant que les utilisateurs disposent d’une méthode compatible. Distribuez d’abord des passkeys, clés FIDO2, Windows Hello for Business ou certificats adaptés, avec Temporary Access Pass pour l’amorçage. Étendez ensuite la force aux applications sensibles et aux autres groupes prêts.

Pour une action très sensible, comme activer un rôle PIM ou consulter un site SharePoint confidentiel, utilisez un authentication context afin de demander une authentification forte au moment de l’action. Cela évite de multiplier les invites partout tout en protégeant le geste qui compte.

• Microsoft — Exiger une MFA résistante à l’hameçonnage pour les administrateurs ↗
• Microsoft — Planifier un déploiement passwordless résistant à l’hameçonnage ↗

L’appareil conforme empêche une session volée de devenir un poste de travail

Une politique qui exige un appareil marqué conforme ajoute une preuve que le poste est connu, chiffré, corrigé et sous contrôle selon vos règles Intune. Elle empêche de nombreux jetons rejoués depuis une machine inconnue d’accéder aux ressources ciblées. Pour les administrateurs, combiner appareil conforme et authentification résistante est nettement plus robuste qu’ajouter simplement davantage d’invites MFA.

La conformité n’est utile que si ses critères sont réels. Intégrez le niveau de risque Microsoft Defender for Endpoint, le chiffrement, le pare-feu et une version minimale du système. Un appareil enregistré mais non géré ne devrait pas être considéré comme équivalent à un appareil conforme.

Les invités, BYOD, appareils mobiles et scénarios d’urgence demandent des chemins séparés. Utilisez les politiques de protection des applications, des restrictions de session ou un accès Web limité au lieu de créer une exclusion permanente qui contourne toute la politique.

• Microsoft — Exiger la conformité de l’appareil avec Conditional Access ↗
• Microsoft — Conditional Access et conformité Intune ↗

Token Protection lie la session à l’appareil, avec des limites à respecter

Token Protection est un contrôle de session Conditional Access qui exige des jetons de connexion liés cryptographiquement à l’appareil. Un artefact exporté ne peut alors pas être utilisé depuis une autre machine prise en charge. La fonctionnalité demande Microsoft Entra ID P1 et doit être validée en Report-only avant l’application.

Le support des applications natives est généralement disponible sur Windows, iOS/iPadOS et macOS, mais les matrices diffèrent. Sur Windows, Microsoft répertorie notamment Outlook, Teams, OneDrive, Word, Excel, PowerPoint, Windows App et certains modules PowerShell; les ressources prises en charge comprennent Exchange Online, SharePoint Online, Teams, Azure Virtual Desktop et Windows 365.

Ne supposez pas que tous les navigateurs et toutes les applications SaaS sont couverts. Le support Web demeure limité à certains scénarios en préversion qui accèdent à Azure Resource Manager. Des clients perpétuels, de vieilles versions, certains types d’inscription d’appareil et des extensions peuvent être bloqués. Mesurez Token Protection - Sign In Session et tokenProtectionStatusDetails dans les journaux avant d’imposer la politique.

• Microsoft — Vue d’ensemble de Token Protection ↗
• Microsoft — Guide de déploiement Token Protection sur Windows ↗

CAE accélère la révocation; raccourcir toutes les sessions n’est pas la solution

Continuous Access Evaluation permet à Exchange Online, SharePoint Online, Teams et à certains clients de réagir à des événements critiques avant l’expiration normale du jeton : compte désactivé, mot de passe réinitialisé, révocation explicite ou risque utilisateur élevé. Microsoft vise une réaction presque en temps réel, avec une latence pouvant atteindre environ 15 minutes pour la propagation de certains événements.

CAE ne couvre pas toutes les combinaisons de clients et de ressources. Une application qui maintient son propre cookie peut aussi conserver la session selon sa politique. Le plan d’intervention doit donc inclure la révocation dans les applications concernées, pas seulement Revoke sessions dans Entra.

Forcer une MFA chaque heure partout augmente la fatigue et habitue les gens à répondre aux invites. Microsoft avertit qu’une réauthentification trop fréquente peut rendre les utilisateurs plus vulnérables aux faux écrans. Réservez Sign-in frequency aux applications, risques et appareils qui le justifient; privilégiez SSO sur appareils gérés, CAE et réauthentification interactive pour les actions sensibles.

• Microsoft — Continuous Access Evaluation ↗
• Microsoft — Invites MFA et durée des sessions ↗

Détecter le rejeu avec le risque d’identité et les journaux

Entra ID Protection expose notamment Anomalous token, Attacker in the Middle, propriétés de connexion inconnues, adresse IP malveillante et tentative d’accès au PRT. Un événement non interactif depuis un nouvel ASN, un appareil vide ou un pays inattendu mérite plus d’attention qu’une simple connexion interactive échouée.

Microsoft indique que certaines détections liées au vol de jetons contenant déjà une revendication MFA ne sont plus automatiquement fermées. Les détails de risque affichent plutôt l’heure, l’IP, le client, le request ID et le correlation ID pour permettre l’enquête. Une politique de risque utilisateur doit donc être réellement configurée; posséder la licence et consulter le tableau de bord de temps en temps ne contient pas l’attaque.

Exportez SigninLogs, AADUserRiskEvents, RiskyUsers et AuditLogs vers Log Analytics ou votre SIEM. Conservez aussi Microsoft Purview Audit, les activités Exchange, SharePoint, OneDrive, Teams et Defender XDR. Une session réussie depuis une nouvelle IP devient beaucoup plus claire lorsqu’elle est suivie d’une règle de boîte, d’un consentement OAuth ou d’un téléchargement massif.

• Microsoft — Détections de risque dans Entra ID Protection ↗
• Microsoft — Traitement des détections liées au vol de jetons ↗

Deux recherches KQL pour commencer l’enquête

La première requête regroupe une même session observée depuis plusieurs réseaux, pays ou appareils. Ce n’est pas une preuve : un VPN, un réseau mobile, Global Secure Access ou un changement de sortie Internet peut produire le même motif. Utilisez-la pour créer une courte liste, puis comparez request ID, correlation ID, application, appareil, chronologie et activité métier.

La deuxième recherche concentre les connexions non interactives réussies déjà marquées risquées. Adaptez les seuils et exclusions à votre environnement, mais n’excluez jamais un réseau ou un fournisseur uniquement parce qu’il apparaît souvent; documentez la raison et surveillez les changements.

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "0" and isnotempty(SessionId)
| extend DeviceId = tostring(DeviceDetail.deviceId),
         Country = tostring(LocationDetails.countryOrRegion)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
            IPs=make_set(IPAddress, 10), ASNs=make_set(AutonomousSystemNumber, 10),
            Countries=make_set(Country, 10), Devices=make_set(DeviceId, 10),
            Apps=make_set(AppDisplayName, 10)
  by UserPrincipalName, SessionId
| where array_length(IPs) > 1
  and (array_length(ASNs) > 1 or array_length(Countries) > 1 or array_length(Devices) > 1)
| order by LastSeen desc

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0" and IsInteractive == false
| where IsRisky == true or RiskLevelAggregated in ("medium", "high")
| extend DeviceId = tostring(DeviceDetail.deviceId),
         Browser = tostring(DeviceDetail.browser),
         Country = tostring(LocationDetails.countryOrRegion)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,
          AutonomousSystemNumber, Country, DeviceId, Browser, SessionId,
          RiskLevelAggregated, RiskEventTypes_V2, ConditionalAccessStatus,
          CorrelationId, OriginalRequestId
| order by TimeGenerated desc

• Microsoft — Schéma SigninLogs ↗
• Guide connexe — Requêtes KQL Defender Advanced Hunting →

Auditer les politiques avant d’en créer de nouvelles

Commencez par exporter les politiques Conditional Access avec un compte en lecture seule. Cherchez les utilisateurs exclus, les applications non couvertes, les contrôles OR trop permissifs, les politiques désactivées et les anciens réglages de session. Comparez ensuite les résultats Report-only dans les journaux de connexion.

Une politique portant un bon nom n’est pas une preuve. Vérifiez ses cibles, son état et l’effet combiné des autres politiques. L’outil What If aide à simuler un utilisateur, une application, une plateforme et une adresse IP, mais un pilote réel reste nécessaire pour Token Protection, la conformité et les clients hérités.

Connect-MgGraph -Scopes 'Policy.Read.All'

$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | Select-Object DisplayName,State,CreatedDateTime,ModifiedDateTime,`
  Conditions,GrantControls,SessionControls |
  Export-Clixml '.\Conditional-Access-Policies.xml'

$policies | Group-Object State | Select-Object Name,Count
Disconnect-MgGraph

• Microsoft — Analyser l’impact en mode Report-only ↗
• Microsoft — Get-MgIdentityConditionalAccessPolicy ↗

Durcir le poste et le chemin qui mène à la fausse page

Les contrôles d’identité interviennent tard si l’utilisateur atteint déjà le faux domaine. Defender for Office 365 protège le courriel et la collaboration avec les politiques anti-hameçonnage et Safe Links. Defender for Endpoint Network Protection étend la réputation SmartScreen aux connexions HTTP(S) des navigateurs et applications pris en charge, ce qui peut bloquer un domaine malveillant avant la saisie du mot de passe.

Sur les postes, activez la protection en temps réel et infonuagique, Network Protection, Tamper Protection, EDR et les règles ASR pertinentes en suivant une progression Audit, Warn puis Block. La protection de l’appareil est indispensable contre le vol qui ne passe pas par AiTM : extension de navigateur malveillante, vol de cookies, accès au profil utilisateur ou tentative d’extraction du PRT.

Formez les utilisateurs à signaler une page inattendue plutôt qu’à compter les invites MFA. Un faux site peut afficher le vrai logo et la vraie MFA. Les signaux plus utiles sont l’adresse du domaine, une connexion déclenchée depuis un document ou un QR code inattendu, et une demande de s’authentifier alors que la session habituelle est déjà ouverte.

• Microsoft — Network Protection dans Defender for Endpoint ↗
• Microsoft — Protection offerte par Defender for Office 365 ↗
• Guide connexe — Déployer les règles ASR progressivement →

Répondre à un vol de jeton sans se limiter au mot de passe

Préservez d’abord les éléments volatils : heures, IP, SessionId, request ID, correlation ID, client, appareil et alertes. Si l’activité ne peut pas être confirmée rapidement, traitez-la comme compromise. Bloquez les nouvelles connexions, révoquez les sessions et isolez le poste associé. Pour un compte hybride, désactivez aussi le compte dans Active Directory et tenez compte du délai de synchronisation.

La commande Revoke-MgUserSignInSession révoque les jetons d’actualisation Entra. Les applications compatibles CAE peuvent réagir rapidement, mais les jetons d’accès et cookies d’application suivent leurs propres règles. Ouvrez les consoles des applications critiques et invalidez leurs sessions lorsque cette fonction existe.

Réinitialisez le mot de passe depuis un poste propre, examinez les méthodes MFA/passkeys enregistrées et forcez une nouvelle inscription si l’attaquant a ajouté une méthode. Ne remettez pas le compte en service avant d’avoir compris le point d’entrée et vérifié l’appareil; sinon le nouveau secret peut être repris immédiatement.

Connect-MgGraph -Scopes 'User.ReadWrite.All','Directory.ReadWrite.All'

$user = Get-MgUser -UserId 'utilisateur@contoso.com'
Update-MgUser -UserId $user.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $user.Id

# Inventorier les méthodes; ne supprimer qu’après validation.
Get-MgUserAuthenticationMethod -UserId $user.Id |
  Select-Object Id,AdditionalProperties

Disconnect-MgGraph

• Microsoft — Procédure de révocation d’urgence ↗

Chercher la persistance dans Microsoft 365 avant de restaurer l’accès

Un attaquant qui possède une session cherche souvent à conserver l’accès : règle de boîte qui supprime ou transfère les messages, transfert SMTP, délégation, application OAuth consentie, nouvelle méthode d’authentification, nouvel appareil ou rôle privilégié. Révoquer la session sans retirer ces changements laisse une porte de retour.

Examinez les activités depuis le premier signal suspect, pas seulement après l’alerte. Cherchez les lectures et téléchargements inhabituels dans Exchange, SharePoint, OneDrive et Teams, puis identifiez les destinataires ou données touchés. Si un courriel frauduleux est parti du compte, utilisez Explorer/Advanced Hunting pour retrouver les destinataires et purger les messages lorsque votre licence le permet.

• Règles de boîte visibles et cachées, transfert de boîte et adresses de redirection.
• Délégations FullAccess, SendAs et SendOnBehalf inattendues.
• Consentements OAuth utilisateur et administrateur, permissions Graph et applications nouvellement ajoutées.
• Méthodes MFA, passkeys, Temporary Access Pass, appareils enregistrés et changements de mot de passe.
• Ajouts à des rôles, activations PIM, modifications Conditional Access et exclusions.
• Téléchargements massifs, recherches, partages externes et accès à des courriels sensibles.

Connect-ExchangeOnline

Get-InboxRule -Mailbox utilisateur@contoso.com -IncludeHidden |
  Select-Object Name,Enabled,Priority,ForwardTo,RedirectTo,DeleteMessage

Get-Mailbox utilisateur@contoso.com |
  Select-Object ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Get-MailboxPermission utilisateur@contoso.com |
  Where-Object { -not $_.IsInherited -and -not $_.Deny }

Get-RecipientPermission utilisateur@contoso.com |
  Where-Object { -not $_.IsInherited }

Disconnect-ExchangeOnline -Confirm:$false

• Microsoft — Répondre à un compte de messagerie compromis ↗
• Microsoft — Enquêter sur les consentements d’application ↗

Déployer en vagues et mesurer autre chose que le nombre d’invites

Un bon déploiement réduit les sessions rejouables sans transformer la journée en suite de demandes MFA. Mesurez l’inscription aux méthodes résistantes, les connexions depuis appareils conformes, l’état Bound de Token Protection, les exceptions, les risques non traités et le temps réel de confinement lors d’un exercice.

Commencez par les comptes qui créeraient le plus grand rayon d’impact. Ajoutez ensuite les utilisateurs manipulant des paiements, des données personnelles ou des boîtes partagées, puis élargissez. Chaque vague doit comprendre un scénario de récupération et un compte d’urgence testé hors du chemin normal.

Le résultat attendu : empêcher, contenir et expliquer

La MFA reste une barrière fondamentale, mais une approbation réussie ne prouve pas que la session demeure entre les mains de l’utilisateur. Une architecture moderne protège la connexion avec des passkeys, protège l’accès avec l’état de l’appareil, protège le jeton contre le rejeu et suppose malgré tout qu’un incident devra un jour être contenu.

Un audit Microsoft 365 utile doit donc examiner ensemble les méthodes d’authentification, Conditional Access, les appareils, les sessions, les risques, les applications OAuth et la capacité d’enquête. C’est cette vue de bout en bout qui transforme une liste de politiques en protection opérationnelle.

• Les comptes privilégiés et sensibles utilisent une méthode résistante à l’hameçonnage.
• Les données critiques exigent un appareil conforme lorsque le modèle d’usage le permet.
• Token Protection est appliqué aux clients compatibles et ses limites sont documentées.
• Les politiques de risque déclenchent une action; les journaux sont exportés et conservés.
• CAE demeure actif et les applications qui gèrent leurs propres sessions sont inventoriées.
• Les protections du courriel, du navigateur et des postes réduisent l’accès aux faux sites et l’extraction locale.
• Le SOC sait relier une session à l’IP, au client, à l’appareil et aux activités Microsoft 365 qui suivent.
• Le plan d’incident couvre les sessions, méthodes MFA, consentements OAuth, règles de boîte et appareils.
• Un exercice confirme le temps de confinement et la capacité de restaurer l’utilisateur proprement.

• Service — Audit de sécurité Microsoft 365 →
• Guide connexe — Sécuriser les agents Copilot et les serveurs MCP →