Password Spraying im Okta System Log erkennen
Password Spraying, Brute Force und Credential Stuffing gegen Okta erkennen: Fehlschläge pro IP und Benutzer, ThreatInsight und der entscheidende Erfolg.
TL;DR. Password Spraying heißt viele Benutzer, wenige Versuche pro Benutzer, dieselbe Quelle: fehlgeschlagene user.session.start- oder user.authentication.verify-Ereignisse, gruppiert nach client.ipAddress, die innerhalb einer Stunde acht oder mehr Konten mit höchstens etwa drei Versuchen pro Konto treffen. Brute Force ist das Gegenteil: viele Fehlschläge bei einem Konto. Beides zählt erst richtig, wenn danach ein Erfolg aus derselben Quelle folgt, also suchen Sie zuerst diesen Erfolg. Verteilte Angriffe über Residential Proxies entgehen der Gruppierung nach IP; pivotieren Sie zusätzlich nach ASN, User-Agent und ThreatInsight-Ereignissen.
Drei Angriffe, drei Muster
| Angriff | Muster im Log | ATT&CK |
|---|---|---|
| Password Spraying | eine Quelle, viele Benutzer, je 1–3 Versuche | T1110.003 |
| Passwort-Raten (Brute Force) | viele Versuche bei einem Benutzer | T1110.001 |
| Credential Stuffing | bekannte Benutzername/Passwort-Paare, verteilt auf viele Quellen, hohe Erfolgsquote bei wiederverwendeten Passwörtern | T1110.004 |
Spraying bleibt absichtlich unter den Sperrschwellen: eine Handvoll gängiger Passwörter pro Konto, über Hunderte Konten. Deshalb ist die Sperre pro Benutzer keine Erkennung.
Oktas Identity-Threat-Research-Team berichtete im Frühjahr 2024 von großen Credential-Stuffing-Kampagnen, die über Tor und Residential Proxies liefen, sodass der Verkehr von den Geräten gewöhnlicher Nutzer statt von VPS-Anbietern zu stammen schien (Okta Security: Anonymisierungsdienste blockieren). Denken Sie daran, wenn ein Spraying von Hunderten privater IPs „kommt“.
Die Ereignisse
| eventType | Was lesen |
|---|---|
user.session.start mit outcome.result = FAILURE | outcome.reason (zum Beispiel INVALID_CREDENTIALS), IP, ASN, User-Agent |
user.authentication.verify mit FAILURE | dasselbe |
user.session.start mit SUCCESS aus derselben Quelle | die Kompromittierung |
user.account.lock | durch die Versuche ausgelöste Sperren |
security.threat.detected | Anfrage von einer IP, die ThreatInsight als bösartig eingestuft hat |
security.attack.start | ThreatInsight hat erkannt, dass die Organisation angegriffen wird |
security.breached_credential.detected | ein Zugangsdatum aus einem bekannten Datenleck wurde verwendet |
security.threat.detected und security.attack.start sind die zwei Abfragen, die Okta Security zur Überwachung dieser Kampagnen vorschlägt (Quelle). Läuft ThreatInsight im Modus „log and enforce“, können Anfragen von IPs mit hoher Bedrohungsstufe schon vor der Authentifizierung blockiert werden und tauchen nie als fehlgeschlagene user.session.start auf, was die Aussagekraft Ihrer Zählungen verändert.
Wie der Analyzer es erkennt
| Regel | Gruppiert nach | Schwellenwert | Hochstufung |
|---|---|---|---|
access.password_spray | Client-IP | ≥ 8 verschiedene Benutzer mit Fehlschlägen in 1 h, Durchschnitt ≤ 3 Fehlschläge pro Benutzer → hoch | ein erfolgreiches user.session.start von dieser IP innerhalb 1 h → kritisch |
access.brute_force | Benutzer | ≥ 10 Fehlschläge in 15 min → mittel | eine erfolgreiche Anmeldung innerhalb 30 min → hoch |
threat.threatinsight | Client-IP | jedes ThreatInsight-Ereignis oder debugData.threatSuspected = true → mittel | — |
threat.breached_credential | — | jedes security.breached_credential.detected → mittel | — |
Die Bedingung „durchschnittliche Versuche pro Benutzer“ trennt ein Spraying von einem lauten NAT. Eine Büro-Ausgangs-IP, an der am Montagmorgen viele Leute ihr Passwort vertippen, erzeugt viele Benutzer mit je einem Fehlschlag, aber auch einen stetigen Strom von Erfolgen derselben Benutzer. Prüfen Sie die Erfolgsquote, bevor Sie Alarm schlagen.
Ein Spraying aufspüren, das die Regeln übersehen könnten
Die Regel pro IP ist präzise, lässt sich mit einem Proxy-Netz aber leicht umgehen. Ergänzen Sie sie von Hand:
- Gruppieren Sie Fehlschläge nach ASN statt nach IP (
securityContext.asNumber). Eine Hosting-ASN mit Fehlschlägen gegen 50 Ihrer Benutzer ist ein Spraying, auch wenn jede Anfrage eine andere IP nutzt. - Gruppieren Sie nach User-Agent. Spraying-Werkzeuge nutzen oft eine feste, manchmal veraltete User-Agent-Kennung über alle IPs hinweg.
- Sehen Sie sich die angegriffenen Benutzernamen an. Sprays gehen alphabetische Listen durch, enthalten ehemalige Mitarbeitende oder folgen einem Namensschema (
vorname.nachname), das aus öffentlichen Quellen erraten wurde. - Finden Sie die Erfolge. Listen Sie für jede IP, ASN oder jeden User-Agent aus den Fehlschlägen die erfolgreichen Anmeldungen auf. Diese kurze Liste ist Ihr Vorfall.
- Prüfen Sie, was die erfolgreichen Konten danach getan haben: Push-Anfragen (Fatigue-Versuch?), Faktorregistrierung, SSO.
Im Analyzer listet der Reiter Entitäten IPs mit ASN, Land, Anzahl der Ereignisse und Anzahl der Fehlschläge: Sortieren Sie nach Fehlschlägen und klicken Sie bei den wichtigsten Quellen auf Ereignisse.
outcome.reason lesen
Nicht jeder Fehlschlag bedeutet dasselbe, und am Begründungsfeld trennen sich Spraying und Benutzerproblem. INVALID_CREDENTIALS bei vielen Konten aus einer Quelle ist das Spraying selbst. Fehlschläge, die in user.account.lock enden, zeigen, dass der Angreifer Ihre Sperrrichtlinie überschritten hat: nützlich für die Eingrenzung (welche Konten entsperrt werden müssen) und ein Zeichen, dass er nicht vorsichtig war. Eine Reihe von Fehlschlägen eines Benutzers aus seinem üblichen Netz, gefolgt von einem Erfolg aus demselben Netz, ist jemand, der eine Passwortänderung vergessen hat, kein Angriff. Lesen Sie die Begründung immer zusammen mit der Quelle.
Wenn eine Anmeldung erfolgreich war
Ein korrektes Passwort bei einem Konto mit MFA-Pflicht bedeutet, dass der Angreifer nun den zweiten Faktor braucht, und genau das ist die Ausgangslage für MFA-Fatigue oder ein Zurücksetzen durch den Helpdesk. Handeln Sie, bevor er ihn bekommt:
- Setzen Sie das Passwort zurück und beenden Sie die Sitzungen jedes Kontos mit einem Erfolg aus der angreifenden Quelle.
- Prüfen Sie bei jedem Pushes, Faktorregistrierungen und SSO nach dem Erfolg.
- Blockieren Sie die Quelle mit einer Sperrlisten-Netzwerkzone; blockieren Sie Anonymisierer mit einer erweiterten dynamischen Zone.
- Informieren Sie die betroffenen Benutzer: Ihr Passwort ist bekannt und wird möglicherweise anderswo wiederverwendet.
Vorbeugung
- ThreatInsight im Modus „Log and enforce security based on threat level“ statt nur Protokollierung (Okta Help Center).
- Erweiterte dynamische Zonen, um Anonymisierer, Tor und Proxys bei der Anmeldung zu blockieren, eine Maßnahme, die Okta Security für diese Kampagnen empfiehlt (Quelle).
- Passwortlose und Phishing-resistente Authenticators: Es gibt kein Passwort, das man sprayen könnte.
- Schutz vor geleakten Passwörtern, wo verfügbar, und Sensibilisierung der Benutzer für Wiederverwendung.