Comptes et authentification
Particuliers et entreprisesHarcèlement aux demandes de validation
MFA fatigue / Push bombing
Des demandes de connexion répétées cherchent à vous faire accepter par lassitude.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Votre téléphone affiche plusieurs demandes de validation que vous n’avez pas déclenchées. Après plusieurs refus, une personne se présente comme le support et vous demande d’accepter pour arrêter le problème. La répétition et le faux dépannage cherchent à transformer un refus en approbation.
Comment cela fonctionne
La fatigue MFA vise les doubles authentifications qui vous demandent d’approuver une connexion par notification. L’attaquant connaît souvent déjà votre mot de passe. Il multiplie les demandes en espérant que la lassitude, la confusion ou l’habitude vous fera accepter. Refusez et signalez toute demande inconnue. Si les notifications cessent après une approbation, cela ne signifie pas que le compte est à nouveau sûr.
- Les demandes arrivent
Vous ne les avez pas initiées.
- La répétition fatigue
Un faux support peut insister.
- Une approbation ouvre l’accès
La session doit alors être révoquée.
Les signes qui doivent attirer l’attention
- Des validations arrivent sans connexion de votre part.
- Les notifications se répètent à des horaires inhabituels.
- Un appel tente de vous convaincre d’accepter une demande inconnue.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Refusez une demande de connexion que vous n’avez pas lancée. Si elles se répètent, contactez le vrai support ; accepter pour faire cesser les notifications peut ouvrir le compte à l’attaquant.
Si vous êtes responsable du service ou de l’organisation
Limitez les demandes répétées et privilégiez les méthodes liées au vrai service. Après une acceptation suspecte, vérifiez les sessions et les nouveaux moyens de récupération.
Appuyer sur une notification peut autoriser la connexion de l’attaquant. Cette validation ne répare pas le compte.
À vous de décider
Les notifications cessent dès que vous appuyez sur « Accepter ». Le problème est-il résolu ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Pas forcément. L’acceptation peut avoir ouvert la session de l’attaquant. Faites fermer les sessions concernées et vérifier les changements apportés au compte.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Une succession de demandes MFA finit par être acceptée
Parmi les demandes de validation, c1 est refusée, c2 expire et c3 est acceptée. Reliez cette acceptation à l’authentification a10, à la session s9 et aux actions suivantes. Le moyen de récupération m9, ajouté ensuite, peut permettre un retour sans passer par le facteur initial.
Une demande acceptée prouve une validation du facteur, pas que la personne a compris ou souhaité la connexion. Elle peut avoir cédé aux notifications, suivi un faux appel du support ou validé par erreur. Il faut lui demander ce qu’elle a vu et fait, sans déduire son intention du statut technique.
Limiter les notifications et afficher le contexte de connexion réduisent les validations accidentelles. La correspondance de nombres améliore le dispositif, mais une personne peut encore être amenée à saisir le nombre fourni au téléphone. Les méthodes résistantes à l’hameçonnage, liées au service auquel on se connecte, traitent un problème plus large. Le support et la récupération de compte doivent offrir un niveau de protection cohérent.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Connexion avec premier facteur
Initiateur vers Fournisseur d’identité
Trace auth_tx a8
- Action
Challenge c1 refusé
Fournisseur d’identité vers Titulaire
Trace résultat denied
- Action
Nouvelle tentative a10
Initiateur vers Fournisseur d’identité
Trace même compte
- Action
Challenge c3 approuvé
Fournisseur d’identité vers Titulaire
Trace méthode et instant
- Réponse
Émission de la session s9
Fournisseur d’identité vers Initiateur
Trace auth_tx a10
- Action
Action sensible via s9
Initiateur vers Application métier
Trace audit applicatif
- Action
Ajout du facteur m9
Initiateur vers Fournisseur d’identité
Trace audit d’enrôlement
Comment repérer cette attaque
Indices à rechercher
Rechercher les séries de demandes MFA refusées ou expirées, une acceptation inattendue et les ajouts de facteurs ou changements de récupération qui suivent.
Quelles informations comparer
Reconstituer refus ou expirations → authentification acceptée → action sensible. Faire confirmer par l’utilisateur s’il a initié la connexion et ce qu’il a validé, sans lui demander son code.
Ce que ces indices ne permettent pas de conclure
Plusieurs refus peuvent venir d’une connexion légitime mal comprise. Une MFA réussie confirme une validation technique, pas le consentement éclairé de la personne à l’action ultérieure.
Comment réagir
Révoquer les sessions et jetons concernés, retirer les facteurs non reconnus et vérifier les sessions locales des applications. Réenrôler depuis un appareil fiable, après validation de l’identité indépendante du canal compromis. Préserver les identifiants de transaction et les modifications de stratégie avant leur correction.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- Simuler en environnement de test deux refus puis une approbation et vérifier la corrélation avec la session exacte.
- Vérifier qu’une preuve de MFA reprise d’un ancien jeton n’est pas comptée comme une nouvelle validation.
- Confirmer qu’un ancien cookie et la méthode de récupération ajoutée ne permettent plus d’accès.
À vous de raisonner
Après plusieurs refus, une demande MFA est acceptée et un moyen de récupération est ajouté. Quel enchaînement devez-vous reconstituer ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Reliez la demande acceptée à la connexion, à la session puis à l’ajout du moyen de récupération. Demandez au titulaire ce qu’il pensait valider. Le statut « accepté » ne prouve pas son intention ; fermer la session sans retirer le moyen de récupération laisserait une possibilité de retour.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
auth_tx- Identifiant commun choisi pour l’exemple ; utiliser l’identifiant de transaction ou de corrélation réellement exposé par le fournisseur.
approved- Validation de la sollicitation dans le cas, distincte de l’approbation d’un ajout de moyen de récupération.
Challenges et émission de session
JSONLJeu synthétique : les identifiants permettent de suivre les challenges sans enregistrer de secret.
{"ts":"10:00:02Z","user":"u7","challenge":"c1","result":"denied","auth_tx":"a8"}
{"ts":"10:00:21Z","user":"u7","challenge":"c2","result":"timeout","auth_tx":"a9"}
{"ts":"10:00:44Z","user":"u7","challenge":"c3","result":"approved","auth_tx":"a10"}
{"ts":"10:00:45Z","user":"u7","auth_tx":"a10","session":"s9","action":"token_issued","device_trust":"unknown"}
{"ts":"10:02:06Z","session":"s9","action":"recovery_method_added","method":"m9"}Préparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Microsoft Entra ID — Sign-in logs
- Où les trouver
- Centre d’administration Entra → Entra ID → Monitoring & health → Sign-in logs. Examiner séparément les connexions interactives, non interactives et celles des applications si elles sont concernées.
- Quoi relever
- Ouvrir les détails d’authentification des connexions : méthode MFA, résultat des étapes, heure, compte, application et contexte de la demande. Selon le fournisseur, toutes les notifications ne sont pas exportées individuellement.
- Accès et prérequis
- Rôle de lecture adapté, par exemple Reports Reader. Vérifier la période conservée et les exports disponibles ; une session applicative n’engendre pas nécessairement une nouvelle connexion Entra.
Microsoft Entra ID — Audit logs
- Où les trouver
- Centre d’administration Entra → Entra ID → Monitoring & health → Audit logs. Filtrer les changements sur le compte ou l’application, puis ouvrir les détails de l’activité.
- Quoi relever
- Après l’acceptation suspecte, rechercher ajout de méthode d’authentification, changement de récupération ou consentement applicatif. Relever l’acteur et la cible de chaque changement.
- Accès et prérequis
- Droits de lecture et rétention suffisants. Ces journaux décrivent des modifications d’annuaire ; ils ne recensent pas toutes les lectures effectuées dans une boîte mail.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- GroupeLAPSUS$
Noms et appellations : DEV-0537 ; Strawberry Tempest depuis 2023 chez Microsoft
Acheter des accès et détourner l’assistance
Microsoft décrit des appels à l’assistance, des demandes répétées de validation MFA et le recrutement rémunéré de salariés ou de prestataires. Les attaquants utilisent ensuite des accès légitimes pour voler des données et pratiquer l’extorsion.
Ce qu’établit la source. Attribution de Microsoft fondée sur ses investigations. Le modèle décrit est l’extorsion et la destruction, sans déploiement de rançongiciel observé dans ce rapport.
Consulter le rapport DEV-0537 criminal actor targeting organizations for data exfiltration and destructionMicrosoft · Publié le
- àGroupeScattered Spider / Octo Tempest
Le support et les identités comme portes d’entrée
Les attaquants imitent des contacts de confiance, appellent l’assistance et détournent des numéros de téléphone. Pour prendre le contrôle des comptes, ils associent hameçonnage, interception de connexions et pression pour faire accepter les validations MFA.
Ce qu’établit la source. Microsoft décrit Octo Tempest comme un périmètre recoupant Scattered Spider, 0ktapus et UNC3944. Ces noms de suivi ne sont pas nécessairement des synonymes exacts.
Consulter le rapport Octo Tempest crosses boundaries to facilitate extortion, encryption, and destructionMicrosoft · Publié le
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.
Si vous pensez être concerné
- Changez le secret depuis un appareil fiable si des demandes inconnues indiquent une exposition possible.
- Si vous avez approuvé, révoquez les sessions et contrôlez les actions récentes.
- Vérifiez qu’aucun facteur ou moyen de récupération inconnu n’a été ajouté.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Multi-Factor Authentication Request Generation — attack.mitre.org
- OWASP — Multifactor Authentication — cheatsheetseries.owasp.org
- NIST SP 800-63B-4 — authentification et résistance au phishing — pages.nist.gov
- Microsoft — détails des connexions — learn.microsoft.com
