🛡️Session hijacking: qué es, cómo te atacan, y cómo Drokio lo detecta

Después del login, pasa algo que casi nadie considera seriamente: el sistema deja de validar tu identidad. Una vez que la contraseña y el 2FA se pasaron, lo que queda es una cookie de sesión — un token que representa "soy el usuario legítimo" y se envía con cada request. Para el sistema, esa cookie es el usuario. No hay segunda verificación.

Esa simplificación es necesaria (sería insoportable re-autenticarse en cada click), pero crea una clase entera de ataques: session hijacking. El atacante no necesita romper tu contraseña ni tu 2FA — solo necesita la cookie. Y en 2026, hay al menos cinco formas de conseguirla que están masivamente automatizadas.

Este artículo explica cómo funcionan los ataques reales, qué señales delatan una sesión robada, por qué 2FA no ayuda acá, y cómo la detección de comportamiento cierra el agujero que los controles tradicionales dejan abierto.

Qué es una sesión y por qué es un cheque en blanco

Cuando hacés login en una aplicación web, el servidor te devuelve una cookie de sesión: una cadena de texto (típicamente 32-64 caracteres aleatorios) que tu navegador guarda y envía con cada request subsiguiente. El servidor usa ese token para reconocerte sin pedirte credenciales cada vez.

Ese modelo tiene una propiedad incómoda: la cookie es transferible. Si alguien más obtiene tu cookie y la inserta en su navegador, el servidor va a tratarlo como vos. No hay forma técnica nativa de atar la cookie a tu identidad física, a tu dispositivo, o a tu biometría. Es pura posesión del token.

Las implicaciones:

• Una contraseña perfecta + 2FA fuerte no importan si alguien te roba la cookie después del login.
• Un ataque de hijacking no genera eventos de autenticación — para el sistema es el usuario real navegando.
• La sesión puede durar horas, días o más. Durante todo ese tiempo, el poseedor de la cookie es el usuario legítimo a los ojos del sistema.

Las 5 técnicas modernas de robo de sesión

1. Infostealer malware

El rey actual del hijacking. Familias como RedLine, Vidar, Lumma, Raccoon, StealC infectan el dispositivo del usuario (típicamente via software pirata, extensiones Chrome maliciosas, instaladores falsos) y extraen todo en una sola pasada:

• Contraseñas guardadas en todos los navegadores.
• Cookies de sesión activas de todos los sitios visitados.
• Tokens de aplicaciones (Discord, Telegram, Steam).
• Wallets de criptomonedas.
• Información de autocompletado.

Los datos se empaquetan y suben a servidor de C2. El operador vende los logs en canales de Telegram por USD 5-15 el paquete. El comprador importa las cookies en su navegador y aparece logueado como la víctima en decenas de sitios simultáneamente.

Dato que pocos saben: los infostealers son tan efectivos que cambiaron el balance del mercado. En 2024-2026, la mayoría de los ataques contra cuentas de usuarios finales empiezan con logs de infostealer, no con credential stuffing.

2. Proxy phishing (Evilginx, Modlishka)

Una variante moderna del phishing que captura todo en una sola pasada:

1. El atacante monta un sitio falso que proxy-ea al real en tiempo real.
2. La víctima ingresa credenciales — el proxy las captura y las pasa al sitio real.
3. El sitio real pide 2FA — el proxy captura el código y lo pasa.
4. El sitio real valida y emite cookie de sesión — el proxy la intercepta.
5. El atacante ahora tiene contraseña, código 2FA consumido (irrelevante) y cookie de sesión válida.

La víctima termina logueada en el sitio real sin notar nada raro. El atacante tiene acceso paralelo con la cookie robada.

Lo que no ayuda: TOTP, SMS, push notifications — todas se interceptan. Lo que sí ayuda: passkeys y security keys físicas, porque están atadas al dominio real y simplemente no funcionan en el proxy.

3. XSS que lee cookies

Si el sitio tiene una vulnerabilidad de Cross-Site Scripting (XSS) y las cookies no están marcadas con httpOnly, el atacante inyecta JavaScript que lee document.cookie y la manda a su servidor.

Mitigación trivial pero no siempre aplicada: marcar cookies como httpOnly para que JavaScript no pueda leerlas. Esto no evita todas las formas de XSS leverage, pero cierra el vector más directo.

4. Man-in-the-middle (MITM) en redes inseguras

En WiFi público sin HTTPS, un atacante puede interceptar el tráfico y leer cookies en texto plano. En 2026, esto debería ser imposible (HTTPS es universal), pero todavía hay:

• Redirecciones HTTP → HTTPS mal configuradas (la primera request es interceptable).
• Certificados TLS inválidos que usuarios ignoran.
• Man-in-the-middle con certificado legítimo en empresas con TLS interception (por software de seguridad corporativo).

Mitigación: HSTS obligatorio, cookies con flag Secure (solo se envían por HTTPS).

5. Session fixation

Ataque menos común pero persistente. El atacante genera una sesión (sin login) en el sitio víctima y le pasa el session ID al usuario (via URL malformada, XSS, o mail). Cuando el usuario hace login, el sitio mal configurado puede reutilizar el mismo session ID en lugar de regenerar uno nuevo — y el atacante queda con sesión válida compartida.

Mitigación: regenerar session ID en cada evento de autenticación (login, cambio de contraseña, elevación de privilegios).

Configuración defensiva de cookies

Antes de hablar de detección, lo básico preventivo. Una cookie de sesión bien configurada debería tener:

• Secure: solo se envía por HTTPS. Sin este flag, se envía por HTTP también y es interceptable.
• HttpOnly: no accesible por JavaScript. Sin este flag, XSS puede leerla.
• SameSite=Strict (o Lax como mínimo): no se envía en requests cross-site, previene CSRF y algunos vectores de hijacking.
• Path=/ y Domain=... correctos: no más amplios de lo necesario.
• Expiración corta: 30 minutos a 4 horas según sensibilidad; re-auth para extender.
• Regeneración en eventos: nuevo session ID al login, cambio de password, elevación de privilegios.

Si alguna de estas falta, el atacante tiene camino más fácil. Muchos sitios WordPress por default tienen cookies sin SameSite correcto — revisar es trabajo de 10 minutos.

UBA: el análisis que detecta al impostor dentro de la sesión

Asumiendo que no pudiste prevenir el robo (infostealer ya corrió en el dispositivo del usuario, proxy phishing fue exitoso), la última línea de defensa es User Behavior Analytics — análisis continuo del comportamiento dentro de la sesión autenticada.

La premisa: el atacante con la cookie robada va a comportarse distinto del usuario legítimo. No perfectamente distinto — imitar es posible — pero suficiente para que un modelo entrenado en el baseline del usuario pueda detectar anomalías.

Qué conforma el baseline de un usuario

Señales que se tracken para cada usuario autenticado:

• Ubicación geográfica: países, ciudades, IPs típicas, ASN.
• Horarios de actividad: distribución por hora del día, por día de la semana, timezone consistente.
• Dispositivo: user-agent, device fingerprint (canvas, WebGL, fonts, hardware), OS, browser.
• Patrón de navegación: secuencias típicas (home → listado → detalle → carrito), páginas frecuentes, páginas que nunca visita.
• Velocidad y ritmo: tiempo entre clicks, duración de sesión típica, distribución de acciones por minuto.
• Endpoints y APIs: qué endpoints el usuario típicamente usa, qué cambios hace típicamente.

Estas señales se acumulan durante las primeras N sesiones del usuario (típicamente 5-20 sesiones) para construir baseline confiable. A partir de ahí, cada sesión nueva se evalúa contra el baseline en tiempo real.

Las 7 señales que delatan una sesión secuestrada

Las desviaciones más predictivas de hijacking:

1. Cambio abrupto de geolocalización: la sesión empezó en Buenos Aires a las 14:00 y de repente hay requests desde Berlín a las 14:03. Viaje imposible — una de las dos ubicaciones está mintiendo, y la cookie es la que se transfirió.
2. Cambio de user-agent o device fingerprint dentro de la sesión: el usuario estaba en Chrome en Windows, ahora aparece Firefox en Linux con las mismas cookies. Improbable.
3. Acceso a endpoints nunca usados por el usuario: el usuario nunca tocó /wp-admin/users.php, pero ahora está ahí. Si es admin y hace esto regularmente, es baseline; si es editor que jamás usó esa página, es red flag.
4. Velocidad no humana: 150 clicks en 60 segundos en páginas distintas. Humanos no navegan así. Bot o script.
5. Patrón de navegación que salta el funnel normal: usuario que siempre entra por home → categoría → producto ahora entra directo a /checkout via URL. Puede ser legítimo (link compartido) o puede ser atacante con conocimiento específico del sistema.
6. Request headers inconsistentes: Accept-Language, timezone del header, otros metadatos que dejan de ser consistentes entre requests de la misma sesión.
7. Acción sensible sin re-autenticación: cambio de email, cambio de contraseña, agregado de nuevo método de pago — sin que haya habido re-auth reciente. Aquí el sistema debe intervenir incluso sin otras señales.

Ninguna señal sola es definitiva. La fuerza está en la combinación: score compuesto que sube cuando varias señales se desvían simultáneamente.

Política de respuesta escalonada

Detectar no sirve si no hay acción correspondiente. El modelo de respuesta correcto es escalonado, no binario:

Nivel 1: baja anomalía

• Log del evento para análisis posterior.
• Ninguna acción visible al usuario.
• Enriquecer baseline con el evento (si resulta ser legítimo).

Nivel 2: anomalía media

• Alerta al SOC o al equipo de seguridad.
• Acceso permitido pero con tracking reforzado en el resto de la sesión.
• Si ocurre acción sensible, elevar a nivel 3 automáticamente.

Nivel 3: anomalía alta

• Re-autenticación forzada antes de continuar. Re-pide contraseña + 2FA.
• Si pasa, la sesión continúa con score reseteado y tracking reforzado.
• Si falla, bloqueo + invalidación + notificación.

Nivel 4: anomalía crítica

• Bloqueo inmediato de la sesión. Invalidación del token.
• Notificación al usuario legítimo por canal fuera de banda (email, SMS).
• Alerta al equipo de seguridad con todo el contexto.
• Registro para forense posterior.

Este modelo balancea detección agresiva con experiencia del usuario legítimo. Un usuario real con desviación menor no se ve afectado; un atacante activo se corta rápidamente.

Acciones sensibles: re-auth siempre, sin excepciones

Independiente del score de anomalía, ciertas acciones deben disparar re-autenticación siempre:

• Cambio de contraseña.
• Cambio de email de la cuenta.
• Agregado o cambio de método de pago.
• Acciones financieras de impacto (transferencias, compras grandes).
• Cambio de permisos o roles.
• Delete masivo de datos.
• Generación o revocación de API keys.

Este es principio de defensa en profundidad. Aunque el score UBA no detecte nada, si una acción sensible ocurre, el sistema pide reconfirmación. Es fricción aceptable para el usuario legítimo (5 segundos) y bloqueo efectivo para el atacante que solo tiene la cookie pero no la contraseña actual.

Cómo Drokio aborda esto (Guardián de Sesión)

El producto Guardián de Sesión en línea Identidad está diseñado específicamente para este vector:

• Baseline por usuario construido automáticamente con las primeras sesiones.
• Score compuesto en tiempo real sobre las 7 señales mencionadas.
• Política escalonada con 4 niveles configurables.
• Re-autenticación forzada integrada con el flujo de login (sin depender del desarrollador del sitio implementarlo).
• Invalidación de sesión con propagación — cuando se bloquea, se bloquea en todos los dispositivos del usuario.
• Notificación cross-channel (email + SMS + push) al usuario legítimo cuando hay actividad crítica.
• Integración con Llave (línea Identidad, gestión de credenciales): si la credencial aparece en dark web monitoring, el score UBA del usuario se eleva automáticamente por 7 días.

El objetivo no es reemplazar 2FA ni password managers — es cerrar el agujero que ambos dejan abierto después del login.

Cierre

El login es solo la mitad del problema de identidad. La otra mitad — la sesión autenticada — es donde los ataques modernos operan, donde 2FA no llega, y donde la mayoría de los sitios siguen sin controles. Infostealers, proxy phishing, XSS: vectores masivos y activos en 2026. La defensa realista no es prevenir 100% (infostealers seguirán rompiendo dispositivos) sino detectar al impostor dentro de la sesión y reaccionar escalonadamente. UBA bien implementado con política escalonada convierte el session hijacking de "breach invisible" en "incidente detectado en minutos". Sin esa capa, una cookie robada es acceso por el tiempo completo de la sesión — que puede ser horas o días.