Cross-tenant impersonation en Okta: persistencia vía IdP
Cómo un atacante añade un proveedor de identidad entrante a Okta para entrar como cualquier usuario, qué eventos lo delatan y cómo quitar la puerta trasera.
TL;DR. Con derechos de administración, un atacante puede añadir un proveedor de identidad que controla como IdP entrante de confianza, hacer coincidir sus nombres de usuario con usuarios reales y luego iniciar sesión como ellos desde fuera, sin sus contraseñas ni su MFA. En el System Log busca system.idp.lifecycle.create y system.idp.lifecycle.activate hechos por un actor inesperado, seguidos de inicios de sesión user.authentication.auth_via_IDP a través de ese IdP. Desactivar el IdP es urgente, pero antes captura su configuración y cada usuario suplantado a través de él.
La técnica
Okta puede confiar en proveedores de identidad externos para el inicio de sesión: el IdP SAML de un socio, un inicio de sesión social u otra organización de Okta. Esta federación entrante es una función legítima. En manos de un atacante con acceso de administración, se convierte en una llave maestra.
Okta Security documentó el patrón en 2023 con el nombre de cross-tenant impersonation. Tras hacerse con cuentas de Super Administrator mediante ingeniería social al helpdesk, el actor malicioso configuró un segundo proveedor de identidad, bajo su control, como IdP «de origen» en una relación de federación entrante (a veces llamada Org2Org), y manipuló el nombre de usuario de los objetivos en ese IdP de origen para que coincidiera con usuarios reales de la organización víctima. Resultado: SSO a las aplicaciones de la víctima como esos usuarios (Okta Security: Cross-Tenant Impersonation). El mismo artículo indica que las cuentas de Super Administrator comprometidas se usaron para conceder privilegios a otras cuentas y, en algunos casos, para eliminar el requisito de segundo factor de las políticas de autenticación.
MITRE ATT&CK clasifica este tipo de cambio de confianza como T1484.002, Domain or Tenant Policy Modification: Trust Modification.
Por qué es una persistencia tan eficaz: restablecer las contraseñas y los factores de los administradores comprometidos no le afecta. El IdP sigue funcionando hasta que alguien lo elimina.
Cómo se ve en el System Log
| Orden | eventType | Actor | Objetivo | Qué capturar |
|---|---|---|---|---|
| 1 | user.session.access_admin_app | administrador comprometido | Admin Console | IP, ASN, sesión |
| 2 | system.idp.lifecycle.create | administrador comprometido | el IdP | nombre, id, requestUri |
| 3 | system.idp.lifecycle.activate | administrador comprometido | el IdP | cuándo entró en servicio |
| 4 | system.idp.lifecycle.update, system.idp.key.create | administrador comprometido | el IdP | cambios posteriores, nuevas claves de firma |
| 5 | user.authentication.auth_via_IDP | usuario suplantado | el IdP | cada usuario que inició sesión así |
| 6 | user.session.start | usuario suplantado | — | sesión creada por la aserción |
| 7 | user.authentication.sso | usuario suplantado | aplicaciones | a qué llegó |
La lista de eventos que Okta Security recomienda vigilar para esta campaña incluye system.idp.lifecycle.create y user.authentication.auth_via_IDP (fuente). Los cambios en las reglas de enrutamiento y en los ajustes de vinculación de cuentas o de aprovisionamiento just-in-time también importan: deciden como qué usuarios puede iniciar sesión un IdP. Sus nombres de evento exactos dependen de cómo se hizo el cambio, así que revisa todo lo que hizo la sesión de administración del atacante, no solo los eventos de IdP.
El nombre no te ayudará. Un atacante llama al IdP de forma verosímil («Partner SSO», «Azure AD backup»). Lo que lo delata es quién lo creó, desde dónde y cuándo, en relación con el resto del incidente.
Cómo lo señala el analizador
| Regla | Eventos | Gravedad |
|---|---|---|
persistence.idp_created | system.idp.lifecycle.create, system.idp.lifecycle.activate | alta |
persistence.idp_modified | system.idp.lifecycle.update, system.idp.key.create, system.idp.key.update, system.idp.lifecycle.read_client_secret | media |
app.sso_after_suspicious | SSO a aplicaciones sensibles por un usuario implicado en un hallazgo alto, en 24 h | alta |
Un IdP nuevo siempre se notifica, porque en la mayoría de las organizaciones es tan raro que una persona debe confirmar cada uno. Combinado con otra regla alta (una concesión de Super Administrator, un restablecimiento del helpdesk seguido de registro), lleva el veredicto a Compromiso probable. El recorrido por el ejemplo ficticio muestra un IdP «Partner SSO» creado desde un VPS y usado para iniciar sesión como una cuenta de servicio.
Lista de investigación
- Haz inventario de todos los IdP en la Admin Console (Security › Identity Providers) y compáralos con los eventos
system.idp.lifecycle.createde tu exportación. Un IdP de más de 90 días no aparecerá en el registro; pregunta a su responsable. - Para cada IdP sospechoso, captura: los eventos de creación y activación, el actor, su configuración (emisor, certificado, correspondencia de nombres de usuario, vinculación de cuentas y JIT) y las reglas de enrutamiento que apuntan a él. Haz capturas o exporta antes de tocar nada.
- Enumera cada
user.authentication.auth_via_IDPa través de él, con los usuarios objetivo. Cada uno es una identidad suplantada cuyas acciones debes revisar. - Sigue cada sesión suplantada:
externalSessionId→ destinos de SSO → registros de las aplicaciones posteriores. Si se llegó a AWS o Microsoft 365, continúa con AWS Forensics o M365 Forensics. - Busca usuarios creados por JIT: los usuarios nuevos aprovisionados por el IdP aparecerán como eventos de ciclo de vida alrededor del primer inicio de sesión.
Remediación
- Desactiva y después elimina el IdP malicioso, tras capturar su configuración.
- Revisa las reglas de enrutamiento de IdP y los ajustes de vinculación de cuentas para que ningún IdP externo pueda iniciar sesión como usuarios existentes salvo que sea intencionado y esté documentado.
- Elimina las sesiones de cada usuario que inició sesión a través de él y revoca sus sesiones en las aplicaciones posteriores.
- Retira el acceso de administración que lo hizo posible (consulta roles y tokens de API).
- Restaura cualquier política de inicio de sesión o MFA que el atacante debilitara.
Como prevención, las recomendaciones de Okta para esta campaña incluyen autenticación resistente al phishing para los administradores, reautenticación en los inicios de sesión de administración, Protected Actions para las operaciones sensibles y roles de administración personalizados en lugar de derechos permanentes de Super Administrator (Okta Security). Una alerta sobre system.idp.lifecycle.create en tu SIEM no cuesta nada y rara vez salta.