El servicio de phishing BigBear 2.0 burló la autenticación multifactor en 258 organizaciones

La plataforma opera como proxy entre la víctima y Microsoft, roba la cookie de sesión ya autenticada y desactiva FIDO2 con JavaScript propio. CloudSEK contabilizó 5,137 credenciales exfiltradas.

Investigadores de CloudSEK obtuvieron acceso administrativo al panel de control de BigBear 2.0, una plataforma de phishing como servicio dirigida contra cuentas de Microsoft 365, y documentaron el alcance real de la operación.

El mecanismo

BigBear 2.0 se construye sobre Evilginx2 y funciona como proxy adversario en el medio. Se coloca entre la víctima y los sistemas de autenticación de Microsoft, captura la contraseña y retiene la cookie de sesión que Microsoft emite una vez completado el segundo factor.

Con esa cookie en mano, el atacante entra a la cuenta sin volver a pasar por el MFA. El usuario completó su verificación correctamente y aun así perdió la sesión.

La plataforma añade dos refinamientos. Inyecta JavaScript propio para desactivar FIDO2 y WebAuthn en la página de inicio de sesión, lo que empuja al usuario hacia métodos de verificación más débiles y interceptables. Y enruta el tráfico por proxies residenciales geolocalizados en 69 países, de modo que el intento de acceso aparente venir del mismo país que la víctima y evada los controles de riesgo de Microsoft.

Los números

Qué significa para las organizaciones dominicanas

La lectura central es incómoda para quien vendió el MFA como respuesta definitiva. El segundo factor por SMS, por código temporal o por notificación push protege contra el robo de contraseña, y deja intacta la ventana del secuestro de sesión.

La contramedida efectiva pasa por llaves de seguridad físicas o passkeys con FIDO2 y WebAuthn, configuradas de manera obligatoria en lugar de opcional, porque el ataque justamente se apoya en la posibilidad de degradar el método. A eso se suma el acceso condicional que exige dispositivo gestionado y conocido, lo que invalida la cookie robada cuando se presenta desde una máquina ajena.

Para las organizaciones ya afectadas, CloudSEK recomienda restablecer las contraseñas expuestas, revocar todas las sesiones activas y refrescar los tokens. Una contraseña nueva sin revocación de sesión deja al intruso adentro.

Fuentes