Phishing Microsoft 365 malgré la MFA : vol de session

Le phishing Microsoft 365 ne se limite plus aux e-mails maladroits et aux fausses pages de connexion. Les attaques commencent dans un compte professionnel compromis, conduisent vers des pages Microsoft trompeuses ou légitimes et se terminent, malgré la MFA, dans la boîte aux lettres, SharePoint ou Teams.

Le rapport semestriel 2026/1 de l’Office fédéral de la cybersécurité concerne les entreprises suisses. Au premier semestre 2026, les signalements de comptes Microsoft 365 compromis ont augmenté. Ces comptes ont servi au phishing et à la fraude. Les attaquants se faisaient passer pour le support IT ou un membre de la direction et contournaient les contrôles à l’aide de tokens de session, du Device Code Phishing ou de Reverse Proxies.

La MFA reste indispensable. Toutes les méthodes ne résistent toutefois pas au phishing. Une session validée peut elle-même devenir la cible. Microsoft 365 doit être sécurisé comme une plateforme d’identité et pas uniquement comme un service de messagerie.

Comment le phishing Microsoft 365 fonctionne malgré la MFA

Après avoir vérifié le mot de passe, le second facteur, l’état de l’appareil et les autres conditions, Entra ID émet des tokens ou des cookies de session. À l’image d’un badge visiteur, c’est ensuite avant tout leur validité qui compte. S’ils parviennent à une autre personne, celle-ci peut, dans certaines circonstances, ne pas devoir repasser les contrôles.

Les types de tokens de Microsoft Entra ID diffèrent par leur fonction et leur durée de vie. Le point essentiel est le suivant : un token volé ou accordé à l’attaquant peut représenter une session authentifiée.

Phishing Adversary-in-the-Middle avec Reverse Proxy

Dans une attaque Adversary-in-the-Middle (AiTM), l’infrastructure de phishing s’intercale entre le navigateur et Microsoft et relaie la connexion réelle en temps réel :

1. Un e-mail renvoie par exemple vers un document SharePoint, un message vocal, une facture ou une demande de signature.
2. Le lien transmet la connexion Microsoft via le Reverse Proxy de l’attaquant.
3. Le nom d’utilisateur, le mot de passe et la réponse MFA sont relayés à Microsoft.
4. Microsoft accepte la connexion confirmée et établit la session.
5. Le proxy intercepte le cookie de session ou les tokens. L’accès ne prend fin qu’à leur expiration, leur révocation ou leur blocage.

La MFA n’a pas été cassée. L’utilisateur a validé une session observée par l’attaquant. Les codes TOTP et les validations Push n’empêchent pas fondamentalement ce relais. Les clés FIDO2, Windows Hello for Business et les Passkeys correctement déployés lient en revanche la connexion de façon cryptographique au service légitime. Même ces méthodes ne protègent pas contre un malware sur un appareil déjà connecté ni contre toutes les formes de vol de session.

Device Code Phishing via une page Microsoft authentique

Le Device Code Flow est prévu pour les appareils qui ne permettent pas une saisie confortable. Un équipement de salle de conférence ou un outil en ligne de commande affiche un code, qui est validé sur un second appareil via Microsoft.

Les attaquants lancent eux-mêmes ce processus et transmettent le code sous un prétexte. Après sa saisie sur la véritable page Microsoft, les tokens sont délivrés à leur session. Le domaine et le certificat sont corrects, mais c’est une connexion tierce qui est autorisée. Microsoft considère ce Flow comme risqué et recommande de le bloquer en l’absence de besoin documenté.

Déluge d’e-mails, faux support IT et phishing en chaîne

Une chaîne d’attaque peut commencer par des centaines d’e-mails de newsletters, d’inscriptions et de notifications. Ils créent du stress et masquent de véritables avertissements. Un faux support IT contacte ensuite la victime via Teams ou par téléphone et demande l’utilisation de Quick Assist ou d’un outil d’assistance à distance. Il peut ainsi exécuter des commandes, installer un malware, lire des données du navigateur et voler des identifiants. C’est le poste de travail qui est compromis, pas la connexion.

Après la prise de contrôle, l’attaquant exploite de véritables correspondances, des fournisseurs connus et l’historique des conversations pour envoyer des factures manipulées, poursuivre le phishing et compromettre d’autres comptes. SPF, DKIM et DMARC ne suffisent pas lorsque le message provient du tenant Microsoft 365 légitime.

Ce que fait la MFA et où se situent ses limites

La MFA empêche de nombreuses compromissions de compte, car le mot de passe ne suffit plus. Les méthodes diffèrent toutefois :

• Mot de passe plus SMS, appel ou simple validation Push : mieux qu’un mot de passe seul, mais vulnérable au Social Engineering, au SIM-Swapping, à la MFA-Fatigue et au phishing en temps réel.
• TOTP ou Authenticator avec Number Matching : plus robuste face aux validations accidentelles, mais un code peut être immédiatement relayé depuis une page AiTM.
• Authentification résistante au phishing : FIDO2, Windows Hello for Business, l’authentification par certificat et les Passkeys vérifient cryptographiquement le service légitime et réduisent fortement les connexions AiTM.

Des risques subsistent : un Endpoint infecté peut lire les sessions, une application OAuth peut obtenir des autorisations durables et un utilisateur peut valider des Device Codes ou des accès à distance tiers. Une MFA résistante au phishing est centrale, mais ne constitue pas à elle seule un concept de sécurité complet.

Renforcer Microsoft Entra ID de manière pertinente

Conditional Access et Token Protection nécessitent des licences Entra adaptées, tandis que les conditions liées aux appareils supposent un parc géré. Les politiques doivent d’abord être testées en mode Report-only avec un groupe pilote.

Prioriser l’authentification résistante au phishing

Le premier déploiement doit couvrir les administrateurs, les responsables financiers, la direction et le Helpdesk. Les Conditional Access Authentication Strengths peuvent y imposer Windows Hello for Business, des clés FIDO2, des Passkeys ou l’authentification par certificat.

Il faut également un processus de Recovery comprenant au moins deux méthodes enregistrées, des appareils de remplacement vérifiés et des comptes d’urgence surveillés séparément. La perte d’une clé ne doit entraîner ni une longue interruption ni des exceptions Helpdesk faciles à manipuler. Les Passkeys conviennent aussi à la connexion à Sophos Central, mais le Recovery et le changement d’appareil doivent également être planifiés.

Vérifier et, si possible, bloquer le Device Code Flow

Son utilisation peut être inventoriée dans les Entra Sign-in Logs via Authentication protocol > Device code. Des équipements de salle de conférence, des outils anciens ou des applications en ligne de commande peuvent en dépendre. En l’absence de besoin justifié, une politique est créée sous Entra ID > Conditional Access > Policies :

1. Sélectionner les utilisateurs ou groupes réguliers.
2. Exclure les comptes d’urgence et les exceptions techniques justifiées.
3. Sous Target resources, sélectionner si possible All resources et ne choisir des cibles plus étroites qu’avec justification.
4. Sous Conditions > Authentication flows, activer Device code flow.
5. Sous Grant, bloquer l’accès.
6. Utiliser d’abord Report-only, examiner les Logs, puis activer la politique.

Les exceptions doivent être strictement limitées, documentées et affectées à des comptes ou ressources précis.

Lier l’accès aux appareils gérés

Conditional Access peut exiger un appareil conforme ou joint à Microsoft Entra pour les applications sensibles. Cela complique l’utilisation abusive de tokens sur des appareils inconnus, mais affecte aussi le BYOD, les invités, les appareils mobiles et les clients spéciaux. Il faut donc connaître le parc, les systèmes d’exploitation et les applications. Des entrées obsolètes, un Enrollment faible ou des exceptions trop larges affaiblissent le contrôle.

Tester Token Protection de manière ciblée

Token Protection lie cryptographiquement les Sign-in-Session-Tokens pris en charge à l’appareil qui les a reçus et complique leur Replay sur d’autres systèmes. Cette fonction nécessite Entra ID P1 et ne couvre que certaines plateformes, applications et ressources. Sous Windows, elle protège surtout les applications Microsoft 365 natives compatibles. Les appareils Apple nécessitent une gestion et le Microsoft Enterprise SSO Plug-in. Les applications Mail et Calendrier d’Apple ne prennent actuellement pas en charge Token Protection.

Le déploiement commence sur un périmètre restreint en Report-only. Les Token Protection Status Details, les clients et les ressources sont ensuite contrôlés dans les Sign-in Logs. L’application de la politique ne suit qu’après confirmation de la compatibilité. Les navigateurs, les logiciels anciens et les appareils spéciaux sont évalués séparément.

Contrôler Teams et l’assistance à distance

Il faut définir quels domaines ou tenants externes peuvent contacter les utilisateurs via Teams et comment les participants externes sont identifiés. Pour le support :

• Une assistance à distance ne démarre qu’avec un ticket ou un rappel vérifié vers un numéro connu.
• Les sessions Quick Assist inattendues provenant de Chats ou d’appels ne sont pas acceptées.
• Les outils d’assistance à distance autorisés sont documentés et surveillés.
• Les outils RMM inconnus sont bloqués ou signalés par Application Control, AppLocker, Windows Defender Application Control ou des contrôles comparables.
• Un déluge inhabituel d’e-mails est signalé à l’IT ou à la Security et n’est pas traité comme du simple Spam.

L’Awareness doit refléter ces processus. Sophos Phish Threat gagne en efficacité avec des voies de signalement claires, des scénarios Teams et un Helpdesk-Runbook réaliste.

Quelles traces les administrateurs doivent vérifier

Un événement MFA réussi ne prouve pas qu’une connexion est légitime. Lors d’une attaque AiTM ou Device Code, le facteur a peut-être été validé par l’utilisateur lui-même. L’identité, la boîte aux lettres, l’Endpoint et les communications doivent être examinés ensemble.

Microsoft Entra Sign-in Logs

Les journaux se trouvent sous Entra ID > Monitoring & health > Sign-in logs et sont accessibles à partir du rôle Reports Reader. Selon les soupçons, l’analyse doit inclure les connexions interactives et non interactives, les Service Principals et les Managed Identities. Les éléments pertinents sont :

• les appareils inconnus ou non conformes ainsi que les IP, régions, applications et clients inhabituels,
• Device code comme Authentication Protocol,
• de nouvelles combinaisons de navigateurs ou d’appareils après une connexion normale,
• des accès inhabituels à Exchange Online, SharePoint ou Microsoft Graph,
• le résultat de Conditional Access, les exigences d’authentification remplies et
• les accès réussis sans interaction utilisateur attendue grâce à des tokens existants.

Un signal isolé ne suffit pas. Une IP suisse peut appartenir à un réseau mobile ou à un VPN, et une connexion depuis l’étranger peut être professionnelle. C’est la combinaison de l’utilisateur, de l’appareil, de l’heure, de l’application et de l’activité consécutive qui compte.

Exchange Online, Audit et Endpoint

Après une compromission, les attaquants recherchent souvent des factures et des historiques de conversation. Il faut contrôler les transferts internes et externes, les Inbox Rules visibles et masquées, les délégations et droits Send-as, les activités inhabituelles de recherche, de lecture, de téléchargement et d’envoi, les nouveaux consentements OAuth et Enterprise Applications, les méthodes d’authentification modifiées ainsi que tous les messages envoyés dans la période concernée.

Lors d’un faux support IT, les traces se trouvent sur l’Endpoint : logiciels d’assistance à distance, téléchargements, PowerShell, MSHTA, tâches planifiées, accès au navigateur et processus suspects. L’Email Security, l’Endpoint Protection ainsi que XDR ou MDR peuvent les bloquer et les corréler si les sources de données sont licenciées, intégrées et surveillées. La stratégie Sophos Fusion y contribue, mais ne remplace ni Conditional Access ni le processus d’incident.

La durée de conservation et le niveau de détail des données d’Audit dépendent de la licence et de la configuration. Ces deux points doivent être clarifiés au préalable, car des Logs activés après l’incident ne créent aucun historique.

Plan d’urgence pour un compte Microsoft 365 compromis

Changer le mot de passe ne suffit pas. Des sessions, des méthodes MFA tierces, des consentements OAuth et des règles de boîte aux lettres peuvent subsister.

1. Utiliser un appareil d’administration sain

Si une compromission de l’Endpoint est possible, le changement de mot de passe et l’administration s’effectuent depuis un autre appareil. Le système affecté est isolé sans effacement prématuré des traces. En cas d’attaque en cours ou de compte privilégié, une désactivation temporaire peut être pertinente.

2. Révoquer les sessions actives

Les sessions peuvent être révoquées dans l’Entra Admin Center ou avec Microsoft Graph PowerShell :

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@example.com

Le User Principal Name doit être adapté. Selon l’application, le type de token et Continuous Access Evaluation, l’accès peut persister brièvement. Le résultat doit donc être contrôlé dans les Logs et les applications.

3. Nettoyer le mot de passe et l’authentification

Le mot de passe est modifié dans la source d’identité principale et, pour les comptes synchronisés ou fédérés, dans l’Active Directory local ou l’Identity Provider. Les méthodes MFA, Passkeys, numéros de téléphone, appareils et Temporary Access Passes sont ensuite contrôlés, et les entrées tierces supprimées. En cas de malware ou d’accès à distance, l’Endpoint est examiné en parallèle et reconstruit si nécessaire.

4. Vérifier les consentements OAuth et les rôles

Les consentements utilisateur, Enterprise Applications et Service Principals suspects peuvent permettre un accès durable. Pour les comptes privilégiés, les rôles Entra, Azure et Microsoft 365 doivent également être contrôlés.

5. Vérifier les transferts et les Inbox Rules

Exchange Online PowerShell affiche les principaux paramètres de la boîte aux lettres :

Get-Mailbox -Identity user@example.com |
  Format-List Forwarding*Address,DeliverTo*

Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

Les règles suspectes sont documentées et supprimées. Les délégations, droits Send-as et règles de transport administratives sont contrôlés séparément.

6. Identifier et informer les victimes suivantes

Message Trace et les données d’Audit indiquent les messages envoyés. Les destinataires internes et externes sont informés avant que des liens, paiements ou autres comptes ne soient affectés. En cas de modification de flux de paiement, la banque, la comptabilité et les partenaires commerciaux sont contactés par des canaux connus. D’autres mesures figurent dans l’article consacré aux mesures immédiates en cas de phishing et de piratage.

7. Déterminer la cause et l’étendue

Enfin, il faut établir si AiTM, Device Code, une MFA validée ou une assistance à distance ont joué un rôle, quels fichiers SharePoint ou OneDrive ont été exfiltrés, si d’autres comptes, applications ou appareils ont été enregistrés et si des données personnelles ou des secrets d’affaires sont concernés. Sans analyse des causes, la faille reste ouverte.

Liste pratique pour les administrateurs Microsoft 365

• Prioriser l’authentification résistante au phishing pour les administrateurs, les finances, la direction et le Helpdesk.
• Séparer, surveiller et tester régulièrement les comptes d’urgence.
• Inventorier l’utilisation du Device Code, la bloquer ou documenter les exceptions justifiées.
• Tester Conditional Access en Report-only avec un groupe pilote.
• Exiger des appareils gérés pour les ressources sensibles et ne déployer Token Protection qu’avec des clients compatibles.
• Définir de manière contraignante les règles de communication Teams externe, les outils d’assistance à distance, le rappel Helpdesk et la vérification d’identité.
• Déclencher des alertes sur les déluges d’e-mails, les connexions inhabituelles, les consentements OAuth et les transferts.
• Tester la révocation de sessions, le nettoyage MFA, les Inbox Rules, les traces d’envoi et l’isolation des Endpoints.
• Clarifier la conservation des données d’Audit et les responsabilités avant l’incident.

Notre recommandation

La MFA reste obligatoire, mais l’association d’un mot de passe et d’une application Push ne tient pas suffisamment compte des attaques modernes. Les comptes privilégiés et financièrement critiques doivent devenir résistants au phishing en priorité. Viennent ensuite le contrôle du Device Code, les appareils gérés et Conditional Access. En raison de ses limites, Token Protection exige un déploiement contrôlé. En parallèle, le Helpdesk a besoin de processus sûrs pour les contacts Teams inattendus.

La protection repose sur l’association d’une identité forte, d’un appareil de confiance, d’une session contrôlée, de communications surveillées et d’un plan d’urgence couvrant les tokens actifs et la persistance masquée.

FAQ