Adaptive MFA sous attaque : pourquoi les moteurs de risque ne voient pas la vague de 7 millions de codes d’appareils

9 min de lecture

Le 23 avril 2026, Barracuda a signalé avoir détecté 7 millions d’attaques de phishing par code de dispositif au cours des quatre dernières semaines. Le 6 avril, Microsoft Security a publié une analyse détaillée d’une campagne de phishing par code de dispositif pilotée par l’intelligence artificielle. Ces deux rapports révèlent une vérité inconfortable : l’authentification multi-facteurs (MFA) adaptative dans Entra, Okta et Duo n’est plus la zone de confort qu’elle était il y a encore douze mois dans chaque feuille de route de sécurité. Les moteurs de risque qui s’appuient sur l’empreinte des dispositifs, la classification des adresses IP et les schémas de comportement sont contournés par des attaquants utilisant l’intelligence artificielle en production, sans qu’une seule vulnérabilité CVE ne soit nécessaire.

Pourquoi les moteurs de risque échouent systématiquement

Qu’est-ce que l’Adaptive MFA ? L’Adaptive MFA est un modèle d’authentification qui ajuste dynamiquement les exigences de MFA (Multi-Factor Authentication) en fonction de signaux de risque tels que la réputation IP, la géolocalisation, la conformité des appareils, le comportement de l’utilisateur et le contexte de la session. L’idée est que les utilisateurs avec un appareil et un réseau connus rencontrent moins de demandes de MFA, tandis que les sessions à risque sont sécurisées avec des facteurs supplémentaires ou des restrictions de session. Cette mise en œuvre est réalisée dans Microsoft Entra ID (Identity Protection), Okta (Adaptive MFA) et Duo (Risk-Based Authentication) avec des composants de télémétrie similaires.

Le mode opératoire de la campagne d’attaque actuelle contourne précisément cette logique. L’attaquant ne construit plus une page de vol de credentials, mais initie un flux OAuth Device Code légitime chez Microsoft ou un autre fournisseur d’identité. Le code généré est envoyé à la victime au bon moment via des e-mails de phishing assistés par l’IA. Dès que la victime entre le code, elle autorise involontairement la session de l’attaquant. La MFA a été réussie, mais par la mauvaise personne pour le bon compte.

Les trois propriétés qui rendent cette attaque invisible pour les moteurs de risque sont intrinsèques à l’architecture. Premièrement : l’authentification et l’origine de la session sont, par conception, découplées dans le flux Device Code. Deuxièmement : le jeton est lié à un processus MFA réel, non volé. Troisièmement : l’adresse IP de la victime semble normale pour le moteur de risque, car il s’agit du véritable appareil qui autorise. Le jeton atterrit ensuite sur le serveur de l’attaquant, mais ce n’est plus la phase d’authentification, mais l’utilisation de la session.

Blog Microsoft Security du 6 avril 2026 en clair

L’article de blog Microsoft du 6 avril 2026 documente une campagne avec deux innovations techniques. Premièrement, la génération dynamique de code d’appareil : le serveur de phishing génère le code OAuth au moment où la victime clique sur le lien. Cela résout le problème des codes d’appareil expirant après 15 minutes, rendant souvent les vagues de phishing par e-mail traditionnelles inefficaces. Deuxièmement, la personnalisation assistée par l’IA : l’e-mail de phishing est adapté en temps réel au rôle, au contexte et au style de communication de la victime. Ces deux éléments combinés augmentent le taux de clics dans les campagnes observées à 4,2 pour cent, contre 0,4 pour cent dans les attaques classiques de fatigue MFA, selon Barracuda.

Les indicateurs de la situation actuelle des menaces

La différence entre « security by design » et « security by incident » est d’environ une semaine de sommeil. L’MFA adaptative ne fournit pas de somnifère lorsque l’attaque contourne le moteur de risque.

Trois contre-mesures qui fonctionnent vraiment

Les équipes de sécurité qui ont bien réagi au cours des deux derniers trimestres suivent toutes le même ordre. Pas de solution miracle, mais trois mesures clairement délimitées, qui peuvent être mises en œuvre dans un DACH-type d’entreprise en huit semaines.

Mesure 1 : Configuration restrictive du flux de code d’appareil

Dans Microsoft Entra ID, le flux de code d’appareil peut être restreint via une politique d’accès conditionnel. La politique bloque l’authentification par code d’appareil pour tous les groupes d’utilisateurs qui n’en ont pas besoin en production (généralement : tous sauf les administrateurs IoT et les comptes de service hors ligne spéciaux). Deux politiques sont pratiques : « Bloquer le flux de code d’appareil pour tous les utilisateurs » avec un groupe d’exceptions pour les cas d’usage documentés. Dans Okta, cette fonctionnalité s’appelle « Authentication Policies avec restriction de code d’appareil ». Pour les utilisateurs de Duo, cela est résolu via le moteur de politiques au niveau application. Cette mesure seule élimine environ 60 % des attaques observées, car le vecteur tout simplement n’est plus disponible.

Mesure 2 : FIDO2 et Passkeys comme facteur principal

Les moteurs de risque ont besoin de signaux contre lesquels même les e-mails de phishing basés sur l’IA ne peuvent pas lutter. Les clés matérielles FIDO2 et les Passkeys de plateforme sont en 2026 la seule classe de facteurs d’authentification largement applicable qui soit robuste contre les attaques de type Adversary-in-the-Middle et le phishing par code d’appareil. L’ordre de déploiement dans nos mandats : commençant par les rôles privilégiés (administrateurs de domaine, administrateurs IdP, finances), puis les rôles d’entreprise avec accès aux données sensibles, puis le déploiement général. Comptez entre 12 et 18 mois pour un déploiement FIDO2 complet dans une organisation de plus de 5 000 employés, y compris l’approvisionnement, la logistique, la formation du helpdesk et la configuration Entra/Okta.

Mesure 3 : Liaison de session et validation continue

Les plateformes modernes d’AMFA adaptative offrent le liant de jeton (Token-Binding) et l’évaluation d’accès continue (CAE). Dans Entra ID, cette fonctionnalité s’appelle « Continuous Access Evaluation » et vérifie en continu les jetons de session contre les signaux de risque. Okta la fournit sous le nom de « Session Risk Signals ». La configuration nécessite trois éléments : Durée de validité stricte du jeton (une heure au lieu de huit heures), activation du CAE sur les politiques d’accès conditionnel et une automatisation de révocation de session qui, en cas de nouveaux IOC (IP suspecte, nouvelle modification géographique, voyage impossible), met fin proactivement à la session. En combinaison avec les mesures 1 et 2, cette politique ferme environ 80 % des attaques réelles.

Ce que les moteurs de risque doivent évaluer différemment en interne

Les trois mesures ci-dessus sont opérationnelles. Mais derrière elles se pose une question plus profonde qui sera tranchée dans les architectures de sécurité des 18 prochains mois : Quels signaux de risque restent utilisables lorsque l’authentification et l’origine de la session sont découplés ? Notre observation chez les clients : Les moteurs de risque déplacent leur logique de « d’où vient la session » vers « comment le jeton se comporte après l’authentification ». Ainsi, des signaux comme la fréquence de rafraîchissement du jeton, le comportement de consentement d’application OAuth, les modifications de règles de boîte aux lettres et les appels d’API Graph inhabituels deviennent des indicateurs primaires, tandis que l’IP et la géolocalisation deviennent des indicateurs secondaires.

Un effet secondaire pratique : Les règles SIEM qui aujourd’hui déclenchent des alertes sur « MFA réussi » et « IP inconnue » produiront plus souvent de fausses alarmes, car le signal IP perd en pertinence. Les règles plus coûteuses mais plus efficaces sont celles qui corréllent les événements du cycle de vie du jeton avec les modèles d’activité utilisateur. Celui qui investit maintenant réduira dans six mois de manière tangible le volume d’alertes.

La dimension IA dans l’attaque : Ce qui a changé par rapport à 2024

Un deuxième point souvent simplifié dans le débat actuel : La composante IA de l’attaque ne réside pas seulement dans la personnalisation de l’e-mail de phishing, mais aussi dans la coordination en temps réel du flux de code d’appareil. En 2024, les campagnes de phishing étaient suffisamment statiques pour qu’un rôle de l’équipe bleue puisse suivre manuellement le processus. En 2026, la génération de code, la personnalisation de l’e-mail et l’extraction du jeton se produisent en une chaîne de millisecondes. Cela modifie le temps de réponse que les opérations de sécurité doivent fournir de manière réaliste. Quiconque dispose encore d’une boucle d’approbation manuelle entre l’alerte et la révocation de session perdra en cas d’incident réel deux à quatre heures, pendant lesquelles le jeton a déjà exécuté des exportations de boîte aux lettres.

La conséquence pour les architectures de sécurité : La révocation de session doit passer d’une décision manuelle à une décision pilotée par politique. Dans Entra ID, cela signifie concrètement l’activation du CAE avec révocation en cas de détection de risque, dans Okta l’intégration de signaux de risque avec l’abonnement aux journaux système et les playbooks de réponse automatisés. Les organisations que nous avons jugées bien préparées ont investi entre six et douze semaines précisément dans cette automatisation et ont ensuite réduit le temps de présence (Dwell-Time) à moins de 45 minutes.

Ce qui compte dans la première semaine de réponse à incident

Lorsqu’une attaque par code d’appareil apparaît dans notre propre télémétrie, trois actions s’imposent dans les premières 24 heures. Premièrement, révocation de session pour le compte utilisateur concerné via Entra ID PowerShell ou Okta API ; L’invalidation du jeton est plus importante que la réinitialisation du mot de passe, car le jeton est déjà actif. Deuxièmement, examen des journaux d’audit des 30 derniers jours sur les accès à la boîte aux lettres, le consentement d’application OAuth et l’exfiltration de données, qui commencent souvent quelques heures seulement après la prise de contrôle du jeton. Troisièmement, chasse aux menaces pour les campagnes parallèles : Les attaques par code d’appareil viennent généralement par vagues, une seule victime est rarement la seule affectée dans l’organisation. Quiconque attend une semaine pour clarifier l’ampleur complète a manqué la fenêtre de containment de l’incident.

Communication envers le conseil d’administration et le conseil de surveillance

Une dimension sous-estimée d’un contournement réussi de l’AMFA adaptative est la communication vers le haut. Les conseils d’administration s’attendent à une déclaration claire sur pourquoi l’investissement MFA existant n’a pas arrêté les attaquants. L’explication est techniquement simple, mais politiquement délicate : Le moteur de risque n’a pas échoué, il a été contourné. Pour la communication, un trio sobre est recommandé : Quel était le chemin d’attaque spécifique, quelle faille de contrôle a été exploitée, quelles trois mesures combleront cette faille d’ici la fin du trimestre. Quiconque dérive dans le jargon technique à ce moment perd la confiance. Celui qui raconte clairement l’histoire obtiendra l’approbation budgétaire pour le déploiement FIDO2 et l’activation du CAE plus rapidement que lors d’un cycle budgétaire normal.

Pour la communication avec le conseil de surveillance, un élément supplémentaire est important : Les leçons tirées (Lessons-Learned) doivent être intégrées comme preuve formelle de mitigation des risques dans la documentation NIS2. L’article 21 exige non seulement l’analyse de risque initiale, mais aussi l’adaptation continue après des incidents. Un incident de contournement d’AMFA sans ajustement documenté sera un constat lors du prochain audit avec un impact sur l’évaluation globale.

Vérification pragmatique finale

L’AMFA adaptative était pour de nombreuses organisations une mise à niveau confortable par rapport à la MFA statique. En 2026, il est clair : Le confort et la sécurité ne sont pas identiques. Une bonne configuration d’AMFA adaptative en 2026 est plus restrictive, pas plus tolérante, et combine des facteurs résistants au phishing avec une validation de session agressive. Quiconque aborde cela au cours des deux prochains trimestres déplacera son organisation hors de la statistique des 7 millions. Quiconque attend se fie au fait que les campagnes basées sur l’IA ne frapperont pas son entreprise. Ce n’est pas une stratégie de sécurité, c’est le hasard. Et le hasard, dans la situation de menace actuelle, est le composant d’architecture le plus cher qu’une organisation puisse se permettre, si l’on calcule de manière réaliste les coûts d’un incident et le traitement ultérieur de la conformité NIS2.

Questions fréquentes

Le flux de code d’appareil (Device-Code-Flow) est-il fondamentalement non sécurisé ?

Non. Ce flux a été développé pour des scénarios spécifiques (authentification sur appareil partagé, IoT, outils en ligne de commande sans navigateur) et y est pertinent. Le risque apparaît lorsqu’il est déployé de manière généralisée sans restrictions et peut être exploité comme vecteur de phishing. La solution n’est pas de désactiver ce flux, mais de le restreint intentionnellement aux cas d’usage documentés.

Comment détecter une attaque en cours par code d’appareil dans les journaux d’activité ?

Dans les journaux de connexion d’Entra ID, les événements de code d’appareil sont explicitement marqués (AuthenticationProtocol = DeviceCode). Une règle d’anomalie KQL qui alerte sur des populations d’utilisateurs inhabituels avec des événements de code d’appareil détecte la plupart des campagnes durant les premières heures. Dans Okta, la même information se trouve dans le journal système sous « login.device_code ». Important : la règle doit se déclencher sur de nouvelles cohortes d’utilisateurs, et non seulement sur le volume.

Le blocage géographique est-il utile dans cette situation ?

Partiellement. Le blocage géographique des pays inutilisés réduit le bruit de fond, mais les attaquants utilisent de plus en plus des réseaux de proxy résidentiels dans le même pays que la victime. Le blocage géographique ne remplace donc pas les contre-mesures mentionnées ci-dessus, il allège simplement l’analyse des alertes.

Quelle est la position de NIS2 concernant le contournement de l’AMFA adaptative ?

NIS2 exige conformément à l’article 21 des mesures appropriées contre l’accès non autorisé, une analyse des risques documentée et un signalement d’incidents. Une campagne réussie de code d’appareil avec exfiltration de données tombe ainsi dans l’obligation de déclaration. Pour se préparer à un tel cas, la documentation des mesures d’AMFA prises et de leurs limites est obligatoire. Toute organisation qui ne documente pas sa politique de restriction de code d’appareil se retrouvera dans une position difficile lors de l’audit NIS2.

Quel est le coût réaliste d’un déploiement FIDO2 ?

Pour une entreprise de 5 000 employés, nous estimons les coûts entre 150 000 et 280 000 euros la première année (matériel, licences IdP, intégration du support, formation). Les économies proviennent d’incidents de phishing réduits, d’appels au helpdesk moins nombreux pour les réinitialisations d’AMFA, et dans le meilleur des cas, de violations de sécurité évitées. Un cas de retour sur investissement réaliste se base sur deux à trois incidents évités par an, dont le coût se situe à 150 000 euros ou plus.

Devrions-nous désactiver complètement le flux de code d’appareil ?

Pour la plupart des organisations, la réponse est : oui, avec des exceptions pour les groupes d’utilisateurs documentés. Une matrice d’exceptions propre comprend généralement trois à cinq cas d’usage (outils en ligne de commande pour les administrateurs, déploiements IoT spécifiques, comptes de service avec objectif d’usage documenté). Tout le reste devrait être bloqué par une politique d’accès conditionnel, à moins qu’une justification métier claire ne soit fournie.

Réseau: Pour aller plus loin dans Security Today

• Contexte sur DORA 2.0 et la politique de la UK-FCA du 16 avril 2026
• Analyse de l’incident concernant l’évasion de la sandbox Terrarium CVE-2026-5752 et la mise à jour 72h de Cohere
• Guide de conformité concernant le CVE Microsoft ASP.NET et le plan de mise à jour hors-bande 72h

Source de l’image de couverture : Pexels / Tima Miroshnichenko (px:5380610)

À propos de l'auteur: Alec Chizhik

Plus d'articles de Alec Chizhik