Une vaste opération de phishing baptisée BigBear 2.0 a réussi à détourner des sessions Microsoft 365 pourtant protégées par l’authentification multifacteur. L’enquête publiée par CloudSEK le 7 septembre 2026 décrit une plateforme industrialisée, proposée comme un service à plusieurs affiliés et capable de voler mots de passe, cookies de session et accès authentifiés.
Les chercheurs ont observé 5 137 enregistrements dérobés, dont 1 032 mots de passe en clair, 4 148 cookies de session et 474 authentifications complètes associées à un contournement de la MFA. Le jeu de données couvrait 461 organisations ciblées, mais CloudSEK précise que 258 organisations distinctes comptaient au moins une compromission achevée.
BigBear 2.0, une plateforme de phishing conçue pour Microsoft 365
BigBear 2.0 repose sur Evilginx2, un framework permettant de mener des attaques dites Adversary-in-the-Middle ou AiTM. Contrairement à une fausse page de connexion classique, le serveur malveillant agit comme un relais entre la victime et le véritable portail d’authentification Microsoft.
La victime voit une interface proche de la page officielle et saisit ses identifiants. Le proxy transmet ces informations à Microsoft en temps réel. Lorsque l’utilisateur valide ensuite son second facteur — code temporaire, notification push ou SMS — Microsoft délivre un cookie attestant que l’authentification a réussi. Comme ce cookie traverse le relais contrôlé par l’attaquant, il peut être intercepté puis rejoué pour ouvrir la session sans redemander le second facteur.
Il ne s’agit donc pas d’une faille cryptographique de la MFA. L’attaque exploite la confiance accordée à une session déjà authentifiée. Cette nuance explique pourquoi un compte peut être détourné même si son propriétaire n’a jamais communiqué son code temporaire directement à l’attaquant.
Une infrastructure commerciale et fortement automatisée
CloudSEK indique avoir obtenu un accès administrateur au panneau de contrôle de BigBear 2.0. Celui-ci aurait piloté 42 nœuds VPS au cours de la campagne, tous configurés pour viser Microsoft 365 à l’aide d’un profil de phishing nommé « offy ». Au moins cinq opérateurs affiliés recevaient les données volées en temps réel par l’intermédiaire de bots Telegram.
Le processus allait de la capture des identifiants à la notification, puis au rejeu automatisé du cookie. Ce fonctionnement réduit fortement les compétences techniques nécessaires pour exploiter une session compromise et illustre l’évolution du Phishing-as-a-Service : l’opérateur fournit l’infrastructure tandis que ses clients conduisent leurs propres campagnes.
L’enquête recense 3 331 adresses IP de victimes dans plus de 40 pays. L’Inde, la France et l’Arabie saoudite figurent parmi les territoires les plus représentés. Les prestataires informatiques et les MSP constituaient le secteur le plus visé, un choix préoccupant puisque la compromission d’un fournisseur peut donner accès aux environnements de plusieurs clients.
Des proxys résidentiels pour tromper les contrôles de connexion
Pour réduire les alertes, BigBear 2.0 utilisait des proxys résidentiels correspondant à 69 pays. Une connexion initiée par une victime située en France pouvait ainsi être relayée depuis une adresse IP française plutôt que depuis un centre de données étranger. Les règles fondées uniquement sur la géolocalisation risquaient alors de considérer l’activité comme habituelle.
Des injections JavaScript personnalisées tentaient également de désactiver les fonctions FIDO2 et WebAuthn dans le navigateur. L’objectif était de pousser l’utilisateur vers une méthode d’authentification plus facilement relayable, comme un code à usage unique ou une validation par notification. Le kit bloquait aussi certains mécanismes de télémétrie et activait l’option permettant de rester connecté afin de prolonger la durée de la session.
Pourquoi les clés de sécurité et les passkeys résistent mieux
Les méthodes FIDO2/WebAuthn sont dites résistantes au phishing parce que la preuve cryptographique est liée au domaine légitime. Une clé de sécurité ou une passkey enregistrée pour Microsoft ne produit pas une assertion valide sur le domaine contrôlé par l’attaquant. Le proxy ne peut donc pas simplement transférer le défi et récupérer une session comme il le fait avec un code ou une notification.
Cette protection n’est réellement utile que si l’organisation impose la méthode résistante au phishing et empêche le retour vers un facteur plus faible. BigBear cherchait précisément à provoquer cette rétrogradation en rendant WebAuthn indisponible côté navigateur.
Quels risques après le vol d’une session Microsoft 365 ?
Un cookie valide peut ouvrir l’accès à Exchange Online, Teams, SharePoint, OneDrive et aux applications reliées par authentification unique. Les attaquants peuvent consulter des messages, rechercher des documents sensibles, usurper un collaborateur ou préparer une fraude au président. Si le compte dispose de privilèges élevés, la session peut aussi faciliter un mouvement latéral vers d’autres ressources cloud.
Le changement du mot de passe ne suffit pas toujours à interrompre immédiatement l’accès. Les équipes doivent aussi révoquer les sessions actives et les jetons d’actualisation, puis imposer une nouvelle authentification. Les comptes administratifs, financiers et ceux des équipes informatiques doivent être examinés en priorité.
Mesures recommandées pour les organisations
- Réinitialiser les mots de passe exposés et révoquer simultanément les sessions ainsi que les jetons d’actualisation.
- Imposer FIDO2, WebAuthn ou des passkeys résistantes au phishing, sans autoriser une méthode de secours moins robuste pour les comptes sensibles.
- Configurer l’accès conditionnel afin d’exiger un appareil géré et conforme, plutôt que de faire confiance à la seule localisation de l’adresse IP.
- Surveiller les connexions inhabituelles, les nouvelles règles de messagerie, les consentements OAuth et les accès anormaux à SharePoint ou OneDrive.
- Former les utilisateurs à vérifier le domaine avant toute authentification, même lorsque la page affiche HTTPS et reproduit fidèlement l’interface Microsoft.
Une alerte sur les limites de la MFA traditionnelle
L’affaire BigBear 2.0 montre que l’activation de la MFA reste indispensable, mais qu’elle ne constitue pas à elle seule une défense absolue. Les facteurs pouvant être relayés protègent efficacement contre le simple vol de mot de passe, sans empêcher toutes les attaques AiTM. La sécurité doit combiner authentification résistante au phishing, contrôle de l’état de l’appareil, surveillance des sessions et réponse rapide aux incidents.
Au moment de la publication des recherches, CloudSEK indiquait avoir alerté les autorités et plusieurs organisations concernées. L’infrastructure de phishing était hors ligne depuis près de trois semaines, tandis que le panneau d’administration restait accessible. Ces observations décrivent l’état de la campagne durant l’enquête et ne permettent pas d’affirmer que chaque organisation ciblée a subi la même profondeur de compromission.
