Cross-tenant impersonation Okta : la persistance par IdP
Comment un attaquant ajoute un IdP entrant à une organisation Okta pour se connecter en tant que n'importe qui, les logs qui le trahissent, et son retrait.
TL;DR. Avec des droits d'administration, un attaquant peut ajouter un fournisseur d'identité qu'il contrôle comme IdP entrant de confiance, faire correspondre ses noms d'utilisateur à de vrais utilisateurs, puis se connecter en tant que ces utilisateurs depuis l'extérieur, sans leur mot de passe ni leur MFA. Dans le System Log, cherchez system.idp.lifecycle.create et system.idp.lifecycle.activate par un acteur inattendu, suivis de connexions user.authentication.auth_via_IDP via cet IdP. Désactiver l'IdP est urgent, mais capturez d'abord sa configuration et chaque utilisateur sous l'identité duquel il a permis de se connecter.
La technique
Okta peut faire confiance à des fournisseurs d'identité externes pour la connexion : l'IdP SAML d'un partenaire, une connexion sociale ou une autre organisation Okta. Cette fédération entrante est une fonctionnalité légitime. Entre les mains d'un attaquant disposant d'un accès administrateur, elle devient un passe-partout.
Okta Security a documenté ce schéma en 2023 sous le nom de cross-tenant impersonation. Après avoir pris le contrôle de comptes Super Administrator grâce à l'ingénierie sociale du helpdesk, l'acteur malveillant a configuré un second fournisseur d'identité, sous son contrôle, comme IdP « source » dans une relation de fédération entrante (parfois appelée Org2Org), et a modifié le nom d'utilisateur des cibles dans cet IdP source pour qu'il corresponde à de vrais utilisateurs de l'organisation victime. Résultat : du SSO vers les applications de la victime en tant que ces utilisateurs (Okta Security : Cross-Tenant Impersonation). Le même article précise que les comptes Super Administrator compromis ont servi à accorder des privilèges à d'autres comptes et, dans certains cas, à retirer l'exigence de second facteur des politiques d'authentification.
MITRE ATT&CK classe ce type de modification de confiance sous T1484.002, Domain or Tenant Policy Modification: Trust Modification.
Pourquoi c'est une persistance si efficace : réinitialiser les mots de passe et les facteurs des admins compromis n'y change rien. L'IdP continue de fonctionner jusqu'à ce que quelqu'un le supprime.
Ce que l'on voit dans le System Log
| Ordre | eventType | Acteur | Cible | À capturer |
|---|---|---|---|---|
| 1 | user.session.access_admin_app | admin compromis | Admin Console | IP, ASN, session |
| 2 | system.idp.lifecycle.create | admin compromis | l'IdP | nom, id, requestUri |
| 3 | system.idp.lifecycle.activate | admin compromis | l'IdP | l'heure de mise en service |
| 4 | system.idp.lifecycle.update, system.idp.key.create | admin compromis | l'IdP | modifications ultérieures, nouvelles clés de signature |
| 5 | user.authentication.auth_via_IDP | utilisateur usurpé | l'IdP | chaque utilisateur connecté ainsi |
| 6 | user.session.start | utilisateur usurpé | — | session créée par l'assertion |
| 7 | user.authentication.sso | utilisateur usurpé | applications | ce qu'il a atteint |
La liste des événements à surveiller publiée par Okta Security pour cette campagne comprend system.idp.lifecycle.create et user.authentication.auth_via_IDP (source). Les modifications des règles de routage et des réglages de liaison de comptes ou de provisioning just-in-time comptent aussi : elles déterminent en tant que quels utilisateurs un IdP peut connecter. Leurs noms d'événements exacts dépendent de la façon dont la modification a été faite ; examinez donc tout ce qu'a fait la session d'administration de l'attaquant, pas seulement les événements d'IdP.
Le nom ne vous aidera pas. Un attaquant donne à l'IdP un nom plausible (« Partner SSO », « Azure AD backup »). Ce qui le trahit, c'est qui l'a créé, d'où et quand, par rapport au reste de l'incident.
Comment l'analyseur le signale
| Règle | Événements | Sévérité |
|---|---|---|
persistence.idp_created | system.idp.lifecycle.create, system.idp.lifecycle.activate | élevée |
persistence.idp_modified | system.idp.lifecycle.update, system.idp.key.create, system.idp.key.update, system.idp.lifecycle.read_client_secret | moyenne |
app.sso_after_suspicious | SSO vers une application sensible par un utilisateur impliqué dans un constat élevé, dans les 24 h | élevée |
Un nouvel IdP est toujours signalé, car c'est assez rare dans la plupart des organisations pour qu'un humain confirme chacun. Combiné à une autre règle élevée (un octroi Super Administrator, une réinitialisation par le helpdesk suivie d'un enrôlement), il fait passer le verdict à Compromission probable. La démonstration sur l'exemple fictif montre un IdP « Partner SSO » créé depuis un VPS et utilisé pour se connecter en tant que compte de service.
Checklist d'enquête
- Inventoriez tous les IdP dans l'Admin Console (Security › Identity Providers) et comparez avec les événements
system.idp.lifecycle.createde votre export. Un IdP de plus de 90 jours n'apparaîtra pas dans le journal ; interrogez son propriétaire. - Pour chaque IdP suspect, capturez : les événements de création et d'activation, l'acteur, sa configuration (émetteur, certificat, correspondance des noms d'utilisateur, liaison de comptes et JIT) et les règles de routage qui pointent vers lui. Faites des captures ou un export avant de toucher quoi que ce soit.
- Listez chaque
user.authentication.auth_via_IDPpassé par lui, avec les utilisateurs cibles. Chacun est une identité usurpée dont il faut examiner les actions. - Suivez chaque session usurpée :
externalSessionId→ cibles SSO → journaux des applications en aval. Si AWS ou Microsoft 365 ont été atteints, poursuivez avec AWS Forensics ou M365 Forensics. - Cherchez les utilisateurs créés en JIT : les nouveaux utilisateurs provisionnés par l'IdP apparaissent comme des événements de cycle de vie autour de la première connexion.
Remédiation
- Désactivez puis supprimez l'IdP malveillant, après avoir capturé sa configuration.
- Revoyez les règles de routage des IdP et les réglages de liaison de comptes pour qu'aucun IdP externe ne puisse connecter des utilisateurs existants, sauf si c'est voulu et documenté.
- Supprimez les sessions de chaque utilisateur connecté via cet IdP, et révoquez leurs sessions dans les applications en aval.
- Retirez l'accès d'administration qui l'a rendu possible (voir rôles et jetons d'API).
- Restaurez toute politique de connexion ou de MFA affaiblie par l'attaquant.
En prévention, les recommandations d'Okta pour cette campagne incluent une authentification résistante au phishing pour les admins, la réauthentification lors des connexions d'administration, les Protected Actions pour les opérations sensibles, et des rôles d'admin personnalisés plutôt que des droits Super Administrator permanents (Okta Security). Une alerte sur system.idp.lifecycle.create dans votre SIEM ne coûte rien et se déclenche rarement.
Pour aller plus loin
- Okta Security : Cross-Tenant Impersonation, prévention et détection
- Okta Help Center : ajouter un fournisseur d'identité SAML (pour comprendre ce qu'un attaquant a configuré)
- MITRE ATT&CK T1484.002
- Les eventTypes utiles en réponse à incident