🧠Análisis de comportamiento en sesiones autenticadas: la nueva frontera

Durante años, la industria enfocó todo el esfuerzo de detección de anomalías en el login: IPs inusuales, horarios raros, dispositivos nuevos. Esa capa está resuelta — cualquier sistema decente hoy lo hace. La frontera 2026 es distinta: detectar anomalías dentro de la sesión ya autenticada.

El problema es fundamental. Los ataques modernos (session hijacking, proxy phishing, infostealers) entregan al atacante una sesión legítima activa — pasaron el login, tienen cookie válida, 2FA ya quedó atrás. La única capa que puede detectarlos es análisis continuo del comportamiento durante la sesión, comparando contra baseline individual del usuario.

Este artículo explica cómo funciona UBA moderno aplicado a sesiones autenticadas, qué señales se usan, cómo se entrena el modelo, y por qué esta capa dejó de ser "nice to have" para volverse obligatoria en cualquier sitio con autenticación seria.

Por qué el login ya no es suficiente punto de control

Históricamente, la lógica era: validar al usuario en el login, emitir token, y asumir que el poseedor del token es el usuario. Esa lógica funcionó mientras el token era difícil de robar. En 2026 no lo es.

Vectores que entregan al atacante una sesión activa sin romper la autenticación:

• Infostealer malware: extrae cookies del navegador. El atacante las importa y queda adentro.
• Proxy phishing (Evilginx, Modlishka): intercepta la cookie durante login legítimo.
• XSS en sitio con cookies mal configuradas: JavaScript del atacante lee cookies.
• Sesión física comprometida: laptop desbloqueada sin atender, dispositivo robado, exempleado con acceso residual.
• Token leak por log, URL, captura de pantalla: sesiones con IDs en URLs que terminan en analytics de terceros.

En cada caso, la autenticación fue exitosa — el ataque ocurre después. Los controles pre-login (contraseña fuerte, 2FA, captcha, rate limiting) son irrelevantes. La única capa efectiva es monitoreo continuo del comportamiento dentro de la sesión.

Las 10 dimensiones del baseline de comportamiento

Un modelo UBA serio tracka mucho más que "IP y horario". Las dimensiones relevantes:

Dimensión 1: geolocalización

• IP origen, país, ciudad.
• ASN y tipo de conexión (residencial, datacenter, VPN, Tor).
• Cambio geográfico dentro de la sesión.
• Viaje plausible vs imposible.

Dimensión 2: temporal

• Hora del día típica.
• Día de la semana.
• Duración habitual de sesión.
• Frecuencia de sesiones.

Dimensión 3: dispositivo

• User-agent completo (no solo browser).
• Device fingerprint: canvas, WebGL, fonts, hardware.
• OS y versión.
• Resolución, timezone, idioma.

Dimensión 4: navegación

• Endpoints visitados típicamente.
• Secuencias de navegación habituales (Markov chain por usuario).
• Endpoints que nunca toca.
• Patrón de entrada (directo, referred, bookmark).

Dimensión 5: velocidad y ritmo

• Tiempo entre acciones.
• Distribución de acciones por minuto.
• Pausas típicas (lectura, reflexión).
• Velocidad de escritura en formularios.

Dimensión 6: interacción

• Movimiento de mouse y patrones de scroll (donde se puede trackear).
• Uso de atajos de teclado.
• Copy-paste vs tipeo.
• Clicks por minuto.

Dimensión 7: API/endpoints

• Qué endpoints de API consume típicamente.
• Volumen de requests por sesión.
• Payload patterns.
• Rate de errores.

Dimensión 8: red

• Latencia típica desde la IP origen.
• Características TCP/TLS.
• Network signature consistencia.

Dimensión 9: contenido

• Tipos de contenido que crea/edita típicamente.
• Volumen de cambios.
• Hora típica de edición vs lectura.

Dimensión 10: social/organizacional

• Con qué otros usuarios interactúa.
• En qué recursos compartidos trabaja.
• Patrón de comunicación.

Un modelo completo incorpora señales de múltiples dimensiones. Un modelo simple usa 2-3 dimensiones y tiene techo de detección bajo.

Score compuesto: cómo se combinan señales

Ninguna señal sola basta. Cambio de IP: puede ser VPN corporativa. Cambio de user-agent: puede ser actualización del browser. Velocidad alta: puede ser usuario impaciente. La detección efectiva viene de la combinación.

Modelo de scoring

Para cada request o batch de requests en sesión activa:

1. Calcular desviación de cada dimensión contra baseline del usuario (puntaje 0-1 por dimensión).
2. Ponderar por importancia de la dimensión (geolocalización suele pesar más que velocidad).
3. Combinar en score compuesto (típicamente media ponderada o modelo ML entrenado).
4. Contextualizar por acción: el mismo score tiene implicación distinta si está leyendo un post vs si está cambiando su contraseña.
5. Comparar contra threshold para disparar política correspondiente.

Thresholds y política

Thresholds típicos con política escalonada:

• Score menor a 0.3: normal. Log para análisis.
• Score entre 0.3-0.5: ligeramente anómalo. Tracking reforzado, sin acción visible.
• Score entre 0.5-0.7: anómalo. Alerta al SOC, re-auth si hay acción sensible.
• Score entre 0.7-0.85: muy anómalo. Re-autenticación forzada obligatoria.
• Score sobre 0.85: crítico. Bloqueo de sesión + notificación fuera de banda.

Los números son ejemplos — tuning real depende del sitio, tipo de usuarios, tolerancia a falsos positivos.

Cómo se entrena el modelo

Hay tres enfoques, en orden de sofisticación:

Enfoque 1: reglas estáticas

Reglas hardcoded tipo "si la IP cambia a otro país en la misma sesión, alertar". Simple, transparente, fácil de implementar. Límites: fácil de evadir, genera falsos positivos en usuarios legítimos atípicos, no captura patrones sutiles.

Útil como: capa base de catch de casos obvios. Siempre combinar con enfoque 2 o 3.

Enfoque 2: ML clásico

Modelo estadístico entrenado sobre baseline del usuario. Técnicas comunes: Isolation Forest, One-Class SVM, Local Outlier Factor, clustering para segmentos.

• Features: las 10 dimensiones vectorizadas.
• Training: sobre primeras N sesiones del usuario para baseline, refinamiento continuo.
• Inference: por request o por batch, típicamente bajo 10ms.

Ventaja: balance bueno entre detección y costo computacional. Interpretable (podés saber por qué score dio alto).

Límite: no captura patrones secuenciales complejos.

Enfoque 3: ML moderno con embeddings y LLM

Modelos más avanzados que usan:

• Embeddings de sesión: cada sesión se representa como vector en espacio semántico. Detectan anomalías por distancia en embedding space.
• Modelos secuenciales (LSTM, Transformers): capturan orden y dependencia entre acciones dentro de la sesión.
• LLM para contextualización: explicación en lenguaje natural de por qué una sesión es anómala, útil para SOC.
• Graph neural networks: cuando hay múltiples usuarios y recursos, modelar la red de interacciones detecta anomalías relacionales.

Ventaja: techo de detección más alto, captura patrones complejos que reglas y ML clásico no ven.

Costo: más infraestructura, más latencia si no se optimiza, menos interpretable.

Adaptación continua vs baseline estático

• Baseline estático: se entrena una vez (primeras N sesiones), no se actualiza. Problema: degrada con el tiempo porque el usuario real cambia patrones legítimamente.
• Baseline adaptativo: se actualiza continuamente incorporando sesiones recientes validadas como legítimas. Problema: si el atacante opera por tiempo largo, puede envenenar el baseline (data poisoning).
• Balance ideal: baseline adaptativo con ventana móvil (ej: últimas 90 sesiones), con detección de drift súbito (cambio rápido del baseline es sospechoso en sí), y con anclaje periódico a baseline estable (cada X semanas se toma snapshot para comparar drift gradual).

Integración con el resto del stack

UBA aislado es valioso pero limitado. Integrado con otras capas multiplica impacto:

Con 2FA

Cuando UBA dispara anomalía media, requerir re-2FA en la próxima acción sensible. 2FA acá no es validación primaria sino fricción adicional contra atacante.

Con vault / password manager

Si una credencial del usuario apareció en dark web monitoring, el threshold de UBA baja automáticamente (más sensible) por 7-14 días. Correlación entre fuga conocida y comportamiento anómalo es señal casi certera de compromiso.

Con SIEM

Eventos UBA estructurados entran al SIEM como cualquier otro evento. Permite correlacionar sesión anómala con otros eventos (alertas de firewall, detecciones de EDR, cambios de configuración).

Con SOAR

Respuesta automatizada: anomalía crítica → runbook automático (invalidar sesión, rotar credencial, notificar usuario, crear ticket). Elimina latencia humana en respuesta.

Con IAM

Si UBA detecta anomalía persistente de un usuario, IAM puede revocar temporalmente permisos elevados hasta revisión manual.

Falsos positivos: el enemigo de UBA

Un sistema UBA que molesta a usuarios legítimos con re-auths frecuentes se va a desactivar políticamente por fricción. El balance es crítico.

Causas comunes de falsos positivos

• Baseline insuficiente (usuario muy nuevo, uso esporádico).
• Usuario con comportamiento legítimamente variable (viajero frecuente, trabaja de distintos dispositivos).
• Cambios legítimos no comunicados al sistema (equipo cambió de oficina, nuevo rol).
• Over-weight de una dimensión que cambió por razón legítima.
• Threshold mal calibrado para el segmento de usuario.

Mitigaciones

• Segmentación de usuarios: thresholds distintos para "admin que trabaja de oficina fija" vs "vendedor que viaja constante".
• Feedback loop: cuando usuario pasa re-auth, marcar sesión como legítima y reforzar baseline.
• Canal para false positive explícito: botón "esto era yo, ajustá baseline" que el usuario legítimo puede usar.
• Whitelisting inteligente: ubicaciones, dispositivos, networks marcados como confiables por el usuario.
• Tuning por ciclos: revisar thresholds trimestralmente con datos reales de falsos positivos.

Un modelo bien tuneado debe estar bajo 1% de falsos positivos críticos (que fuerzan re-auth). Sobre ese número, hay que ajustar.

Límites de UBA

Honestidad intelectual: UBA no es invencible.

• Atacante paciente y observador: si el atacante estudia el comportamiento del usuario antes de actuar (ej: session hijacking con acceso por semanas), puede imitar el baseline lo suficiente para no disparar umbrales.
• Baseline insuficiente en usuarios nuevos o esporádicos: cobertura débil durante semanas iniciales.
• Evasión por canary: atacante sofisticado puede probar umbrales con acciones menores antes de ejecutar la sensible.
• No detecta ataques donde el usuario legítimo es el problema (insider malicioso operando dentro de su baseline normal).
• Dependencia de volumen de señales: si el sitio no emite suficientes eventos trackeables, el modelo queda subalimentado.

UBA es capa crítica pero no la única. Combinada con 2FA fuerte, vault con rotación, dark web monitoring y detección en endpoint (EDR), la superficie total se cubre mucho más.

Cuándo adoptar UBA en tu stack

Indicadores de que ya lo necesitás:

• Tu sitio tiene zona autenticada con datos sensibles (admin panel, finanzas, datos personales).
• Tus usuarios tienen privilegios asimétricos (admins vs users con acceso distinto).
• Has tenido al menos un incidente relacionado con cuenta comprometida (o conocés competidores que sí).
• Regulación aplicable (PCI, HIPAA, GDPR en sitios de datos) menciona controles de acceso continuos.
• Tenés capacidad de respuesta: alerta sin respuesta es ruido.

Si cumplís 3 de estos 5, UBA deja de ser opcional.

Cierre

La detección de anomalías en login es territorio resuelto. La frontera real en 2026 es detectar al impostor después del login, dentro de la sesión autenticada que ya pasó todos los controles tradicionales. UBA con modelo moderno, baseline por usuario, score compuesto sobre múltiples dimensiones y política escalonada es la única capa efectiva contra session hijacking, proxy phishing e infostealers. Implementado bien, atrapa ataques invisibles a los otros controles sin generar fricción para usuarios legítimos. Implementado mal, genera ruido y se desactiva por política. La diferencia es tuning, integración y honestidad sobre sus límites.