MFA-Fatigue-Angriffe in Okta-System-Logs erkennen

Q: Welches Okta-Ereignis zeigt einen abgelehnten Push?

In der Classic Engine user.mfa.okta_verify.deny_push. In der Identity Engine ein user.authentication.auth_via_mfa-Ereignis mit dem Ergebnis FAILURE und einem Okta-Verify-Push-Faktor in debugData. Überwachen Sie beide.

TL;DR. MFA-Fatigue (Push-Bombing) zeigt sich im System Log als Serie von system.push.send_factor_verify_push für einen Benutzer, mit Ablehnungen als user.mfa.okta_verify.deny_push in der Classic Engine oder als fehlgeschlagenes user.authentication.auth_via_mfa in der Identity Engine, manchmal gefolgt von einem akzeptierten Push. Fünf oder mehr in 15 Minuten rechtfertigen einen Alarm; ein akzeptierter Push direkt nach der Serie ist ein Vorfall. Der Angreifer kennt das Passwort bereits: Setzen Sie es zurück, beenden Sie die Sitzungen, setzen Sie die Faktoren zurück und aktivieren Sie Number Challenge.

Wie der Angriff funktioniert

Der Angreifer hat ein gültiges Passwort (per Phishing erbeutet, wiederverwendet, gekauft, gesprayt). Das Konto verlangt einen Okta-Verify-Push. Also löst er wieder und wieder Anmeldungen aus, bis der Benutzer, müde, verwirrt oder durch einen gefälschten Anruf des „IT-Supports“ beruhigt, auf Genehmigen tippt. MITRE ATT&CK führt dies als T1621, Multi-Factor Authentication Request Generation. Die gemeinsame Warnung von CISA und FBI zu Scattered Spider nennt wiederholte MFA-Anfragen, die Beschäftigte schließlich bestätigen, als eine der Techniken der Gruppe (CISA AA23-320A).

Nichts wird ausgenutzt. Die Logs zeigen einfach einen Benutzer, der weit mehr Anfragen bekommt, als ein Mensch erzeugt.

So sieht es im System Log aus

eventType	Classic Engine	Identity Engine	Bedeutung
`system.push.send_factor_verify_push`	ja	ja	ein Push wurde an das Gerät gesendet
`user.mfa.okta_verify.deny_push`	ja	nein	der Benutzer hat den Push abgelehnt
`user.authentication.auth_via_mfa` + `outcome.result = FAILURE` + Push-Faktor	—	ja	Push-Überprüfung fehlgeschlagen oder abgelehnt
`user.authentication.auth_via_mfa` + SUCCESS	ja	ja	eine Faktorüberprüfung war erfolgreich
`user.session.start`	ja	ja	die Anmeldungen, die die Anfragen ausgelöst haben

Der Unterschied zwischen Classic und OIE ist in Oktas Katalog der Event Types dokumentiert: Der Eintrag zu deny_push besagt, dass die Identity Engine stattdessen den allgemeinen auth_via_mfa-Fehlschlag verwendet. Die Push-Fatigue-Workflows von Okta Security nutzen genau diese zwei Abfragen, eine pro Engine, mit einem Standard von mehr als fünf Ablehnungen innerhalb einer Stunde (Okta Security: auf auffällige Push-Anfragen reagieren).

Eine typische Serie, vereinfacht:

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   ← der entscheidende

Achten Sie auf die IP: Jeder Push wird durch die Anmeldung des Angreifers ausgelöst, daher ist client.ipAddress bei diesen Ereignissen seine, nicht die des Telefons des Benutzers.

Eine vertretbare Erkennung

Die Regel im Okta-Forensics-Analyzer (mfa.push_fatigue) lautet:

Parameter	Wert
Gezählte Ereignisse	gesendete Pushes, `deny_push`, fehlgeschlagenes `auth_via_mfa` mit Push-Faktor
Gruppiert nach	Benutzer
Schwellenwert	5 Ereignisse in 15 Minuten → hoch
Hochstufung	ein erfolgreiches `auth_via_mfa` oder `user.mfa.okta_verify` für diesen Benutzer innerhalb von 15 Minuten nach der Serie → kritisch
ATT&CK	T1621

Warum diese Werte: Eine echte Anmeldung erzeugt einen Push, vielleicht zwei, wenn das Telefon langsam ist. Fünf in einer Viertelstunde liegen deutlich außerhalb des Normalen, aber niedrig genug, um einen geduldigen Angreifer zu erwischen, der seine Anfragen verteilt. Die Workflow-Vorlage von Okta nutzt ein breiteres Fenster von einer Stunde; wenn Sie eine eigene SIEM-Regel abstimmen, testen Sie beide an Ihren eigenen Daten.

Was nach MFA-Fatigue aussieht, aber keine ist

Ein Benutzer, der sich in kurzer Zeit bei vielen Apps mit App-spezifischer MFA anmeldet, am Morgen nach einer Passwortänderung. Alle Pushes werden akzeptiert und kommen aus seinem üblichen Netz. Prüfen Sie Ergebnisse und IP.
Ein defektes Gerät (Benachrichtigungen verzögert, dann gebündelt zugestellt). Der Benutzer versucht es erneut; Sie sehen Sendungen ohne Ablehnungen.
Gemeinsam genutzte Dienstkonten mit Push-MFA (an sich schon keine gute Idee).

Entscheidend sind das Quellnetz der auslösenden Anmeldungen, das Verhältnis von Ablehnungen zu Bestätigungen und ob der Benutzer es erklären kann. Rufen Sie ihn unter einer bekannten Nummer an.

Einen Treffer untersuchen

Holen Sie alle Ereignisse des Benutzers für diesen Tag. Welche IP und welche ASN haben die Pushes ausgelöst? Ist es ein Hosting-Anbieter oder ein Anonymisierer (securityContext.isProxy, debugData.tunnels)?
Wurde ein Push akzeptiert? Wenn ja, finden Sie die durch diese Bestätigung entstandene Sitzung (authenticationContext.externalSessionId) und listen Sie alles auf, was sie getan hat: SSO-Ziele, Faktorregistrierung, Zugriff auf die Admin Console.
Hat der Angreifer einen eigenen Faktor registriert? Ein user.mfa.factor.activate von der IP des Angreifers bedeutet, dass er die Zustimmung des Benutzers nicht mehr braucht. Das ist derselbe Brückenkopf wie beim Social Engineering am Helpdesk.
Hat der Benutzer es gemeldet? user.account.report_suspicious_activity_by_enduser erscheint, wenn Benutzer den Meldelink in Oktas Sicherheitsbenachrichtigungen per E-Mail nutzen (Okta Help Center). Das ist ein wertvolles Signal: Behandeln Sie es als hohen Befund.
Suchen Sie dieselbe Quelle anderswo. Ein Angreifer mit einem Passwort hat oft mehrere. Pivotieren Sie in der Entitätenansicht auf die IP.

Eindämmung und Härtung

In dieser Reihenfolge:

Beenden Sie die Sitzungen des Benutzers und widerrufen Sie seine Tokens.
Setzen Sie das Passwort (der Angreifer kennt es) und die Faktoren zurück; registrieren Sie über einen verifizierten Kanal neu.
Entfernen Sie jeden Faktor, der aus dem Netz des Angreifers registriert wurde.
Untersuchen Sie die Anwendungen, die mit der bestätigten Sitzung geöffnet wurden.

Dann schließen Sie die Tür:

Number Challenge. Okta Verify kann verlangen, dass der Benutzer die auf dem Anmeldebildschirm angezeigte Zahl auswählt, bei allen Pushes oder nur bei riskanten Anmeldungen (Okta Help Center: Okta-Verify-Optionen). CISA empfiehlt Number Matching als Übergangsmaßnahme für Push-basierte MFA (CISA-Faktenblatt).
Phishing-resistente Authenticators (was das bedeutet), zuerst für Administratoren, dann für alle: Es gibt keine Anfrage mehr, die man bestätigen könnte.
Meldung verdächtiger Aktivität aktivieren, mit einem Ablauf, der noch am selben Tag darauf reagiert.

FAQ

Welches Okta-Ereignis zeigt einen abgelehnten Push?

In der Classic Engine user.mfa.okta_verify.deny_push. In der Identity Engine ein user.authentication.auth_via_mfa-Ereignis mit dem Ergebnis FAILURE und einem Okta-Verify-Push-Faktor in debugData. Überwachen Sie beide.

Bedeutet MFA-Fatigue, dass das Passwort kompromittiert ist?

Fast immer. Der Push ist der zweite Faktor: Der Angreifer musste in der Regel den Passwortschritt bestehen, um ihn auszulösen. Setzen Sie neben den Faktoren auch das Passwort zurück.

Was stoppt Push-Bombing?

Number Challenge bei Okta-Verify-Pushes verringert blinde Bestätigungen; Phishing-resistente Authenticators wie Okta FastPass oder FIDO2-Schlüssel beseitigen den Schritt des Bestätigens ganz.