Token Hijacking

¿Qué es Token Hijacking?

Token hijacking es una técnica de ciberataque que consiste en capturar y utilizar tokens de autenticación válidos de usuarios legítimos para suplantar su identidad digital sin necesidad de conocer sus contraseñas.

A diferencia del phishing tradicional que busca robar credenciales, el token hijacking explota la confianza en sistemas de autenticación modernos como OAuth, JWT (JSON Web Tokens) o tokens de sesión de aplicaciones web.

Cómo Funciona el Token Hijacking

Vectores de Ataque Principales

Los cuatro vectores que aparecen en la respuesta a incidentes, sin cuantificar su peso relativo —no hay una fuente pública que lo mida para España—:

Proceso Típico de Ataque

Tipos de Tokens Vulnerables

OAuth Access Tokens

¿Qué son? Tokens que permiten acceso a recursos específicos sin revelar credenciales.

Duración típica: 1-24 horas Scope: Limitado a permisos específicos (leer email, acceder calendario) Vulnerabilidad: Pueden robarse y usarse inmediatamente

Refresh Tokens

¿Qué son? Tokens de larga duración que generan nuevos access tokens.

Duración típica: Días, semanas o indefinida Scope: Generar nuevos access tokens Vulnerabilidad: Si se roban, permiten acceso persistente

JWT (JSON Web Tokens)

¿Qué son? Tokens autocontenidos que incluyen información del usuario.

Duración típica: Variable (minutos a horas) Scope: Definido en el payload del token Vulnerabilidad: Difíciles de revocar una vez comprometidos

Session Tokens

¿Qué son? Tokens de sesión que identifican usuarios autenticados.

Duración típica: Hasta cierre de sesión Scope: Acceso completo a la aplicación web Vulnerabilidad: Capturables mediante XSS o network sniffing

Los dos escenarios que llegan a peritaje

No son casos concretos con nombre y cifras, sino los dos patrones en los que este ataque acaba en un procedimiento judicial. Lo relevante para el perito es dónde queda el rastro en cada uno.

Escenario A — consentimiento OAuth concedido por la propia víctima

Un directivo recibe un correo que imita a la plataforma corporativa y le pide autorizar una aplicación para una supuesta auditoría. La aplicación es real y está registrada: no falsifica nada, simplemente solicita permisos de lectura de correo, calendario y contactos, y la víctima los concede.

Lo que hace difícil el caso es que no hay intrusión que demostrar: el acceso posterior es técnicamente legítimo. Lo que se acredita es la concesión de consentimiento, que queda registrada en el registro de auditoría del proveedor de identidad con su fecha, el identificador de la aplicación y el ámbito de permisos otorgado. Microsoft documenta cómo revisarlas y revocarlas en Investigate and remediate risky OAuth apps.

Escenario B — token robado del equipo por un infostealer

El atacante no engaña a nadie: infecta el puesto de trabajo con un ladrón de credenciales que copia las cookies de sesión que el navegador guarda en disco, y las reproduce desde su propia máquina. La sesión sigue siendo válida y el segundo factor no vuelve a pedirse.

Aquí sí hay dos rastros que correlacionar: los artefactos del malware en el endpoint —que fijan el momento de la infección— y el uso de la misma sesión desde una IP y un dispositivo distintos en los registros de inicio de sesión. La distancia temporal entre ambos delimita la ventana de exposición, que es el dato que suele decidir el alcance de la responsabilidad.

Detección Forense de Token Hijacking

Indicadores Técnicos

Logs a Analizar

Microsoft 365 (Azure AD)

{
  "ActivityDateTime": "2025-10-19T23:45:11.000Z",
  "Activity": "FileDownloaded",
  "UserId": "cfo@empresa.com",
  "ClientAppUsed": "Other clients; MSAL.NET",
  "IPAddress": "203.0.113.42",
  "UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
  "ConditionalAccessStatus": "success"
}

Google Workspace

{
  "timestamp": "2025-10-19T23:45:11.000Z",
  "event_name": "download",
  "user_email": "cfo@empresa.com",
  "ip_address": "203.0.113.42",
  "user_agent": "Google APIs Explorer",
  "doc_title": "Estrategia_Financiera_2026.xlsx"
}

Herramientas de Análisis

Metodología Forense Paso a Paso

Fase 1: Preservación de Evidencia

1. Captura inmediata de logs

   • Export completo de los registros disponibles. ⚠️ Entra ID no guarda 90 días: son 7 en el plan gratuito y 30 en P1/P2, así que la exportación es urgente. El Unified Audit Log de Purview sí conserva más, y es otra fuente
   • Screenshot de OAuth applications autorizadas
   • Lista de sesiones activas y ubicaciones

2. Documentación del incidente

   • Timestamp de primer acceso sospechoso
   • Datos/sistemas potencialmente comprometidos
   • Acciones inmediatas tomadas por la organización

Fase 2: Timeline Reconstruction

Ejemplo de timeline forense:
2025-10-12 09:18:22 - Infección inicial (malware)
2025-10-12 09:19:45 - Robo de tokens del navegador
2025-10-19 23:45:11 - Primer uso malicioso del token
2025-10-19 23:47:22 - Acceso a datos financieros
2025-10-20 00:15:33 - Descarga masiva de documentos
2025-10-20 01:22:18 - Creación de usuario backup

Fase 3: Análisis de Impacto

Fase 4: Atribución y Evidencia

• Correlación de IPs: Vincular direcciones con infraestructura conocida
• TTPs (Tactics, Techniques, Procedures): Comparar con ataques similares
• Artifacts únicos: Identificadores que permitan atribuir a grupos específicos
• Cadena de custodia: Documentar evidencia para uso judicial

Prevención y Mitigación

Para Usuarios Individuales

Para Empresas

Políticas de Acceso

• Conditional Access: Geolocalización, dispositivos conocidos
• Zero Trust: Verificar cada acceso, no confiar en red interna
• MFA obligatorio: Incluso para accesos con token válido
• Device compliance: Solo dispositivos gestionados

Monitorización Continua

Alertas críticas:
- OAuth grants fuera de horario laboral
- Accesos desde nuevos países/ubicaciones  
- Descarga masiva de datos (>100 archivos/hora)
- Creación de usuarios o aplicaciones
- Cambios en permisos de aplicaciones OAuth

Respuesta a Incidentes

Proceso automático:
1. Detectar: SIEM alerta actividad anómala
2. Contener: Suspender cuenta afectada
3. Investigar: Análisis forense de logs
4. Erradicar: Revocar todos los tokens
5. Recuperar: Restaurar acceso legítimo
6. Lecciones: Actualizar detecciones

Aspectos Legales del Token Hijacking

Tipificación Penal

En España, el token hijacking puede tipificarse como:

• Art. 197 bis CP: acceso no autorizado a un sistema de información vulnerando sus medidas de seguridad. (El 197.1 es otra cosa: descubrimiento de secretos e interceptación de telecomunicaciones.)
• Art. 249.1.a) CP: estafa por manipulación informática, si hay transferencia patrimonial no consentida. La LO 14/2022 la trasladó aquí desde el antiguo 248.2
• Art. 401 CP: usurpación del estado civil, que no es «suplantar la identidad» en sentido coloquial: exige arrogarse la personalidad completa de otro, no usar una credencial suya
• RGPD: Violación de datos personales

Evidencia Digital Válida

Para que el análisis forense sea válido judicialmente:

1. Cadena de custodia: Documentar obtención y conservación de logs
2. Integridad: Hash SHA-256 de archivos de evidencia
3. Perito cualificado: la LEC no exige colegiación para las materias sin título oficial; lo que el tribunal valora es conocimiento acreditable de la materia y método reproducible
4. Metodología reconocida: Seguir estándares ISO 27037, RFC 3227
5. Reproducibilidad: Otros peritos deben poder verificar resultados

Responsabilidad Civil

Las empresas pueden enfrentarse a:

• Multas RGPD: Hasta 20 millones € o 4% facturación anual
• Demandas de empleados: Por filtración de datos personales
• Pérdida de contratos: Clientes que pierden confianza
• Costes de recuperación: Forensics, consultoría, sistemas nuevos

Herramientas Forenses Especializadas

Para Análisis de Office 365

Microsoft Defender XDR (antes Microsoft 365 Defender)

• Consultas de advanced hunting en KQL
• Timeline de eventos
• Análisis de OAuth apps
• Correlación con threat intelligence

Ejemplo KQL para detectar token hijacking:

// SigninLogs es la tabla de Microsoft Sentinel. En el hunting de Defender XDR
// la tabla equivalente es AADSignInEventsBeta / EntraIdSignInEvents.
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == 0
| summarize 
    Countries = dcount(LocationDetails.countryOrRegion),
    Cities = dcount(LocationDetails.city),
    IPs = dcount(IPAddress)
    by UserPrincipalName
| where Countries > 2 or IPs > 10

Para Análisis de Google Workspace

Google Admin Console

• Security > Investigation tool
• Apps OAuth permissions
• Login events analysis
• Data export for forensics

Token Analysis Tools

jwt.io - Decodificar y analizar JWT tokens ⚠️ No usar «OAuth 2.0 Debugger» (oauthdebugger.com) sobre material de un incidente: construye peticiones de autorización en vivo, no analiza grants pasados, y meter ahí un código o un token es entregarlo a un tercero Burp Suite - Interceptar y analizar tokens en tráfico HTTP

Casos de Uso en Litigios

Despidos Procedentes

Escenario: Empleado niega haber descargado información confidencial.

Qué aportan los artefactos:

• Los registros sitúan el acceso en una IP doméstica, distinta de la corporativa
• El token era legítimo y se usó fuera del horario habitual
• Volumen de descarga muy superior al patrón previo de esa cuenta
• User-Agent de un dispositivo que no figura en el inventario de la empresa

Qué acreditan y qué no. Todo lo anterior describe una sesión, no una persona: una dirección IP no identifica a nadie —identifica una línea, en un momento— y el User-Agent lo declara el propio cliente. Para llegar al autor hacen falta la identificación del abonado por vía judicial y el cruce con otros artefactos. Y la intención no sale de ningún registro: se argumenta con el conjunto, y la valora el tribunal.

Competencia Desleal

Escenario: Empresa competidora conoce estrategia comercial confidencial.

Evidencia forense:

• Token hijacking mediante consent phishing
• Aplicación OAuth falsa registrada por la competencia
• Timeline muestra acceso inmediatamente antes de licitación
• Correlación con anuncios publicitarios de la competencia

Qué sostiene el análisis: la existencia de una aplicación OAuth no autorizada, el momento del acceso y su correlación temporal con la licitación. Lo que no sostiene: que esa correlación sea causa, ni cuál sea el desenlace de una demanda — eso lo decide el tribunal.

Futuro del Token Hijacking

Evolución de las Amenazas (2026-2027)

Defensas Emergentes

• Continuous Access Evaluation (CAE): Reevaluación constante de tokens
• Device binding: Tokens vinculados a hardware específico
• Zero Trust Network Access (ZTNA): Verificación por cada recurso
• Behavioral analytics: AI que detecta patrones anómalos de uso

Conclusión

El token hijacking representa una evolución sofisticada del cibercrimen que explota la confianza en sistemas de autenticación modernos. Su detección requiere análisis forense especializado que combine conocimientos técnicos de protocolos OAuth, investigación de logs y correlación de evidencias digitales.

Para abogados y empresas, entender esta amenaza es crucial ya que los casos de token hijacking serán cada vez más frecuentes en litigios relacionados con:

• Violaciones de datos
• Espionaje industrial
• Competencia desleal
• Disputas laborales
• Reclamaciones de seguros

La evidencia forense de token hijacking puede ser decisiva para demostrar accesos no autorizados, determinar responsabilidades y cuantificar daños en procesos judiciales.

Referencias y fuentes

1. Microsoft — Token theft playbook. Guía de investigación y respuesta: prerrequisitos de acceso a los registros de inicio de sesión y auditoría de Microsoft Entra ID, y árbol de decisión del incidente.
2. Microsoft Defender for Cloud Apps — Investigate and remediate risky OAuth apps. Revisión y revocación de las aplicaciones OAuth con consentimiento concedido.
3. Ley 1/2000, de Enjuiciamiento Civil — art. 340, condiciones de los peritos.

Última actualización: 29 de agosto de 2026 Categoría: Técnico Código: THJ-001