Attaque MFA fatigue

Comment fonctionne l’attaque MFA fatigue

L’authentification multifacteur (MFA) bloque 99,9 % des attaques automatisées sur les comptes, selon Microsoft. Mais le MFA par notification push — le mode par défaut de Microsoft Authenticator, Duo et Okta Verify — repose sur une décision humaine : appuyer sur “Approuver” ou “Refuser”. Et les humains ont des limites.

L’attaque MFA fatigue exploite cette limite. L’attaquant ne casse pas la technologie. Il casse la personne qui l’utilise.

Étape 1 : obtenir le mot de passe

L’attaque MFA fatigue ne commence jamais de zéro. L’attaquant possède déjà les identifiants de la victime (email + mot de passe), obtenus par phishing, credential stuffing, achat sur le dark web, infostealer (malware qui vole les mots de passe du navigateur) ou interception via un proxy de phishing (EvilProxy).

Le mot de passe seul ne suffit pas car le MFA bloque la connexion. L’attaquant doit contourner cette deuxième barrière.

Étape 2 : le bombardement push

L’attaquant entre les identifiants de la victime sur la page de connexion du service cible (Microsoft 365, VPN, application cloud). Le système MFA envoie une notification push sur le téléphone de la victime : “Approuver cette connexion ?”

La victime refuse ou ignore la notification. L’attaquant recommence. Et recommence. Et recommence encore.

Le rythme peut être d’une notification toutes les quelques secondes, pendant des minutes ou des heures. Le téléphone de la victime vibre sans arrêt. Les notifications s’empilent. Si l’attaque a lieu à 2 heures du matin, la victime est réveillée par un téléphone qui ne cesse de vibrer.

Étape 3 : l’approbation

Trois mécanismes mènent la victime à approuver :

• La lassitude : après 30, 50 ou 100 notifications, la victime appuie sur “Approuver” juste pour que les vibrations cessent. C’est le scénario le plus courant.
• La confusion : la victime pense que le système bugue ou qu’une mise à jour nécessite une validation. Elle approuve “pour régler le problème”.
• L’erreur : sur un petit écran de smartphone, le bouton “Approuver” est à quelques millimètres du bouton “Refuser”. En voulant refuser pour la 40e fois, le doigt glisse.

Étape 4 (variante) : l’ingénierie sociale

Les attaquants les plus méthodiques combinent le bombardement push avec un contact direct. Après avoir envoyé des dizaines de notifications, l’attaquant contacte la victime par téléphone, SMS, WhatsApp ou même Slack en se faisant passer pour le support IT de l’entreprise :

“Bonjour, nous avons détecté un problème avec votre compte. Vous avez dû recevoir des notifications d’authentification. Pouvez-vous approuver la prochaine pour que nous puissions finaliser la vérification de sécurité ?”

La victime, déjà exaspérée par les notifications et rassurée par cet appel qui semble provenir du support IT, approuve la notification suivante. L’attaquant accède au compte.

C’est une forme de social engineering qui exploite à la fois la fatigue de la victime et son envie de coopérer avec le support informatique.

Étape 5 : la prise de contrôle

Une fois la notification approuvée, l’attaquant est connecté. Selon les privilèges du compte, il peut accéder aux emails, se déplacer latéralement dans le réseau, installer une persistance (règles de transfert, applications OAuth), lancer un ransomware ou envoyer du phishing interne depuis le compte compromis.

Exemples réels

Uber (septembre 2022, Lapsus$)

L’attaque contre Uber est le cas le plus documenté de MFA fatigue. Un attaquant de 18 ans, affilié au groupe Lapsus$, a acheté les identifiants d’un sous-traitant d’Uber sur le dark web. Les identifiants avaient probablement été volés par un infostealer installé sur le poste du sous-traitant.

Le déroulement :

1. L’attaquant a tenté de se connecter au VPN d’Uber avec les identifiants volés
2. Le système MFA a envoyé une notification push sur le téléphone du sous-traitant
3. Le sous-traitant a refusé. L’attaquant a recommencé — pendant plus d’une heure
4. L’attaquant a ensuite contacté le sous-traitant sur WhatsApp, en se faisant passer pour le support IT d’Uber, et lui a demandé d’approuver la prochaine notification
5. Le sous-traitant a approuvé

L’impact : Une fois connecté au VPN, l’attaquant a scanné le réseau interne et trouvé un script PowerShell contenant les identifiants en clair d’un compte administrateur Thycotic (coffre-fort de secrets). Il a accédé à Slack, Google Workspace, les tableaux de bord financiers et la base de vulnérabilités HackerOne d’Uber. L’attaquant a posté un message sur le Slack interne pour annoncer la compromission.

Uber a publié un rapport complet sur l’incident. Cet événement a accéléré le déploiement du number matching chez Microsoft, Okta et Duo.

Cisco (mai 2022, Yanluowang)

Un attaquant affilié au groupe Yanluowang a compromis le compte Google personnel d’un employé Cisco. Les identifiants VPN étaient synchronisés dans Chrome. L’attaquant a lancé un bombardement MFA combiné à des appels de vishing imitant des organisations de confiance. L’employé a fini par approuver. Cisco Talos a publié l’analyse complète, confirmant le MFA fatigue comme vecteur d’accès initial.

Microsoft (janvier 2022, Lapsus$)

Le groupe Lapsus$ a compromis un employé Microsoft par bombardement MFA, accédant à des dépôts de code source internes (Azure, Bing, Cortana). Microsoft a publié une analyse des techniques de Lapsus$, identifiant le MFA fatigue comme méthode récurrente du groupe. Ce rapport a accéléré l’activation du number matching par défaut dans Microsoft Authenticator (mai 2023).

Le schéma Lapsus$

Le groupe Lapsus$ (actif en 2021-2022) a systématisé le MFA fatigue. Outre Uber, Cisco et Microsoft, le groupe a compromis Okta, Samsung, Nvidia et T-Mobile avec la même approche : achat d’identifiants sur le dark web, bombardement push, escalade par ingénierie sociale. Le profil des attaquants — des adolescents au Royaume-Uni et au Brésil — montre que cette technique ne nécessite aucune compétence avancée.

Pourquoi cette attaque fonctionne

Fatigue d’alerte. Le cerveau humain n’évalue pas de manière critique des dizaines d’alertes identiques en série. La notification n°50 reçoit moins de scrutin que la n°1. C’est le même phénomène qui affecte les équipes SOC face au flux d’alertes.

Confusion contextuelle. L’employé qui reçoit une notification non sollicitée doute plutôt qu’il ne s’alarme : “Session ouverte quelque part ? Bug du système ?” Cette hésitation joue en faveur de l’attaquant, surtout pendant les heures de travail, quand l’employé effectue réellement des connexions.

Attaque nocturne. Les attaquants choisissent des horaires où la victime est moins vigilante : entre 1h et 4h du matin, le weekend, pendant les vacances. Un téléphone qui vibre en pleine nuit pousse à une réaction réflexe plutôt qu’à une analyse posée.

Escalade par ingénierie sociale. Quand le bombardement seul échoue, l’appel imitant le support IT fait basculer la victime. L’autorité perçue du service informatique neutralise la vigilance résiduelle.

Absence de formation spécifique. Beaucoup d’entreprises forment au phishing mais ne couvrent pas le MFA fatigue. Les employés ne savent pas qu’une notification MFA non sollicitée est un signal d’attaque.

Les limites du MFA push classique

Le problème du “Approuver / Refuser”

La notification push classique présente un choix binaire sans preuve que l’utilisateur est à l’origine de la demande. Le problème est structurel : la notification ne lie pas l’utilisateur à la tentative de connexion. L’attaquant déclenche la connexion sur son écran, la notification arrive sur le téléphone de la victime, et n’importe qui peut appuyer sur “Approuver”.

MFA push vs MFA résistant au phishing

Caractéristique	Push classique	Number matching	FIDO2 / Passkeys
Résistance au MFA fatigue	Non	Oui	Oui (pas de notification)
Résistance au phishing AiTM	Non	Non	Oui
Vérification du domaine	Non	Non	Oui (cryptographique)
Nécessite une action physique	Non (un appui)	Partielle (saisie d’un code)	Oui (toucher la clé / biométrie)
Coût de déploiement	Gratuit (app incluse)	Gratuit (configuration)	25-70 euros par clé physique

Le push classique est le maillon faible. Le number matching corrige le problème de la fatigue mais reste vulnérable aux attaques de phishing en temps réel (AiTM) via des outils comme EvilProxy. Seules les clés FIDO2 et les passkeys résistent à la fois au MFA fatigue et au phishing.

Pourquoi le MFA reste votre meilleure protection

L’existence du MFA fatigue ne remet pas en cause le MFA. Sans MFA, l’attaquant qui possède le mot de passe se connecte directement, sans bruit. Avec MFA, il doit bombarder la victime (ce qui prend du temps et génère des traces) et espérer qu’elle approuve. Le Verizon DBIR 2024 confirme que les organisations avec MFA déployé subissent nettement moins de compromissions. La solution : passer à des méthodes résistantes.

Comment protéger votre entreprise

Activer le number matching

Le number matching transforme la notification push. Au lieu d’un simple “Approuver / Refuser”, le système affiche un nombre à deux chiffres sur l’écran de connexion (par exemple : 37). L’utilisateur doit saisir ce nombre dans l’application d’authentification sur son téléphone pour valider.

L’attaquant qui déclenche la notification voit le nombre sur son écran de connexion. Mais la victime ne le voit pas — elle n’est pas devant l’écran de l’attaquant. Impossible d’approuver à l’aveugle.

Microsoft Authenticator : le number matching est activé par défaut depuis mai 2023 pour tous les tenants Azure AD / Entra ID. Documentation Microsoft sur le number matching.

Okta : le number matching est disponible dans Okta Verify et peut être imposé par politique d’authentification.

Duo : Cisco Duo propose le “Verified Push” qui combine number matching et contexte de connexion.

Si vous utilisez encore des notifications push simples sans number matching, activez-le cette semaine. C’est un changement de configuration, pas un déploiement logiciel.

Déployer FIDO2 et passkeys

Les clés FIDO2 (YubiKey, Google Titan, Feitian) et les passkeys (Windows Hello, Touch ID, empreinte Android) éliminent le problème du MFA fatigue par conception. Il n’y a pas de notification push. L’authentification se fait par :

• Un contact physique avec la clé de sécurité (l’utilisateur touche le bouton de la YubiKey)
• Une vérification biométrique (empreinte digitale, reconnaissance faciale)
• Un PIN saisi localement sur l’appareil

Aucune notification à approuver = aucun bombardement possible. En prime, les clés FIDO2 vérifient cryptographiquement le domaine du site de connexion : un faux site contrôlé par un attaquant via EvilProxy ne recevra pas la réponse d’authentification. C’est le seul facteur MFA qui résiste à la fois au MFA fatigue et au phishing en temps réel.

Le NIST recommande les authentificateurs FIDO2 comme le niveau le plus élevé d’assurance d’authentification (AAL3 / résistance au phishing vérifiable).

Déploiement progressif recommandé pour une PME :

1. Comptes administrateurs et IT : clés FIDO2 en priorité — ce sont les comptes les plus ciblés
2. Direction et finance : passkeys sur les appareils professionnels
3. Ensemble des collaborateurs : passkeys avec le number matching comme solution de repli

Configurer le rate limiting et les alertes SOC

Limitez le nombre de notifications push par session. Après 3 à 5 notifications refusées en 10 minutes, le compte doit être temporairement verrouillé. Cette configuration est disponible dans Azure AD / Entra ID (politiques d’accès conditionnel), Okta (politiques d’authentification) et Duo (paramètre de lockout).

Configurez aussi des alertes dans votre SIEM pour détecter les schémas de MFA fatigue : plus de 5 notifications en 10 minutes, notifications refusées suivies d’une approbation (pattern du bombardement réussi), notifications depuis une IP ou géolocalisation inhabituelle. Ces alertes permettent à l’équipe SOC d’intervenir en temps réel.

Appliquer des politiques d’accès conditionnel

Les politiques d’accès conditionnel bloquent les tentatives avant l’envoi de la notification push : géolocalisation (bloquer les pays où l’entreprise n’opère pas), état de l’appareil (n’autoriser que les appareils conformes), réseau (MFA renforcé hors réseau d’entreprise), et risque utilisateur (ré-authentification renforcée si le compte est signalé comme compromis).

Former les collaborateurs

Trois messages à ancrer dans les formations :

• Une notification MFA non sollicitée est un signal d’attaque, pas un bug. Refusez et alertez le service IT.
• Le support IT ne demandera jamais d’approuver une notification MFA par téléphone. Un tel appel est une attaque d’ingénierie sociale.
• Approuver “pour que ça s’arrête” revient à donner les clés de votre compte.

Le rapport ENISA Threat Landscape 2023 documente la hausse des techniques de contournement du MFA à mesure que les organisations généralisent son déploiement.

MFA fatigue et phishing

Le phishing comme préalable

L’attaque MFA fatigue ne peut pas exister sans un mot de passe volé. Et le phishing reste le premier fournisseur de mots de passe volés.

Le scénario type : un collaborateur reçoit un email de spear phishing imitant une notification Microsoft 365 — “Votre session a expiré, reconnectez-vous”. Il clique sur le lien, arrive sur une page qui ressemble à la page de connexion Microsoft, et saisit ses identifiants. L’attaquant récupère le mot de passe en temps réel.

Si le compte est protégé par un MFA push classique, l’attaquant dispose du mot de passe mais pas du deuxième facteur. Il lance alors le bombardement push. Le phishing a ouvert la porte, le MFA fatigue la franchit.

Le credential stuffing joue le même rôle en amont : les mots de passe qui ont fuité dans des violations de données sont testés automatiquement sur des milliers de services. Les hits — les mots de passe qui fonctionnent — deviennent des cibles pour le MFA fatigue.

La double formation nécessaire

Former au phishing sans expliquer le MFA fatigue laisse un angle mort : l’employé ne sait pas quoi faire quand son téléphone l’alerte de connexions non initiées. Former au MFA sans expliquer le phishing donne une fausse assurance : l’employé baisse sa vigilance face aux emails frauduleux sans réaliser que le phishing est la première étape qui rend le MFA fatigue possible.

La formation doit couvrir les deux fronts : reconnaître un email de phishing pour empêcher le vol de mot de passe en amont, et savoir réagir à une notification MFA suspecte pour bloquer l’attaque en aval.

Le rôle du Zero Trust

L’approche Zero Trust traite chaque demande d’accès comme potentiellement malveillante. Le MFA n’est qu’un des signaux évalués : le système vérifie aussi l’état de l’appareil, la géolocalisation et le comportement habituel de l’utilisateur. Un modèle Zero Trust correctement déployé bloque la plupart des tentatives de MFA fatigue avant l’envoi de la première notification.

Testez la vigilance de vos équipes face aux emails de phishing qui précèdent les attaques MFA fatigue. Notre outil de simulation reproduit les scénarios de vol d’identifiants Microsoft 365, Google Workspace et VPN — le point de départ de toute attaque MFA fatigue.