L'appel venait de l'intérieur du helpdesk

Le 24 avril, BleepingComputer a publié un article sur un groupe à motivation financière que la Unit 42 de Palo Alto suit sous le nom de CL-CRI-1116, également connu sous le nom de BlackFile, également connu sous le nom de UNC6671, et que CrowdStrike (séparément, mais probablement les mêmes gens, ou au moins des cousins) appelle Cordial Spider. La taxonomie est un fouillis. Le comportement, non.

Voici le comportement, dans l'ordre où il vous arrive :

1. Vous recevez un appel. L'identifiant d'appelant indique l'IT interne, ou quelque chose qui s'en approche — VoIP usurpé, ou un CNAM frauduleux (le nom lisible que le réseau téléphonique affiche à côté d'un numéro et qui, finalement, n'est pas particulièrement bien authentifié). La personne au téléphone est amicale et un peu désolée. Elle est vraiment navrée de vous déranger. Il y a un petit problème avec votre compte.
2. Pour résoudre ce petit problème avec votre compte, elle aimerait que vous vous connectiez à une page d'entreprise dont elle va vous envoyer le lien par SMS — ou parfois elle vous y guide directement. La page a l'air correcte. Elle a le logo de la société. Elle a la bonne formulation. Ce n'est pas la bonne page.
3. Vous tapez votre mot de passe. La page demande votre code à usage unique de votre application d'authentification. Vous le tapez aussi.
4. La page vous remercie et affiche éventuellement un spinner. Vous raccrochez.
5. L'attaquant, sur son propre ordinateur portable, ailleurs, prend votre mot de passe fraîchement tapé et votre code à six chiffres fraîchement tapé, se connecte à votre vrai portail SSO dans les quatre-vingt-dix secondes qui suivent, et — c'est la partie élégante — enregistre son propre appareil MFA sur votre compte.
6. Il est désormais vous. Il a un second facteur permanent qui vit dans sa poche. Votre second facteur fonctionne aussi toujours, c'est pour ça que personne ne remarque rien.
7. Il va sur Salesforce, il va sur SharePoint, il cherche les fichiers contenant les mots « confidential » ou « SSN », il télécharge tout ce qu'il peut, et une semaine plus tard votre PDG reçoit un courriel de rançon à sept chiffres depuis une adresse Gmail. Parfois, d'après le rapport de BleepingComputer, les employés reçoivent aussi des menaces de swatting, ce qui est un niveau de service à la clientèle que la plupart des bandes d'extorsion ne se donnent pas la peine de fournir.

Bref.

Où, exactement, l'attaque se déroule

Cela vaut la peine d'être précis sur la partie de cette chaîne qui s'exécute où, parce que la chaîne n'est pas entière au même endroit.

L'appel passe par le téléphone. L'appel a une forme téléphonique. Aucun navigateur, aucun ordinateur, aucun système d'exploitation que vous puissiez patcher ne peut faire quoi que ce soit contre l'appel lui-même, parce que l'appel n'est pas sur l'ordinateur. (Vous pouvez former les gens, vous pouvez mettre des affiches dans la salle de pause, vous pouvez faire en sorte que le vrai helpdesk envoie un courriel de suivi après chaque appel légitime, et tout cela aide, mais l'appel est, comme on dit dans le métier, un problème en forme de personne.)

La fausse page de connexion s'exécute dans un navigateur. Concrètement, elle s'exécute dans n'importe quel navigateur que l'employée a ouvert sur son ordinateur professionnel, dans n'importe quel profil qu'elle utilisait en dernier, avec n'importe quelles sessions, cookies et mots de passe d'auto-remplissage qu'elle se trouve à trimballer. Cette partie est un problème en forme d'ordinateur.

L'enregistrement MFA sur le compte réel s'exécute sur l'ordinateur de l'attaquant, dans son navigateur, contre le portail SSO légitime. Ce n'est pas du tout un problème dans le navigateur de l'utilisateur ; c'est un problème de la façon dont le portail SSO gère l'inscription MFA quand quelqu'un connaît le mot de passe et un OTP courant. Votre IdP (le fournisseur d'identité qui fait tourner le SSO — Okta, Entra ID, Google Workspace, celui qui a décidé que votre mot de passe est correct) traite « j'ai le mot de passe et un OTP frais » comme une preuve suffisante pour ajouter un autre facteur. C'est un choix de politique, et c'est la politique avec laquelle la plupart des entreprises sortent par défaut, parce que l'alternative serait que les utilisateurs se retrouvent verrouillés quand ils changent de téléphone.

L'exfiltration vers Salesforce et SharePoint s'exécute aussi sur l'ordinateur de l'attaquant, contre votre vrai SaaS, avec son second facteur fraîchement frappé. Cette partie n'est, au sens strict, pas « une attaque sur le navigateur de l'employée ». C'est l'attaquant qui se connecte comme une personne normale, parce qu'à ce stade c'est une personne normale. Le navigateur de votre employée a sauté les trois dernières étapes.

Donc, si vous cherchez un seul levier technologique sur lequel appuyer pour empêcher BlackFile de bout en bout, il n'y en a pas. L'attaque est répartie entre un téléphone, une fausse page, une politique d'IdP et l'ordinateur d'un attaquant.

Ce qu'il y a — et c'est la seule partie de la chaîne sur laquelle un éditeur de navigateur peut crédiblement dire quelque chose — c'est la deuxième étape, la fausse page de connexion. La page doit s'afficher quelque part. Où qu'elle s'affiche, l'employée tape de vrais identifiants et un vrai OTP dedans. La question est donc juste : dans quel genre de conteneur voulez-vous que cet événement particulier se produise ?

La page doit s'afficher quelque part

Bien. Donc la page s'affiche dans un navigateur. Lequel ?

Si vous ne faites rien, elle s'affiche dans n'importe quel navigateur que l'employée utilisait — Chrome sur un ordinateur personnel, Edge sur un ordinateur professionnel, Safari sur l'iPad qui se trouvait à portée. Quel que soit le navigateur, il est là depuis un moment. Il a un profil qui est là depuis un moment. Ce profil a probablement déjà des cookies pour le vrai portail SSO de l'entreprise, parce que l'employée se connecte au travail tous les matins. Il a des mots de passe enregistrés. Il a une suggestion d'auto-remplissage qui est, fort utilement, le mot de passe d'entreprise réel — sauf que l'auto-remplissage ne se déclenche correctement pas sur un domaine de phishing (les navigateurs sont bons pour ça), donc l'utilisatrice le tape manuellement, ce qu'elle fait également bien, parce qu'elle l'a fait dix mille fois.

La fausse page n'a besoin d'aucun de ces cookies. La fausse page a juste besoin que les doigts de l'utilisatrice continuent de faire ce que les doigts font quand une page demande un mot de passe. La fausse page récupère le mot de passe. La fausse page récupère l'OTP. La fausse page a fini.

Mais voici la question qui me trotte dans la tête. Pourquoi le navigateur personnel de l'employée, avec son profil de longue date et sa collection de tous les sites où elle s'est jamais connectée, était-il l'endroit où la fausse page de connexion d'entreprise s'est affichée en premier lieu ? La page prétend être corporate. L'utilisatrice est au travail. L'utilisatrice est, pour autant qu'elle sache, en train de faire des choses de travail. Pourquoi « la page de connexion d'entreprise » s'affiche-t-elle dans le même environnement logiciel que « le lien Spotify partagé par la cousine » et « un compte Etsy de 2018 » ?

C'est, je pense, la question.

L'argument du navigateur géré, en petit

Voici la version petite, étroite et honnête de l'argument Bromure pour cette attaque.

Un service IT peut déployer Bromure comme le navigateur d'entreprise homologué. Pas le seul navigateur sur l'ordinateur — l'utilisatrice peut toujours avoir Chrome et Safari pour la navigation personnelle — mais le seul navigateur qui est configuré, enrôlé, et marqué visiblement comme l'endroit où le SaaS d'entreprise est censé vivre. Bromure a un onglet Enterprise dans les paramètres dont la seule mission est exactement celle-ci : un champ pour un proxy HTTP, et un emplacement pour les certificats racine internes. Deux paramètres. C'est tout ce qu'il fait, et c'est intentionnellement tout ce qu'il fait. Une organisation configure ces deux choses une fois, remet aux employés un profil Bromure préconfiguré pour faire confiance à la CA d'entreprise et router via le proxy d'entreprise, et laisse le profil être visiblement l'endroit où vit le SaaS d'entreprise.

(Nous ne prétendons pas que l'onglet Enterprise est un plan de contrôle MDM complet. Ce sont deux champs texte. Deux champs texte bien choisis, ça suffit parfois.)

À l'intérieur de Bromure, chaque onglet est sa propre VM Linux jetable, avec son propre profil éphémère. Donc quand l'onglet Salesforce d'entreprise s'ouvre, il s'ouvre dans une VM gérée qui connaît le proxy d'entreprise et fait confiance à la CA d'entreprise. Quand l'employée ouvre, séparément, le lien Spotify partagé par sa cousine, cela s'ouvre dans une VM différente avec un profil différent qui n'a rien de tout cela.

Maintenant, l'appel téléphonique se produit toujours, exactement de la même manière. L'utilisatrice est toujours guidée vers un lien. Voici ce qui change :

• Le lien, quand on clique dessus, s'ouvre dans une VM Bromure. Il ne s'ouvre pas, par défaut, dans la même VM que la vraie session Salesforce de l'employée. (Les profils dans Bromure ne fusionnent pas silencieusement. La page qui se charge dans un profil « lien jetable » ne peut pas lire les cookies du profil « Salesforce d'entreprise », parce qu'ils vivent dans des VMs différentes avec des piles réseau différentes et des disques différents.)
• L'utilisatrice tape, possiblement, de vrais identifiants d'entreprise et un vrai OTP dans la page malgré tout. Bromure n'arrête pas la frappe au clavier. C'est la partie honnête.
• Le jeton de session (ou parfois juste les cookies, selon le kit) que la page capture vit dans un profil que l'utilisatrice est sur le point de fermer, sur une VM qui est sur le point d'être effacée, sans aucune relation privilégiée avec quoi que ce soit d'entreprise. Le jeton capturé est, en ce sens, de basse qualité — c'est un souvenir d'onglet.

Sur ce dernier point, je veux être prudent, car c'est exactement le genre de chose où il est facile de surpromettre.

Dans la chaîne BlackFile telle qu'elle est documentée, le jeton capturé n'est pas réellement utilisé pour se connecter au vrai Salesforce — l'attaquant utilise les identifiants et l'OTP pour se connecter au vrai portail SSO depuis son propre ordinateur, et enregistre son propre appareil MFA. Les cookies capturés n'allaient de toute façon jamais être rejoués contre la vraie session d'entreprise, parce que ce sont des cookies pour un domaine de phishing, pas pour le vrai domaine. Là où l'isolation par VM de Bromure compte, c'est dans la jambe derrière la fausse page : tout chahut côté onglet (exfiltration de jeton vers un endpoint de l'attaquant, script de suivi qui tente de lire d'autres cookies, chaînes de redirection qui déposent des charges supplémentaires) est contenu à l'intérieur d'une VM dont le système de fichiers, le réseau et l'arborescence de processus sont scellés par rapport au reste de l'ordinateur et à la vraie session de navigateur d'entreprise. La fausse page est une fausse page. Elle obtient juste d'être une fausse page dans une boîte.

L'indice, en particulier, fait beaucoup de travail dans ce schéma, et ça vaut la peine de le dire à voix haute. Un déploiement de navigateur géré dont la seule fonction est « l'onglet Salesforce / SharePoint / Workday d'entreprise est visiblement différent de l'onglet du lien quelconque » est, à lui seul, une défense non triviale, parce que la victime canonique de BlackFile est une personne fatiguée qui a reçu un appel à 16 h 45 un jeudi. La distinction visible n'est pas une fioriture d'UI ; c'est tout le match.

Ce que cela ne corrige pas

Je veux continuer à être honnête sur ce point, parce que le mode d'échec ici, c'est un fournisseur qui explique comment son produit aurait empêché une attaque et qui, quand on le lit attentivement, décrit une attaque différente.

Cela n'arrête pas l'appel. L'appel est sur le téléphone. Bromure ne tourne pas sur le téléphone, ne voit pas le téléphone, n'a pas d'opinion sur le téléphone. Si l'utilisatrice décroche et est convaincue par une voix amicale qu'il y a un petit problème avec son compte, l'utilisatrice va regarder une fausse page de connexion. On peut changer le navigateur où la page s'affiche. On ne peut pas changer si l'utilisatrice la regarde.

Cela n'arrête pas la frappe. Si l'utilisatrice tape de vrais identifiants et un vrai OTP dans la fausse page, ces identifiants et cet OTP sont désormais en possession de l'attaquant, peu importe où la page a été affichée. Le fait que la page soit dans une VM jetable n'efface pas ce que l'utilisatrice vient de taper.

Cela n'arrête pas l'inscription MFA. La jambe de l'inscription MFA se déroule sur l'ordinateur de l'attaquant, contre l'IdP légitime. Bromure ne tourne pas sur l'ordinateur de l'attaquant, et Bromure n'est pas l'IdP. La parade ici est du côté de l'IdP, et c'est la parade ennuyeuse : activez « exiger une authentification renforcée pour toute nouvelle inscription MFA », limitez les inscriptions au réseau d'entreprise ou à un appareil géré, alertez sur l'enregistrement de nouveaux facteurs, et acceptez que l'alternative soit que les utilisateurs se retrouvent verrouillés quand ils changent de téléphone. C'est un choix de configuration que chaque administrateur Okta et Entra ID peut faire dès aujourd'hui, et beaucoup ne l'ont pas fait, et c'est — pour le dire avec douceur — la partie de cette histoire qui devrait empêcher les RSSI de dormir plus que la partie navigateur.

Cela n'arrête pas, au sens strict, une attaque par proxy AiTM en temps réel. Une autre catégorie de kits de phishing (Evilginx, Modlishka, Caffeine, les locations d'AiTM-as-a-service à 2 500 $ pièce qui sont devenues le schéma d'attaque dominant sur Microsoft 365) fait du relais en temps réel : l'utilisatrice tape dans une page qui fait proxy, en temps réel, vers l'IdP légitime. Le cookie de session que l'IdP émet va au proxy ; le proxy le repasse à l'attaquant. Si vous imaginez un appel à la BlackFile dirigeant l'utilisatrice vers ce genre de page — ce que BlackFile n'est pas actuellement décrit comme faisant, mais c'est là que va la catégorie — alors le cookie capturé est un vrai cookie de session pour l'IdP légitime, et la question devient de savoir s'il peut être rejoué depuis ailleurs. C'est un autre billet, plus difficile, et la réponse honnête implique des contrôles de liaison de session (DBSC, jetons liés mTLS) qui relèvent surtout de l'IdP et seulement en partie du navigateur. Nous ne ferons pas de magie là-dessus.

Ce que Bromure géré fait, étroitement : il fait que la fausse page s'affiche dans un endroit non géré, éphémère et visiblement distinct de l'environnement d'entreprise géré. Il limite le rayon de soufflage de toute astuce post-page que le kit pourrait tenter (installations d'extensions, écritures sur le système de fichiers hôte, persistance) à une VM qui va disparaître. Et, dans la chaîne BlackFile telle que décrite, il n'empêche pas en lui-même l'attaquant d'aller ensuite enregistrer son propre appareil MFA — c'est le boulot de l'IdP. Nous atténuons une des quatre machines dans la chaîne, celle sur laquelle nous tournons.

Pourquoi c'est, à terme, la seule voie

Bref. Voilà. Prenons du recul.

Ce qui est intéressant avec BlackFile, c'est que c'est un commerce remarquablement efficace. Ils ont choisi le retail et l'hôtellerie parce que le retail et l'hôtellerie ont beaucoup d'employés, des horaires éclatés, du travail en dehors des heures de bureau, des équipes helpdesk IT réelles qui appellent légitimement les employés, et des effectifs très stressés qui ne veulent vraiment pas être la raison pour laquelle les caisses sont en panne. Ils ont choisi le vishing parce que le vishing passe à l'échelle (une personne au téléphone peut appeler une douzaine de cibles en une heure, et le taux de succès est, selon les standards de cette industrie, incroyable) et parce que l'appel est la partie de la chaîne que vous ne pouvez pas patcher. Ils récoltent les identifiants et les OTPs parce que les identifiants et les OTPs sont la partie de la chaîne qui, en 2026, est encore la porte d'entrée principale de la plupart des entreprises, malgré une décennie de présentations expliquant qu'ils ne devraient pas l'être.

La part de la chaîne qu'un navigateur peut influencer est petite. C'est une machine sur quatre. Vous ne devriez pas acheter un navigateur parce qu'il prétend mettre en échec BlackFile de bout en bout. Vous devriez acheter un navigateur parce qu'il fait bien la seule chose qu'il puisse bien faire — garder la session d'entreprise dans un endroit géré et identifiable, et garder la session du lien quelconque dans un endroit qui cesse d'exister quand vous le fermez — puis l'apparier avec les contrôles ennuyeux et peu sexy côté IdP qui ferment vraiment la boucle.

Le téléphone va continuer de sonner. La page va continuer de se charger. La question est juste de savoir où, exactement, elle se charge, et qu'est-ce qu'il y a autour quand elle le fait. Il s'avère que cela, on peut le changer.

Sources :

• BleepingComputer — New BlackFile extortion gang targets retail and hospitality orgs (2026-04-24)
• CrowdStrike — Cordial Spider adversary profile
• Help Net Security — Attackers use AiTM phishing kit, typosquatted domains to hijack AWS accounts (2026-03-10) (référencé pour le contexte plus large du marché AiTM-as-a-service, pas spécifiquement pour BlackFile)