Fatigue MFA : stopper les attaques push bombing

Un attaquant qui possède le mot de passe peut encore avoir besoin du second facteur. La fatigue MFA, ou push bombing, transforme ce contrôle en pression sociale : multiplier les demandes jusqu’à une approbation par erreur, habitude ou épuisement.

L’attaque ne se limite généralement pas à une notification. Elle associe identifiants volés, usurpation du support, appels en temps réel et création rapide de persistance.

Fonctionnement du push bombing

L’attaquant soumet de vrais identifiants sur le portail légitime, déclenchant une notification sur l’appareil de la victime. Il recommence ou appelle en se faisant passer pour le support. Après approbation, il peut enregistrer un facteur, voler des jetons, créer des règles de messagerie ou atteindre le cloud.

La CISA identifie explicitement le push bombing parmi les menaces contre les formes faibles de MFA.

Détecter la séquence

Les signaux forts sont :

• nombreuses notifications refusées ou expirées ;
• demandes depuis un pays, ASN ou appareil nouveau ;
• approbation après une rafale d’échecs ;
• enrollment d’un facteur ou reset juste après ;
• contact du help desk pendant la rafale ;
• session depuis une IP étrangère à l’historique ;
• nouveau grant OAuth, règle de boîte ou action privilégiée.

Une notification refusée peut être une erreur. Vingt demandes suivies d’un nouvel appareil constituent un incident.

Réduire la surface d’attaque

Migrer vers une authentification résistante

FIDO2, WebAuthn, passkeys et clés matérielles lient l’authentification à l’origine légitime. L’attaquant ne peut pas rejouer une approbation ou un code capturé ailleurs.

Utiliser le number matching en transition

Le number matching complique l’approbation aveugle. Affichez application et localisation, et interdisez l’approbation d’une connexion non initiée.

Limiter les demandes

Appliquez une limite par compte, appareil et source, avec backoff. Évitez qu’elle devienne un moyen simple de déni de service.

Protéger enrollment et récupération

Exigez une réauthentification forte pour ajouter un facteur. Alertez sur les modifications et empêchez qu’une procédure support faible contourne tout le dispositif.

Détection et automatisation SOC

Envoyez au SIEM compte, IP, appareil, application, facteur, résultat et identifiant de corrélation. Enrichissez les sources avec la réputation IP et comparez-les à l’historique utilisateur.

Automatisez d’abord les actions réversibles : augmenter le risque, imposer une réauthentification, révoquer les sessions suspectes et ouvrir un incident. Un verrouillage large à chaque rafale peut servir l’attaquant.

Reliez la détection au guide sur le vol de jetons de session. Une notification approuvée peut ouvrir une chaîne d’abus plus longue.

Playbook utilisateur et help desk

L’utilisateur doit refuser et contacter le support via un canal connu. Le support ne doit jamais demander d’approuver une notification. Après signalement :

1. révoquez ou placez à risque les sessions ;
2. vérifiez l’utilisateur par une procédure approuvée ;
3. réinitialisez les secrets compromis ;
4. retirez facteurs et appareils inconnus ;
5. inspectez grants, transferts et actions privilégiées ;
6. conservez IP et chronologie.

Formez le help desk à résister à l’urgence et à l’autorité simulée.

Métriques

Suivez rafales, approbations après refus, délai de révocation, nouveaux facteurs, couverture de la MFA résistante et incidents avec contact du support. Mesurez la migration selon le niveau de privilège.

Conclusion

La fatigue MFA réussit lorsqu’une décision devient réflexe. Remplacez le push simple par une authentification liée à l’origine, détectez la séquence complète et simplifiez le signalement. Croisez l’identité avec la réputation IP en temps réel pour transformer la rafale en alerte précoce.