ClickFix et PowerShell : préparer la détection et le durcissement

ClickFix pousse une personne à exécuter elle-même une instruction présentée comme une vérification ou une réparation. Le guide grand public explique comment reconnaître le piège. Cette page s’adresse aux équipes informatiques : quels événements collecter, comment éviter les faux positifs et comment vérifier qu’une politique réduit réellement le risque sans bloquer les usages nécessaires ?

1. Définir le périmètre Windows

Inventoriez les éditions et builds Windows, Windows PowerShell 5.1 et les éventuelles versions PowerShell 7, les profils utilisateurs, les outils de gestion et les agents de sécurité. Un poste de développement et un poste de bureautique n’ont pas les mêmes besoins. La protection ne peut pas se résumer à interdire un nom de programme sans examiner les autres interpréteurs et chemins d’exécution.

L’analyse de Microsoft sur ClickFix montre l’importance de l’ingénierie sociale. La victime peut ouvrir un outil système en suivant une instruction du navigateur. Il n’existe donc pas nécessairement une relation parent-enfant directe entre le navigateur et PowerShell. Une règle imposant cette relation pourrait manquer des scénarios.

2. Construire la chaîne d’observation

La documentation PowerShell décrit les mécanismes de journalisation et AMSI. Vérifiez leur activation effective et leur remontée. N’enregistrez pas systématiquement des secrets pour améliorer une alerte : protégez les traces et définissez leur durée de conservation.

3. Écrire une hypothèse, puis mesurer son bruit

Une hypothèse possible est l’apparition, sur un poste bureautique, d’un interpréteur inhabituel suivie d’un accès réseau peu habituel, proche d’un signalement utilisateur. Ce n’est pas une signature universelle. Comparez avec les déploiements logiciels, les tâches d’administration et les scripts internes avant de fixer une alerte.

Les fragments de commande comme -e ou iex ne suffisent pas : ils peuvent produire du bruit, être absents ou être transformés. Conservez une logique explicable, la liste des sources nécessaires et les exceptions justifiées. Mesurez les alertes légitimes et les cas manqués dans le laboratoire. Une règle Sigma doit ensuite être adaptée aux champs du moteur cible ; la convertir ne valide pas sa qualité.

4. Choisir une protection réellement appliquée

Une politique de contrôle des applications peut limiter les exécutables et scripts autorisés. Microsoft décrit comment App Control interagit avec PowerShell, avec des comportements dépendant des versions. Préparez un mode d’audit, les applications nécessaires et une voie de récupération avant toute application bloquante.

Ne présentez pas __PSLockdownPolicy comme un mécanisme de durcissement de production : une variable de test ne remplace pas une politique de sécurité appliquée par le système. De même, ExecutionPolicy ou la suppression du raccourci Exécuter ne bloque pas tous les chemins d’exécution.

Avec AppLocker, les appartenances de groupes et la priorité des refus doivent être examinées. Un refus visant un groupe large peut aussi atteindre vos administrateurs ; une autorisation ajoutée ailleurs ne l’annule pas nécessairement. Vérifiez les règles effectives sur un poste pilote, pas seulement leur intention dans la console.

5. Recette sans charge malveillante

Préparez un poste de laboratoire, un utilisateur standard et un compte d’administration séparé. La commande ci-dessous affiche seulement un marqueur. Elle permet de vérifier une partie de la collecte ; elle ne simule pas toutes les propriétés d’une attaque ClickFix.

Write-Output "KENAWEK-TEST-JOURNALISATION"

• Noter l’heure, l’identité et le terminal utilisé pour cette commande inoffensive.
• Retrouver les événements attendus dans les sources effectivement activées.
• Tester un script interne autorisé et vérifier que la politique ne le bloque pas.
• Tester le refus d’un programme de laboratoire non autorisé selon la politique pilote.
• Vérifier qu’une source manquante est signalée plutôt qu’interprétée comme une absence d’activité.
• Rejouer le parcours de signalement avec une page de sensibilisation sans commande dangereuse.

Le succès attendu comprend la collecte, l’alerte prévue et la continuité des usages légitimes. Consignez les versions et les écarts avant de déployer.

6. Réagir et revenir à un état maîtrisé

Après une exécution suspecte, recueillez ce que la personne a fait sans lui demander de recommencer. Coordonnez l’isolement du poste, la conservation des traces et l’examen des identités. Une analyse antivirus sans alerte ne suffit pas à exclure une exposition de session.

Pour une politique pilote problématique, appliquez le mécanisme de récupération documenté et restaurez l’état antérieur validé. Les politiques signées ou verrouillées peuvent demander une procédure spécifique : testez-la avant généralisation. Chez Kenawek, le canal d’urgence de réponse à incident relève des procédures prévues pour les clients sous contrat ; le formulaire public sert à cadrer un besoin.

Sources et références

Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.

• Microsoft - Analyse de ClickFix
• Microsoft - Fonctions de sécurité PowerShell
• Microsoft - App Control et PowerShell