Beispiel-Zeitleiste eines Okta-Vorfalls (fiktiv)
Ein fiktiver Okta-Einbruch Ereignis für Ereignis: Helpdesk-Reset, Faktor des Angreifers, Super Admin, bösartiger IdP, AWS-Zugriff und die Befunde des Analyzers.
TL;DR. Alles in diesem Artikel ist fiktiv: die Organisation, die Personen, die IP-Adressen (Dokumentationsbereiche), die AS-Nummern (Dokumentationsbereich) und die Domains (.example). Es ist das Beispiel hinter der Schaltfläche Beispiel testen im Analyzer: 160 System-Log-Ereignisse über zwei Tage, in denen ein Angreifer den Helpdesk dazu bringt, Passwort und Faktoren einer IT-Administratorin zurückzusetzen, von einem VPS aus sein eigenes Okta Verify registriert, einem Dienstkonto Super Administrator vergibt, einen eingehenden Identity Provider hinzufügt und damit AWS erreicht. Das Urteil des Analyzers lautet Wahrscheinlich kompromittiert, mit einem kritischen und fünf hohen Befunden. Dieser Durchgang zeigt, wie man es liest.
Die fiktive Ausgangslage
„Northwind Logistics“ (northwind.example) betreibt eine kleine Okta-Organisation: zwölf Konten, ein Büronetz in Lyon, einige Mitarbeitende im Homeoffice und Anwendungen wie Slack, Salesforce, Google Workspace, Jira und AWS IAM Identity Center. Drei Konten sind wichtig:
| Konto | Rolle in der Geschichte |
|---|---|
m.okafor@northwind.example | IT-Administratorin (Super Administrator), am Morgen des Vorfalls krankgemeldet |
h.lambert@northwind.example | Helpdesk-Mitarbeiter |
svc-sync@northwind.example | Dienstkonto für die Verzeichnissynchronisation; meldet sich nie interaktiv an |
Netze: das Büro (198.51.100.10, „Example Telecom“, AS64496), privates Breitband (192.0.2.x, AS64497) und der VPS des Angreifers (203.0.113.77, „Example VPS Hosting Ltd“, AS64511, Amsterdam).
Der 14. September und der Vormittag des 15. sind gewöhnliche Arbeitstage: Passwortanmeldungen, Okta-Verify-Pushes, SSO in Anwendungen, ab und zu ein vertipptes Passwort.
Der Einbruch, Ereignis für Ereignis (2026-09-15, UTC)
| Zeit | eventType | Akteur | Ziel / Detail | Quelle |
|---|---|---|---|---|
| 13:58:40 | user.session.access_admin_app | h.lambert | Okta Admin Console | Büro |
| 14:03:12 | user.account.reset_password | h.lambert | m.okafor | Büro |
| 14:03:40 | user.mfa.factor.reset_all | h.lambert | m.okafor | Büro |
| 14:09:05 | policy.evaluate_sign_on | m.okafor | Risiko HIGH, neues Gerät / neues Land | VPS |
| 14:09:09 | user.session.start | m.okafor | Passwort | VPS |
| 14:10:22 | user.mfa.factor.activate | m.okafor | Okta Verify registriert | VPS |
| 14:10:51 | user.authentication.auth_via_mfa | m.okafor | Okta-Verify-Push | VPS |
| 14:12:30 | user.session.access_admin_app | m.okafor | Okta Admin Console | VPS |
| 14:19:02 | user.account.privilege.grant | m.okafor | svc-sync, „Super administrator“ | VPS |
| 14:26:47 | system.idp.lifecycle.create | m.okafor | IdP „Partner SSO“ | VPS |
| 14:27:10 | system.idp.lifecycle.activate | m.okafor | IdP „Partner SSO“ | VPS |
| 14:33:15 | user.authentication.auth_via_IDP | svc-sync | über „Partner SSO“ | VPS |
| 14:33:16 | user.session.start | svc-sync | Föderations-Assertion | VPS |
| 14:35:18 | user.authentication.sso | svc-sync | AWS IAM Identity Center | VPS |
| 14:36:02 | user.authentication.sso | m.okafor | AWS IAM Identity Center | VPS |
| 15:41:08 | user.session.start FAILURE | m.okafor | INVALID_CREDENTIALS | Zuhause |
| 15:41:52 | user.session.start FAILURE | m.okafor | INVALID_CREDENTIALS | Zuhause |
Lesen Sie es als Geschichte: Um 14:03 setzt der Helpdesk Passwort und Faktoren von Maya zurück (ein Anrufer hatte sich als sie ausgegeben). Sechs Minuten später meldet sich „Maya“ von einem niederländischen VPS an, den sie nie benutzt hat, registriert ein neues Okta Verify und ist keine zehn Minuten später in der Admin Console. Sie macht ein Dienstkonto zum Super Administrator, legt einen eingehenden Identity Provider an, aktiviert ihn und meldet sich darüber als Dienstkonto an. Beide Identitäten öffnen AWS. Um 15:41 kann sich die echte Maya, wieder online von zu Hause, nicht mehr anmelden: Ihr Passwort wurde geändert.
Das ist das Muster aus dem Artikel zu Social Engineering am Helpdesk und dem Artikel zu Cross-Tenant Impersonation, verdichtet auf 33 Minuten.
Was der Analyzer meldet
Urteil: Wahrscheinlich kompromittiert. Statistik: 160 Ereignisse, 12 Benutzer, 5 IP-Adressen, 24 Sitzungen, vom 2026-09-14 07:56 bis 2026-09-15 15:41 UTC.
| Schweregrad | Befund | Schlüssel | Warum er ausgelöst hat |
|---|---|---|---|
| Kritisch (hochgestuft) | Zurücksetzen durch den Helpdesk, dann neuer Faktor registriert | m.okafor | Zurücksetzen durch h.lambert, dann user.mfa.factor.activate innerhalb von 24 h, von einem Hosting-Anbieter / neuen Netz |
| Hoch | Sensible App nach verdächtiger Aktivität geöffnet | m.okafor → Okta Admin Console | Zugriff auf die Admin Console nach dem kritischen Befund |
| Hoch | Super-Administrator vergeben | svc-sync | privilegeGranted = Super administrator |
| Hoch | Neuer Identity Provider (eingehende Föderation) | Partner SSO | Anlage + Aktivierung |
| Hoch | Sensible App nach verdächtiger Aktivität geöffnet | svc-sync → AWS IAM Identity Center | SSO durch ein Konto aus einem hohen Befund; verweist auf AWS Forensics |
| Hoch | Sensible App nach verdächtiger Aktivität geöffnet | m.okafor → AWS IAM Identity Center | ebenso |
| Mittel | Anmeldung von einem Hosting-Anbieter | m.okafor | „Example VPS Hosting Ltd“ passt zur Hosting-Liste |
| Mittel | Anmeldung von einem Hosting-Anbieter | svc-sync | dasselbe Netz |
| Niedrig | Passwort oder Faktoren von einem anderen Benutzer zurückgesetzt | m.okafor | informativer Kontext für die Zeitleiste |
Der kritische Befund allein würde für das Urteil Wahrscheinlich kompromittiert genügen; vier verschiedene hohe Regeln machen es eindeutig.
Zwei Details, die auffallen sollten:
- Die IdP-Anmeldung selbst ist kein eigener Befund.
user.authentication.auth_via_IDPist in Organisationen mit Föderation normal. Hier taucht sie über die Hosting-Regel und die Regel „SSO nach verdächtiger Aktivität“ auf, weilsvc-syncZiel der Super-Administrator-Vergabe war. In einem echten Fall listen Sie jedesauth_via_IDPüber einen neuen IdP von Hand auf. - Auch die fehlgeschlagenen Anmeldungen des Opfers sind kein Befund. Zwei Fehlschläge sind normales Rauschen. Sie stehen trotzdem in der Zeitleiste und markieren in einem echten Fall den Moment, in dem die Benutzerin es bemerkt; fragen Sie, wann sie den Helpdesk angerufen hat.
Die Bearbeitung in der Oberfläche
- Reiter Befunde. Öffnen Sie die Belege des kritischen Befunds: drei Ereignisse (Passwort-Reset, Faktor-Reset, Faktoraktivierung). Akteur der ersten beiden ist
h.lambert, des drittenm.okaforvon203.0.113.77. - Zeitleiste des Vorfalls. Die Belege aller mittleren und höheren Befunde plus die Admin-Aktionen der beteiligten Konten, in zeitlicher Reihenfolge: im Wesentlichen die Tabelle oben, für Sie aufgebaut.
- Entitäten → IP-Adressen.
203.0.113.77(AS64511, Niederlande) hat Ereignisse zweier Benutzer,m.okaforundsvc-sync. Klicken Sie auf Ereignisse, um alles zu sehen, was diese IP getan hat. - Entitäten → Sitzungen. Die Angreifersitzung für
m.okaforenthält Registrierung, Zugriff auf die Admin Console, Rechtevergabe und IdP-Anlage: eine Sitzung, der ganze Angriff. - Behebung. Logs sichern; Sitzungen beenden; Admins prüfen; Prüfung am Helpdesk verschärfen; Faktoren und Passwort zurücksetzen; AWS untersuchen und dort Sitzungen widerrufen; Super-Administrator-Vergabe entziehen; IdP entfernen und Routing-Regeln prüfen; Hosting-Anbieter bei der Anmeldung blockieren; die Benutzerin kontaktieren; an die Incident Response eskalieren.
Was ein Responder als Nächstes täte
- In Okta eindämmen: „Partner SSO“ entfernen, die Admin-Rolle von
svc-syncentziehen, die Sitzungen beider Konten beenden, Maya persönlich neu registrieren. - In AWS weiterverfolgen: Beide Identitäten erreichten AWS IAM Identity Center zwischen 14:35 und 14:36 von
203.0.113.77. CloudTrail ist nun die Hauptquelle; AWS Forensics liest es auf dieselbe Weise. - Den Einstiegspunkt schließen: klären, wie der Helpdesk den Anrufer um 14:03 geprüft hat, und den Ablauf für Zurücksetzungen bei Administratoren ändern.
Selbst ausprobieren
Öffnen Sie den Analyzer, klicken Sie auf Beispiel testen und folgen Sie den obigen Schritten. Lesen Sie danach die Schritt-für-Schritt-Analyse, um dasselbe mit Ihrem eigenen Export zu tun, oder den Untersuchungsleitfaden für die Methode.
Das Beispiel wird von einem Skript im Projekt erzeugt (scripts/make-samples.py), das dem System-Log-Schema LogEvent aus der Entwicklerdokumentation von Okta folgt und eventTypes aus dem Katalog der Event Types verwendet. Die IP-Adressen stammen aus den Dokumentationsbereichen von RFC 5737 und die AS-Nummern aus dem Dokumentationsbereich von RFC 5398; nichts davon verweist auf ein echtes Netz.