Faux CAPTCHA (ClickFix) : anatomie d'une attaque réelle sur un poste de PME

L'essentiel en 30 secondes

Récemment, sur le poste d'une PME de services professionnels que nous protégeons, une page web a affiché un faux test « Je ne suis pas un robot ». Pour le « valider », elle demandait d'appuyer sur Windows + R, de coller un texte puis de taper Entrée. Ce texte était une commande PowerShell chargée d'aller chercher un programme malveillant sur un serveur de l'attaquant.

• Notre SOC a reçu une alerte « exécution PowerShell suspecte » sur ce poste.
• 11 minutes plus tard, un analyste avait pris l'incident en charge et isolé le poste du réseau.
• Aucun signe de propagation vers d'autres machines n'a été observé.

Cette technique porte un nom : ClickFix. Elle contourne une bonne partie des protections classiques, parce que c'est l'utilisateur lui-même qui lance l'attaque. Cet article explique son fonctionnement à partir de la commande réellement exécutée, puis passe en revue les barrières qui pouvaient l'arrêter, dont une qui était en cours de déploiement chez ce client : le filtrage DNS.

Tout ce qui permettrait d'identifier le client (nom, poste, compte, date) a été retiré.

ClickFix : faire pirater un poste par son propre utilisateur

Ce que voit la victime

Le scénario type ressemble à ceci :

Vérification de sécurité Pour prouver que vous n'êtes pas un robot :

1. Appuyez sur la touche Windows + R
2. Appuyez sur Ctrl + V
3. Appuyez sur Entrée

En arrière-plan, la page a déjà copié une commande dans le presse-papiers. On ne la voit pas, ou seulement son début. On croit répondre à un contrôle anodin, comme on en croise tous les jours ; en réalité, on ouvre la boîte de dialogue « Exécuter » de Windows et on y lance un programme.

Les variantes sont nombreuses : faux message d'erreur d'affichage, faux correctif de navigateur, fausse invitation à une visioconférence. Le principe reste le même : « cliquer pour réparer », d'où le nom ClickFix.

Pourquoi ça marche

• Pas de pièce jointe, pas de téléchargement par le navigateur : les filtres qui inspectent les e-mails et les fichiers téléchargés n'ont rien à analyser.
• Un outil légitime : PowerShell est présent sur tous les postes Windows et utilisé chaque jour par les administrateurs. Son lancement n'a rien d'anormal en soi.
• L'action vient de l'utilisateur : Microsoft souligne que, l'exécution reposant sur une intervention humaine, ces campagnes peuvent passer au travers des solutions de sécurité conventionnelles et automatisées.

L'ampleur est réelle. Microsoft observe des campagnes ClickFix visant chaque jour des milliers d'appareils, diffusées par phishing, par publicités malveillantes et par des sites légitimes compromis. ESET a mesuré une hausse de plus de 500 % de ces attaques entre le second semestre 2024 et le premier semestre 2025 : elles représentaient alors près de 8 % des attaques bloquées par ses produits, au deuxième rang derrière le phishing.

Ce qui arrive ensuite

Selon Microsoft, la charge finale la plus fréquente des campagnes ClickFix est un voleur d'informations (Lumma Stealer). Ce type de programme récupère les mots de passe enregistrés dans le navigateur, les cookies de session et d'autres données, puis les envoie à l'attaquant. Microsoft cite aussi des outils de prise de contrôle à distance, qui donnent à l'attaquant un accès durable au poste.

Un cookie de session volé est particulièrement dangereux : il permet de réutiliser une session déjà ouverte, sans connaître le mot de passe et sans repasser par la double authentification.

Notre cas : ce que faisait la commande, étape par étape

La commande collée faisait une trentaine de lignes. Notre SOC l'a capturée en entier. Voici ce qu'elle faisait, traduit en clair, sans reproduire le code.

1. Masquer ses intentions. Les adresses des serveurs de l'attaquant étaient chiffrées (AES), donc illisibles dans la commande. Les mots sensibles étaient découpés en morceaux ('Op'+'en', 'Se'+'nd', 'ResponseBo'+'dy') pour ne pas correspondre aux motifs que recherchent les antivirus. Pour télécharger, la commande passait par un ancien composant Windows (WinHTTP) plutôt que par les commandes PowerShell habituelles, plus surveillées.
2. Patienter. Une pause de 16 secondes avant d'agir, procédé d'évasion courant face aux outils d'analyse automatisée.
3. Préparer le terrain. Création d'un dossier au nom aléatoire dans le répertoire temporaire de l'utilisateur.
4. Télécharger deux fichiers. Un petit programme d'extraction d'archives et une archive compressée protégée par un mot de passe, ce mot de passe figurant, encodé, dans la commande elle-même. Une archive chiffrée ne peut pas être inspectée pendant son transfert : son contenu reste opaque pour les filtres réseau et pour l'antivirus jusqu'à l'extraction. En cas d'échec, la commande faisait jusqu'à trois tentatives.
5. Extraire et lancer. L'archive était décompressée, puis la commande cherchait un exécutable précis, au nom imitant un composant système de Windows, et le lançait.
6. Effacer les traces. L'archive était supprimée trois secondes plus tard.
7. Prévenir l'attaquant. Une dernière requête partait vers une autre adresse chiffrée, très probablement pour signaler que l'installation avait réussi.

Ce que nous ne savons pas. Le rapport d'investigation ne mentionne aucun fichier malveillant retrouvé sur le poste. Nous ne pouvons donc pas dire si le programme final a eu le temps de s'exécuter, ni ce qu'il était. Dans le doute, la règle est simple : le poste et le compte sont traités comme compromis.

Ce que ce cas enseigne. Être simple utilisateur ne protège pas. Toute l'attaque se déroule dans le dossier personnel, sans droits d'administrateur. Un voleur d'informations n'a pas besoin d'être administrateur pour lire les mots de passe enregistrés dans le navigateur de la personne connectée.

La réponse : isoler d'abord, analyser ensuite

Isoler un poste, c'est couper toutes ses communications réseau, sauf avec la console de sécurité. Le poste reste allumé, ce qui préserve les éléments utiles à l'analyse, mais il ne peut plus joindre le serveur de l'attaquant ni atteindre les autres machines de l'entreprise. L'isolement n'attend pas d'avoir joint le client au téléphone : l'analyste le déclenche, puis le client est prévenu.

Le plan de remédiation :

• réinstaller entièrement le poste, plutôt que tenter de le « nettoyer » : on ne sait pas ce qui a été installé ;
• réinitialiser le mot de passe du compte et révoquer ses sessions Microsoft 365, depuis un autre appareil ;
• bloquer les indicateurs de l'attaque (domaine et adresses) sur le pare-feu et les outils de filtrage ;
• désactiver la boîte « Exécuter » par stratégie de groupe ;
• sensibiliser l'équipe aux faux CAPTCHA.

Sept barrières qui pouvaient arrêter cette attaque

Aucune protection n'est infaillible. La défense en profondeur consiste à empiler des barrières indépendantes, pour que l'attaquant doive toutes les franchir. Voici celles qui s'appliquaient ici, dans l'ordre où l'attaque les aurait rencontrées.

1. Le filtrage DNS, avant même l'affichage de la page

Avant de joindre un site, l'ordinateur demande l'adresse correspondant à son nom : c'est le rôle du DNS, l'annuaire d'Internet. Un filtre DNS répond « introuvable » pour les domaines malveillants connus, mais aussi pour des catégories entières : domaines enregistrés depuis quelques jours, extensions rarement utilisées par des sites légitimes, sites de publicité douteuse. La page piège ne s'affiche jamais. Notre article sur le filtrage DNS en PME détaille le principe.

2. La sensibilisation : une seule règle à retenir

Aucun site, aucun CAPTCHA, aucun support technique légitime ne vous demandera d'ouvrir « Exécuter », PowerShell ou le Terminal pour y coller quelque chose. Cette phrase devrait figurer dans toute sensibilisation en 2026. Microsoft recommande aussi d'apprendre aux utilisateurs à vérifier ce qu'ils copient et collent. Les campagnes de phishing simulées permettent de vérifier que le réflexe est acquis, pas seulement expliqué.

3. Désactiver la boîte « Exécuter »

La plupart des collaborateurs n'utilisent jamais Windows + R. Microsoft recommande de la désactiver quand elle n'est pas nécessaire, et notre SOC l'a recommandé à son tour après cet incident. Le paramètre s'appelle « Supprimer le menu Exécuter du menu Démarrer » : déployé par stratégie de groupe ou par Intune, il retire la commande du menu Démarrer et du Gestionnaire des tâches, et neutralise le raccourci Windows + R.

C'est une barrière, pas une solution complète : Microsoft précise que ce paramètre n'empêche pas de lancer des programmes par d'autres moyens, et des variantes de ClickFix demandent déjà d'ouvrir le Terminal à la place.

4. Encadrer PowerShell

Deux mécanismes de Windows et de Microsoft Defender visent précisément ce que faisait la commande :

• la règle de réduction de la surface d'attaque (ASR) « Bloquer l'exécution de scripts potentiellement obfusqués » détecte les propriétés suspectes d'un script masqué, et prend en charge PowerShell. Une commande remplie de chaînes chiffrées et de mots découpés en morceaux est exactement sa cible ;
• le contrôle des applications (App Control for Business ou AppLocker) fait basculer PowerShell en mode de langage restreint. Dans ce mode, l'utilisateur garde les commandes courantes, mais ne peut plus appeler les fonctions .NET et les composants COM qu'une commande comme celle-ci utilisait pour déchiffrer ses adresses et télécharger ses fichiers.

Le contrôle des applications demande un vrai projet de déploiement. Les règles ASR, elles, s'activent en quelques minutes depuis Intune ou Microsoft Defender, dès lors que l'antivirus Microsoft Defender est actif sur les postes, idéalement en mode audit d'abord pour repérer les applications métier qui déclencheraient des faux positifs.

5. Le filtrage DNS, deuxième chance : couper la ligne avec l'attaquant

Pour télécharger ses fichiers, la commande devait d'abord résoudre le nom de domaine de l'attaquant, ici un domaine en .beer. Cette requête passe par le système, donc par un filtre DNS installé sur le poste. Si le domaine est bloqué, le téléchargement échoue, l'archive n'arrive jamais, et la commande s'arrête d'elle-même : elle prévoit de quitter si l'archive est absente.

Chez ce client, le filtrage DNS était en cours de déploiement au moment de l'attaque. Aurait-il bloqué ce domaine précis ? Nous ne pouvons pas l'affirmer : tout dépend de sa classification au moment de l'attaque. Les domaines d'attaque sont souvent créés peu de temps avant leur utilisation, d'où l'intérêt de bloquer la catégorie des domaines récemment enregistrés, et pas seulement les listes de domaines déjà signalés. La protection réseau de Microsoft Defender for Endpoint, recommandée par Microsoft contre ClickFix, joue un rôle comparable en bloquant les connexions vers les domaines de mauvaise réputation.

6. Bloquer l'exécutable inconnu

La règle ASR « Bloquer l'exécution des fichiers exécutables, sauf s'ils répondent à un critère de prévalence, d'âge ou de liste de confiance » s'appuie sur la protection cloud de Microsoft pour évaluer la réputation d'un programme. Un exécutable tout juste extrait d'une archive, dans un dossier temporaire, inconnu du reste du monde, correspond exactement à ce qu'elle bloque. Elle peut gêner des logiciels métier très confidentiels : là encore, le mode audit permet de mesurer l'impact avant de l'activer.

C'est aussi le moment où un EDR observe le comportement du poste : un processus PowerShell lancé depuis « Exécuter », qui télécharge, extrait puis lance un exécutable, forme une séquence que les moteurs de détection reconnaissent.

7. Quand tout le reste a cédé : détecter, isoler, limiter

Dans ce cas réel, c'est cette dernière barrière qui a fonctionné : l'agent de détection a remonté l'alerte, et un analyste humain, disponible 24/7, a isolé le poste 11 minutes après l'alerte. Une alerte non traitée ne protège personne ; c'est la différence entre un EDR seul et un SOC managé.

Reste à limiter la valeur de ce qui aurait pu être volé :

• ne pas enregistrer ses mots de passe dans le navigateur, première cible des voleurs d'informations, et utiliser un gestionnaire de mots de passe ;
• exiger un appareil géré et conforme pour accéder à Microsoft 365, avec l'accès conditionnel : un attaquant qui rejoue une session depuis sa propre machine se heurte alors à une barrière supplémentaire ;
• savoir révoquer les sessions d'un compte en quelques minutes, comme nous le détaillons dans notre article sur les connexions suspectes à Microsoft 365.

Ce qu'il faut retenir pour votre entreprise

Si un site vous demande d'appuyer sur Windows + R : fermez l'onglet et prévenez votre support informatique.

Si la commande a déjà été lancée :

1. déconnectez le poste du réseau (câble débranché, Wi-Fi coupé), sans l'éteindre ;
2. appelez immédiatement votre support informatique ;
3. depuis un autre appareil, changez le mot de passe de votre compte professionnel et ceux des comptes enregistrés dans votre navigateur.

Côté direction, les protections ne protègent qu'une fois déployées. Chez ce client, l'EDR et la surveillance 24/7 étaient en place ; le filtrage DNS arrivait. C'est donc la dernière barrière de la chaîne qui a tenu. Pour ne pas dépendre d'une seule couche, voici l'ordre que nous recommandons :

• dès maintenant : la règle « jamais de Windows + R à la demande d'un site » dans la sensibilisation, et la boîte « Exécuter » désactivée sur les postes qui n'en ont pas besoin ;
• dans le mois : le filtrage DNS sur tous les postes, y compris en télétravail, et les règles ASR en mode audit puis en blocage ;
• en continu : un EDR surveillé 24/7 par des analystes capables d'isoler un poste sans attendre, et le durcissement des postes.

Sources

• Microsoft Threat Intelligence : « Think before you Click(Fix) », analyse de la technique ClickFix (21 août 2025)
• ESET : Threat Report H1 2025, hausse des attaques ClickFix (juin 2025)
• Microsoft : référence des règles de réduction de la surface d'attaque (ASR)
• Microsoft : paramètre « Supprimer le menu Exécuter du menu Démarrer » (NoRun)
• Microsoft : modes de langage PowerShell et mode restreint