Un seul objectif : réduire les validations accidentelles quand un attaquant bombarde l’utilisateur de demandes MFA.
À utiliser comme aide-mémoire lors d’un audit MFA, d’un durcissement rapide, ou d’un incident “push spam”.
Une attaque par fatigue MFA consiste à provoquer une série de demandes d’approbation, jusqu’à obtenir un “Oui” par erreur ou par lassitude.
Fait vérifié : un mot de passe volé peut déclencher des demandes répétées que la victime finit parfois par accepter (source : https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa).
L’idée à retenir : plus de notifications ne veut pas dire plus de sécurité. Si l’utilisateur est inondé, il finit par “faire cesser le bruit”.
Votre levier principal est simple : rendre chaque approbation plus intentionnelle, et rendre les rafales de refus visibles et actionnables.
##Signaux simples à vérifier tout de suite
- -Notification d’approbation MFA alors que l’utilisateur n’a lancé aucune connexion
- -Plusieurs notifications MFA en peu de temps (même compte, même appareil ou non)
- -Suite de refus (“Non”, “Deny”) avant un “Oui” final
- -Demandes MFA en dehors des heures habituelles de l’utilisateur
- -Connexion réussie après une rafale de prompts MFA
- -Tickets support du type “je reçois plein de demandes, je n’ai rien fait”
##Chemin d’action en 30 minutes (triage puis durcissement)
##Contrôles anti-fatigue MFA : quoi configurer, quoi détecter, quoi prouver
Groupe 1 : 1) Rendre l’approbation intentionnelle (prévention)
- ->Activer le number matching sur les applications et comptes à risque
- ->Exiger une interaction claire (pas un simple “Accepter” sans contexte)
- ->Former la règle simple : “si je n’ai rien lancé, je refuse et je signale”
Groupe 2 : 2) Réduire la rafale de prompts (durcissement)
- ->Limiter les demandes MFA répétées (seuil et fenêtre de temps)
- ->Bloquer temporairement après trop de demandes ou trop de refus
- ->Éviter les parcours qui réessaient automatiquement sans action utilisateur
Groupe 3 : 3) Détecter la fatigue en logs (détection)
- ->Alerter sur les rafales de refus MFA (même compte, court délai)
- ->Alerter sur “refus, refus, acceptation” dans une même séquence
- ->Surveiller les connexions réussies après une série de prompts MFA
Groupe 4 : 4) Preuves à collecter (support et incident)
- ->Preuve de configuration : number matching activé (capture écran ou export de config)
- ->Preuve de limitation : règle de seuil/délai en place (policy, paramètre, ticket de change)
- ->Preuve de détection : règle d’alerte sur rafales de refus + exemple d’événement
##Flux opérationnel : de la demande MFA à la décision
Carte simple du mécanisme, pour aligner utilisateur, support et sécurité sur les mêmes réflexes.
- ├─Un attaquant obtient un mot de passe (phishing, fuite, réutilisation)
- ├─Il tente des connexions et provoque des demandes MFA répétées
- └─Il vise une validation “pour que ça s’arrête”
- ├─Une notification d’approbation arrive sans action volontaire
- ├─Les demandes reviennent en boucle
- └─La tentation est de cliquer “Accepter” par automatisme
- ├─Rafales de refus MFA sur un même compte
- ├─Répétition de prompts sur une courte fenêtre
- └─Acceptation finale après plusieurs refus
- ├─Si l’utilisateur n’a rien initié : refuser, signaler, réinitialiser les identifiants
- ├─Si la rafale est confirmée : limiter les demandes et activer number matching
- └─Si doute sur compromission : investigation ciblée + rotation des secrets
##Questions rapides (pour trancher sans débat)
Idée fausse : “J’ai de la MFA, donc un mot de passe compromis ne sert à rien” ?
À traiter comme une hypothèse risquée. Certaines MFA basées sur des notifications peuvent être contournées par fatigue si l’utilisateur finit par approuver.
Quel est le signal le plus simple côté utilisateur ?
Une demande d’approbation qui arrive alors qu’il n’a lancé aucune connexion. La consigne doit être : refuser et signaler.
Qu’est-ce qui réduit le mieux les validations accidentelles ?
Rendre l’approbation plus intentionnelle (ex. number matching) et limiter les rafales de demandes. Ce sont les deux leviers les plus directs.
Que dois-je alerter en priorité côté logs ?
Les rafales de refus MFA, et la séquence “refus/refus/acceptation”. Ce sont des motifs simples et exploitables en opérationnel.
Test de clarté : puis-je expliquer ce mécanisme sans citer un produit ?
Oui : “Quelqu’un sonne sans arrêt. À force, on ouvre pour avoir la paix.” Si vous ne pouvez pas l’expliquer ainsi, vos messages internes seront trop vagues.