Secuestro de sesión en Okta: detectar cookies robadas
Detecta el secuestro de sesión en el System Log de Okta: un externalSessionId usado desde varios ASN o navegadores, itinerancia, y cómo descartar VPN y móviles.
TL;DR. Una cookie de sesión de Okta robada permite al atacante saltarse por completo la contraseña y el MFA, así que no hay ningún inicio de sesión fallido que encontrar. Lo que sí puedes encontrar es una sesión usada desde dos sitios: el mismo authenticationContext.externalSessionId con dos valores distintos de securityContext.asNumber, o con dos user agents distintos, en cuestión de horas. Añade los eventos security.session.detect_client_roaming del propio Okta y descarta las VPN corporativas y los móviles que pasan del wifi a los datos antes de hablar de robo.
Cómo se roban las sesiones
Tras un inicio de sesión correcto, el navegador guarda una cookie de sesión. Quien presente esa cookie es el usuario hasta que termine la sesión. Okta Security describe las dos vías habituales por las que las cookies salen del equipo de la víctima: malware de tipo infostealer que extrae las cookies del navegador, y sitios de phishing adversary-in-the-middle que hacen de proxy del inicio de sesión real y capturan la sesión resultante (Okta Security: defensa frente al secuestro de sesión). MITRE ATT&CK recoge el robo como T1539, Steal Web Session Cookie y la reutilización como T1550.004, Web Session Cookie.
Los artefactos de sesión también se filtran por canales menos evidentes. En el incidente de octubre de 2023 en el sistema de soporte de Okta, un actor malicioso accedió a ficheros adjuntos a casos de soporte; algunos eran ficheros HAR con tokens de sesión, que se usaron para secuestrar sesiones de cinco clientes (Okta Security: causa raíz y remediación). Sanear los ficheros HAR antes de compartirlos es una lección para cualquier proceso de soporte, no solo el de Okta.
Los campos que identifican una sesión
| Campo | Uso |
|---|---|
authenticationContext.externalSessionId | el identificador de sesión (externalSessionId); agrupa por él |
authenticationContext.rootSessionId | la raíz de la sesión interactiva; Okta Security señala que externalSessionId puede regenerarse tras eventos del ciclo de vida de los factores mientras la raíz persiste (artículo sobre rootSessionId) |
securityContext.asNumber, asOrg | la red (ASN) desde la que llegó la petición |
client.ipAddress | el origen exacto |
client.userAgent.rawUserAgent | navegador y sistema operativo |
La idea clave: las peticiones legítimas de la víctima y las peticiones reutilizadas del atacante comparten identificador de sesión, pero difieren en la red y, normalmente, en el navegador.
Señales, de la más fuerte a la más débil
| Señal | Por qué importa | Regla del analizador | Gravedad |
|---|---|---|---|
| Misma sesión, 2 o más ASN en 12 h | la cookie se está usando desde otra red | session.multi_asn | alta |
| Misma sesión, 2 o más user agents en 12 h | otro navegador tiene la cookie | session.multi_user_agent | media |
security.session.detect_client_roaming | el propio Okta marcó la sesión como itinerante | session.roaming | media |
| Actividad de la sesión desde un proveedor de hosting o un anonimizador | los atacantes reutilizan desde VPS y proxies | access.hosting_provider, access.anonymizer | media |
| SSO a aplicaciones sensibles desde la red nueva | el atacante está usando lo que robó | app.sso_after_suspicious | alta |
En organizaciones con Identity Engine, busca también user.session.context.change (el contexto de la sesión cambió lo bastante como para reevaluar las políticas) y policy.auth_reevaluate.fail, ambos en el catálogo de event types de Okta. El analizador todavía no los usa como detecciones; la tabla de eventos los muestra.
Recorrer una alerta
Supongamos que el analizador informa de «Sesión usada desde varias redes» para a.user:
- Abre las pruebas y ordénalas por hora. ¿Dónde empezó la sesión? El
user.session.start(y el MFA) deberían venir de la red habitual del usuario. Las peticiones posteriores desde un segundo ASN son la posible reutilización. - Caracteriza la segunda red. Si el
asOrges un ISP residencial de la ciudad del usuario, probablemente sea su propio móvil o su casa. Un proveedor cloud, un hosting de VPS o un país donde el usuario nunca ha estado, no. - Comprueba el user agent. La misma cadena de navegador en ambas redes apunta a un usuario que se desplaza; un sistema o navegador distintos en la segunda red apuntan a una copia de la cookie.
- Enumera lo que hizo la segunda red. Destinos de SSO, acciones de administración, registro de factores. Un atacante con una sesión secuestrada suele registrar un factor o crear un token para persistir más allá de la vida de la sesión.
- Revisa el equipo del usuario. Un robo de cookies por infostealer significa que el endpoint está comprometido; restablecer la contraseña de Okta no lo limpia.
Falsos positivos que te encontrarás
- Móviles que pasan del wifi a los datos móviles. Dos ASN (el ISP de casa y el operador móvil) en una sesión, mismo user agent. Muy habitual.
- VPN corporativa conectada a mitad de sesión. La sesión empieza en el ISP de casa y continúa desde la salida de la VPN. Si tu VPN sale por un proveedor cloud, también dispara la regla de proveedor de hosting.
- Proxies de seguridad y pasarelas web que salen por su propio ASN solo para parte del tráfico.
- Actualizaciones del navegador durante una sesión larga cambian la cadena del user agent.
Por eso la regla multi-ASN es un hallazgo alto y no crítico. El artículo de ajuste explica cómo tratarlos; en resumen, conoce los ASN de salida de tu VPN y tus operadores móviles y compruébalos primero.
Contención
- Elimina las sesiones del usuario y revoca sus tokens: esto invalida la cookie robada en Okta.
- Revoca las sesiones en las aplicaciones posteriores a las que llegó el atacante. Son independientes de las de Okta.
- Trata el endpoint como comprometido si un infostealer es plausible: reinstálalo y restablece todas las credenciales usadas en él.
- Restablece contraseña y factores si el atacante registró también un factor o no puedes descartar el robo de credenciales.
Prevención
Las recomendaciones de Okta Security contra la reutilización de cookies incluyen vincular las sesiones de administración a la red (IP o ASN), exigir reautenticación para recursos sensibles, autenticadores resistentes al phishing (que frustran el phishing adversary-in-the-middle), requisitos de gestión de dispositivos y sesiones más cortas donde los datos son sensibles (Okta Security). Tras el incidente de los ficheros HAR, Okta describió además la vinculación de las sesiones de administración a la ubicación de red como mejora del producto (artículo sobre la causa raíz).