Le service de phishing BigBear 2.0 a détourné des sessions Microsoft 365 dans 258 organisations

Une plateforme de phishing-as-a-service connue sous le nom de BigBear 2.0 a compromis des comptes Microsoft 365 dans 258 organisations, en utilisant des techniques d’adversary-in-the-middle pour voler des sessions authentifiées après que les utilisateurs ont terminé leur authentification multifacteur.

CloudSEK a publié ces résultats le 7 septembre 2026 à 11 h 39, après avoir obtenu un accès administrateur au panneau de contrôle de l’opération. Les chercheurs ont identifié 42 nœuds de serveurs privés virtuels, chacun configuré pour cibler l’authentification Microsoft 365.

La campagne a collecté plus de 5 000 enregistrements d’identifiants associés à Microsoft 365 et a touché des milliers d’adresses IP dans plus de 40 pays. Son infrastructure n’avait pas pour objectif de casser la MFA, mais de capturer la session créée après son acceptation par Microsoft.

Cette distinction rend l’attaque particulièrement dangereuse. Un utilisateur peut saisir un mot de passe correct, approuver une demande de MFA et malgré tout transmettre à l’attaquant une session cloud authentifiée.

BigBear transformait les connexions réussies en sessions contrôlées par les attaquants

BigBear 2.0 repose sur Evilginx2, un framework de phishing adversary-in-the-middle, ou AiTM. Au lieu de présenter aux victimes un formulaire de connexion entièrement falsifié, le service relaie le trafic entre le navigateur de la victime et les systèmes d’authentification légitimes de Microsoft.

La victime voit un parcours de connexion Microsoft 365 et saisit son nom d’utilisateur et son mot de passe. BigBear transmet ces informations à Microsoft tout en restant positionné entre les deux parties.

Lorsque Microsoft demande un facteur d’authentification supplémentaire, la victime effectue cette étape via la connexion relayée. BigBear peut alors observer les éléments d’authentification et capturer le cookie de session émis une fois la connexion réussie.

Un affilié peut envoyer le cookie volé à l’API de BigBear et rejouer la session authentifiée. Comme Microsoft a déjà vérifié le mot de passe et le défi MFA, l’attaquant peut accéder au compte sans renouveler l’interaction avec le second facteur.

Il s’agit d’un détournement de session, et non d’une défaillance cryptographique de la MFA. Le facteur d’authentification peut fonctionner exactement comme prévu tandis que la session obtenue est volée.

L’écosystème touché comprend :

• Microsoft 365
• Exchange Online
• Teams
• SharePoint
• OneDrive
• Authentification Entra ID
• Les applications connectées via l’authentification unique de l’organisation

Les conséquences dépendent des autorisations de la victime. Un compte standard peut exposer des e-mails, des conversations, des documents et des fichiers partagés. Une identité Entra ID dotée de privilèges peut donner accès à des ressources d’administration ou à d’autres applications qui font confiance à la même identité cloud.

Aucun identifiant CVE ne s’applique à l’activité signalée. Il s’agit d’un abus de l’authentification relayée et de cookies de session volés, et non d’une vulnérabilité logicielle divulguée affectant un ensemble défini de versions de Microsoft 365.

Le panneau a recensé des compromissions dans plus de 40 pays

Les données de ciblage élargies de BigBear faisaient état de 461 organisations. CloudSEK a estimé que 258 d’entre elles avaient subi au moins une compromission aboutie impliquant un contournement de la MFA par vol de session.

Le panneau de contrôle recensait également 3 331 adresses IP de victimes distinctes, réparties dans plus de 40 pays. Une adresse IP ne correspond pas nécessairement à un seul compte individuel ; ce chiffre ne doit donc pas être interprété comme un nombre exact de victimes.

CloudSEK a signalé 5 137 enregistrements d’identifiants exfiltrés, répartis comme suit :

• 474 authentifications abouties lors desquelles les protections MFA ont été contournées
• 1 032 mots de passe en clair
• 4 148 cookies de session authentifiés

Ces trois chiffres totalisent 5 654, et non 5 137. On ignore si les catégories se recoupent, si certaines entrées ont été dédupliquées ou si l’une des valeurs communiquées est erronée. L’écart n’est toujours pas résolu et ne doit pas être corrigé par supposition.

Le panneau était toujours accessible au moment de la publication des résultats. Toutefois, l’infrastructure de phishing associée aurait été hors ligne depuis près de trois semaines. Cette interruption a peut-être stoppé la collecte active, mais elle n’invalide pas les cookies, mots de passe ou jetons déjà obtenus.

Les accès volés précédemment pouvaient rester utilisables jusqu’à ce que les défenseurs révoquent les sessions, fassent expirer les jetons, modifient les identifiants ou imposent de nouvelles exigences d’authentification.

Les affiliés recevaient les identifiants volés via Telegram

BigBear fonctionnait comme un service multi-utilisateur plutôt que comme un outil réservé à un seul acteur malveillant. Son panneau aurait été loué à au moins cinq opérateurs affiliés, permettant à des clients de mener des campagnes sans développer leur propre infrastructure AiTM.

CloudSEK a relié ces opérateurs à des bots d’exfiltration Telegram actifs. Ces bots transmettaient les identifiants capturés aux affiliés en temps réel, réduisant le délai entre la connexion d’une victime et la tentative d’utilisation de la session obtenue par l’attaquant.

La plateforme utilisait une configuration « offy » pour positionner son proxy dans l’échange d’authentification Microsoft. Elle fonctionnait également à travers 42 nœuds VPS, ce qui indique une infrastructure conçue pour prendre en charge plusieurs campagnes ou clients.

Aucune liste d’adresses de nœuds, de domaines de phishing, d’empreintes de fichiers ou d’autres indicateurs directement exploitables dans les recherches n’a été publiée. Les organisations ne peuvent donc pas se contenter de bloquer l’infrastructure BigBear connue.

La détection doit également porter sur les identités et le comportement des sessions. Les signaux pertinents peuvent inclure l’utilisation inhabituelle de sessions authentifiées, des accès depuis des appareils non gérés, une activité inattendue dans les boîtes aux lettres ou sur les fichiers, des changements de privilèges et l’utilisation de jetons incompatible avec les habitudes de travail de l’utilisateur.

Les proxys résidentiels et les interférences avec WebAuthn réduisaient la détection

BigBear prenait en charge des connexions via des proxys résidentiels avec correspondance géographique dans 69 pays. Ces proxys permettaient aux affiliés de générer du trafic d’authentification depuis des adresses résidentielles proches de la localisation apparente de la victime.

Cette capacité affaiblit les contrôles principalement fondés sur la géographie. Une session volée utilisée depuis un pays éloigné peut déclencher une alerte de déplacement impossible ou fondée sur la localisation, tandis qu’un proxy résidentiel situé dans la région attendue peut rendre le même accès moins suspect.

La localisation reste un signal utile, mais elle ne suffit pas à elle seule. L’état de gestion de l’appareil, les propriétés de la session, l’activité des applications, le comportement des jetons et les privilèges du compte doivent également influencer les décisions d’accès.

CloudSEK a également découvert du JavaScript personnalisé destiné à perturber la prise en charge de FIDO2/WebAuthn par le navigateur. L’objectif apparent était d’empêcher ou de perturber l’utilisation d’une authentification résistante au phishing, afin de pousser les victimes vers des méthodes plus faciles à relayer via un proxy AiTM.

Lorsqu’elle est correctement imposée, l’authentification FIDO2/WebAuthn résiste au phishing classique des identifiants, car l’authentification est liée à l’origine web légitime. BigBear ne cherchait donc pas à casser directement cette protection, mais à la rendre indisponible pendant le parcours de connexion de la victime.

Les organisations doivent enquêter sur les échecs inattendus de WebAuthn, en particulier lorsque les utilisateurs se voient ensuite proposer une méthode de connexion moins robuste. Autoriser un mécanisme de secours peut annuler une grande partie du bénéfice de sécurité apporté par le déploiement d’identifiants résistants au phishing.

Les défenseurs doivent révoquer les sessions, pas seulement changer les mots de passe

Une simple réinitialisation du mot de passe peut ne pas déconnecter un attaquant qui possède déjà un cookie de session valide. Les équipes de réponse à incident doivent traiter une exposition potentiellement liée à BigBear à la fois comme une compromission d’identifiants et comme un vol de jeton.

Les mesures recommandées comprennent :

1. Réinitialiser les mots de passe associés aux comptes exposés ou suspects.
2. Révoquer les sessions Microsoft 365 actives afin que les cookies capturés ne permettent plus d’accéder aux comptes.
3. Invalider ou renouveler les jetons concernés, notamment ceux utilisés par les applications cloud connectées.
4. Forcer une nouvelle authentification pour les identités privilégiées, les administrateurs et les autres comptes à fort impact.
5. Imposer des méthodes FIDO2/WebAuthn résistantes au phishing et limiter les options de secours moins robustes lorsque cela est possible sur le plan opérationnel.
6. Utiliser des politiques Conditional Access exigeant des appareils gérés ou conformes pour les services sensibles.
7. Examiner l’activité Exchange Online, Teams, SharePoint, OneDrive et Entra ID afin d’identifier les actions incompatibles avec le rôle ou l’historique des appareils de l’utilisateur.
8. Éviter de considérer la cohérence géographique comme une preuve de légitimité, compte tenu de la prise en charge des proxys résidentiels par BigBear.

CloudSEK a indiqué avoir alerté les autorités et plusieurs organisations touchées. Les identifiants exposés ont également été inclus dans des signalements de divulgation responsable.

Le problème plus général tient au fait qu’une activité malveillante devient plus difficile à stopper lorsqu’elle se déroule au sein d’une session authentifiée valide. Une évaluation citée de Blue Report 2026 a montré que seulement 37 % des actions d’attaquants effectuées avec des identifiants valides ont été bloquées sur 338 millions de simulations menées dans les environnements de production de clients. Ce résultat ne concernait pas spécifiquement BigBear, mais il illustre l’importance de la surveillance après authentification.

La MFA reste indispensable, mais toutes les méthodes MFA n’offrent pas le même niveau de protection contre le phishing AiTM. Pour les organisations exposées à des services tels que BigBear, le modèle le plus robuste associe une authentification liée à l’origine, des exigences concernant les appareils gérés, une révocation rapide des sessions et une surveillance comportementale après la connexion.