Missbrauch von Super-Admin-Rolle und API-Tokens in Okta
Okta-Admin-Rollen, API-Tokens, geschwächte Richtlinien und Support-Zugriffe im System Log finden, von Routinearbeit abgrenzen und Persistenz entfernen.
TL;DR. Hat ein Angreifer einen Okta-Administrator in der Hand, sorgt er dafür, ihn zu behalten: ein zweiter Super Administrator (user.account.privilege.grant mit debugData.privilegeGranted), ein API-Token (system.api_token.create), das Passwort- und MFA-Zurücksetzungen übersteht, und geschwächte Abwehr (policy.*, security.authenticator.lifecycle.deactivate, zone.*). Listen Sie jede Admin-Aktion des kompromittierten Kontos ab seiner ersten verdächtigen Anmeldung auf, dann die jedes Kontos, das es befördert hat. Entfernen Sie Tokens und Rollen, bevor Sie irgendjemandem sagen, der Vorfall sei eingedämmt.
Warum Admin-Persistenz wichtiger ist als der Einstiegspunkt
Das zuerst kompromittierte Konto wird meist bemerkt und zurückgesetzt. Was der Angreifer in der Zwischenzeit damit getan hat, hält ihn drin. Die Darstellung von Okta Security zur Kampagne von 2023 beschreibt kompromittierte Super-Administrator-Konten, mit denen anderen Konten höhere Rechte zugewiesen, Authenticators bestehender Admins zurückgesetzt und in einigen Fällen die Anforderung eines zweiten Faktors aus Authentifizierungsrichtlinien entfernt wurde (Okta Security). Jede dieser Aktionen wird protokolliert.
Beteiligte MITRE-ATT&CK-Techniken: T1098.003 Additional Cloud Roles, T1098.001 Additional Cloud Credentials, T1556.006 Multi-Factor Authentication (Schwächung der MFA).
Vergabe von Admin-Rollen
| eventType | Bedeutung | Zu lesendes Feld |
|---|---|---|
user.account.privilege.grant | die Admin-Rechte eines Benutzers haben sich geändert | debugContext.debugData.privilegeGranted, target |
group.privilege.grant | eine Gruppe hat Admin-Rechte erhalten | danach prüfen, wer in der Gruppe ist |
user.account.privilege.revoke | alle Admin-Rechte eines Benutzers entzogen | wer aufgeräumt hat und wann |
user.session.access_admin_app | Admin Console geöffnet | erster Admin-Zugriff aus einem neuen Netz |
Der Katalog vermerkt, dass user.account.privilege.grant die Liste der Rechte enthält, die der Benutzer aktuell hat (Event Types). Der Analyzer teilt Vergaben in zwei Regeln: Super-Administrator vergeben (hoch), wenn privilegeGranted Super Administrator nennt, und Admin-Rolle vergeben (mittel) für jede andere Rolle.
Was eine Vergabe verdächtig macht:
- der Empfänger ist ein Dienstkonto oder ein ruhendes Konto, mit dem sich niemand interaktiv anmeldet;
- der Vergebende hat sich Minuten vorher aus einem neuen Netz oder nach einem Faktor-Zurücksetzen angemeldet;
- die Vergabe erfolgt außerhalb Ihres Änderungsprozesses (kein Ticket, ungewöhnliche Uhrzeit für diesen Admin);
- eine Gruppe erhält Admin-Rechte, und danach wird jemand hinzugefügt.
API-Tokens
Oktas Dokumentation ist eindeutig in den Eigenschaften, die Tokens für Angreifer attraktiv machen: Ein Token hat die Rechte des Benutzers, der es erstellt hat, bleibt 30 Tage gültig und verlängert sich bei jeder Nutzung, und es wird erst abgelehnt, wenn sein Ersteller deaktiviert ist (Okta Help Center: API-Tokens). Passwort oder Faktoren des Erstellers zurückzusetzen widerruft es nicht.
| eventType | Bedeutung |
|---|---|
system.api_token.create | ein neues API-Token wurde erstellt |
system.api_token.revoke | ein Token wurde widerrufen |
system.api_token.request_outside_allowed_range | ein Token wurde außerhalb seiner erlaubten Netzwerkzone verwendet |
Um zu sehen, was ein Token getan hat, empfiehlt Okta Security eine Abfrage auf transaction.detail.rootApiTokenId (Okta Security). Jedes im Zeitfenster des Vorfalls erstellte Token sollte widerrufen und seine Aktivität anschließend geprüft werden.
Der Analyzer meldet jede Erstellung als API-Token erstellt (mittel): Tokens sind für Integrationen üblich, dieser Befund braucht also Kontext und wird neben einem hohen Befund desselben Akteurs entscheidend.
Schwächung der Abwehr
| eventType | Analyzer-Regel | Schweregrad |
|---|---|---|
security.authenticator.lifecycle.deactivate, system.mfa.factor.deactivate | Authenticator deaktiviert | hoch |
policy.lifecycle.deactivate, policy.lifecycle.delete, policy.rule.deactivate, policy.rule.delete | Richtlinie oder Regel deaktiviert | mittel |
policy.lifecycle.update, policy.rule.update, policy.lifecycle.overwrite | Richtlinie geändert | niedrig |
security.threat.configuration.update, security.attack_protection.settings.update, security.session_protection.status.update, zone.update, zone.delete, zone.deactivate, zone.remove_blacklist | Sicherheitseinstellungen geändert | mittel |
Eine Änderung an einer Richtlinie ist für sich allein informativ, weil Admins ständig Regeln anpassen. Das System Log hält fest, dass sich die Regel geändert hat; öffnen Sie die Richtlinie in der Admin Console und vergleichen Sie mit Ihrer Dokumentation, um zu sehen, was sich geändert hat (etwa: MFA für eine Gruppe nicht mehr verlangt).
Support-Impersonation
user.session.impersonation.grant und user.session.impersonation.initiate protokollieren, dass Support-Zugriff aktiviert und genutzt wurde. Der Analyzer meldet sie als Okta-Support-Zugriff / Impersonation (mittel). Die Frage ist einfach: Hat jemand aus Ihrem Team einen Supportfall eröffnet, der das erforderte? Wenn nicht, widerrufen Sie den Zugriff und finden Sie heraus, wer ihn aktiviert hat.
Ablauf der Untersuchung
- Verankern Sie sich beim kompromittierten Admin. Listen Sie ab seinem ersten verdächtigen
user.session.startjedes Ereignis auf, in dem er Akteur ist. Der Entitäten-Pivot des Analyzers erledigt das mit einem Klick. - Erstellen Sie die Liste des Angefassten: jeden beförderten Benutzer, jedes erstellte Token, jede berechtigte Gruppe, jeden geänderten IdP, jede Richtlinie, jeden Authenticator und jede Zone.
- Wiederholen Sie Schritt 1 für jedes beförderte Konto. Angreifer verketten Identitäten.
- Vergleichen Sie mit dem aktuellen Zustand in der Admin Console (Security › Administrators, Security › API › Tokens). Was vor mehr als 90 Tagen angelegt wurde, steht nicht im Log.
Reihenfolge der Behebung
- Widerrufen Sie die während des Vorfalls erstellten API-Tokens (Security › API › Tokens).
- Entziehen Sie die während des Vorfalls vergebenen Admin-Rollen, beginnend mit Super Administrator; prüfen Sie danach jede Admin-Zuweisung.
- Beenden Sie die Sitzungen der beteiligten Konten.
- Stellen Sie Richtlinien, Authenticators, Netzwerkzonen und ThreatInsight-Einstellungen wieder her.
- Entfernen Sie unbekannte Identity Provider.
Warum Tokens zuerst: Ein Token erlaubt dem Angreifer, eine gerade entzogene Rolle erneut zu vergeben, solange sein Ersteller aktiv ist.
Langfristig umfassen Oktas Empfehlungen für diese Angriffsfamilie weniger dauerhafte Super Administrators (auf die Aufgabe zugeschnittene benutzerdefinierte Admin-Rollen), erneute Authentifizierung für Admin-Sitzungen und Protected Actions bei sensiblen Vorgängen (Okta Security). Die Seite zu den Standard-Admin-Rollen hilft bei der Entscheidung, wer was braucht.