TerminalFix : comment de faux CAPTCHA installent un tunnel inversé sur les PC Windows

TerminalFix est une campagne d’ingénierie sociale analysée par Microsoft le 28 août 2026. Il s’agit d’une variante de la technique ClickFix : plutôt que d’exploiter une faille du navigateur, les attaquants convainquent directement l’utilisateur d’exécuter du code. 1

L’attaque commence sur un site légitime compromis, mais peut se conclure par l’installation d’un tunnel inversé persistant. Le PC infecté devient alors un point de relais permettant d’atteindre certains services internes accessibles depuis cette machine. 1

Le faux CAPTCHA qui déclenche l’attaque

La victime consulte un site légitime dont le contenu a été modifié. Une fenêtre superposée imitant Cloudflare Turnstile affiche une demande familière : « Vérifiez que vous êtes humain ».

Le piège apparaît à l’étape suivante. La page demande de copier un contenu, puis de le coller dans Windows Terminal ou PowerShell, en le présentant comme une étape de vérification.

C’est un signal d’alerte majeur. Un CAPTCHA s’effectue dans le navigateur : il ne nécessite ni l’ouverture d’un terminal ni l’exécution d’un contenu placé dans le presse-papiers. TerminalFix exploite précisément le fait que l’utilisateur considère la commande comme une partie du contrôle de sécurité, au lieu d’y voir du code. 1

Le recours à Windows Terminal ou PowerShell permet en outre aux attaquants de transmettre des commandes plus longues et plus complexes que dans les campagnes ClickFix qui utilisent habituellement la boîte de dialogue « Exécuter ». 1

Une chaîne d’infection en plusieurs étapes

Après l’exécution de la commande, plusieurs mécanismes s’enchaînent pour dissimuler l’activité malveillante derrière des outils et des fichiers apparemment ordinaires :

1. Téléchargement d’une archive : PowerShell télécharge une archive ZIP et l’extrait dans un répertoire à l’apparence masquée sous C:\ProgramData.
2. Détournement de DLL : l’archive place un exécutable Microsoft signé, LockScreenContentServer.exe, à côté de fichiers dui70.dll contrôlés par les attaquants. Lorsque l’exécutable recherche une bibliothèque nécessaire dans son propre répertoire, il charge la DLL malveillante. La signature de l’exécutable est donc exploitée, mais elle ne rend pas la DLL légitime.
3. Charges utiles dissimulées dans des images : des composants ultérieurs sont cachés dans les données de fichiers PNG grâce à la stéganographie, ce qui complique leur repérage lors d’une inspection élémentaire des fichiers ou des téléchargements.
4. Persistance : des entrées de démarrage du Registre et des tâches planifiées permettent aux composants de se relancer après l’ouverture de session ou à intervalles définis. 1

Pour les équipes de défense, cette progression est importante : bloquer un seul nom de fichier ne suffira probablement pas. Il faut corréler plusieurs comportements, notamment l’exécution de PowerShell, l’extraction d’archives, l’écriture de fichiers dans des emplacements inhabituels, le chargement de DLL, l’accès à des images et la création de mécanismes de persistance.

Ce que le malware cherche sur la machine

Selon l’analyse de Microsoft, le malware effectue une reconnaissance de l’hôte et du réseau : système, utilisateur, processus, services, configuration réseau et contexte de sécurité. Il explore également Active Directory afin d’identifier l’environnement de domaine ainsi que les systèmes ou comptes susceptibles d’être utiles pour la suite de l’intrusion. 1

Des requêtes inhabituelles vers les services d’annuaire depuis un poste de travail standard méritent donc une attention particulière lorsqu’elles apparaissent en parallèle de la chaîne d’exécution de TerminalFix. Les recherches peuvent notamment porter sur les contrôleurs de domaine, les utilisateurs, les groupes, les relations d’approbation, les partages, les systèmes distants ou les comptes privilégiés.

Le tunnel inversé transforme le risque

L’élément le plus préoccupant de la campagne est un implant Python, client.py, lancé avec pythonw.exe. Ce binaire n’affiche généralement pas de fenêtre de console classique, ce qui peut le rendre moins visible pour l’utilisateur. 1

Le client communique vers l’extérieur au moyen de TLS et de WebSockets avec gitnow[.]dev. Il peut recevoir l’ordre de se connecter, depuis le PC victime, à une adresse et à un port internes, puis de relayer le trafic TCP via la connexion WebSocket chiffrée, selon un fonctionnement comparable à celui d’un proxy SOCKS5. 1

En pratique, l’ordinateur compromis peut devenir un relais réseau contrôlé à distance. Cela ne donne pas automatiquement accès à tous les systèmes internes : la connectivité et les droits disponibles restent déterminants. Mais des services qui ne sont pas exposés directement sur Internet peuvent devenir accessibles par l’intermédiaire du poste infecté. L’incident ne concerne donc plus seulement un PC contaminé ; il devient un problème d’accès au réseau interne.

Indicateurs à rechercher

Aucun artefact isolé ne constitue une preuve suffisante. Les équipes doivent plutôt rechercher des combinaisons de signaux :

• Une session de navigation immédiatement suivie du lancement de Windows Terminal ou de PowerShell, notamment après l’affichage d’un CAPTCHA ou d’une prétendue vérification.
• Des commandes PowerShell qui téléchargent, décodent, extraient ou exécutent du contenu fourni par le presse-papiers.
• L’utilisation de PowerShell avec une fenêtre masquée, ou l’écriture d’archives et d’exécutables dans des répertoires inhabituels sous ProgramData.
• L’exécution de LockScreenContentServer.exe en dehors de son emplacement Windows habituel, surtout lorsqu’il se trouve avec dui70.dll dans un dossier inhabituel ou accessible en écriture par l’utilisateur.
• L’accès à des fichiers PNG juste avant l’apparition de nouvelles DLL, de fichiers Python, de tâches planifiées ou d’entrées de démarrage.
• La création ou la modification de valeurs HKCU ou HKLM sous ...\CurrentVersion\Run.
• Des tâches planifiées aux noms inhabituels, exécutées de manière récurrente, pointant vers des chemins suspects ou lançant PowerShell, pythonw.exe ou client.py.
• Le lancement de pythonw.exe avec l’argument client.py, associé à des connexions TLS ou WebSocket sortantes vers gitnow[.]dev.
• Des activités de découverte Active Directory et réseau depuis un poste qui n’effectue habituellement pas ce type d’énumération. 1

Les équipes peuvent rechercher gitnow[.]dev dans les journaux DNS, proxy, pare-feu, EDR, TLS/SNI et WebSocket. L’avis de Microsoft doit servir de référence pour les hachages, URL, chemins, noms de tâches et règles de détection complets, car les noms de fichiers et l’infrastructure peuvent évoluer. 1

Que faire après une exécution suspecte ?

1. Isoler le poste. Déconnectez la machine du réseau tout en préservant, si possible, la mémoire, les arbres de processus, les journaux PowerShell, les définitions de tâches planifiées, les clés de persistance, les journaux DNS et proxy ainsi que les données EDR.
2. Bloquer et rechercher. Bloquez les domaines et l’infrastructure identifiés dans le DNS, les passerelles web sécurisées, les proxys, les pare-feu et les outils de protection des terminaux. Recherchez la même séquence d’exécution sur les autres machines avant de reconnecter le poste.
3. Protéger les identités. Considérez comme potentiellement exposés les identifiants utilisés ou enregistrés sur la machine. Après le confinement et un premier périmètre d’analyse, réinitialisez les mots de passe concernés et révoquez les sessions et jetons actifs, en donnant la priorité aux comptes administrateurs, de domaine, cloud, VPN, navigateur, service et API accessibles depuis le poste.
4. Examiner l’activité interne. Vérifiez les authentifications Active Directory, les accès à distance, les serveurs de fichiers, le VPN et les outils d’administration associés à la machine et à son utilisateur.
5. Réinstaller si nécessaire. Pour les systèmes confirmés comme compromis, une réinstallation complète peut être préférable. Supprimer une seule DLL, une tâche planifiée ou une clé de démarrage ne garantit pas l’élimination d’autres mécanismes de persistance ni des accès établis via le tunnel.

Mesures préventives

Les organisations devraient limiter PowerShell et Windows Terminal aux usages nécessaires selon les rôles, mettre en place un contrôle applicatif comme WDAC ou AppLocker lorsque cela est pertinent, et ne pas considérer la stratégie d’exécution PowerShell comme une frontière de sécurité suffisante. Le principe du moindre privilège et la suppression des droits d’administrateur local inutiles réduisent l’impact d’une compromission.

La collecte centralisée des journaux de blocs de script PowerShell, notamment l’événement 4104, ainsi que la journalisation des modules et, lorsque cela est adapté, la transcription, peuvent aider à reconstituer l’attaque. Ces mesures doivent être associées à AMSI, à la détection sur les terminaux, à la protection contre les modifications et à la journalisation de la création des processus. 1

Les protections web et les navigateurs devraient également surveiller les redirections depuis des sites compromis, l’injection de scripts malveillants, les manipulations suspectes du presse-papiers et l’accès à des infrastructures connues de commande et de contrôle. 1

La consigne destinée aux utilisateurs doit rester simple : ne collez jamais une commande dans Exécuter, l’invite de commandes, PowerShell ou Windows Terminal parce qu’un site, un CAPTCHA, une erreur de navigateur, une publicité ou une page d’assistance vous le demande. Fermez la page et signalez plutôt son URL.

TerminalFix rappelle que des composants fiables peuvent être assemblés dans une chaîne malveillante. Un exécutable signé, Python, TLS, les WebSockets, des fichiers image et un site légitime peuvent sembler ordinaires pris séparément. La défense repose donc sur la corrélation des comportements, l’isolement rapide des postes et la protection des identités, plutôt que sur le blocage d’un simple nom de fichier ou d’une signature. 1