Okta Cross-Tenant Impersonation: Persistenz über IdPs
Wie Angreifer einen eingehenden Identity Provider in Okta anlegen, um sich als beliebige Benutzer anzumelden, welche Logs das zeigen und wie man ihn entfernt.
TL;DR. Mit Admin-Rechten kann ein Angreifer einen von ihm kontrollierten Identity Provider als vertrauenswürdigen eingehenden IdP hinzufügen, dessen Benutzernamen echten Benutzern zuordnen und sich dann von außen als diese Benutzer anmelden, ohne deren Passwörter oder MFA. Suchen Sie im System Log nach system.idp.lifecycle.create und system.idp.lifecycle.activate durch einen unerwarteten Akteur, gefolgt von user.authentication.auth_via_IDP-Anmeldungen über diesen IdP. Den IdP zu deaktivieren ist dringend, aber sichern Sie vorher seine Konfiguration und jeden Benutzer, als der man sich darüber angemeldet hat.
Die Technik
Okta kann externen Identity Providern für die Anmeldung vertrauen: dem SAML-IdP eines Partners, einem Social Login oder einer anderen Okta-Organisation. Diese eingehende Föderation ist eine legitime Funktion. In den Händen eines Angreifers mit Admin-Zugang wird sie zum Generalschlüssel.
Okta Security hat das Muster 2023 unter dem Namen Cross-Tenant Impersonation dokumentiert. Nachdem der Angreifer per Social Engineering am Helpdesk Super-Administrator-Konten übernommen hatte, richtete er einen zweiten, von ihm kontrollierten Identity Provider als „Quell“-IdP in einer eingehenden Föderationsbeziehung ein (manchmal Org2Org genannt) und manipulierte die Benutzernamen der Zielpersonen in diesem Quell-IdP so, dass sie echten Benutzern der Opferorganisation entsprachen. Ergebnis: SSO in die Anwendungen des Opfers als diese Benutzer (Okta Security: Cross-Tenant Impersonation). Derselbe Artikel hält fest, dass kompromittierte Super-Administrator-Konten genutzt wurden, um anderen Konten Rechte zu geben, und in einigen Fällen, um die Anforderung eines zweiten Faktors aus Authentifizierungsrichtlinien zu entfernen.
MITRE ATT&CK ordnet solche Vertrauensänderungen als T1484.002, Domain or Tenant Policy Modification: Trust Modification ein.
Warum das als Persistenz so wirksam ist: Passwörter und Faktoren der kompromittierten Admins zurückzusetzen ändert daran nichts. Der IdP funktioniert weiter, bis ihn jemand entfernt.
So sieht es im System Log aus
| Reihenfolge | eventType | Akteur | Ziel | Was sichern |
|---|---|---|---|---|
| 1 | user.session.access_admin_app | kompromittierter Admin | Admin Console | IP, ASN, Sitzung |
| 2 | system.idp.lifecycle.create | kompromittierter Admin | der IdP | Name, ID, requestUri |
| 3 | system.idp.lifecycle.activate | kompromittierter Admin | der IdP | Zeitpunkt der Inbetriebnahme |
| 4 | system.idp.lifecycle.update, system.idp.key.create | kompromittierter Admin | der IdP | spätere Änderungen, neue Signaturschlüssel |
| 5 | user.authentication.auth_via_IDP | übernommener Benutzer | der IdP | jeden Benutzer, der sich so angemeldet hat |
| 6 | user.session.start | übernommener Benutzer | — | durch die Assertion erzeugte Sitzung |
| 7 | user.authentication.sso | übernommener Benutzer | Anwendungen | was erreicht wurde |
Die Liste der zu überwachenden Ereignisse, die Okta Security zu dieser Kampagne veröffentlicht hat, enthält system.idp.lifecycle.create und user.authentication.auth_via_IDP (Quelle). Änderungen an Routing-Regeln und an Einstellungen zur Kontoverknüpfung oder Just-in-Time-Bereitstellung zählen ebenfalls: Sie entscheiden, als welche Benutzer ein IdP anmelden darf. Deren genaue Ereignisnamen hängen davon ab, wie die Änderung vorgenommen wurde; prüfen Sie daher alles, was die Admin-Sitzung des Angreifers getan hat, nicht nur IdP-Ereignisse.
Der Name hilft Ihnen nicht. Ein Angreifer gibt dem IdP einen plausiblen Namen („Partner SSO“, „Azure AD backup“). Verräterisch ist, wer ihn angelegt hat, von wo und wann, im Verhältnis zum restlichen Vorfall.
Wie der Analyzer es meldet
| Regel | Ereignisse | Schweregrad |
|---|---|---|
persistence.idp_created | system.idp.lifecycle.create, system.idp.lifecycle.activate | hoch |
persistence.idp_modified | system.idp.lifecycle.update, system.idp.key.create, system.idp.key.update, system.idp.lifecycle.read_client_secret | mittel |
app.sso_after_suspicious | SSO in sensible Apps durch einen Benutzer aus einem hohen Befund, innerhalb von 24 h | hoch |
Ein neuer IdP wird immer gemeldet, weil er in den meisten Organisationen so selten ist, dass ein Mensch jeden einzelnen bestätigen sollte. Zusammen mit einer weiteren hohen Regel (einer Super-Administrator-Vergabe, einem Helpdesk-Zurücksetzen mit anschließender Registrierung) führt er zum Urteil Wahrscheinlich kompromittiert. Das Durchspielen des fiktiven Beispiels zeigt einen IdP „Partner SSO“, der von einem VPS aus angelegt und zur Anmeldung als Dienstkonto genutzt wurde.
Checkliste zur Untersuchung
- Inventarisieren Sie alle IdPs in der Admin Console (Security › Identity Providers) und vergleichen Sie sie mit den
system.idp.lifecycle.create-Ereignissen im Export. Ein IdP, der älter als 90 Tage ist, erscheint nicht im Log; fragen Sie die verantwortliche Person. - Sichern Sie für jeden verdächtigen IdP: Anlage- und Aktivierungsereignisse, den Akteur, seine Konfiguration (Aussteller, Zertifikat, Benutzernamenzuordnung, Kontoverknüpfung und JIT) und die Routing-Regeln, die auf ihn verweisen. Machen Sie Screenshots oder einen Export, bevor Sie etwas ändern.
- Listen Sie jedes
user.authentication.auth_via_IDPüber ihn auf, samt Zielbenutzern. Jeder davon ist eine übernommene Identität, deren Aktionen Sie prüfen müssen. - Verfolgen Sie jede übernommene Sitzung:
externalSessionId→ SSO-Ziele → Logs der nachgelagerten Anwendungen. Wurden AWS oder Microsoft 365 erreicht, machen Sie mit AWS Forensics oder M365 Forensics weiter. - Suchen Sie per JIT angelegte Benutzer: Neue, vom IdP bereitgestellte Benutzer erscheinen als Lifecycle-Ereignisse rund um die erste Anmeldung.
Behebung
- Deaktivieren und löschen Sie den bösartigen IdP, nachdem Sie seine Konfiguration gesichert haben.
- Prüfen Sie IdP-Routing-Regeln und Einstellungen zur Kontoverknüpfung, sodass kein externer IdP sich als bestehende Benutzer anmelden kann, sofern das nicht beabsichtigt und dokumentiert ist.
- Beenden Sie die Sitzungen aller Benutzer, die sich darüber angemeldet haben, und widerrufen Sie deren Sitzungen in nachgelagerten Apps.
- Entziehen Sie den Admin-Zugang, der das ermöglicht hat (siehe Rollen und API-Tokens).
- Stellen Sie jede vom Angreifer geschwächte Anmelde- oder MFA-Richtlinie wieder her.
Zur Vorbeugung empfiehlt Okta für diese Kampagne Phishing-resistente Authentifizierung für Admins, erneute Authentifizierung bei Admin-Anmeldungen, Protected Actions für sensible Admin-Vorgänge und benutzerdefinierte Admin-Rollen statt dauerhafter Super-Administrator-Rechte (Okta Security). Ein Alarm auf system.idp.lifecycle.create in Ihrem SIEM kostet nichts und schlägt selten an.
Weiterführende Links
- Okta Security: Cross-Tenant Impersonation, Prävention und Erkennung
- Okta Help Center: einen SAML-Identity-Provider hinzufügen (um zu verstehen, was ein Angreifer konfiguriert hat)
- MITRE ATT&CK T1484.002
- Die eventTypes, die Responder brauchen