Análisis de comportamiento en sesiones autenticadas: la nueva frontera | Drokio Blog | Drokio
IdentidadUBAcomportamientoanomalías
🧠Análisis de comportamiento en sesiones autenticadas: la nueva frontera
Detección de anomalías en el login es territorio conocido. La frontera 2026 es detectar anomalías después del login, dentro de la sesión autenticada. Cómo funciona UBA moderno, qué señales importan, cómo se entrena el modelo por usuario y por qué es el único control efectivo contra sesiones secuestradas.
Drokio··10 min de lectura
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é la detección de anomalías en login no cubre hijacking y credenciales robadas.
Las 10 dimensiones que conforman un baseline de comportamiento por usuario.
Cómo se combinan señales en un score compuesto sin generar falsos positivos.
Entrenamiento y actualización continua del modelo: baseline estático vs adaptativo.
Diferencias entre UBA con reglas, con ML clásico, y con LLM/embedding moderno.
Cómo integrar UBA con el resto del stack de identidad (2FA, vault, dark web monitoring).
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).
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:
Calcular desviación de cada dimensión contra baseline del usuario (puntaje 0-1 por dimensión).
Ponderar por importancia de la dimensión (geolocalización suele pesar más que velocidad).
Combinar en score compuesto (típicamente media ponderada o modelo ML entrenado).
Contextualizar por acción: el mismo score tiene implicación distinta si está leyendo un post vs si está cambiando su contraseña.
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.
¿Querés proteger tu sitio ahora?
Drako es el plugin de seguridad con IA para WordPress. Instalación en 2 minutos, desde $9/mes.
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.
Preguntas frecuentes
¿En qué se diferencia UBA de SIEM tradicional?
SIEM tradicional correlaciona eventos de log con reglas predefinidas (ej: '5 logins fallidos = alerta'). UBA construye baseline por usuario y alerta cuando hay desviación significativa del baseline individual — aunque ningún evento específico sea 'sospechoso' por reglas clásicas. SIEM responde 'esto rompió una regla conocida'; UBA responde 'esto no se parece a cómo este usuario normalmente opera'. Son complementarios, no sustitutos.
¿Cuánto tiempo necesita UBA para generar baseline útil?
Varía por señal. Geolocalización y horarios típicos se estabilizan en 5-10 sesiones. Patrones de navegación necesitan 10-30 sesiones. Velocidad y ritmo pueden ser útiles desde la tercera sesión. Un sistema bien diseñado usa baseline parcial con confianza calibrada — las primeras sesiones tienen menos sensibilidad porque el baseline es incompleto, y la sensibilidad sube a medida que el baseline madura. Entre 2-4 semanas de uso activo para baseline sólido.
¿UBA funciona para usuarios nuevos sin baseline?
Sí, pero con fallback distinto. Mientras no hay baseline individual suficiente, el sistema usa baseline por segmento (ej: baseline de 'admin de tienda WooCommerce chica' vs 'comprador mobile ocasional'). Un usuario nuevo se ubica en el segmento más cercano y se lo evalúa contra ese baseline hasta que acumule historia propia. La detección es más laxa en este período pero no nula.
¿Los usuarios legítimos se ven afectados por cambios normales (viaje, nuevo dispositivo)?
Con modelo bien calibrado, no. El sistema reconoce que cambios legítimos ocurren y adapta baseline. Viaje real se detecta por progresión (llegada a aeropuerto, nuevo país), no por salto abrupto. Nuevo dispositivo típicamente se acompaña de login manual con 2FA, lo que señala cambio autorizado. Los falsos positivos ocurren cuando se trata cambio legítimo como anómalo — indicador de modelo mal ajustado o que necesita más datos de entrenamiento.
¿Este tipo de análisis no es costoso computacionalmente?
Menos de lo que uno supondría. El análisis por request es liviano — comparar features del request contra baseline vectorizado. Lo pesado es el entrenamiento del baseline y la actualización periódica del modelo, pero eso ocurre en batch offline, no en el path crítico. Un sitio con 100k usuarios activos puede correr UBA sin impacto perceptible en latencia si la arquitectura está bien diseñada (evaluación async, cache de baseline, thresholds pre-computados).
¿Se puede usar UBA sin IA? ¿Solo con reglas?
Parcialmente. Reglas simples (misma sesión cambia de país, velocidad imposible, user-agent cambia) atrapan casos obvios pero son fáciles de evadir por atacantes que conocen las reglas. ML agrega la capacidad de detectar patrones sutiles que no son capturables por regla, y de adaptarse a baseline por usuario individual. Lo óptimo 2026 es capa de reglas duras (catch obvio) + modelo ML (catch sutil) + threshold de severidad combinado. Solo reglas: útil pero techo bajo.
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.
