Fin mars 2026, plus de 340 organisations se sont fait compromettre sur Microsoft 365. Le point d’entrée : un simple code à 8 caractères tapé sur une page Microsoft légitime. Selon les informations rapporté l’éditeurs de solutions de cybersécurité Huntress, les groupes Storm-2372 et APT29, liés à la Russie, ont exploité le flux d’authentification « device code » pour voler des tokens d’accès, MFA compris. Pour les MSP, le sujet est critique : ces usages sont rarement maîtrisés, et les configurations par défaut laissent souvent la porte ouverte.
Voici un plan d’action en 10 étapes pour verrouiller les tenants de vos clients.
Ce qui s’est passé
Le 25 mars 2026, les équipes de Huntress identifient une campagne active ciblant des environnements Microsoft 365, reposant sur une technique encore peu connue : le device code phishing. Le mode opératoire tranche avec les campagnes classiques. Aucun lien frauduleux, aucun fichier piégé.
Les attaquants envoient un message par email, Microsoft Teams ou SMS contenant un code d’authentification et un prétexte crédible (accès à une application, onboarding sur un outil, validation d’un compte) du type « Validez votre accès à la nouvelle plateforme projet ».
La victime est invitée à se rendre sur la page officielle de Microsoft dédiée à l’authentification par code (microsoft.com/devicelogin).
Elle saisit le code, puis s’authentifie normalement, MFA inclus.
À ce stade, aucune anomalie apparente : tout se déroule sur une infrastructure légitime, avec un parcours utilisateur conforme.
En réalité, cette action permet aux attaquants de récupérer des jetons d’accès (access tokens) et de renouvellement (refresh tokens), leur ouvrant un accès persistant au compte compromis.
Pourquoi c’est un problème majeur pour les MSP ? Parce que tout est légitime aux yeux des outils de sécurité. Le domaine est celui de Microsoft. Le MFA est validé par l’utilisateur lui-même. Aucun filtre anti-phishing ne se déclenche. Seul un durcissement du tenant peut bloquer ce vecteur.
Le plan d’action : 3 niveaux, 10 règles
Toutes les mesures n’ont pas le même niveau d’effort ni le même impact opérationnel. Nous les avons structurées en trois paliers, selon le temps de déploiement attendu côté MSP.
- Palier 1 : actions immédiates, déployables en moins d’une heure par tenant
- Palier 2 : mesures de durcissement avancé, nécessitant quelques ajustements
- Palier 3 : logique de détection et de surveillance active
Le premier palier répond à un objectif clair : fermer les portes les plus évidentes, exploitées aujourd’hui par les attaquants.
Palier 1 — Fermer la porte (moins d’une heure par tenant)
1. Bloquer le flux device code dans Conditional Access
C’est la mesure prioritaire. Rendez-vous dans Entra ID → Protection → Conditional Access. Créez une policy ciblant tous les utilisateurs. Dans les conditions, sélectionnez Authentication flows → Device code flow → Block.
Seule exception à prévoir : les comptes de service Teams Rooms ou certains appareils de visioconférence qui utilisent légitimement ce flux. Documentez chaque exception. Pour tous les autres utilisateurs, ce flux n’a aucune raison d’être ouvert.
2. Verrouiller le consentement aux applications
Par défaut, un utilisateur peut autoriser une application à accéder à ses données. Dans un scénario de compromission par token, ce mécanisme devient un levier de persistance pour l’attaquant.
Dans Entra ID → Enterprise applications → Consent and permissions, passez le paramètre sur « Do not allow user consent » ou, au minimum, « Allow for verified publishers only ». Activez le workflow d’approbation admin.
Sans cette mesure, un attaquant qui récupère un token peut accorder des permissions à une app malveillante et maintenir son accès même après un changement de mot de passe.
3. Couper les protocoles d’authentification hérités
Créez une policy Conditional Access bloquant les Legacy authentication clients (IMAP, POP3, SMTP Auth). Ces protocoles ne supportent pas le MFA et élargissent inutilement la surface d’attaque.
Avant activation, un point de vigilance côté MSP : analysez les logs de connexion sur les 30 derniers jours pour identifier d’éventuelles dépendances applicatives. Dans certains environnements, ces protocoles sont encore utilisés par des applications métiers ou des équipements.
Palier 2 — Réduire la fenêtre d’exploitation (une demi-journée)
4. Restreindre les connexions par géolocalisation
Définissez des Named Locations dans Entra ID avec les seuls pays où le client opère et bloquez tout le reste. Dans la campagne observée par Huntress, une grande partie des accès frauduleux provenait de localisations atypiques.
Pour les collaborateurs en déplacement, prévoyez une gestion des exceptions : accès conditionnel temporaire, avec MFA renforcé ou validation spécifique.
5. Activer la Continuous Access Evaluation (CAE)
La CAE permet à Microsoft 365 de révoquer un token en quasi-temps réel lorsqu’un changement de risque est détecté (nouvelle IP, policy modifiée). Sans elle, un token volé peut rester valide plus d’une heure. Les applications Office récentes supportent la CAE nativement, vérifiez simplement la compatibilité des apps tierces.
6. Configurer les alertes critiques dans Defender
Activez les alertes sur trois événements précis :
- Création ou modification de règles de boîte aux lettres (forwarding, redirection externe)
- Consentement à de nouvelles applications
- Connexions classées « à risque » par Entra ID Protection
L’enjeu n’est pas seulement de les activer, mais de les intégrer dans votre supervision MSP : boîte mail dédiée, canal Microsoft Teams ou remontée dans un SIEM.
L’objectif : détecter en minutes, pas en jours.
7. Raccourcir la durée de vie des sessions
Un token volé n’est dangereux que tant qu’il reste valide. Via les Session Controls de Conditional Access, réduisez la fréquence de reconnexion (Sign-in frequency) à 1 jour sur les applications sensibles : Exchange Online, SharePoint, portail d’administration.
Cela limite mécaniquement la durée d’exploitation possible d’un refresh token compromis. C’est un arbitrage classique entre confort utilisateur et sécurité.
Côté MSP, l’important est d’anticiper l’impact : informer le client en amont pour éviter une hausse des tickets liée aux reconnexions.
Palier 3 — Passer en mode détection active
8. Créer des règles de détection dans le SIEM
Si vous utilisez Microsoft Sentinel, créez une règle analytique sur les sign-in logs filtrant sur AuthenticationProtocol == "deviceCode", corrélée avec une géolocalisation inhabituelle ou un user-agent atypique. Chaque alerte doit déclencher une vérification manuelle immédiate.
Même sans Sentinel, une requête planifiée dans Log Analytics fait le travail.
9. Auditer les applications et leurs permissions
Utilisez le module Microsoft Graph PowerShell pour lister toutes les applications disposant de permissions sensibles : Mail.Read, Mail.ReadWrite, Files.ReadWrite.All, Directory.ReadWrite.All. Supprimez celles qui ne sont pas justifiées. Planifiez cet audit chaque trimestre.
Les applications oubliées avec des permissions excessives sont le meilleur allié de la persistance post-compromission.
10. Préparer le Token Protection (preview)
Cette fonctionnalité lie les tokens à l’appareil qui les a émis. Un token volé devient inutilisable sur une autre machine. Activez la preview sur un groupe pilote, surveillez la compatibilité, et préparez un déploiement dès le passage en disponibilité générale.
Ce que ça change pour votre offre
Ce plan d’action a une vertu supplémentaire : il se vend. Structurez-le en deux briques.
- La première, un pack « Hardening M365 » facturé en one-shot : audit initial, déploiement des 10 règles, rapport de conformité avec un scorecard visuel avant/après. La valeur ici est immédiate : vous corrigez des écarts précis, directement liés à des scénarios d’attaque observés.
- La seconde, un abonnement « M365 Security Review » : revue trimestrielle des configurations, rapport de dérive, ajustement des policies. Dans les faits, les tenants évoluent en permanence (nouveaux usages, applications ajoutées, exceptions créées). Sans suivi, les écarts réapparaissent.
L’argument commercial tient en une phrase : « Le MFA seul ne suffit plus. 340 organisations en ont fait les frais. Nos règles de durcissement couvrent ce que Microsoft ne fait pas par défaut. »
Vous pouvez également livrer un scorecard vert/orange/rouge à chaque comité de pilotage. C’est ce qui transforme une prestation technique en pilotage lisible, compréhensible côté client — et en revenu récurrent.
Pour suivre l’évolution des menaces et les bonnes pratiques opérationnelles côté MSP, consultez régulièrement Guide du MSP.