El servicio de phishing BigBear 2.0 secuestró sesiones de Microsoft 365 en 258 organizaciones

Una plataforma de phishing como servicio conocida como BigBear 2.0 comprometió cuentas de Microsoft 365 en 258 organizaciones mediante técnicas de adversario en el medio para robar sesiones autenticadas después de que los usuarios completaran la autenticación multifactor.

CloudSEK informó de los hallazgos el 7 de septiembre de 2026, a las 11:39 a. m., después de obtener acceso de administrador al panel de control de la operación. Los investigadores encontraron 42 nodos de servidores privados virtuales, cada uno configurado para atacar la autenticación de Microsoft 365.

La campaña recopiló más de 5.000 registros de credenciales relacionados con Microsoft 365 y afectó a miles de direcciones IP en más de 40 países. Su infraestructura no estaba diseñada para vulnerar la MFA, sino para capturar la sesión creada después de que Microsoft la aceptara.

Esa distinción hace que el ataque sea especialmente peligroso. Un usuario puede introducir una contraseña correcta, aprobar una solicitud de MFA y, aun así, entregar al atacante una sesión autenticada en la nube.

BigBear convertía los inicios de sesión legítimos en sesiones del atacante

BigBear 2.0 está construido sobre Evilginx2, un framework de phishing de adversario en el medio, o AiTM. En lugar de mostrar a las víctimas un formulario de inicio de sesión completamente falsificado, el servicio actúa como proxy entre el navegador de la víctima y los sistemas legítimos de autenticación de Microsoft.

La víctima ve un flujo de inicio de sesión de Microsoft 365 e introduce su nombre de usuario y contraseña. BigBear retransmite esos datos a Microsoft mientras permanece situado entre ambas partes.

Cuando Microsoft solicita un factor de autenticación adicional, la víctima completa ese paso a través de la conexión intermediada por el proxy. BigBear puede observar entonces el material de autenticación y capturar la cookie de sesión emitida después de que el inicio de sesión se complete correctamente.

Un afiliado puede enviar la cookie robada a través de la API de BigBear y reproducir la sesión autenticada. Como Microsoft ya ha verificado la contraseña y el desafío de MFA, el atacante puede acceder a la cuenta sin repetir la interacción con el segundo factor.

Se trata de un secuestro de sesión, no de una derrota criptográfica de la MFA. El factor de autenticación puede funcionar exactamente como está diseñado y, aun así, la sesión resultante puede ser robada.

El ecosistema afectado incluye:

• Microsoft 365
• Exchange Online
• Teams
• SharePoint
• OneDrive
• Autenticación de Entra ID
• Aplicaciones conectadas mediante el inicio de sesión único de la organización

Las consecuencias dependen de los permisos de la víctima. Una cuenta normal podría exponer correos electrónicos, conversaciones, documentos y archivos compartidos. Una identidad de Entra ID con privilegios podría proporcionar acceso a recursos administrativos o a otras aplicaciones que confían en la misma identidad en la nube.

No se aplica ningún identificador CVE a la actividad descrita. Se trata de un abuso de la autenticación intermediada y de cookies de sesión robadas, no de una vulnerabilidad de software divulgada que afecte a un conjunto definido de versiones de Microsoft 365.

El panel registró compromisos en más de 40 países

Los datos de segmentación más amplios de BigBear incluían 461 organizaciones. CloudSEK evaluó que 258 habían sufrido al menos un compromiso completado que implicaba eludir la MFA mediante el robo de sesiones.

El panel de control también registró 3.331 direcciones IP únicas de víctimas distribuidas en más de 40 países. Una dirección IP no tiene por qué corresponder a una única cuenta individual, por lo que esa cifra no debe interpretarse como el número exacto de víctimas.

CloudSEK informó de 5.137 registros de credenciales exfiltrados, con las siguientes cifras desglosadas:

• 474 autenticaciones completadas en las que se eludieron las protecciones de MFA
• 1.032 contraseñas en texto plano
• 4.148 cookies de sesión autenticadas

Estas tres cifras suman 5.654, no 5.137. No se sabe si las categorías se solapan, si algunas entradas se deduplicaron o si uno de los valores comunicados es incorrecto. La discrepancia sigue sin resolverse y no debe corregirse basándose en suposiciones.

El panel seguía accesible cuando se comunicaron los hallazgos. Sin embargo, según los informes, la infraestructura de phishing relacionada llevaba casi tres semanas fuera de línea. Eso puede haber interrumpido la recopilación activa, pero no invalida las cookies, contraseñas o tokens obtenidos previamente.

El acceso robado podría seguir siendo útil hasta que los equipos defensivos revoquen las sesiones, caduquen los tokens, cambien las credenciales o impongan nuevos requisitos de autenticación.

Los afiliados recibían las credenciales robadas a través de Telegram

BigBear operaba como un servicio multiusuario y no como una herramienta reservada para un único actor de amenazas. Según los informes, su panel se alquilaba al menos a cinco operadores afiliados, lo que permitía a los clientes ejecutar campañas sin crear su propia infraestructura AiTM.

CloudSEK vinculó a esos operadores con bots de exfiltración activos en Telegram. Los bots entregaban las credenciales capturadas a los afiliados en tiempo real, reduciendo el intervalo entre el inicio de sesión de la víctima y el intento del atacante de utilizar la sesión resultante.

La plataforma utilizaba una configuración denominada “offy” para situar su proxy en el intercambio de autenticación de Microsoft. También operaba mediante 42 nodos VPS, lo que indica un modelo de infraestructura pensado para respaldar varias campañas o clientes.

No se ha divulgado ninguna lista de direcciones de nodos, dominios de phishing, hashes de archivos u otros indicadores que puedan buscarse directamente. Por tanto, las organizaciones no pueden basarse únicamente en el bloqueo de la infraestructura conocida de BigBear.

La detección también debe centrarse en la identidad y el comportamiento de las sesiones. Entre las señales relevantes pueden estar el uso inusual de sesiones autenticadas, el acceso desde dispositivos no administrados, actividad inesperada en buzones o archivos, cambios de privilegios y uso de tokens que no coincida con el patrón de trabajo habitual del usuario.

Los proxies residenciales y la interferencia con WebAuthn dificultaban la detección

BigBear admitía conexiones mediante proxies residenciales con coincidencia geográfica en 69 países. Estos proxies permitían a los afiliados generar tráfico de autenticación desde direcciones residenciales cercanas a la ubicación aparente de la víctima.

Esta capacidad debilita los controles basados principalmente en la geografía. Una sesión robada utilizada desde un país lejano puede activar una alerta de viaje imposible o basada en la ubicación, mientras que un proxy residencial de la región esperada puede hacer que el mismo acceso parezca menos anómalo.

La ubicación sigue siendo una señal útil, pero no es suficiente por sí sola. El estado de administración del dispositivo, las propiedades de la sesión, la actividad de las aplicaciones, el comportamiento de los tokens y los privilegios de la cuenta también deben influir en las decisiones de acceso.

CloudSEK también encontró JavaScript personalizado destinado a alterar la compatibilidad del navegador con FIDO2/WebAuthn. El objetivo aparente era impedir o interferir con la autenticación resistente al phishing, orientando a las víctimas hacia métodos que pueden retransmitirse con mayor facilidad a través de un proxy AiTM.

La autenticación FIDO2/WebAuthn aplicada correctamente es resistente al phishing convencional de credenciales porque la autenticación queda vinculada al origen web legítimo. Por tanto, la respuesta de BigBear no consistía en romper directamente esa protección, sino en intentar que no estuviera disponible durante el flujo de inicio de sesión de la víctima.

Las organizaciones deberían investigar los fallos inesperados de WebAuthn, especialmente cuando posteriormente se ofrece a los usuarios un método de inicio de sesión más débil. Permitir mecanismos alternativos puede eliminar buena parte del beneficio de seguridad que aporta el despliegue de credenciales resistentes al phishing.

Los equipos defensivos deben revocar las sesiones, no limitarse a cambiar las contraseñas

Un simple restablecimiento de contraseña puede no expulsar a un atacante que ya posee una cookie de sesión válida. Los equipos de respuesta a incidentes deben tratar la posible exposición a BigBear como un compromiso de credenciales y un robo de tokens al mismo tiempo.

Entre las acciones recomendadas se incluyen:

1. Restablecer las contraseñas asociadas a cuentas expuestas o sospechosas.
2. Revocar las sesiones activas de Microsoft 365 para impedir que las cookies capturadas sigan proporcionando acceso.
3. Invalidar o renovar los tokens pertinentes, incluidos los utilizados por aplicaciones conectadas en la nube.
4. Forzar una nueva autenticación para identidades con privilegios, administradores y otras cuentas de alto impacto.
5. Exigir métodos FIDO2/WebAuthn resistentes al phishing y restringir las opciones alternativas más débiles cuando sea posible desde el punto de vista operativo.
6. Utilizar políticas de Conditional Access que exijan dispositivos administrados o compatibles para los servicios sensibles.
7. Revisar la actividad de Exchange Online, Teams, SharePoint, OneDrive y Entra ID en busca de acciones que no coincidan con la función del usuario o con el historial de sus dispositivos.
8. Evitar considerar la coherencia geográfica como una prueba de legitimidad, dada la compatibilidad de BigBear con proxies residenciales.

CloudSEK afirmó que notificó a las fuerzas del orden y a varias organizaciones afectadas. Las credenciales expuestas también se incluyeron en informes de divulgación responsable.

El desafío general es que la actividad maliciosa resulta más difícil de detener una vez que tiene lugar dentro de una sesión autenticada válida. Una evaluación de Blue Report 2026 citada determinó que solo se bloqueó el 37 % de las acciones de los atacantes realizadas con credenciales válidas en 338 millones de simulaciones llevadas a cabo en entornos de producción de clientes. Ese resultado no era específico de BigBear, pero ilustra por qué es importante supervisar la actividad posterior a la autenticación.

La MFA sigue siendo necesaria, pero no todos los métodos de MFA ofrecen el mismo nivel de protección frente al phishing AiTM. Para las organizaciones que se enfrentan a servicios como BigBear, el modelo más sólido combina autenticación vinculada al origen, requisitos de dispositivos administrados, revocación rápida de sesiones y supervisión del comportamiento después del inicio de sesión.