Las sesiones ya autenticadas son el ataque que esquiva el control de acceso condicional

Prophet Security ha publicado su primer informe trimestral de amenazas después de investigar todas las alertas de sus entornos de cliente entre el 1 de mayo y el 31 de julio de 2026, sin aplicar el filtro humano que decide qué alerta merece análisis completo. De las investigaciones cerradas, el 93% resultaron benignas y el 7% actividad maliciosa confirmada. El hallazgo que destaca sobre el resto: en cerca de la mitad de esa actividad confirmada, el objetivo era la identidad.

Los números salen de 4,7 millones de preguntas lanzadas contra los entornos de los clientes a lo largo del trimestre, con una mediana de 35 por investigación.

Sesiones robadas frente a contraseñas

Los ataques directos contra cuentas y sesiones sumaron alrededor del 18% de la actividad maliciosa confirmada: secuestro de sesión, reenvío de tokens, bypass de MFA, credential stuffing y persistencia posterior al compromiso mediante reglas de bandeja de entrada y concesiones de consentimiento OAuth. El factor que mejor predecía el éxito no era la habilidad del atacante, sino el método de autenticación empleado.

Con contraseña, casi siempre se frenaba. El acceso condicional bloqueó contraseñas correctas que llegaban desde VPN comerciales en países nuevos o desde proveedores de hosting desconocidos, y el MFA resistente al phishing paró los proxys de intermediario que capturaban credenciales. Con una sesión ya autenticada, en cambio, los intentos entraban una y otra vez. En algunos casos, una misma cuenta acumuló decenas de inicios de sesión maliciosos a lo largo de tres semanas, con acceso continuo al correo.

El motivo es mecánico: las comprobaciones del acceso condicional ocurren durante la autenticación, y una cookie de sesión reenviada se salta ese paso, así que no dispara ninguna política. El refresh token solo vuelve al proveedor de identidad cuando se canjea, y ese es el único momento para reevaluar y revocar el acceso.

Las consecuencias se vieron en dos organizaciones donde desactivar la cuenta no detuvo al atacante: siguió usando permisos concedidos antes del bloqueo. En un caso cambió los métodos de autenticación y otorgó consentimientos OAuth cuando el equipo de seguridad daba el incidente por cerrado. Otra pista útil: un inicio de sesión en un país seguido de una aprobación de MFA en otro distinto dieciséis segundos después, y 118 segundos en un segundo intento. Ese hueco tan corto delata un proxy en tiempo real. También hubo fatiga de MFA, con avisos repetidos desde un proxy residencial hasta que el usuario aprobó, y una combinación de fuerza bruta, bloqueo, desbloqueo automático y push bombing para registrar un dispositivo nuevo.

Infostealers, del navegador a la identidad

La ejecución de código malicioso y su herramienta asociada supuso cerca del 23% de lo confirmado. Los infostealers tocaron a alrededor de una cuarta parte de las organizaciones investigadas y llegaron mayoritariamente por el navegador, no por correo: sitios legítimos comprometidos, anuncios maliciosos, resultados patrocinados y falsas puertas CAPTCHA del estilo ClickFix, que exigen un clic humano y así esquivan el sandbox automático. Los instaladores troyanizados fueron el punto de entrada más común, presentes en torno a un cuarto de las organizaciones. Uno de ellos era una versión manipulada de una aplicación de IA popular que se ejecutaba desde la carpeta de descargas, desactivaba Windows Defender, creaba una tarea programada con privilegios altos y abría canales de mando y control. Entre las herramientas de distribución aparecen ClearFake y SocGholish, y entre las cargas útiles Lumma Stealer, Vidar, HijackLoader y AsyncRAT. La infraestructura de SocGholish se desmanteló el 18 de junio de 2026 en la operación Endgame, pero el modelo de la falsa actualización sigue vivo en ClearFake.

El paso final es conocido: la cookie robada no necesita contraseña ni MFA, y sobrevive a un cambio de contraseña o al borrado del dispositivo si la sesión no se revoca. En un incidente, un script descifró el almacén de cookies del navegador, extrajo las de autenticación de Microsoft y las usó para hacer peticiones autenticadas a la API.

La categoría más grande fue el phishing de credenciales, con un 28% de lo confirmado, orientado a robar credenciales.

Los datos son del propio proveedor, que vende justamente un SOC con IA, así que conviene leerlos como cifras suyas y no de un tercero independiente. Lo aprovechable para quien administra identidades es concreto: revisar la revocación de sesiones y refresh tokens, no solo los cambios de contraseña, y asumir que una cookie robada convierte un endpoint comprometido en un compromiso de identidad.