Session hijacking: qué es, cómo te atacan, y cómo Drokio lo detecta | Drokio Blog | Drokio
Identidadsession hijackingcookiesUBA
🛡️Session hijacking: qué es, cómo te atacan, y cómo Drokio lo detecta
Después de un login legítimo, la sesión autenticada es un cheque en blanco. Si el atacante roba la cookie, 2FA es irrelevante: ya está dentro. Cómo funciona el hijacking moderno (infostealers, proxy phishing, XSS), qué señales delatan una sesión robada, y cómo detectarlo sin afectar la experiencia del usuario legítimo.
Drokio··10 min de lectura
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.
Por qué 2FA protege el login pero no la sesión posterior.
Las 5 técnicas modernas de robo de sesión: infostealers, proxy phishing, XSS, MITM, session fixation.
Qué son las cookies de sesión y cómo deberían estar configuradas.
User Behavior Analytics (UBA): la técnica que detecta al impostor dentro de la sesión.
Las 7 señales que delatan una sesión secuestrada.
Cómo balancear detección agresiva con experiencia del usuario legítimo.
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:
El atacante monta un sitio falso que proxy-ea al real en tiempo real.
La víctima ingresa credenciales — el proxy las captura y las pasa al sitio real.
El sitio real pide 2FA — el proxy captura el código y lo pasa.
El sitio real valida y emite cookie de sesión — el proxy la intercepta.
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.
¿Querés proteger tu sitio ahora?
Drako es el plugin de seguridad con IA para WordPress. Instalación en 2 minutos, desde $9/mes.
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:
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:
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ó.
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.
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.
Velocidad no humana: 150 clicks en 60 segundos en páginas distintas. Humanos no navegan así. Bot o script.
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.
Request headers inconsistentes: Accept-Language, timezone del header, otros metadatos que dejan de ser consistentes entre requests de la misma sesión.
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.
Preguntas frecuentes
Si tengo HTTPS, ¿puede alguien robar mi cookie?
HTTPS protege la cookie en tránsito entre cliente y servidor, pero no la protege en los dos extremos. El atacante no intercepta tráfico encriptado — roba la cookie del navegador del usuario (via infostealer, extensión maliciosa, XSS) o desde un proxy phishing que la captura en el momento del login legítimo. HTTPS es necesario pero no suficiente contra session hijacking; necesitás capas adicionales como cookies httpOnly/secure/sameSite, detección de anomalías en sesión y expiración agresiva.
¿2FA detiene el session hijacking?
No, y este es el punto crítico que la mayoría no ve. El 2FA ocurre en el login. Si el atacante roba la cookie después del login (cuando ya estás autenticado), no necesita volver a hacer login — importa la cookie en su navegador y queda adentro como vos. El 2FA no vuelve a dispararse porque no hay re-autenticación. La única defensa post-login contra hijacking es análisis de comportamiento dentro de la sesión, no 2FA.
¿Cómo saben los sistemas que una sesión fue secuestrada?
Ninguna señal sola es definitiva — se combinan varias: cambio brusco de IP/geolocalización sin viaje plausible, cambio de user-agent o device fingerprint, desviación del patrón de navegación habitual del usuario, velocidad imposible entre acciones, acceso a endpoints que el usuario nunca toca. Un sistema moderno asigna score compuesto a cada sesión y dispara política cuando supera umbral — bloqueo, re-autenticación forzada o alerta al usuario legítimo.
¿Puedo prevenir hijacking en vez de solo detectarlo?
Parcialmente. Flags correctas en cookies (httpOnly, secure, sameSite strict), CSP fuerte contra XSS, expiración corta de sesión, rotación de session ID en eventos sensibles, y bindeo de sesión a device fingerprint reducen significativamente la superficie. Pero ninguna combinación previene 100% — infostealers siguen siendo efectivos si el dispositivo se infecta. Por eso detección en sesión es capa obligatoria, no opcional.
¿El análisis de comportamiento no genera falsos positivos molestos?
Genera falsos positivos si está mal calibrado. Bien calibrado, balancea baseline individual por usuario (no genérico), adapta thresholds según nivel de riesgo de la acción (navegar un post vs hacer checkout), y escala respuesta (log → re-auth → bloqueo) en lugar de binario. El objetivo no es detectar cualquier desviación — es detectar desviaciones que correlacionan con ataques reales. Modelos maduros tienen tasa de falsos positivos bajo 1% con alta detección.
¿Cuándo debería invalidar una sesión y forzar re-login?
En 5 escenarios: (1) cambio de IP con geofence imposible o país distinto, (2) detección de anomalías con score crítico, (3) acción sensible (pago, cambio de password, cambio de email, delete masivo) — siempre re-auth aunque la sesión parezca limpia, (4) credencial del usuario apareció en dark web monitoring, (5) inactividad prolongada (configurable, típicamente 30 minutos a 4 horas según sensibilidad). Escenarios 1 y 2 son automáticos; 3 es por diseño del flujo; 4 es integración cross-capa; 5 es higiene básica.
Producto mencionado
🛡️
Guardián de Sesión
El score de riesgo de secuestro de tus sesiones, vía API
Riesgo de secuestro de tus sesiones autenticadas: geo-velocidad, cambio de huella de dispositivo, sesiones concurrentes, escalada de privilegios e inactivo-luego-ráfaga — un score 0-100 de hijacking con banda, counts-only, vía señales por API, identity-free. $12/mes.
2FA para WordPress: por qué no es opcional en 2026
El login de WordPress es el endpoint más atacado del sitio. Sin 2FA, una contraseña comprometida es acceso total. Con 2FA bien elegido, los ataques masivos por credencial se vuelven económicamente inviables. Qué tipo de 2FA elegir, cómo imponerlo sin perder usuarios, y los errores que anulan su valor.
