Abuso del rol Super Admin y de tokens de API en Okta
Encuentra en el System Log de Okta concesiones de roles, tokens de API, políticas debilitadas y accesos del soporte, y elimina la persistencia del atacante.
TL;DR. Cuando un atacante tiene un administrador de Okta, se asegura de conservarlo: un segundo Super Administrator (user.account.privilege.grant con debugData.privilegeGranted), un token de API (system.api_token.create) que sobrevive a los restablecimientos de contraseña y MFA, y defensas debilitadas (policy.*, security.authenticator.lifecycle.deactivate, zone.*). Enumera cada acción de administración de la cuenta comprometida desde su primer inicio de sesión sospechoso, y después las de cada cuenta que ascendió. Retira tokens y roles antes de anunciar a nadie que el incidente está contenido.
Por qué la persistencia de administración importa más que el punto de entrada
La primera cuenta comprometida suele detectarse y restablecerse. Lo que el atacante hizo con ella mientras tanto es lo que le mantiene dentro. El informe de Okta Security sobre la campaña de 2023 describe cuentas de Super Administrator comprometidas usadas para asignar privilegios más altos a otras cuentas, restablecer los autenticadores de administradores existentes y, en algunos casos, eliminar el requisito de segundo factor de las políticas de autenticación (Okta Security). Cada una de esas acciones queda registrada.
Técnicas de MITRE ATT&CK en juego: T1098.003 Additional Cloud Roles, T1098.001 Additional Cloud Credentials, T1556.006 Multi-Factor Authentication (debilitar el MFA).
Concesiones de roles de administración
| eventType | Significado | Campo a leer |
|---|---|---|
user.account.privilege.grant | cambiaron los privilegios de administración de un usuario | debugContext.debugData.privilegeGranted, target |
group.privilege.grant | un grupo recibió privilegios de administración | después, revisa quién está en el grupo |
user.account.privilege.revoke | se retiraron todos los privilegios de administración de un usuario | quién limpió y cuándo |
user.session.access_admin_app | apertura de la Admin Console | primer acceso de administración desde una red nueva |
El catálogo indica que user.account.privilege.grant incluye la lista de privilegios que tiene el usuario en ese momento (event types). El analizador divide las concesiones en dos reglas: Rol de Super administrador concedido (alta) cuando privilegeGranted menciona Super Administrator, y Rol de administrador concedido (media) para cualquier otro rol.
Qué hace sospechosa una concesión:
- quien la recibe es una cuenta de servicio o una cuenta inactiva con la que nadie inicia sesión de forma interactiva;
- quien la concede inició sesión minutos antes desde una red nueva o tras un restablecimiento de factores;
- la concesión ocurre fuera de tu proceso de cambios (sin ticket, a una hora rara para ese administrador);
- un grupo recibe derechos de administración y después alguien se añade a él.
Tokens de API
La documentación de Okta es clara sobre las propiedades que hacen atractivos los tokens para un atacante: un token tiene los permisos del usuario que lo creó, es válido 30 días y se renueva cada vez que se usa, y solo se rechaza cuando su creador se desactiva (Okta Help Center: tokens de API). Restablecer la contraseña o los factores del creador no lo revoca.
| eventType | Significado |
|---|---|
system.api_token.create | se creó un token de API nuevo |
system.api_token.revoke | se revocó un token |
system.api_token.request_outside_allowed_range | se usó un token fuera de su zona de red permitida |
Para ver qué hizo un token, Okta Security recomienda consultar transaction.detail.rootApiTokenId (Okta Security). Todo token creado durante la ventana del incidente debe revocarse y después revisarse su actividad.
El analizador notifica cada creación como Token de API creado (media): los tokens son habituales en integraciones, así que este necesita contexto, y se vuelve decisivo junto a un hallazgo alto del mismo actor.
Debilitar las defensas
| eventType | Regla del analizador | Gravedad |
|---|---|---|
security.authenticator.lifecycle.deactivate, system.mfa.factor.deactivate | Autenticador desactivado | alta |
policy.lifecycle.deactivate, policy.lifecycle.delete, policy.rule.deactivate, policy.rule.delete | Política o regla desactivada | media |
policy.lifecycle.update, policy.rule.update, policy.lifecycle.overwrite | Política modificada | baja |
security.threat.configuration.update, security.attack_protection.settings.update, security.session_protection.status.update, zone.update, zone.delete, zone.deactivate, zone.remove_blacklist | Ajustes de seguridad modificados | media |
Una modificación de política es informativa por sí sola, porque los administradores cambian reglas continuamente. El System Log registra que la regla cambió; abre la política en la Admin Console y compárala con tu documentación para ver qué cambió (por ejemplo, que ya no se exige MFA a un grupo).
Suplantación por parte del soporte
user.session.impersonation.grant y user.session.impersonation.initiate registran que se habilitó y se usó el acceso del soporte. El analizador los notifica como Acceso del soporte de Okta / suplantación (media). La pregunta es sencilla: ¿abrió alguien de tu equipo un caso de soporte que lo necesitara? Si no, revoca el acceso y averigua quién lo habilitó.
Flujo de investigación
- Ancla la investigación en el administrador comprometido. Desde su primer
user.session.startsospechoso, enumera cada evento en el que es el actor. El pivote por entidades del analizador lo hace con un clic. - Construye la lista de lo que tocó: cada usuario que ascendió, cada token que creó, cada grupo al que dio derechos, cada IdP, política, autenticador y zona que cambió.
- Repite el paso 1 con cada cuenta ascendida. Los atacantes encadenan identidades.
- Compara con el estado actual en la Admin Console (Security › Administrators, Security › API › Tokens). Lo creado hace más de 90 días no estará en el registro.
Orden de remediación
- Revoca los tokens de API creados durante el incidente (Security › API › Tokens).
- Revoca los roles de administración concedidos durante el incidente, empezando por Super Administrator; después revisa todas las asignaciones de administración.
- Elimina las sesiones de las cuentas implicadas.
- Restaura políticas, autenticadores, zonas de red y ajustes de ThreatInsight.
- Elimina los proveedores de identidad desconocidos.
Por qué los tokens primero: un token permite al atacante volver a conceder un rol que acabas de retirar, mientras su creador siga activo.
A largo plazo, las recomendaciones de Okta para esta familia de ataques incluyen menos Super Administrators permanentes (roles de administración personalizados acotados a la tarea), reautenticación en las sesiones de administración y Protected Actions en las operaciones sensibles (Okta Security). La página de roles de administración estándar es el sitio para decidir quién necesita qué.