La mayoría de los kits de phishing todavía fallan en el momento en que un objetivo tiene activada la autenticación multifactor. BigBear 2.0 no. Investigadores del equipo TRIAD de CloudSEK encontraron el panel de control del operador y lograron entrar directamente, y lo que vieron fue una operación de robo de credenciales de Microsoft 365 construida específicamente para sobrevivir al MFA, a una escala que ya había comprometido a 258 organizaciones cuando el reporte se hizo público.
Entrando al Propio Panel del Operador
BigBear 2.0 es un kit de intermediario adversario (AiTM) basado en Evilginx2, una versión renombrada de una herramienta anterior vendida bajo el mismo nombre. Evilginx2 funciona como un proxy inverso: la víctima hace clic en un enlace, llega a una página que refleja el flujo real de inicio de sesión de Microsoft pixel por pixel, y cada campo que escribe, contraseña y código de un solo uso incluidos, pasa por el servidor del atacante en su camino hacia los servidores reales de Microsoft. Microsoft emite una sesión real, y el proxy captura la cookie de sesión junto con ella. Los investigadores de CloudSEK descubrieron que BigBear ejecuta un único phishlet, construido exclusivamente para Microsoft 365, y rastrearon la operación a través de 42 nodos VPS durante la vida de la campaña, la mayoría alojados en Vultr. Dentro del propio panel estaban los números de la operación: 5,137 registros de credenciales robadas, 1,032 de ellas todavía en texto plano, 4,148 cookies de sesión capturadas, y 474 autenticaciones posteriores al MFA completadas y registradas contra 3,331 direcciones IP de víctimas distintas.
Tres Adiciones Que Marcan la Diferencia
Evilginx2 estándar ya derrota el MFA básico al retransmitir el código en tiempo real. Los operadores de BigBear le añadieron tres inyecciones personalizadas dirigidas específicamente a las defensas que las organizaciones agregan después de creer que el MFA ya resolvió el problema. Una bloquea la solicitud de llaves de hardware FIDO2 y WebAuthn, forzando que el flujo de inicio de sesión recurra a un método más fácil de suplantar, como un código SMS o una notificación de una app autenticadora. Otra suprime las señales de telemetría y tokens señuelo que Microsoft usa para detectar que un inicio de sesión pasa por un proxy en lugar de un navegador real. La tercera selecciona automáticamente “mantener la sesión iniciada”, lo que extiende el tiempo que una cookie de sesión robada permanece válida antes de necesitar renovarse. Ninguna de estas es un exploit de día cero exótico. Son ediciones pequeñas y deliberadas dirigidas exactamente a los controles que un equipo de seguridad señalaría como prueba de que su programa de MFA es sólido.
Igualando la Ubicación Real de la Víctima
El kit enruta los intentos de inicio de sesión a través de proxies residenciales geolocalizados que abarcan 69 países, eligiendo una IP de salida cercana a la víctima real antes de que las credenciales lleguen a Microsoft. Las verificaciones de viaje imposible y de reputación de IP están diseñadas para detectar un inicio de sesión que aparece desde un centro de datos al otro lado del mundo segundos después de la última sesión real del usuario. Cuando el tráfico del atacante parece provenir de la propia ciudad de la víctima, toda esa categoría de detección no tiene nada que señalar.
Por Qué Esto Es una Historia de DMARC, No Solo de MFA
Una contraseña robada y un MFA vencido son el titular, pero la parte que debería preocupar específicamente a un programa de DMARC llega después. Una vez que el operador de BigBear tiene una cookie de sesión activa, tiene acceso funcional a la bandeja real, en la propia infraestructura de Microsoft, bajo la identidad real del usuario. El correo enviado desde ese acceso no está suplantado, prestado, ni enrutado a través de un dominio parecido. Sale por los mismos servidores, con la misma clave DKIM, desde la misma cuenta autenticada que la víctima usa todos los días, y pasa SPF, DKIM y DMARC porque cada una de esas verificaciones responde con honestidad: sí, esta bandeja está autorizada a enviar como este dominio. Un mensaje de seguimiento construido desde una sesión secuestrada también puede aterrizar dentro de un hilo de respuesta real y existente con un colega o proveedor genuino, que es exactamente el tipo de contexto que un destinatario usa para decidir que un mensaje es seguro.
Qué Significa Esto Para Tu Programa
El MFA detiene el relleno de credenciales. No detiene un proxy en tiempo real que retransmite tu código de MFA hacia el servicio real en el instante en que lo escribes. Las llaves de hardware cierran esa brecha para un inicio de sesión, pero solo cuando el flujo de inicio de sesión permite que el dispositivo complete realmente su desafío, que es precisamente el paso que la inyección FIDO2 de BigBear está diseñada para bloquear.
Una bandeja comprometida es una brecha ciega para DMARC por definición, porque DMARC nunca fue diseñado para detectarla. El protocolo verifica que un dominio autorizó un mensaje. No tiene forma de verificar que la persona o el proceso detrás de un envío autorizado siga siendo aquel en quien tu organización confía.
El robo de cookies de sesión merece la misma atención operativa que el robo de contraseñas, y la mayoría de los programas de detección todavía invierten poco en ello. Las políticas de acceso condicional que fuerzan una nueva autenticación en dispositivos nuevos, la reducción de la vida útil de las sesiones, y el monitoreo de reutilización de sesiones imposible o anómala cierran brechas que un paso limpio de DMARC nunca revelará por sí solo.
“Mantener la sesión iniciada” es una función de conveniencia con un costo de seguridad que la mayoría de los usuarios, y muchos administradores, nunca sopesan entre sí. Cada hora que una sesión permanece válida sin volver a autenticarse es una hora en la que una cookie robada sigue funcionando.
La Conclusión
BigBear 2.0 no venció a DMARC. Se saltó por completo la pregunta que DMARC responde, tomando control de una cuenta en la que DMARC ya confiaba. Doscientas cincuenta y ocho organizaciones aprendieron que un resultado de autenticación en verde en un mensaje saliente no dice nada sobre si la persona que lo envía sigue siendo quien debería. A medida que los kits AiTM sigan añadiendo defensas diseñadas específicamente contra FIDO2 y la detección por telemetría, las bandejas que tu dominio ya autenticó merecen vigilarse tan de cerca como las que intentan suplantarte.
DMARC confirma que un mensaje fue autorizado a enviarse como tu dominio. No puede decirte cuándo la cuenta que lo envía fue tomada silenciosamente por alguien más. Excello Mail te da visibilidad continua sobre todo lo que envía en nombre de tu dominio, para que la actividad autenticada inusual se destaque en lugar de perderse entre los reportes de DMARC que pasan sin problema. Regístrate gratis en Excello Mail y pon esa visibilidad en marcha antes de que un kit AiTM encuentre la brecha primero.