À 18 h 56, un utilisateur colle une commande dans une fenêtre Windows parce qu’une page web le lui demande pour prouver qu’il n’est pas un robot. Moins d’une minute plus tard, son ordinateur portable héberge un environnement NodeJS complet, un client Tor déjà connecté et une tâche planifiée déguisée en composant Windows. Sept secondes après la détection, le poste est coupé du réseau. Ce dossier reconstitue la soirée minute par minute : le leurre, ce que la commande a installé, pourquoi un tunnel Tor sur un poste menace directement le compte Microsoft 365, ce que chaque geste de confinement coupe et ne coupe pas, et les contrôles qui ferment ce chemin. Il est écrit pour un dirigeant ou un RCCI qui veut comprendre ce qu’il doit exiger, et pour les équipes qui doivent reconnaître le piège.
Le leurre : une vérification anti-robot qui demande d’ouvrir Windows
Tout le monde a déjà coché une case « Je ne suis pas un robot » ou cliqué sur des feux tricolores. Le leurre s’appuie sur ce réflexe. La page, souvent un site légitime compromis ou une publicité, affiche une vérification au graphisme familier. Mais au lieu d’une case à cocher, elle donne trois instructions courtes :
- appuyer sur la touche Windows et la touche X, puis choisir Terminal (ou la touche Windows et R, selon les variantes) ;
- appuyer sur Ctrl et V ;
- appuyer sur Entrée.
Au moment où l’utilisateur a cliqué sur la case, le script de la page a écrit une commande dans son presse-papier. Il ne l’a pas vue. En suivant les trois étapes, il ouvre lui-même une console PowerShell, y colle la commande et l’exécute avec ses propres droits. Dans les campagnes documentées, la ligne collée se termine souvent par un commentaire rassurant du type « vérification réussie, identifiant 4821 », seule partie visible dans une fenêtre étroite. Microsoft regroupe ces campagnes sous le nom ClickFix et les décrit en détail : observées depuis 2024, elles servent à installer des voleurs d’identifiants et des outils d’accès à distance (voir les sources en fin d’article).
C’est exactement ce que montrent nos journaux. Le processus détecté est un PowerShell lancé par Windows Terminal, sous la session de l’utilisateur. Pas de pièce jointe, pas de macro, pas d’exécutable téléchargé et ouvert : le seul programme que l’utilisateur ait lancé est un outil livré avec Windows.
Il n’y a pas de faute grave à chercher. Le site avait l’air normal, la demande avait l’air d’une vérification, et personne n’a appris aux utilisateurs qu’un captcha ne demande jamais d’ouvrir une fenêtre Windows. Ce piège vise précisément des personnes vigilantes, qui ne cliquent pas sur les pièces jointes douteuses.
Ce que la commande a installé en moins d’une minute
Le rapport de remédiation de l’EDR liste chaque fichier et chaque clé de registre touchés. On peut donc reconstituer la charge avec précision, ce qui est rare.
Un environnement NodeJS complet
Dans le profil de l’utilisateur, sous AppData\Local\SystemSyncqY\rtdO\, la commande a déposé un NodeJS complet, avec npm et corepack : plus de 1 400 fichiers, récupérés sous forme d’archive dans le dossier temporaire. Le nom du dossier imite une synchronisation système, le suffixe est aléatoire.
Pourquoi NodeJS ? Parce que c’est un logiciel légitime, signé, utilisé par des millions de développeurs. Un antivirus à signatures n’a aucune raison de le bloquer. Le code malveillant, quelques lignes de JavaScript, s’exécute à l’intérieur de cet environnement propre. L’EDR l’a d’ailleurs classé comme « téléchargeur NodeJS » : un interpréteur légitime détourné pour récupérer et lancer une charge.
Un client Tor, déjà démarré
À côté, sous AppData\Local\SystemSyncqY\channeleYLh\, un client Tor complet : son fichier de configuration, ses modules de contournement de filtrage (pour passer même si Tor est bloqué sur le réseau), ses bases de géolocalisation. Le plus inquiétant n’est pas sa présence, c’est son état : le fichier d’état, le journal de relais et la liste des relais du réseau Tor étaient déjà téléchargés. Le client s’était connecté.
Une archive au nom explicite, tunnel-rt.tar.gz, accompagnait l’ensemble. Ce n’est pas un voleur de mots de passe classique qui expédie ses trouvailles et disparaît : c’est un tunnel, conçu pour rester.
Une tâche planifiée déguisée
Pour survivre à un redémarrage, la commande a créé une tâche planifiée nommée « App Compatibility Manager » suivie d’un numéro, déclenchée à chaque ouverture de session. Le nom imite un composant de compatibilité de Windows : dans la liste des tâches d’un poste, personne ne la remarque.
Les comportements qui l’ont trahie
L’EDR a relevé une quinzaine de comportements sur la même chaîne de processus, parmi lesquels :
- des commandes PowerShell et cmd obfusquées, et une modification de la politique d’exécution des scripts ;
- un PowerShell qui télécharge du code sur Internet, avec des adresses encodées ;
- un interpréteur déposé puis exécuté par un autre interpréteur ;
- une requête WMI de reconnaissance, pour décrire la machine ;
- une altération de la journalisation d’événements de Windows (ETW), pour réduire ce que les outils de sécurité voient ;
- un crochet sur les événements clavier et souris ;
- la création de la tâche planifiée.
Pris un par un, certains de ces gestes existent dans des outils légitimes. Enchaînés en quelques secondes par un PowerShell lancé depuis un Terminal, ils dessinent une attaque. C’est ce que détecte un moteur comportemental, et ce qu’aucune liste de signatures ne voit.
Pourquoi un tunnel Tor sur un poste menace le compte Microsoft 365
Un tunnel sur un poste, à quoi cela sert-il à un attaquant ? À une chose précise : se faire passer pour l’utilisateur, au sens réseau.
Les politiques d’accès conditionnel de Microsoft Entra ID comparent chaque connexion à des repères : pays, adresse IP connue, appareil enregistré. Une connexion depuis l’étranger ou depuis un hébergeur est bloquée ou déclenche une alerte. Mais si l’attaquant fait passer son trafic par le poste de l’utilisateur, ses connexions sortent par la box du domicile ou le réseau du bureau, avec l’adresse IP habituelle, dans la ville habituelle. Les journaux ne voient rien d’anormal. Tor sert ici à rendre le chemin entre l’attaquant et le poste anonyme et difficile à couper par un simple filtrage.
Reste à entrer dans le compte. C’est là qu’intervient le jeton de session. Quand un utilisateur se connecte à Outlook, Teams ou OneDrive, Microsoft ne lui redemande pas son mot de passe à chaque fois : il dépose sur l’appareil des jetons, sortes de badges d’accès temporaires, renouvelables tant que la session n’est pas révoquée. Les navigateurs conservent aussi des cookies de session et des mots de passe enregistrés. Un programme qui tourne sous le compte de l’utilisateur peut tenter de copier ces éléments. Avec un badge copié et l’adresse IP de la victime, l’attaquant n’a besoin ni du mot de passe ni du MFA.
Dans notre cas, rien n’indique que l’attaquant soit allé jusque-là. Mais c’est ce scénario qui dicte le confinement : on ne se contente pas de nettoyer le poste.
Ce qui l’a arrêté : sept secondes
Le blocage n’est pas venu d’une signature, mais du moteur comportemental de l’EDR, en mode protection, c’est-à-dire autorisé à agir seul sans attendre un analyste.
| Heure | Ce qui se passe | Qui agit |
|---|---|---|
| 18 h 55 environ | L’utilisateur colle la commande dans Windows Terminal | Utilisateur |
| 18 h 56 min 26 s | Comportement malveillant identifié sur la chaîne PowerShell | EDR, seul |
| 18 h 56 min 33 s | Poste coupé du réseau : le tunnel tombe | EDR, seul |
| 18 h 56 à 18 h 57 | Processus tués, à plusieurs reprises, au fur et à mesure qu’ils se relancent | EDR, seul |
| 18 h 57 | 1 167 fichiers mis en quarantaine | EDR, seul |
| 18 h 58 | 1 451 éléments remédiés : dossiers, archive, tâche planifiée et clés de registre supprimés | EDR, seul |
| 19 h 31 | Qualification par ITAIA : vrai positif, remédiation vérifiée | ITAIA |
| 19 h 32 | Poste reconnecté au réseau | ITAIA |
| 19 h 35 à 19 h 45 | Vérification du compte Microsoft 365 dans les journaux Entra | ITAIA |
| 19 h 47 | Révocation de toutes les sessions Microsoft 365 de l’utilisateur | ITAIA |
Les sept secondes entre l’identification et l’isolement sont le chiffre qui compte. Pendant ces sept secondes, et pendant le temps qui a séparé le collage de la détection, le tunnel était potentiellement ouvert. Après, il ne l’était plus.
Une remarque honnête sur ce tableau : la qualification humaine est arrivée trente-cinq minutes après le blocage. C’est acceptable parce que le blocage était automatique et complet. Sans isolement automatique, ces trente-cinq minutes auraient été trente-cinq minutes de tunnel ouvert.
Ce que chaque geste coupe, et ce qu’il ne coupe pas
Le réflexe naturel, une fois le poste nettoyé, est de considérer l’incident clos. C’est l’erreur à éviter. Chaque geste de confinement ne coupe qu’une ligne.
Isoler et nettoyer le poste
L’isolement coupe le tunnel. La remédiation supprime la charge et la tâche planifiée, donc le retour au prochain démarrage. Ces deux gestes protègent le poste. Ils ne font rien pour ce qui a pu en sortir avant.
Révoquer les sessions Microsoft 365
Si des jetons ou des cookies de session ont été copiés, ils restent valables après le nettoyage du poste, puisqu’ils sont désormais ailleurs. La révocation des sessions dans Microsoft Entra ID les invalide : chaque application devra redemander une authentification complète, MFA compris. Les applications compatibles avec l’évaluation continue de l’accès réagissent en quelques minutes, les autres à l’expiration du jeton en cours, soit une heure au plus par défaut. C’est pourquoi l’utilisateur doit s’attendre à se reconnecter partout, sur son ordinateur comme sur son téléphone.
Changer le mot de passe du compte
La révocation ne change pas le mot de passe. Si celui-ci a été lu, l’attaquant peut tenter une nouvelle connexion, et seul le MFA l’arrête. Dans notre cas, le mot de passe n’avait pas changé depuis plus de six ans, et le compte était synchronisé depuis l’Active Directory local : le changement se fait dans l’annuaire de l’entreprise, puis se vérifie dans Entra après synchronisation. Changer le mot de passe dans le portail Microsoft ne suffirait pas, ou échouerait.
Changer les mots de passe enregistrés dans le navigateur
C’est la ligne qu’aucun outil ne coupe à la place de l’utilisateur. Banque, sites métier, messagerie personnelle : tout ce que le navigateur retenait doit être changé, de préférence depuis un autre appareil. Il faut l’expliquer simplement à l’utilisateur, et vérifier que c’est fait.
Vérifier le compte : ce que disent les journaux Entra, et leurs faux amis
Entre 19 h 35 et 19 h 45, nous avons relu les journaux de connexion et d’audit Microsoft Entra du compte, depuis 18 h et sur les sept jours précédents. Cette relecture a sa méthode, et ses pièges.
Ce que nous avons vérifié :
- les connexions interactives et non interactives depuis 18 h : adresse IP, lieu, application, résultat, appareil ;
- les adresses IP vues sur sept jours, pour connaître la normale de l’utilisateur ;
- les méthodes d’authentification enregistrées, pour détecter un téléphone ou une application ajoutés ;
- le journal d’audit Entra sur le compte : modification, ajout de méthode, changement de rôle ;
- les consentements accordés à des applications tierces ;
- les détections de risque d’Entra ID Protection.
Résultat : toutes les connexions provenaient du poste de l’utilisateur, avec les applications habituelles ; aucune méthode ajoutée, aucune modification du compte, aucune détection de risque.
Deux faux amis méritent d’être racontés, parce qu’ils feront perdre du temps à d’autres.
Le premier est une application au nom inconnu, apparue dans les connexions juste avant la détection. Un nom qui ne dit rien, au milieu d’une attaque, attire l’œil. La bonne question n’est pas « est-ce que je la connais ? », mais « est-ce qu’elle apparaît chez les autres utilisateurs du tenant ? ». Elle apparaissait chez une trentaine d’entre eux : c’était un composant interne de Microsoft 365.
Le second est plus troublant. Une connexion d’un composant Microsoft, quatorze minutes avant la détection, portait un user agent node-fetch, la bibliothèque HTTP de NodeJS. En plein incident NodeJS, la coïncidence est frappante. Même vérification : ce composant se présente avec ce user agent chez plus de quarante utilisateurs du tenant. Faux ami, là encore. Comparer au reste du tenant avant de conclure évite de déclencher une alerte générale sur un artefact normal, ou à l’inverse de rater une vraie anomalie noyée dans le bruit.
Et la limite, qu’il faut écrire noir sur blanc : puisque le tunnel faisait passer le trafic par l’adresse IP de l’utilisateur, des connexions d’un tiers pendant son fonctionnement ressembleraient exactement à celles de l’utilisateur. Les journaux n’établissent pas d’usage frauduleux du compte. Ils ne permettent pas non plus de l’exclure. C’est cette nuance qui justifie la révocation des sessions et le changement des mots de passe, même quand tout semble propre.
Ce que nous n’avons pas pu établir
L’honnêteté sur les limites fait partie du compte rendu.
- Le site d’origine. Le poste ne disposait pas de télémétrie réseau détaillée, et le navigateur n’a pas été analysé ce soir-là. La meilleure source reste l’utilisateur : quel site, quelle page, quelle demande. C’est aussi le seul moyen de bloquer ce site pour ses collègues.
- Le texte exact de la commande. PowerShell conserve l’historique des commandes saisies dans un fichier du profil de l’utilisateur. La remédiation automatique l’a supprimé avec le reste, parce que la charge y avait écrit. Pour une prochaine fois, la journalisation des blocs de scripts PowerShell, recommandée par Microsoft, conserve ce texte hors de portée de l’attaquant.
- Ce que le code JavaScript a eu le temps de faire avant l’isolement. Le tunnel était établi, mais rien dans les journaux disponibles ne montre de connexion d’un tiers. Nous écrivons donc « les journaux n’établissent pas d’exfiltration », et non « il n’y a pas eu d’exfiltration ».
Ce qui ferme le chemin
Aucun contrôle unique ne suffit. Ceux qui suivent se complètent, du plus efficace au plus simple.
- Un EDR comportemental en mode protection, avec isolement automatique du poste. C’est ce qui a fait la différence ici : sept secondes plutôt que trente-cinq minutes. Un EDR en simple mode détection aurait seulement prévenu.
- Restreindre ce que l’utilisateur peut lancer. La fenêtre Exécuter peut être désactivée par stratégie de groupe pour les postes qui n’en ont pas l’usage, comme le recommande Microsoft pour ce type d’attaque. Le lancement de PowerShell, de NodeJS ou de tout exécutable depuis le profil de l’utilisateur (
AppData) peut être limité par des règles de contrôle des applications. Ces règles demandent un inventaire préalable des usages réels, sous peine de bloquer des outils métier. - Journaliser PowerShell. La journalisation des blocs de scripts conserve le texte exact des commandes exécutées, ce qui manquait ici pour l’analyse.
- Lier les jetons à l’appareil. La protection des jetons de l’accès conditionnel n’accepte, pour les applications natives Microsoft 365 compatibles, que des jetons liés cryptographiquement à l’appareil enregistré. Un jeton copié et rejoué depuis la machine de l’attaquant est refusé, même à travers un tunnel. Le déploiement se fait par groupe pilote, en mode rapport seul d’abord.
- Ne pas laisser les mots de passe professionnels dans le navigateur. Un gestionnaire de mots de passe d’entreprise limite ce qu’un programme lancé sous le compte de l’utilisateur peut lire, et permet de changer les secrets touchés d’un coup.
- Bloquer Tor en sortie sur le pare-feu. Les modules de contournement rendent ce blocage imparfait, mais il ralentit et il alerte.
- Une sensibilisation ciblée, avec une seule règle : aucun site légitime ne demande d’ouvrir une fenêtre Windows ni d’y coller quoi que ce soit. Une règle courte se retient mieux qu’une formation générale.
Ce qu’un dirigeant peut demander à son prestataire
Cinq questions, dont les réponses tiennent en une ligne chacune.
- Notre EDR est-il en mode protection, avec isolement automatique, ou seulement en détection ?
- En combien de temps un poste compromis est-il coupé du réseau, et ce délai est-il mesuré ?
- Après un incident sur un poste, qui révoque les sessions Microsoft 365 de l’utilisateur, et à quel moment de la procédure ?
- Les comptes synchronisés depuis l’Active Directory ont-ils une procédure de changement de mot de passe en urgence, testée ?
- La fenêtre Exécuter et PowerShell sont-ils accessibles à tous les utilisateurs, et pourquoi ?
Le message à transmettre aux équipes
Le texte ci-dessous peut être repris tel quel dans une communication interne.
Conclusion : bloquer, puis tirer les deux fils
Cette attaque a été bloquée en sept secondes parce que l’outil sur le poste avait le droit d’agir seul. C’est la première condition. La seconde est de comprendre qu’un incident sur un poste est aussi un incident sur un compte : le tunnel visait Microsoft 365, pas l’ordinateur. Nettoyer le poste, révoquer les sessions, changer le mot de passe du compte et ceux du navigateur, chercher la même charge ailleurs : chaque geste ferme une porte différente, et aucun ne remplace les autres.
Le risque résiduel existe. Un utilisateur collera un jour une autre commande, sur une autre page. Ce que nous garantissons, c’est qu’elle sera vue, coupée du réseau sans attendre, et que le compte qui se trouve derrière sera traité dans la même soirée.
Sources
- Microsoft Threat Intelligence, Think before you Click(Fix): Analyzing the ClickFix social engineering technique : fonctionnement du leurre (presse-papier, fenêtre Exécuter, Windows Terminal), charges observées, recommandations (désactivation de la fenêtre Exécuter par stratégie de groupe, journalisation des blocs de scripts PowerShell, sensibilisation).
- Microsoft Learn, Revoke user access in an emergency in Microsoft Entra ID : durée de vie des jetons d’accès, révocation des sessions, évaluation continue de l’accès, cas des comptes synchronisés depuis un Active Directory local.
- Microsoft Learn, Token protection in Conditional Access : jetons liés à l’appareil, applications et plateformes prises en charge, déploiement en mode rapport seul.
