BigBear 2.0 : le kit de phishing qui a franchi le MFA de 258 organisations - l'autopsie

En juin 2026, des analystes de CloudSEK ne se contentent pas d’observer un service de phishing de l’extérieur : ils entrent dans son tableau de bord. « En juin 2026, la cellule TRIAD de CloudSEK a découvert BigBear 2.0, un framework de phishing-as-a-service rebaptisé, basé sur Evilginx2, et a pu obtenir un accès administrateur au panneau de l’acteur malveillant », écrit le rapport publié le 7 septembre. À l’intérieur, la comptabilité brute d’une industrie criminelle : 5 137 identifiants Microsoft 365 exfiltrés, dont 474 authentifications où le MFA a été effectivement franchi — et la France en deuxième position des pays touchés.

Ce dossier ouvre une nouvelle série, « Autopsie d’un kit de phishing ». Contrairement à nos autopsies d’incidents — France Travail, le CHU de Brest, les faux conseillers bancaires —, il ne raconte pas une victime, mais l’outil qui les produit en série. Sa source de référence est le rapport primaire de CloudSEK, « Tracking BigBear 2.0 Evilginx2 Phishing Campaign » (Gagan Aggarwal, 7 septembre 2026), fondé sur l’accès direct des chercheurs au panneau ; la reprise de BleepingComputer (Bill Toulas, même jour) confirme les chiffres. Nous y ajoutons les publications de Microsoft et de la CISA sur l’AiTM et le MFA phishing-résistant.

Une précision de cadrage, essentielle et posée d’emblée : la leçon de ce dossier n’est pas « le MFA est inutile ». Le MFA élève considérablement la barre. Mais quand l’attaque est une « attaque de l’homme-du-milieu » (AiTM) et qu’un humain clique, elle enjambe la barre. Le leurre arrive toujours par email ; le clic reste le point d’entrée. Vigilance des utilisateurs et authentificateurs phishing-résistants ne s’opposent pas : ils se complètent.

À retenir

• L’accès : « En juin 2026, la cellule TRIAD de CloudSEK a découvert BigBear 2.0, un framework de phishing-as-a-service rebaptisé, basé sur Evilginx2, et a pu obtenir un accès administrateur au panneau de l’acteur malveillant » (CloudSEK, 7 septembre 2026). Le rapport ne détaille pas comment cet accès a été obtenu ; c’est cet accès qui donne au dossier sa valeur de source primaire.
• Le bilan : « Le panneau a exfiltré 5 137 identifiants — dont 474 authentifications avec MFA franchi, 1 032 mots de passe en clair et 4 148 cookies de session — affectant 3 331 adresses IP de victimes uniques dans plus de 40 pays » (CloudSEK). BleepingComputer précise que 258 organisations ont subi au moins une compromission MFA aboutie, sur 461 ciblées.
• La France : deuxième pays le plus touché. « L’Inde est le pays le plus ciblé avec 658 identifiants (12,8 % du total de 5 137), suivie par la France (463, 9,0 %) et l’Arabie saoudite (353, environ 6 %) » (CloudSEK).
• La mécanique : un kit Evilginx2 (phishlet « offy ») qui met un proxy inverse entre la victime et la vraie page Microsoft 365, capture le mot de passe et le cookie de session émis après le MFA, et l’exfiltre « en temps réel » par bots Telegram à « au moins cinq opérateurs affiliés ». Un JavaScript sur mesure « désactive le MFA FIDO2/WebAuthn » pour forcer un facteur plus faible.
• L’antidote : le MFA phishing-résistant. CloudSEK le dit du kit lui-même : FIDO2 est « la seule méthode de MFA qui empêche structurellement le phishing AiTM » ; la CISA le nomme « l’étalon-or ». Que BigBear ait dû coder un JavaScript pour neutraliser FIDO2 est la meilleure preuve, en creux, de son efficacité.
• Le cadrage : Microsoft le rappelle depuis 2022 — « ce n’est pas une vulnérabilité du MFA ». Le MFA par push, SMS ou TOTP n’est pas nul ; il n’est simplement plus suffisant seul. La porte d’entrée reste le clic sur un email.

Le dossier en chiffres

258

organisations avec au moins une authentification compromise malgré le MFA (461 ciblées au total)

CloudSEK, 07/09/2026 ; BleepingComputer, 07/09/2026

5 137

identifiants exfiltrés : 474 authentifications MFA franchies, 1 032 mots de passe en clair, 4 148 cookies de session

CloudSEK, « Tracking BigBear 2.0 », 07/09/2026

463

identifiants volés en France, 2e pays le plus touché (9,0 % du total), derrière l'Inde

CloudSEK, 07/09/2026

42

serveurs (VPS) pilotés par le panneau, loués à au moins 5 opérateurs affiliés via des bots Telegram

CloudSEK, 07/09/2026

Chronologie

Chronologie

Le fil des événements

1. 2017

   Evilginx : l'outil open source d'où tout part

   Kuba Gretzky publie Evilginx, « un framework d'attaque de l'homme-du-milieu utilisé pour hameçonner les identifiants de connexion ainsi que les cookies de session, ce qui permet à son tour de contourner la protection par authentification à deux facteurs » (README du projet). Outil de red team assumé, distribué avec un avertissement : « Evilginx ne doit être utilisé que dans des missions de test d'intrusion légitimes, avec l'autorisation écrite des parties à hameçonner. »

   Source — Evilginx, dépôt public de Kuba Gretzky (kgretzky)

2. 12 juillet 2022

   Microsoft alerte sur la vague AiTM à grande échelle

   Microsoft documente « une campagne de phishing à grande échelle qui a utilisé des sites de phishing de type homme-du-milieu (AiTM) [pour] voler des mots de passe, détourner la session de connexion d'un utilisateur et sauter l'étape d'authentification même si l'utilisateur avait activé l'authentification multifacteur (MFA) ». La campagne « a tenté de cibler plus de 10 000 organisations depuis septembre 2021 ».

   Source — Microsoft Threat Intelligence, 12/07/2022

3. Octobre 2022

   La CISA publie sa doctrine du MFA phishing-résistant

   L'agence américaine publie « Implementing Phishing-Resistant MFA » : « Bien que toute forme de MFA soit meilleure que pas de MFA [...], le MFA phishing-résistant est l'étalon-or, et les organisations devraient faire de la migration vers celui-ci une priorité élevée. » Elle nomme « la seule authentification phishing-résistante largement disponible » : FIDO/WebAuthn.

   Source — CISA, « Implementing Phishing-Resistant MFA », octobre 2022

4. 2023-2024

   Le marché du PhaaS AiTM se structure

   Les services clés en main se multiplient : EvilProxy, apparu sur le dark web en 2022 (Resecurity), loué « 150 dollars pour dix jours » ; Tycoon 2FA, actif « depuis au moins août 2023 », plus de 1 100 domaines détectés entre octobre 2023 et février 2024, forfaits « à partir de 120 dollars pour 10 jours » (Sekoia.io). Le contournement du MFA classique devient une marchandise.

   Source — Resecurity (2022) ; Sekoia.io, analyse Tycoon 2FA (2024)

5. Juin 2026

   CloudSEK entre dans le panneau de BigBear 2.0

   « En juin 2026, la cellule TRIAD de CloudSEK a découvert BigBear 2.0, un framework de phishing-as-a-service rebaptisé, basé sur Evilginx2, et a pu obtenir un accès administrateur au panneau de l'acteur malveillant. » Le panneau pilotait « 42 nœuds VPS sur la durée de vie de la campagne — hébergés principalement par The Constant Company LLC (Vultr) — configurés avec le phishlet « offy » ciblant exclusivement Microsoft 365 ».

   Source — CloudSEK, « Tracking BigBear 2.0 », 07/09/2026

6. Depuis fin juillet 2026

   L'opérateur efface ses traces

   « Depuis fin juillet 2026, l'acteur malveillant a supprimé 26 des 42 nœuds VPS observés depuis le panneau — signe d'une activité active de contre-investigation en réponse à la détection. » Un seul nœud reste actif au moment de la publication, mais le panneau d'administration, lui, reste accessible aux chercheurs.

   Source — CloudSEK, 07/09/2026

7. 7 septembre 2026

   Publication du rapport CloudSEK et reprise par BleepingComputer

   CloudSEK publie « Tracking BigBear 2.0 Evilginx2 Phishing Campaign » (Gagan Aggarwal). Le même jour, BleepingComputer titre : « Le service de phishing Microsoft 365 BigBear a contourné le MFA chez 258 organisations » (Bill Toulas). Bilan chiffré : 258 organisations avec au moins une compromission aboutie sur 461 ciblées, 5 137 identifiants exfiltrés, plus de 40 pays.

   Source — CloudSEK ; BleepingComputer, 07/09/2026

Acte 1 : ce que CloudSEK a vu depuis l’intérieur du panneau

La plupart des rapports de threat intelligence décrivent une campagne de l’extérieur : domaines observés, échantillons de leurres, victimes recensées. BigBear 2.0 est différent parce que les analystes de CloudSEK ont pu, selon leur propre récit, « obtenir un accès administrateur au panneau de l’acteur malveillant ». Ils n’ont donc pas estimé le volume de vol ; ils ont lu la comptabilité du kit. Le rapport, honnête sur ses limites, ne précise pas la méthode d’accès — et nous ne spéculerons pas dessus.

Ce que le panneau contenait tient en une phrase de synthèse : « Le panneau a exfiltré 5 137 identifiants — dont 474 authentifications avec MFA franchi, 1 032 mots de passe en clair et 4 148 cookies de session — affectant 3 331 adresses IP de victimes uniques dans plus de 40 pays. » Décomposons, parce que chaque nombre raconte une étape.

Les 1 032 mots de passe en clair sont le butin minimal : des identifiants saisis sur la fausse page. Les 4 148 cookies de session sont plus graves : chacun est un jeton d’accès déjà validé, qui permet d’ouvrir la session sans mot de passe ni MFA. Et les 474 authentifications complètes avec MFA franchi — 9,2 % du total — sont le cœur du dossier : 474 fois, un utilisateur a fait tout ce que la sécurité lui demandait, y compris valider son second facteur, et l’attaquant s’est retrouvé authentifié à sa place. Comme le résume CloudSEK, « chaque session complète représente un compte Microsoft 365 entièrement compromis », avec accès potentiel à la messagerie, à Teams, à SharePoint et OneDrive, et à l’Entra ID.

Côté infrastructure, le panneau pilotait « 42 nœuds VPS sur la durée de vie de la campagne — hébergés principalement par The Constant Company LLC (Vultr) — configurés avec le phishlet “offy” ciblant exclusivement Microsoft 365 ». Un « phishlet » est le fichier de configuration d’Evilginx qui décrit quel service imiter et quelles règles de réécriture appliquer ; « offy » est celui, propre à BigBear, taillé pour Microsoft 365. Et ce panneau n’était pas l’affaire d’un pirate isolé : « le panneau PhaaS multi-utilisateurs est loué à au moins cinq opérateurs affiliés identifiés grâce à des bots Telegram d’exfiltration en direct, chacun recevant les identifiants volés en temps réel ». Un modèle de plateforme, avec un opérateur principal (alias « General Boss »), des revendeurs et des sous-opérateurs.

Deux détails complètent le portrait. D’abord la discrétion : BigBear « déployait des pools de proxies résidentiels géolocalisés » couvrant 69 pays, pour que la connexion frauduleuse semble provenir du même pays que la victime et échappe à la détection d’anomalie géographique de Microsoft. Ensuite la contre-investigation : « depuis fin juillet 2026, l’acteur malveillant a supprimé 26 des 42 nœuds VPS observés depuis le panneau — signe d’une activité active de contre-investigation en réponse à la détection ». Autrement dit, l’opérateur savait qu’on le regardait. À la publication, l’infrastructure de phishing est largement démontée, mais le panneau d’administration reste, lui, accessible aux chercheurs. Le rapport CloudSEK ne fait état d’aucun démantèlement judiciaire ni notification aux autorités ; nous ne l’affirmerons donc pas.

Acte 2 : la chaîne d’attaque, au niveau conceptuel

Chaîne d'attaque

Comment l'intrusion s'est déroulée

Reconstitution à visée défensive — chaque maillon compris est un maillon que l’on peut casser.

1. 01

   Le leurre arrive par email — le clic reste la porte d'entrée

   Rien ne se passe sans une action humaine. La victime reçoit un lien de phishing (CloudSEK cartographie la technique MITRE ATT&CK T1566.002, « Spearphishing Link »). Les URL « utilisent des domaines légitimes (compromis ou ressemblants) avec des certificats SSL valides. Sans analyse de réputation d'URL, la plupart des passerelles de messagerie laissent passer ces liens » (CloudSEK). Le MFA élève la barre ; le clic, lui, reste le point d'entrée.

2. 02

   Un proxy inverse qui rejoue la vraie page Microsoft 365

   La victime n'atterrit pas sur une copie statique. « Les phishlets Evilginx2 fonctionnent comme des proxies homme-du-milieu (AiTM) : lorsqu'une victime visite l'URL de phishing, le moteur relaie tout le trafic entre la victime et le service Microsoft légitime » (CloudSEK). La page affichée est le contenu réel de Microsoft, servi via le proxy — pixel pour pixel. Le phishlet par défaut, « offy », est « configuré pour intercepter l'authentification Microsoft 365 ».

3. 03

   La victime s'authentifie — y compris son MFA

   Login, mot de passe, puis second facteur : la victime complète toute l'authentification, chaque interaction étant relayée à Microsoft. « TOTP, notification push, SMS et même l'appel vocal sont tous également vulnérables — le proxy capture le cookie de session résultant, quel que soit le type de MFA » (CloudSEK). Pour forcer le passage, un JavaScript sur mesure « désactive le MFA FIDO2/WebAuthn » afin que « les utilisateurs de clés matérielles se rabattent sur un MFA hameçonnable ».

4. 04

   Le kit capture le mot de passe ET le cookie de session

   Une fois l'authentification réussie, Microsoft émet un cookie de session — la preuve que le MFA a été franchi. « L'attaquant n'a jamais besoin de connaître le code SMS pour détourner la session » (CloudSEK). Le proxy intercepte ce cookie avant de le transmettre à la victime, qui voit Outlook s'ouvrir normalement, sans aucune alerte. Des proxies résidentiels géolocalisés (69 pays) font apparaître la connexion depuis le pays attendu, déjouant la détection d'anomalie de Microsoft.

5. 05

   Exfiltration en temps réel vers les affiliés par Telegram

   Le cookie et les identifiants partent aussitôt : « pipeline de traitement automatisé des identifiants : capture → notification Telegram → pièce jointe cookie.js → moteur de rejeu via l'API Cookie » (CloudSEK). Le panneau multi-utilisateurs est « loué à au moins cinq opérateurs affiliés », chacun recevant les identifiants « en temps réel » dans son propre canal Telegram — une chaîne logistique, pas un pirate solitaire.

6. 06

   Rejeu du cookie et prise de contrôle du compte

   Depuis sa machine, l'affilié importe le cookie et accède à la session : messagerie, Teams, SharePoint, OneDrive — sans login ni MFA. Un mécanisme de « keepalive » « rafraîchit périodiquement les cookies capturés en réutilisant le refresh token », prolongeant l'accès. CloudSEK relie la monétisation au courtage d'accès initial : « les cookies de session permettent le déploiement de rançongiciels, l'extorsion de données ou des campagnes de BEC ».

Nous décrivons ici le déroulé tel que les éditeurs et les chercheurs le publient — sans aucun détail opérationnel qui aiderait à reproduire l’attaque, et sans listes d’indicateurs de compromission : ceux-ci figurent dans le rapport CloudSEK, à destination des défenseurs.

Le point à retenir traverse toute la chaîne : l’AiTM ne casse rien, il relaie tout. La page vue par la victime n’est pas une contrefaçon approximative, c’est le contenu réel de Microsoft rendu à travers le proxy. Le mot de passe est le bon, le second facteur est le bon, l’IP source (celle d’un proxy résidentiel géolocalisé) est plausible. Microsoft « voit » une connexion parfaitement normale et émet un cookie de session. C’est ce cookie — pas le mot de passe — qui est le vrai trophée : il matérialise le fait que le MFA a déjà été franchi, et il se rejoue sans second facteur. CloudSEK est sans ambiguïté : « TOTP, notification push, SMS et même l’appel vocal sont tous également vulnérables — le proxy capture le cookie de session résultant, quel que soit le type de MFA. »

Un détail technique du kit vaut d’être souligné, car il est révélateur. BigBear embarque « un JavaScript sur mesure qui désactive le MFA FIDO2/WebAuthn », de sorte que « l’attaquant manipule le flux d’authentification pour que la victime finisse par utiliser une méthode d’authentification alternative, plus faible ou non phishing-résistante ». Traduction : le kit a spécifiquement besoin d’empêcher la victime d’utiliser sa clé FIDO2, parce que celle-ci résisterait. C’est l’aveu, dans le code même de l’attaquant, de ce qui l’arrête.

Acte 3 : l’écosystème AiTM, et l’outil légitime qu’il détourne

BigBear 2.0 n’est pas né dans le vide. Il s’inscrit dans une vague documentée depuis des années, et il repose sur un outil qui, à l’origine, n’a rien de criminel.

Evilginx : un outil de red team, présenté honnêtement

Le socle technique de BigBear est Evilginx, publié en 2017 par le chercheur en sécurité Kuba Gretzky. Son dépôt public le décrit comme « un framework d’attaque de l’homme-du-milieu utilisé pour hameçonner les identifiants de connexion ainsi que les cookies de session, ce qui permet à son tour de contourner la protection par authentification à deux facteurs ». Ce n’est pas un logiciel malveillant clandestin, mais un outil de sécurité offensive largement utilisé — y compris par l’industrie de la simulation de phishing, la nôtre comprise, pour mesurer la résistance réelle des organisations aux techniques AiTM. Son auteur assume la dualité et l’encadre par un avertissement : « Evilginx ne doit être utilisé que dans des missions de test d’intrusion légitimes, avec l’autorisation écrite des parties à hameçonner. » L’outil n’est pas le crime ; l’usage sans consentement l’est. BigBear en est le détournement criminel, « rebaptisé » et loué à des affiliés.

La vague AiTM, documentée depuis 2022

Microsoft a tiré la sonnette d’alarme dès le 12 juillet 2022, en décrivant « une campagne de phishing à grande échelle qui a utilisé des sites de phishing de type homme-du-milieu (AiTM) [pour] voler des mots de passe, détourner la session de connexion d’un utilisateur et sauter l’étape d’authentification même si l’utilisateur avait activé l’authentification multifacteur ». La campagne « a tenté de cibler plus de 10 000 organisations depuis septembre 2021 ». Et Microsoft posait déjà le cadre que ce dossier reprend : « ce n’est pas une vulnérabilité du MFA ; puisque le phishing AiTM vole le cookie de session, l’attaquant est authentifié à la place de l’utilisateur, quelle que soit la méthode de connexion utilisée. »

Depuis, le marché du phishing-as-a-service AiTM s’est structuré. EvilProxy, apparu sur le dark web en 2022, était loué « 150 dollars pour dix jours » selon Resecurity, avec paiement organisé via un opérateur sur Telegram. Tycoon 2FA, actif « depuis au moins août 2023 » d’après Sekoia.io, comptait « plus de 1 100 noms de domaine détectés entre octobre 2023 et février 2024 », avec des forfaits « à partir de 120 dollars pour 10 jours ». Le fil rouge de ces services est le même que celui de BigBear : abaisser la barrière technique pour que n’importe quel affilié, sans savoir configurer un proxy inverse, puisse louer une capacité de contournement du MFA. Le contournement du MFA classique est devenu une marchandise à l’abonnement.

Ce qui défait réellement l’AiTM

La bonne nouvelle du dossier, c’est qu’il existe une parade structurelle — et qu’elle est nommée par la source primaire elle-même.

Le MFA phishing-résistant : FIDO2, passkeys

CloudSEK explique pourquoi FIDO2/WebAuthn résiste là où push, SMS et TOTP échouent : « l’assertion cryptographique est liée au domaine d’origine (par exemple login.microsoftonline.com). Lorsque Evilginx2 relaie le trafic, l’origine vue par le navigateur est le domaine de phishing […], pas le vrai domaine Microsoft. L’assertion FIDO2 échoue parce que l’origine ne correspond pas à l’origine enregistrée de l’identifiant. C’est la seule méthode de MFA qui empêche structurellement le phishing AiTM. » En clair : une clé FIDO2 refuse de signer pour un domaine qui n’est pas celui où elle a été enrôlée. Le proxy ne peut pas relayer une signature qui n’a jamais été produite.

La CISA en a fait une doctrine dès octobre 2022 : « bien que toute forme de MFA soit meilleure que pas de MFA […], le MFA phishing-résistant est l’étalon-or, et les organisations devraient faire de la migration vers celui-ci une priorité élevée. » Elle nomme FIDO/WebAuthn « la seule authentification phishing-résistante largement disponible » et recommande de commencer par « les administrateurs système et les autres cibles de haute valeur ». Côté français, le guide de référence de l’ANSSI (« Recommandations relatives à l’authentification multifacteur et aux mots de passe », ANSSI-PG-078) classe FIDO2 et FIDO U2F parmi les mécanismes d’authentification forte reposant sur un facteur de possession, et privilégie explicitement l’usage de matériels physiques ayant subi une évaluation de sécurité (tokens FIDO, cartes à puce) — la même famille que celle que la CISA place en tête de son tableau.

Le meilleur argument, pourtant, vient de l’attaquant lui-même : BigBear a dû coder un JavaScript pour désactiver FIDO2/WebAuthn et forcer la victime à se rabattre sur un facteur hameçonnable. On ne se donne pas cette peine contre une défense qui ne gêne pas.

L’accès conditionnel et la protection des jetons

FIDO2 ne suffit pas s’il reste possible de se connecter avec un simple mot de passe. Il faut une politique d’accès conditionnel qui exige une force d’authentification phishing-résistante pour les ressources critiques, et qui restreint l’usage des jetons. C’est exactement ce que recommande CloudSEK en remédiation : « réinitialiser les mots de passe concernés, révoquer les sessions et les refresh tokens, forcer une réauthentification, activer un MFA phishing-résistant — FIDO2 ou WebAuthn, imposer l’accès conditionnel, exiger des appareils conformes ». Notre guide de protection de Microsoft 365 contre l’AiTM détaille la configuration concrète : forces d’authentification, enrôlement FIDO2 sans se verrouiller hors du tenant, détection AiTM et protection des jetons.

L’honnêteté sur ce que le MFA « par code » ne protège pas

Il faut le dire sans détour : le MFA par notification push, par SMS ou par code TOTP ne protège pas contre l’AiTM. Ces facteurs partagent une faille commune : ils ne sont pas liés au domaine. Un code TOTP est valide pour quiconque le saisit dans les trente secondes, sur n’importe quelle page ; une notification push approuve un événement Microsoft, pas le navigateur exact de la victime. C’est précisément ce que BigBear exploite. Mais « ne protège pas contre l’AiTM » n’est pas « ne sert à rien » : ce MFA-là bloque toujours le bourrage d’identifiants, le mot de passe volé rejoué à froid, une large part des attaques opportunistes. La CISA a raison sur les deux tableaux : « toute forme de MFA est meilleure que pas de MFA », et le phishing-résistant est « l’étalon-or ». La stratégie mûre n’est pas de choisir, c’est de hiérarchiser.

Ce qu’une PME sous Microsoft 365 doit faire ce trimestre

Pour une organisation de 50 à 500 personnes, l’objectif n’est pas la perfection, c’est de refermer les portes les plus rentables pour l’attaquant, dans le bon ordre.

1. Passkeys/FIDO2 pour les administrateurs d’abord

Les comptes à privilèges sont les cibles les plus payantes : un seul suffit à ouvrir tout le tenant. CloudSEK relève d’ailleurs que le secteur le plus visé par BigBear était celui des prestataires informatiques et MSP (151 organisations), précisément « parce que le personnel IT dispose souvent d’accès à privilèges à Azure AD ». Commencez par équiper chaque administrateur global, Exchange, direction et finance de deux clés FIDO2, et créez une politique d’accès conditionnel exigeant une authentification phishing-résistante pour ces rôles. C’est l’investissement au meilleur ratio efficacité-prix sur Microsoft 365 — la marche à suivre est dans notre guide de déploiement du MFA en entreprise et le guide AiTM.

2. Les bases de l’accès conditionnel

Au-delà des clés, activez ce que votre licence permet : exiger des appareils conformes ou gérés, activer la détection AiTM (Microsoft Defender XDR, Automatic Attack Disruption) et la protection des jetons. Ces contrôles ne demandent pas de matériel, seulement de la configuration — et ils réduisent la valeur d’un cookie volé en le liant à un appareil et à un contexte.

3. « Signaler avant de cliquer »

Le leurre de BigBear arrive par email : c’est le seul moment où un humain peut casser la chaîne avant qu’elle ne s’enclenche. Ancrez le réflexe de transmettre un message douteux au lieu de cliquer — bouton de signalement, canal dédié, débriefing sans blâme. Le facteur humain est impliqué dans 62 % des violations de données (Verizon DBIR 2026 — voir nos statistiques du phishing en France). Entraîner le signalement, c’est renforcer exactement le maillon que l’AiTM attaque en premier.

4. Des simulations qui incluent l’AiTM et la fatigue MFA

Une simulation qui ne teste que le clic sur un lien classique n’entraîne pas au risque réel de 2026. Intégrez des scénarios de type AiTM (fausse page de connexion Microsoft, prompt de second facteur) et de fatigue MFA (rafales de notifications push jusqu’à l’approbation lasse). Mesurez les taux de signalement, débriefez, recommencez. C’est ainsi qu’on transforme une consigne en réflexe — voir notre comparatif face à l’Attack Simulator de Microsoft. Et pour l’analyse a posteriori d’un email suspect, notre analyseur d’en-têtes email aide à remonter l’origine réelle d’un message. Retrouvez ce dossier et plus de 100 incidents dans notre base de données des cyberattaques en France.

Verdict

BigBear 2.0 restera comme une radiographie rare : non pas la description d’un incident vu de l’extérieur, mais la comptabilité d’un kit de phishing lue depuis son propre tableau de bord. Ce que cette comptabilité montre est à la fois inquiétant et clarifiant. Inquiétant, parce que 474 fois, des utilisateurs ont fait tout ce que la sécurité leur demandait — y compris valider leur MFA — et se sont fait voler leur session ; parce que la France est le deuxième pays touché ; parce que le service se louait à des affiliés comme un logiciel banal. Clarifiant, parce que le rapport nomme lui-même l’antidote — FIDO2, « la seule méthode de MFA qui empêche structurellement le phishing AiTM » — et parce que l’attaquant a dû coder une routine pour désactiver précisément cette défense.

La morale n’est donc pas « le MFA est mort ». Elle est plus exigeante et plus juste : le MFA par code ou par push a fait son temps comme rempart unique, l’authentification phishing-résistante doit prendre le relais sur les comptes sensibles, et rien de tout cela ne dispense de la vigilance en amont — car le leurre, lui, continue d’arriver par email, et le clic reste la porte d’entrée. Le proxy peut tout relayer, sauf une chose : une clé FIDO2 qui refuse de signer pour le mauvais domaine, et un utilisateur qui a signalé au lieu de saisir.

FAQ

Qu’est-ce que BigBear 2.0 ? Selon CloudSEK, « un framework de phishing-as-a-service rebaptisé, basé sur Evilginx2 », ciblant exclusivement Microsoft 365 : un service de phishing loué à des affiliés, qui met un proxy « homme-du-milieu » entre la victime et la vraie page Microsoft et exfiltre identifiants et cookies par Telegram. Les chercheurs indiquent avoir obtenu un accès administrateur à son panneau.

Comment a-t-il contourné le MFA ? Par une attaque AiTM : la victime s’authentifie (mot de passe + second facteur) sur un proxy qui relaie tout vers Microsoft ; le proxy capture le cookie de session émis après le MFA. « L’attaquant n’a jamais besoin de connaître le code SMS pour détourner la session » (CloudSEK). Microsoft : « ce n’est pas une vulnérabilité du MFA ».

La France est-elle concernée ? Oui, au deuxième rang : « l’Inde […] suivie par la France (463, 9,0 %) et l’Arabie saoudite » (CloudSEK). Des identifiants d’organisations françaises figurent parmi les 5 137 enregistrements du panneau.

Le MFA est-il devenu inutile ? Non. Il élève la barre et bloque la plupart des attaques opportunistes ; il n’est simplement plus suffisant seul face à l’AiTM. « Toute forme de MFA est meilleure que pas de MFA » (CISA). La parade est le MFA phishing-résistant sur les comptes sensibles, plus la vigilance des utilisateurs.

Evilginx est-il illégal ? Non : c’est un outil open source de red team publié en 2017 par Kuba Gretzky, à n’utiliser « que dans des missions de test d’intrusion légitimes, avec l’autorisation écrite des parties à hameçonner ». BigBear en est un détournement criminel.

Qu’est-ce qui arrête réellement l’AiTM ? Le MFA phishing-résistant — FIDO2, passkeys, Windows Hello for Business, certificats. CloudSEK : FIDO2 est « la seule méthode de MFA qui empêche structurellement le phishing AiTM ». À compléter par l’accès conditionnel et la formation.

---

Sources :

• CloudSEK (Gagan Aggarwal), « Tracking BigBear 2.0 Evilginx2 Phishing Campaign », 7 septembre 2026 — source primaire : cloudsek.com (consulté le 08/09/2026)
• BleepingComputer (Bill Toulas), « BigBear Microsoft 365 phishing service bypassed MFA at 258 organizations », 7 septembre 2026 : bleepingcomputer.com (consulté le 08/09/2026)
• Microsoft Threat Intelligence, « From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud », 12 juillet 2022 : microsoft.com (consulté le 08/09/2026)
• CISA, « Implementing Phishing-Resistant MFA », fact sheet, octobre 2022 : cisa.gov (consulté le 08/09/2026)
• ANSSI, « Recommandations relatives à l’authentification multifacteur et aux mots de passe » (ANSSI-PG-078), 8 octobre 2021 : cyber.gouv.fr (PDF) (consulté le 08/09/2026)
• Evilginx, dépôt public de Kuba Gretzky (kgretzky) : github.com/kgretzky/evilginx2 (consulté le 08/09/2026)
• Resecurity, « EvilProxy Phishing-as-a-Service with MFA Bypass Emerged in Dark Web », 2022 : resecurity.com (consulté le 08/09/2026)
• Sekoia.io, « Tycoon 2FA: an in-depth analysis of the latest version of the AiTM phishing kit », 2024 : blog.sekoia.io (consulté le 08/09/2026)
• Verizon, Data Breach Investigations Report 2026 : verizon.com (consulté le 08/09/2026)

Note : « General Boss » et les opérateurs affiliés désignés par CloudSEK sont des alias techniques suivis par les analystes ; ils ne visent aucune personne identifiée, et aucune procédure judiciaire publique n’était connue à la date de publication. Les figures citées proviennent de l’accès des chercheurs de CloudSEK au panneau du service, reproduites à des fins descriptives et défensives ; cet article ne comporte aucun détail opérationnel permettant de reproduire l’attaque ni aucun indicateur de compromission — ceux-ci figurent dans le rapport CloudSEK, à destination des défenseurs. Lorsque BleepingComputer (258 organisations compromises) et le rapport primaire (461 organisations ciblées, 474 authentifications complètes) diffèrent dans leur mise en avant, nous privilégions la source primaire pour les décomptes bruts.