Détecter une attaque par fatigue MFA dans les logs Okta

TL;DR. La fatigue MFA (push bombing) apparaît dans le System Log comme une rafale de system.push.send_factor_verify_push pour un même utilisateur, avec des refus journalisés en user.mfa.okta_verify.deny_push sur Classic Engine ou en user.authentication.auth_via_mfa en échec sur Identity Engine, et parfois un push finalement accepté. Cinq ou plus en 15 minutes justifient une alerte ; un push accepté juste après la rafale, c'est un incident. L'attaquant a déjà le mot de passe : réinitialisez-le, supprimez les sessions, réinitialisez les facteurs et activez le number challenge.

Comment fonctionne l'attaque

L'attaquant possède un mot de passe valide (hameçonné, réutilisé, acheté, obtenu par spraying). Le compte exige un push Okta Verify. Il relance donc la connexion encore et encore jusqu'à ce que l'utilisateur, fatigué, perdu ou rassuré par un faux appel du « support informatique », touche Approuver. MITRE ATT&CK répertorie cette technique sous T1621, Multi-Factor Authentication Request Generation. L'avis conjoint CISA/FBI sur Scattered Spider cite, parmi les techniques du groupe, des demandes MFA répétées qui finissent par être acceptées (CISA AA23-320A).

Rien n'est exploité. Les journaux montrent simplement un utilisateur qui reçoit bien plus de demandes qu'un humain n'en génère.

Ce que l'on voit dans le System Log

La différence Classic / OIE est documentée dans le catalogue des event types d'Okta : l'entrée deny_push indique qu'Identity Engine utilise à la place l'échec générique auth_via_mfa. Les Workflows anti-fatigue MFA d'Okta Security reposent précisément sur ces deux requêtes, une par moteur, avec par défaut plus de cinq refus en une heure (Okta Security : réagir aux demandes push anormales).

Une rafale typique, simplifiée :

09:12:03  system.push.send_factor_verify_push   j.doe   203.0.113.50
09:12:31  user.authentication.auth_via_mfa      j.doe   FAILURE  factor=OKTA_VERIFY_PUSH
09:13:10  system.push.send_factor_verify_push   j.doe   203.0.113.50
09:13:40  user.authentication.auth_via_mfa      j.doe   FAILURE
09:15:02  system.push.send_factor_verify_push   j.doe   203.0.113.50
...
09:21:47  user.authentication.auth_via_mfa      j.doe   SUCCESS   ← celui qui compte

Regardez l'IP : chaque push est déclenché par la connexion de l'attaquant, donc le client.ipAddress de ces événements est le sien, pas celui du téléphone de l'utilisateur.

Une détection défendable

La règle de l'analyseur Okta Forensics (mfa.push_fatigue) est la suivante :

Pourquoi ces valeurs : une vraie connexion produit un push, parfois deux si le téléphone est lent. Cinq en un quart d'heure sort nettement du comportement normal, tout en restant assez bas pour attraper un attaquant patient qui espace ses demandes. Le modèle de Workflow d'Okta utilise une fenêtre plus large d'une heure ; si vous réglez votre propre règle SIEM, testez les deux sur vos données.

Ce qui ressemble à de la fatigue MFA sans en être

• Un utilisateur qui se connecte à de nombreuses applications avec MFA par application, en peu de temps, le matin après un changement de mot de passe. Tous les push sont acceptés et viennent de son réseau habituel. Regardez les résultats et l'IP.
• Un appareil défaillant (notifications retardées puis livrées d'un coup). L'utilisateur réessaie ; vous voyez des envois sans refus.
• Des comptes de service partagés avec MFA par push (une mauvaise idée en soi).

Ce qui départage : le réseau d'origine des connexions déclenchantes, le rapport refus/approbations, et la capacité de l'utilisateur à l'expliquer. Appelez-le sur un numéro connu.

Enquêter sur une alerte

1. Récupérez tous les événements de l'utilisateur sur la journée. Quelle IP et quel ASN ont déclenché les push ? Un hébergeur, un anonymiseur (securityContext.isProxy, debugData.tunnels) ?
2. Un push a-t-il été accepté ? Si oui, trouvez la session (authenticationContext.externalSessionId) créée par cette approbation et listez tout ce qu'elle a fait : cibles SSO, enrôlement de facteur, accès à l'Admin Console.
3. L'attaquant a-t-il enrôlé son propre facteur ? Un user.mfa.factor.activate depuis l'IP de l'attaquant signifie qu'il n'a plus besoin de l'approbation de l'utilisateur. C'est la même tête de pont que dans l'ingénierie sociale du helpdesk.
4. L'utilisateur l'a-t-il signalé ? user.account.report_suspicious_activity_by_enduser apparaît quand un utilisateur utilise le lien de signalement des e-mails de notification de sécurité d'Okta (Okta Help Center). C'est un signal précieux : traitez-le comme un constat de sévérité élevée.
5. Cherchez la même source ailleurs. Un attaquant qui a un mot de passe en a souvent plusieurs. Pivotez sur l'IP dans la vue des entités.

Confinement et durcissement

Dans l'ordre :

1. Supprimez les sessions de l'utilisateur et révoquez ses jetons.
2. Réinitialisez le mot de passe (l'attaquant le connaît) et les facteurs ; réenrôlez par un canal vérifié.
3. Retirez tout facteur enrôlé depuis le réseau de l'attaquant.
4. Enquêtez sur les applications ouvertes avec la session approuvée.

Puis fermez la porte :

• Number challenge. Okta Verify peut exiger que l'utilisateur choisisse le nombre affiché sur l'écran de connexion, pour tous les push ou seulement pour les connexions à risque (Okta Help Center : options d'Okta Verify). La CISA recommande le number matching comme mesure transitoire pour la MFA par push (fiche CISA).
• Des authentificateurs résistants au phishing (de quoi il s'agit) pour les administrateurs d'abord, puis pour tous : il n'y a plus de demande à approuver.
• Le signalement d'activité suspecte activé, avec une procédure qui le traite dans la journée.

FAQ

Quel événement Okta indique un push refusé ?

Sur Classic Engine, user.mfa.okta_verify.deny_push. Sur Identity Engine, un événement user.authentication.auth_via_mfa avec un résultat FAILURE et un facteur push Okta Verify dans debugData. Surveillez les deux.

La fatigue MFA signifie-t-elle que le mot de passe est compromis ?

Presque toujours. Le push est le second facteur : l'attaquant a généralement dû passer l'étape du mot de passe pour le déclencher. Réinitialisez le mot de passe en plus des facteurs.

Qu'est-ce qui arrête le push bombing ?

Le number challenge sur les push Okta Verify limite les approbations à l'aveugle ; les authentificateurs résistants au phishing comme Okta FastPass ou les clés FIDO2 suppriment carrément l'étape d'approbation.

Pour aller plus loin

• Okta Security : utiliser Workflows pour réagir aux demandes push anormales
• MITRE ATT&CK T1621
• Guide d'investigation d'une compromission Okta
• Limites de détection et réglage