Okta-Kompromittierung untersuchen: der Leitfaden
So untersuchen Sie eine Okta-Kompromittierung im System Log: Umfang, wichtige eventTypes, die Angriffskette Schritt für Schritt und was zuerst einzudämmen ist.
TL;DR. Eine Okta-Kompromittierung hinterlässt fast immer eine lesbare Spur im System Log: ein Zurücksetzen oder eine Flut von MFA-Anfragen, eine Anmeldung aus einem Netz, das der Benutzer nie verwendet hat, ein neuer Faktor, danach Admin-Aktionen (Rollen, API-Tokens, Identity Provider) und Single Sign-on in die Anwendungen, auf die es ankommt. Exportieren Sie mindestens die vollen 90 Tage Aufbewahrung, lesen Sie sie als Abfolge statt als einzelne Alarme, dämmen Sie in der Reihenfolge Sitzungen → Faktoren → Admin-Rechte → Tokens und IdPs → nachgelagerte Apps ein und untersuchen Sie jede vom Angreifer geöffnete Anwendung in deren eigenen Logs. Der kostenlose Okta-Forensics-Analyzer übernimmt die Korrelation in Ihrem Browser, ohne etwas hochzuladen.
Ich habe viele Zeitleisten von Identitätsvorfällen gelesen, und das Muster ist fast langweilig konstant: Der Angreifer nutzt keine Schwachstelle im Identity Provider aus. Er bringt eine Person oder einen Helpdesk-Mitarbeiter dazu, ihm Zugang zu verschaffen, und verwendet dann die Admin-Funktionen genau so, wie sie gedacht sind. Das ist eine gute Nachricht für Incident Responder, denn was so gedacht ist, wird protokolliert. Dieser Leitfaden beschreibt meine Methode; der Rest der Serie „Einen Okta-Tenant untersuchen“ vertieft jeden Schritt.
Schritt 0: die Fragen festlegen
Schreiben Sie sie auf, bevor Sie die erste Logzeile öffnen. Eine Kompromittierungsuntersuchung muss fünf Dinge beantworten:
- Erstzugriff. Welches Konto wurde zuerst übernommen, wann und wie (Passwort-Raten, MFA-Fatigue, Zurücksetzen durch den Helpdesk, gestohlene Sitzung)?
- Rechte. Hat der Angreifer einen Administrator erreicht oder sich selbst Admin-Rechte gegeben?
- Persistenz. Was hat er hinterlassen: zusätzliche Admins, API-Tokens, einen neuen Identity Provider, geschwächte Richtlinien?
- Reichweite. Welche nachgelagerten Anwendungen hat er per SSO geöffnet?
- Eindämmungsstatus. Ist irgendetwas davon gerade noch aktiv?
Alles Weitere beantwortet eine dieser Fragen.
Schritt 1: das ganze Log holen, keine gefilterte Ansicht
Die System-Log-API liefert nur 90 Tage an Daten, wie Oktas System-Log-Abfrageleitfaden dokumentiert. Starten Sie den Export jetzt, bevor Beweise verfallen, und exportieren Sie die gesamte Organisation statt einer Suche nach einem Benutzer: Die meisten nützlichen Korrelationen (ein Zurücksetzen durch jemand anderen, eine Admin-Rolle für ein anderes Konto) stecken in Ereignissen, in denen Ihr Verdächtiger das Ziel ist, nicht der Akteur.
Der Leitfaden zum Export des System Log behandelt die API, den CSV-Export der Admin Console, Log Streaming und SIEM-Exporte, einschließlich der Paginierungsfalle, die unbemerkt Ereignisse verliert.
Schritt 2: die gesuchte Angriffskette kennen
Diese Kette ist nicht theoretisch. Im August 2023 beschrieb Okta Security Angreifer, die IT-Servicedesks anriefen, um die Faktoren privilegierter Benutzer zurücksetzen zu lassen, den so erlangten Super-Administrator-Zugang nutzten, um anderen Konten Rechte zu geben, und einen zweiten Identity Provider einrichteten, um sich als andere Benutzer anzumelden (Okta Security, Cross-Tenant Impersonation). Die gemeinsame Warnung von CISA und FBI zu Scattered Spider beschreibt dieselben Technikfamilien, darunter Identitätstäuschung gegenüber dem Helpdesk und wiederholte MFA-Anfragen (CISA AA23-320A).
Jeder Schritt hat eine kurze Liste von eventTypes:
| Schritt | Was passiert | Wichtige eventTypes | Vertiefung |
|---|---|---|---|
| Erstzugriff | Push-Flut, Helpdesk-Zurücksetzen, Spraying, gestohlenes Cookie | system.push.send_factor_verify_push, user.mfa.okta_verify.deny_push, user.mfa.factor.reset_all, user.session.start (FAILURE) | MFA-Fatigue, Helpdesk-Zurücksetzungen, Spraying, Session Hijacking |
| Brückenkopf | Angreifer registriert eigenen Faktor | user.mfa.factor.activate | Helpdesk-Zurücksetzungen |
| Admin-Zugriff | Admin Console geöffnet | user.session.access_admin_app | Admin-Missbrauch |
| Rechte und Persistenz | Rollen, Tokens, Richtlinien | user.account.privilege.grant, group.privilege.grant, system.api_token.create, policy.lifecycle.deactivate | Admin-Missbrauch |
| Föderations-Hintertür | Neuer eingehender IdP, Anmeldung darüber | system.idp.lifecycle.create, user.authentication.auth_via_IDP | Cross-Tenant Impersonation |
| Reichweite | SSO zu AWS, Microsoft 365, GitHub … | user.authentication.sso | dieser Leitfaden, Schritt 6 |
Die vollständige Nachschlagetabelle finden Sie unter die eventTypes, die Responder wirklich brauchen.
Schritt 3: Patient null finden
Arbeiten Sie sich von den stärksten Signalen nach unten:
- Zurücksetzungen durch jemand anderen. Filtern Sie
user.mfa.factor.reset_all,user.mfa.factor.deactivateunduser.account.reset_password, bei denen der Akteur nicht das Ziel ist. Suchen Sie danach kurz darauf einuser.mfa.factor.activatedes Ziels. Kommt diese Registrierung aus einem Netz, das der Benutzer nie zuvor genutzt hat, haben Sie vermutlich den Einstiegspunkt. - Push-Serien. Mehrere Push-Anfragen oder Ablehnungen für einen Benutzer innerhalb weniger Minuten, vor allem wenn am Ende eine akzeptiert wird.
- Fehlgeschlagene Anmeldungen vieler Benutzer von einer IP, gefolgt von einem Erfolg.
- Eine Sitzung, mehrere Netze. Dieselbe externalSessionId aus zwei ASNs ist die klassische Spur eines wiederverwendeten Sitzungscookies.
- Woher die Anmeldung kam.
securityContext.asOrg,securityContext.isProxyunddebugContext.debugData.tunnelszeigen, ob die Quelle ein Hosting-Anbieter, ein Proxy oder Tor ist. Mitarbeitende melden sich selten von einem VPS an.
Schritt 4: der Admin-Spur folgen
Sobald Sie das kompromittierte Konto kennen, pivotieren Sie darauf als Akteur. Listen Sie alles auf, was es als Administrator zwischen seiner ersten verdächtigen Anmeldung und jetzt getan hat: Rollenvergaben (debugContext.debugData.privilegeGranted nennt die Rolle), API-Tokens, Identity Provider, Routing-Regeln, Änderungen an Richtlinien und Authenticators, Netzwerkzonen, ThreatInsight-Einstellungen. Wiederholen Sie den Pivot dann für jedes Konto, das es angefasst hat: Ein frisch beförderter Admin oder ein Dienstkonto, das sich über einen neuen IdP anmeldet, ist die zweite Identität des Angreifers, die Sie nicht übersehen dürfen.
Schritt 5: die Zeitleiste aufbauen
Eine belastbare Zeitleiste hat eine Zeile pro Ereignis, in UTC, mit Akteur, Ziel, Quell-IP und ASN, Sitzung und Ergebnis. Bewahren Sie die rohe uuid jedes Ereignisses auf, damit jeder Ihre Lesart mit dem Original-Log abgleichen kann. Das Durchspielen eines fiktiven Vorfalls zeigt, wie das bei einem vollständigen, wenn auch erfundenen Einbruch aussieht.
Schritt 6: dem Angreifer in die Anwendungen folgen
user.authentication.sso sagt Ihnen, welche Anwendungen wann und von wo geöffnet wurden, aber nichts darüber, was darin geschah. Das Audit-Log der Anwendung selbst ist die nächste Station. Sitzungen in diesen Anwendungen überdauern zudem die Okta-Sitzung: Wer die Okta-Sitzung beendet, meldet den Angreifer dort nicht ab. Für AWS ist CloudTrail die Quelle; das Schwester-Tool AWS Forensics liest es so, wie diese Website das System Log liest. Für Microsoft 365 und Entra ID leistet M365 Forensics dasselbe.
Schritt 7: in der richtigen Reihenfolge eindämmen
Die Reihenfolge zählt, weil manche Stellungen des Angreifers die Entfernung anderer überleben:
- Sichern Sie den Export, bevor Sie irgendetwas ändern.
- Beenden Sie die Sitzungen der betroffenen Benutzer und widerrufen Sie deren Tokens.
- Setzen Sie Faktoren und Passwörter zurück und registrieren Sie den echten Benutzer über einen verifizierten Kanal neu.
- Entfernen Sie unerwartete Admin-Rollen, beginnend mit Super Administrator.
- Widerrufen Sie API-Tokens, die während des Vorfalls erstellt wurden: API-Tokens tragen die Rechte ihres Erstellers und hängen nicht von dessen Passwort ab.
- Deaktivieren Sie unbekannte Identity Provider und prüfen Sie die Routing-Regeln.
- Stellen Sie Richtlinien, Authenticators und Sicherheitseinstellungen wieder her.
- Widerrufen Sie Sitzungen in nachgelagerten Apps und untersuchen Sie diese.
Oktas Empfehlungen zur Kampagne von 2023 ergänzen Härtungsmaßnahmen für den Plan nach dem Vorfall: Phishing-resistente Authenticators, strengere Prüfung durch den Helpdesk und erneute Authentifizierung für sensible Admin-Aktionen (Okta Security).
Mit dem Analyzer
All das lässt sich von Hand in einem SIEM oder einer Tabellenkalkulation erledigen. Der Okta-Forensics-Analyzer automatisiert die Korrelation: Legen Sie den Export ab, und er wendet 25 Erkennungsregeln (Schwellenwerte, Sequenzen und Folgebedingungen) auf jedes Ereignis an und liefert ein Urteil (Keine Anzeichen einer Kompromittierung, Verdächtige Aktivität oder Wahrscheinlich kompromittiert) mit Begründung, eine Zeitleiste, einen Entitäten-Pivot und eine nach Dringlichkeit geordnete Checkliste zur Behebung. Alles läuft lokal in WebAssembly; die Logs verlassen Ihren Rechner nie. Die Schritt-für-Schritt-Anleitung zeigt jede Ansicht.
FAQ
Wie weit kann ich in Okta zurückblicken?
Die System-Log-API liefert 90 Tage an Ereignissen. Ältere Daten gibt es nur, wenn sie vorher an ein SIEM oder einen Speicher gestreamt oder exportiert wurden.
Welches Konto sollte ich zuerst prüfen?
Administratoren, dann jedes Konto, dessen Passwort oder Faktoren von jemand anderem zurückgesetzt wurden, dann Konten mit Anmeldungen von Hosting-Anbietern oder Anonymisierern. Diese Reihenfolge folgt dem Ablauf jüngerer Identitätsangriffe.
Beweist ein sauberes Ergebnis, dass der Tenant sicher ist?
Nein. Es deckt nur die Ereignisse im Export ab. Prüfen Sie den Zeitraum, prüfen Sie, dass der Export nicht gefiltert war, und bestätigen Sie mit den beteiligten Personen. Der Leitfaden zu Grenzen und Feinabstimmung listet die blinden Flecken.