MFA Fatigue dans Entra ID : détection et prévention

Qu’est-ce que la MFA Fatigue ?

La MFA fatigue, aussi appelée MFA bombing ou push bombing, consiste à générer de manière répétée des invites de multifactor authentication jusqu’à ce qu’un utilisateur en approuve finalement une. MITRE suit cette technique sous T1621, Multi-Factor Authentication Request Generation.

Le mécanisme est plus étroit que ce que beaucoup d’équipes décrivent. Dans le cas le plus courant, l’attaquant possède déjà le mot de passe de la victime et n’est bloqué que par le second facteur. Au lieu d’abandonner, il déclenche encore et encore des notifications push vers Microsoft Authenticator, Duo, Okta Verify ou un service MFA similaire, en espérant user l’utilisateur.

Le périmètre de cet article est Microsoft Entra ID et la MFA push via Microsoft Authenticator, avec un accent sur la détection opérationnelle et le durcissement du tenant. La MFA fatigue n’est pas la même chose que le password spraying, le phishing adversary-in-the-middle ou le SIM swapping, même si ces techniques sont souvent utilisées avant ou en parallèle.

Le risque clé est simple : une MFA fondée sur l’approbation d’une notification push dépend encore d’un utilisateur qui doit prendre la bonne décision sous pression. Si l’attaquant peut créer des invites répétées, ou associer ces invites à un prétexte d’ingénierie sociale, un contrôle qui semblait fort dans la politique peut échouer en pratique.

Comment fonctionne la MFA Fatigue

La définition de MITRE est précise : les adversaires peuvent tenter de contourner la MFA en générant des demandes MFA envoyées aux utilisateurs. S’ils possèdent déjà des identifiants valides, ils peuvent être bloqués uniquement parce qu’ils ne contrôlent pas le second facteur. Pour contourner cela, ils abusent des notifications push et espèrent que l’utilisateur finira par accorder l’accès.

C’est important, car l’attaque n’est pas une rupture cryptographique. C’est un abus du design du workflow d’authentification et du comportement d’approbation humain.

Une séquence typique côté Entra ressemble à ceci :

l’attaquant obtient un nom d’utilisateur et un mot de passe valides via phishing, password spraying, credential stuffing ou ingénierie sociale help desk
l’attaquant lance une connexion interactive qui requiert une approbation Microsoft Authenticator
l’utilisateur reçoit des notifications push répétées
l’attaquant continue de réessayer, souvent à des heures choisies pour créer de la confusion ou de l’agacement
si l’utilisateur finit par approuver une invite, l’attaquant obtient une session authentifiée valide

MITRE note aussi un second chemin que certains défenseurs sous-estiment : si l’attaquant ne possède pas encore les identifiants, la génération automatique de push peut aussi être exploitée dans certains scénarios de self-service password reset lorsque le workflow est configuré pour envoyer des notifications push.

La MFA fatigue n’est pas la même chose que d’autres attaques d’identité

Les différences comptent, car les mitigations ne sont pas identiques.

Le password spraying essaie un ou quelques mots de passe sur beaucoup d’utilisateurs pour obtenir le premier identifiant valide. Voir Password Spraying : détection et prévention dans Active Directory et Entra ID.
La MFA fatigue commence après que l’attaquant a déjà obtenu, ou est sur le point d’obtenir, un premier facteur valide et cherche à transformer une connexion bloquée en connexion approuvée.
Le phishing adversary-in-the-middle proxifie le flux de connexion pour capturer des jetons ou du contexte de session en temps réel. Il ne dépend pas de l’agacement de l’utilisateur de la même manière.
Le SIM swapping cible les facteurs basés sur le numéro de téléphone en prenant le contrôle du mobile de la victime.

La MFA fatigue vise spécifiquement l’étape d’approbation humaine dans une MFA fondée sur des notifications push.

Pourquoi la MFA Fatigue fonctionne encore

La MFA fatigue reste efficace lorsque trois problèmes se superposent : l’attaquant possède un premier facteur valide, le tenant s’appuie encore sur des approbations push pour des comptes importants, et l’utilisateur n’a pas assez de contexte ou de friction pour rejeter l’invite en toute confiance.

La guidance Microsoft sur la phishing-resistant MFA est explicite : les méthodes MFA traditionnelles comme les SMS, les OTP par e-mail et les notifications push deviennent moins efficaces face aux attaquants modernes. Le document cite explicitement user fatigue et MFA bombing comme exemples concrets de contournement des méthodes MFA plus anciennes.

En pratique, la MFA fatigue fonctionne parce que :

Les approbations push sont faciles à déclencher en boucle

L’attaquant n’a pas besoin de casser un token ou de vaincre une clé matérielle. Il lui suffit d’un flux de connexion qui continue à générer des invites.

Beaucoup d’utilisateurs voient encore des invites avec peu de contexte

Si la notification n’affiche pas clairement le nom de l’application et le contexte géographique de la connexion, l’utilisateur dispose de moins d’informations pour distinguer un vrai besoin d’approbation d’une attaque. Microsoft recommande désormais explicitement d’afficher ce contexte dans les notifications Authenticator.

L’utilisateur peut être manipulé pendant que les notifications arrivent

Une notification push a plus de chances d’être approuvée si elle arrive pendant que l’attaquant met l’utilisateur sous pression par téléphone ou messagerie, au cours d’une vraie réinitialisation de mot de passe ou à un moment où l’utilisateur s’attend déjà à une activité de connexion légitime.

Des comptes à forte valeur sont encore protégés uniquement par une MFA standard

Si les administrateurs s’appuient encore sur de simples approbations push au lieu d’une MFA résistante au phishing, la liste de cibles de l’attaquant prend beaucoup plus de valeur.

Préconditions pour qu’une attaque de MFA Fatigue réussisse

Une attaque MFA fatigue réussie nécessite en général les conditions suivantes.

1. L’attaquant dispose d’un premier facteur valide ou peut déclencher un flux de reset

L’hypothèse de base de MITRE est que l’attaquant possède déjà des identifiants valides. Dans l’univers Entra, cela signifie en général un mot de passe volé, récupéré lors d’une autre intrusion, ou obtenu après Password Spraying : détection et prévention dans Active Directory et Entra ID.

2. La cible utilise une MFA push

L’attaque dépend du fait que l’utilisateur reçoive une demande d’approbation. Si le compte cible est limité à des méthodes résistantes au phishing, par exemple via des authentication strengths plus fortes pour les connexions privilégiées, la MFA fatigue devient beaucoup moins utile.

3. Le tenant n’a pas assez réduit les approbations à faible contexte

Si l’invite ne montre qu’une demande générique, ou si le signalement d’activité suspecte n’est pas activé, les utilisateurs disposent de moins de contexte et les défenseurs de moins de signaux de haute confiance en cas d’abus.

4. Le compte a suffisamment de valeur pour justifier des tentatives répétées

Les administrateurs, opérateurs cloud, équipes help desk et administrateurs d’applications sont des cibles privilégiées, car une seule invite approuvée peut ouvrir un accès large en aval.

5. Les workflows de réponse sont trop lents

Si des refus répétés d’invites ne déclenchent pas rapidement d’investigation, ou si les signalements d’invite suspecte n’entraînent pas de containment, l’attaquant peut continuer jusqu’à ce qu’un utilisateur approuve une demande ou qu’une seconde étape d’ingénierie sociale réussisse.

La chaîne d’attaque

Une chaîne d’intrusion MFA fatigue ressemble généralement à ceci.

Étape 1 - Obtenir le mot de passe

L’attaquant récupère d’abord le mot de passe par phishing, password spraying, réutilisation d’identifiants ou ingénierie sociale.

Étape 2 - Déclencher le challenge MFA

L’attaquant tente une connexion à Microsoft 365, Azure ou une charge reliée à Entra qui exige une approbation Authenticator.

Étape 3 - Répéter la génération des invites

Au lieu d’accepter l’échec initial, l’attaquant continue à générer des demandes d’approbation. C’est exactement le comportement que MITRE capture dans T1621.

Étape 4 - Ajouter de la pression sociale

Les attaquants peuvent accompagner les invites d’appels ou de messages qui poussent l’utilisateur à approuver une demande, souvent en se faisant passer pour le support interne ou en exploitant un moment de confusion autour d’une vraie connexion ou d’une vraie réinitialisation de mot de passe.

Étape 5 - Exploiter immédiatement la session approuvée

Une fois qu’une invite est approuvée, l’attaquant a ce qu’il cherchait : une session valide dans le tenant cible. La suite dépend du niveau de privilège et de la couverture des politiques. Les actions les plus fréquentes sont la revue du répertoire, l’identification de rôles privilégiés, la recherche d’app registrations, l’accès à des boîtes mail ou la modification de paramètres d’authentification.

L’invite approuvée n’est donc pas la fin de l’incident. C’est le point de pivot entre connexion bloquée et accès authentifié.

Détection

Il n’existe pas d’événement Entra unique qui dise « ceci était définitivement de la MFA fatigue ». Le bon modèle est une détection fondée sur les séquences et le contexte.

Rechercher des refus MFA répétés sur un même utilisateur

Le signal le plus évident est un groupe de tentatives répétées où le même utilisateur reçoit plusieurs demandes MFA et les refuse ou les ignore. Dans les sign-in logs Entra, cela apparaît souvent comme des connexions interrompues répétées avec des détails d’échec MFA avant une réussite éventuelle.

Traiter les signalements utilisateur d’invite suspecte comme un signal à haute confiance

La fonctionnalité Microsoft Report suspicious activity est le signal natif le plus fort dans ce workflow. D’après Microsoft Learn :

les utilisateurs qui signalent une invite MFA inconnue comme suspecte passent en High User Risk
l’événement apparaît dans les sign-in logs, les audit logs et les risk detections
le riskEventType est userReportedSuspiciousActivity

C’est important, car cela permet de passer d’une simple hypothèse à un signal spécifique, confirmé par l’utilisateur lui-même.

Corréler la séquence MFA avec le contexte de connexion

Les investigations doivent corréler la séquence d’invites avec :

des IP ou géographies inhabituelles pour l’utilisateur
des applications qui initient une connexion sans être habituelles pour ce compte
des tentatives répétées depuis une même source contre un compte à forte valeur
une série de refus suivie d’une unique approbation
de l’activité immédiatement après l’approbation réussie

Accorder une attention particulière aux identités privilégiées

Un seul épisode de push bombing contre un utilisateur ordinaire est déjà sérieux. Le même schéma contre un Global Administrator, un Conditional Access Administrator ou un Privileged Role Administrator exige un containment immédiat.

C’est l’une des raisons pour lesquelles il faut relire Acces Privilegie Azure : Trop d'Admins Globaux et Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique avec ce type d’attaque à l’esprit.

Éviter les conclusions à partir d’un seul événement

Les utilisateurs refusent parfois de vraies invites légitimes. Un changement de réseau mobile, une connexion depuis un nouvel appareil ou une simple confusion utilisateur peuvent aussi créer du bruit. Le meilleur détecteur n’est donc pas un seul refus. C’est un motif répété, surtout lorsqu’il est couplé à un userReportedSuspiciousActivity, à un contexte de connexion inhabituel ou à des actions privilégiées en aval.

Remediation / Remédiation

Arrêter la MFA fatigue ne consiste pas à ajouter encore plus de notifications MFA génériques. Il s’agit de rendre les approbations malveillantes plus difficiles à déclencher, plus faciles à reconnaître et moins utiles lorsqu’elles se produisent.

1. Vérifier que les flux push Authenticator utilisent bien le number matching

Microsoft indique que le number matching est activé pour les notifications push Authenticator actuelles et le présente comme une amélioration de sécurité importante par rapport à l’ancien modèle Approve/Deny.

Cela compte parce que l’attaquant ne peut plus gagner avec un simple tap inattentif sur une invite générique. L’utilisateur doit saisir un nombre affiché dans le flux de connexion.

Si votre environnement dépend encore d’intégrations MFA plus anciennes ou périphériques, il faut valider leur comportement séparément au lieu de supposer que tous les workflows push bénéficient du même niveau de protection que l’expérience actuelle Entra + Authenticator.

2. Activer le contexte de connexion dans les notifications Authenticator

Microsoft recommande explicitement d’afficher le nom de l’application et la localisation géographique dans les notifications Authenticator afin de permettre à l’utilisateur de prendre une décision d’approbation informée.

Un tenant qui laisse les approbations push trop génériques facilite les attaques de fatigue. Lorsque l’invite affiche une application ou une localisation que l’utilisateur ne reconnaît pas, le rejet devient beaucoup plus probable.

Ce contrôle est particulièrement utile lorsque l’attaquant possède déjà un vrai mot de passe et tente de le transformer en session approuvée.

3. Activer Report suspicious activity et le brancher dans la réponse

C’est l’un des contrôles Entra les plus rentables contre la MFA fatigue.

Microsoft documente que lorsqu’un utilisateur signale une invite MFA suspecte :

l’utilisateur est marqué High User Risk
l’événement est visible dans les sign-in logs, audit logs et risk detections
les organisations qui disposent des licences adaptées peuvent utiliser un risk-based Conditional Access pour bloquer ou forcer une remédiation sécurisée
les organisations sans cette automatisation disposent malgré tout d’un signal concret, exploitable en investigation et containment

Opérationnellement, cela signifie que l’utilisateur peut faire plus que cliquer sur Deny. Il peut générer un vrai signal d’incident visible côté défenseur à partir de la même invite.

4. Faire passer les utilisateurs privilégiés sur une MFA résistante au phishing

La guidance actuelle de Microsoft est claire : les rôles administratifs privilégiés sont des cibles fréquentes et les organisations doivent exiger une phishing-resistant MFA pour ces rôles.

Pour le sujet de cet article, ce point est central. Une simple approbation push standard peut toujours être détournée par fatigue ou ingénierie sociale. Une authentication strength résistante au phishing rend cette voie d’attaque beaucoup plus difficile.

Si vous êtes en train de durcir l’accès privilégié, il faut relier cela à Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas et Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués.

5. Réduire le nombre de mots de passe que les attaquants peuvent réutiliser au départ

La MFA fatigue commence en général après une compromission de mot de passe. Si vous réduisez le vol de mots de passe et le succès du password spraying, vous réduisez aussi le nombre d’opportunités de push bombing.

C’est ce qui rend Failles d’Accès Conditionnel Azure : Contournement du MFA et Durcissement du Tenant Azure : Corriger les Configs à Risque directement pertinents. Des flux d’approbation MFA plus robustes sont utiles, mais ils doivent reposer sur un tenant qui réduit déjà l’accès initial fondé sur le mot de passe.

6. Revoir séparément les identités externes et invitées

Le risque lié aux approbations push ne se limite pas aux comptes employés. Les identités externes, comptes B2B invités et accès partenaires peuvent eux aussi devenir des chemins d’approbation bruyants ou insuffisamment revus s’ils sont exemptés de contrôles plus forts ou moins bien supervisés. C’est pour cela que Comptes Invités Azure : Risques du Tenant fait partie du même mouvement de revue.

7. Déployer des politiques plus fortes avec prudence

La guidance Microsoft à destination des administrateurs contient un vrai avertissement opérationnel : avant d’exiger largement une MFA résistante au phishing pour les administrateurs, il faut confirmer que ces utilisateurs sont déjà enregistrés avec les bonnes méthodes. Sinon, vous risquez de vous verrouiller vous-même hors du tenant.

La même logique s’applique plus largement aux changements de Conditional Access :

utiliser le mode report-only lorsqu’il est disponible
protéger volontairement les comptes d’accès d’urgence
revoir séparément les comptes de service et les workload identities
vérifier que les workflows help desk et de récupération d’identité continuent de fonctionner

Un bon durcissement identité ne consiste pas seulement à ajouter des contrôles plus forts. Il consiste aussi à éviter des pannes auto-infligées.

Validation après durcissement

Il ne faut pas clore ce sujet simplement parce qu’une option a été activée dans Entra. Il faut valider l’ensemble du workflow d’approbation.

confirmer que le tenant présente bien le number matching pour les scénarios Authenticator push réellement utilisés
confirmer que l’invite affiche le nom de l’application et la localisation géographique lorsqu’elle le doit
confirmer que Report suspicious activity est activé pour la population visée
confirmer que les signalements d’invite suspecte créent bien les signaux attendus dans les sign-in logs, audit logs et risk detections
confirmer que le workflow de réponse révoque les sessions, enquête sur les connexions et réinitialise les identifiants lorsqu’un utilisateur signale une invite malveillante
confirmer que les administrateurs privilégiés sont couverts par des exigences d’authentification plus fortes que les utilisateurs ordinaires

Le vrai test n’est pas de savoir si la MFA est activée dans le tenant. Le vrai test est de savoir si un mot de passe volé, combiné à des tentatives push répétées, a encore une voie réaliste vers une approbation.

Comment EtcSec détecte les expositions liées

La MFA fatigue est une technique d’attaque, pas une unique mauvaise configuration Entra. Les findings de catalogue les plus proches sont les lacunes de contrôle qui rendent le push bombing plus susceptible de réussir ou plus difficile à contenir.

Les expositions liées les plus pertinentes sont :

l’absence de risk-based sign-in response, qui affaiblit le containment après qu’un utilisateur a signalé une invite suspecte
une protection trop faible ou incomplète des identités privilégiées, surtout lorsque les utilisateurs administratifs ne sont pas basculés vers des schémas d’authentification plus forts
des designs de Conditional Access qui s’appuient encore trop fortement sur de simples approbations MFA standard au lieu d’exiger des méthodes plus robustes

C’est pour cela que ce sujet se place à côté de Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués, Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas et Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique, plutôt que d’exister comme un simple réglage isolé.

Contrôles liés

Si vous revoyez la MFA fatigue, vous devez aussi revoir les contrôles qui façonnent le même chemin d’attaque : Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas, Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués, Failles d’Accès Conditionnel Azure : Contournement du MFA, Durcissement du Tenant Azure : Corriger les Configs à Risque, Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique et Comptes Invités Azure : Risques du Tenant.