TL;DR. Öffnen Sie den Okta-Forensics-Analyzer, legen Sie Ihren System-Log-Export ab (JSON, JSON Lines, CSV, gzip, ZIP oder einen ganzen Ordner) und lesen Sie das Urteil: Keine Anzeichen einer Kompromittierung, Verdächtige Aktivität oder Wahrscheinlich kompromittiert, mit den Befunden, die es begründen. Gehen Sie danach fünf Reiter durch: Befunde (was ausgelöst hat und bei welchen Ereignissen), Zeitleiste des Vorfalls, Entitäten (Benutzer, IPs, Sitzungen, Faktoren, Apps, Admins), Alle Ereignisse (filterbar, exportierbar) und Behebung (eine nach Dringlichkeit geordnete Checkliste). Nichts wird hochgeladen: Der Analyzer ist in Rust geschrieben, nach WebAssembly kompiliert und läuft in Ihrem Browser.

Dies ist der Artikel „welchen Knopf drücke ich“. Für die Methode dahinter (wonach man sucht und warum) lesen Sie zuerst den Leitfaden zur Untersuchung einer Okta-Kompromittierung.

Bevor Sie beginnen

Sie brauchen einen Export des Okta System Log. Der Export-Leitfaden erklärt die Optionen; kurz gesagt: die gesamte Organisation, der längste verfügbare Zeitraum, möglichst rohes JSON aus der API.

Kein Export zur Hand? Klicken Sie auf der Startseite auf Beispiel testen. Das lädt einen synthetischen Export eines fiktiven Vorfalls (160 Ereignisse, erfundene Organisation, IP-Adressen aus Dokumentationsbereichen), damit Sie die Oberfläche an einem Fall kennenlernen, der garantiert Befunde erzeugt. Das Durchspielen des fiktiven Vorfalls erklärt jeden dieser Befunde.

Schritt 1: Dateien laden

Legen Sie Dateien in der Ablagezone ab oder verwenden Sie Dateien auswählen / Ordner auswählen. Was akzeptiert wird:

Eingabe	Hinweise
JSON-Array aus `/api/v1/logs`	mehrere Seiten in einer Datei sind kein Problem
JSON Lines, Zeilen mit Syslog-Präfix	ein Ereignis pro Zeile
Exporte aus EventBridge, Elastic, Splunk	Umschläge `detail`, `_source`, `result` / `_raw` werden entpackt
CSV	Kopfzeilen als LogEvent-Pfade (`actor.alternateId`, `target[0].displayName` …) oder eine `_raw`-Spalte; Komma, Semikolon oder Tabulator
`.gz`, `.zip`, Ordner	im Browser entpackt und durchsucht, verschachtelte ZIPs eingeschlossen

Dateien werden in 4-MB-Blöcken gelesen und an den Analyzer gestreamt, sodass Exporte von mehreren Gigabyte funktionieren; die eigentliche Grenze ist der Speicher für die Ereignisse selbst. Bei sehr großen Exporten (über 200.000 Ereignisse) laufen die Erkennungen weiterhin über alle Ereignisse, die Tabelle zeigt aber alle Belege plus die jüngsten Ereignisse.

Schritt 2: prüfen, was tatsächlich gelesen wurde

Bevor Sie einem Urteil vertrauen, öffnen Sie Analysierte Dateien. Jede Datei zeigt Anzahl der Ereignisse, Format und Größe sowie Hinweise: entfernte Duplikate, Datensätze, die keine System-Log-Ereignisse sind, ungültiges JSON, Ereignisse ohne lesbaren Zeitstempel oder eine Datei, die mitten in einem Ereignis endet (abgeschnittener Export). Nicht analysierte Dateien erklärt jede Ablehnung: leere Datei, kein Okta-Log, eine Tabellenkalkulation statt CSV, ein beschädigtes gzip oder ZIP.

Sehen Sie sich dann die Statistikzeile an: Ereignisse, Benutzer, IP-Adressen, Sitzungen und den Zeitraum (UTC). Entspricht der Zeitraum nicht Ihrem Export, halten Sie an und korrigieren Sie den Export.

Schritt 3: das Urteil lesen

Die Logik des Urteils ist bewusst einfach und sichtbar:

Urteil	Regel
Wahrscheinlich kompromittiert	ein kritischer Befund oder hohe Befunde aus zwei verschiedenen Regeln
Verdächtige Aktivität	jeder andere hohe oder mittlere Befund
Keine Anzeichen einer Kompromittierung	nichts oberhalb von niedrig (niedrige Befunde sind informativ)

Unter Warum stehen die Befunde, die das Urteil bestimmt haben. Ein sauberes Urteil bedeutet, dass keine der 25 Erkennungsregeln auf diese Ereignisse zutraf. Es ist kein Zertifikat; der Artikel zu den Grenzen erklärt, was übersehen werden kann.

Schritt 4: die Befunde prüfen

Jede Befundkarte zeigt einen Schweregrad (kritisch, hoch, mittel, niedrig), ein Abzeichen hochgestuft, wenn eine Folgebedingung ihn angehoben hat (zum Beispiel eine Push-Serie, auf die ein akzeptierter Push folgt), einen aus den Belegen gebildeten Satz, erste und letzte Zeitstempel, die beteiligten Benutzer und IPs, die MITRE-ATT&CK-Techniken und Ereignisse anzeigen, um die Belege in der Ereignistabelle zu öffnen.

Jede Familie wird in einem eigenen Artikel erklärt:

MFA-Anfragen und Zurücksetzungen: MFA-Fatigue, Social Engineering am Helpdesk
Sitzungen: Session Hijacking
Administration und Persistenz: Rollen und API-Tokens, Identity Provider
Angriffe auf die Anmeldung: Password Spraying

Wurde nach verdächtiger Aktivität eine sensible Anwendung geöffnet (AWS, Microsoft 365, Google Workspace, GitHub, Kubernetes-Plattformen …), verweist der Befund auf das Schwester-Tool, das die Logs dieser Plattform liest, zum Beispiel AWS Forensics für CloudTrail.

Schritt 5: die Zeitleiste des Vorfalls durchgehen

Der Reiter Zeitleiste des Vorfalls ordnet die Belege aller mittleren, hohen und kritischen Befunde sowie die Admin-Aktionen der beteiligten Konten zeitlich. Das ist der Entwurf für die Chronologie Ihres Berichts. Wechseln Sie mit dem Schalter zwischen UTC und Lokal; verwenden Sie UTC für alles, was Sie weitergeben.

Schritt 6: nach Entitäten pivotieren

Der Reiter Entitäten listet Benutzer, IP-Adressen (mit ASN und Land), Sitzungen, Faktoren, Apps und Admins, jeweils mit Anzahl der Ereignisse und Fehlschläge, erstem und letztem Auftreten und den Befunden, in denen sie vorkommen. Klicken Sie in einer Zeile auf Ereignisse, und die Ereignistabelle wird auf diese Entität gefiltert. So beantworten Sie „Was hat diese IP sonst noch getan?“ oder „Was ist in dieser Sitzung passiert?“, ohne eine Abfrage zu schreiben.

Schritt 7: Ereignisse filtern und exportieren

Alle Ereignisse kombiniert einen Freitextfilter (Benutzer, IP, eventType, App, Sitzung, Datum), einen Kategoriefilter (Authentifizierung, MFA, Sitzungen, Admin und IdP, Richtlinien, App-Zugriff …), einen Ergebnisfilter und Nur in Befunden. Klicken Sie auf eine Zeile, um jedes relevante Feld zu sehen: Meldung, Ergebnis, Akteur, Ziele, Client, Netz, Sitzung, Faktor, vergebenes Recht, Risiko, Verhaltensmerkmale, Anonymisierungstunnel, ThreatInsight-Kennzeichen, Request-URI, Transaktion und uuid.

CSV und JSON exportieren, was gerade gefiltert ist. Die CSV ist gegen Formel-Injection geschützt und kann gefahrlos in einer Tabellenkalkulation geöffnet werden.

Schritt 8: beheben

Der Reiter Behebung macht aus den Befunden eine nach Dringlichkeit geordnete Checkliste: Logs sichern, Sitzungen beenden, Faktoren und Passwörter zurücksetzen, Admin-Rollen prüfen und entziehen, API-Tokens widerrufen, unbekannte Identity Provider entfernen, Richtlinien wiederherstellen, nachgelagerte Anwendungen untersuchen. Haken Sie Punkte ab, während Sie vorankommen (der Zustand bleibt nur in der Seite). Der Block Nächste Schritte verweist auf Oktas eigene Sicherheitsdokumentation.

Datenschutz in Kürze

Die Logs enthalten personenbezogene Daten. Deshalb hat der Analyzer keinen Upload-Endpunkt: Die Dateien werden lokal in einem Web Worker gelesen, von WebAssembly verarbeitet, und die Ergebnisse bleiben in der Seite. Wenn Sie den Tab schließen, sind sie weg.

Okta System Log analysieren: Schritt für Schritt (gratis)