Aller au contenu
Beveiligingsnieuws

ClickFix macOS : empreinte navigateur pour tromper

ClickFix macOS fingerprinting

Microsoft Threat Intelligence signale une campagne ClickFix sur macOS qui exploite une empreinte navigateur pour décider, à la volée, quel contenu afficher aux visiteurs. L’objectif est clair : présenter une “lure” (leurre) uniquement à des machines et des contextes jugés pertinents, tout en évitant que les pages soient correctement analysées par des robots, des bacs à sable ou des environnements d’expertise.

Selon l’analyse, l’infrastructure s’étend sur plus de 250 domaines front-end et s’appuie sur une porte de décision côté serveur. Résultat : deux visites sur la même adresse peuvent aboutir à des pages totalement différentes, rendant la détection plus complexe que sur une page malveillante statique.

Une opération ClickFix conditionnée par l’empreinte navigateur

Le mécanisme décrit par Microsoft repose sur un script JavaScript d’environ 2,5 Ko. Ce script collecte des signaux caractéristiques à partir du navigateur, notamment des informations de la plateforme, des dimensions d’écran et de fenêtre, ainsi que des indices liés à WebGL. L’idée n’est pas seulement d’identifier “un navigateur”, mais de distinguer un environnement réellement associé à du matériel Apple d’un environnement virtuel, émulé ou instrumenté.

La décision se fait ensuite sur le serveur : l’empreinte navigateur est envoyée, puis le système renvoie une réponse adaptée au profil détecté. Un visiteur jugé “non qualifié” peut recevoir une page vide, une page sans rapport ou même une fausse interface visant à détourner l’investigation.

Pourquoi les pages semblent inoffensives pour les analystes

Microsoft explique que la porte côté serveur sert de filtre. Les pages malicieuses peuvent être invisibles pour des crawlers et des sandboxes, non pas parce que le domaine “est propre”, mais parce que le contenu fourni ne correspond pas au scénario attendu.

Concrètement, certains signaux sont conçus pour repérer les conditions d’analyse :

  • Un compteur qui augmente lorsque la console développeur du navigateur est ouverte.
  • Un test détourné utilisant canPlayType(« video/mp4 »), employé comme “tripwire” pour repérer des navigateurs dissimulant des capacités multimédias via des scripts.
  • Des vérifications liées au fuseau horaire, à l’existence d’un encadrement dans une iframe, et à la détection de support tactile (souvent atypique sur un Mac de bureau).

Cette approche rend l’analyse automatisée moins fiable : les outils qui chargent la page dans un contexte différent de celui de la cible peuvent ne jamais déclencher la partie “leurre”.

Le leurre “macOS” et la fausse confiance

Lorsque le visiteur correspond aux conditions, le serveur renvoie une page de type “téléchargement pour macOS”, présentée sur un habillage style GitHub et accompagnée d’un badge de “Verified Publisher” forgé. L’objectif est de réduire les doutes et d’encourager l’utilisateur à suivre la procédure proposée.

Microsoft insiste sur un point important : une réponse qui ressemble à quelque chose de banal ou de non suspect n’est pas une preuve de sécurité. Le domaine peut rester malveillant, mais la page affichée dépend du contexte du navigateur et de ses signaux.

Le point de bascule : une commande Terminal à coller

Le piège ne s’arrête pas à un téléchargement “classique”. Même après avoir reçu la page de leurre, l’attaque exige une action manuelle : l’utilisateur doit copier et exécuter une commande obfusquée dans Terminal.

La commande sert ensuite de chaînon pour récupérer des scripts distants, puis lancer l’étape d’exfiltration. D’après Microsoft, la chaîne analysée aboutit à des modules identifiés dans le cluster plus large, notamment AMOS et, dans l’ensemble des campagnes observées, MacSync (tous les domaines ne sont pas forcément mappés à un payload particulier).

Ce que la commande fait ensuite

Une fois la commande exécutée, le flux décrit par Microsoft contacte ensuite une route de type /curl/<id> pour obtenir des scripts additionnels. Ensuite, l’infostealer ciblé vise des données sensibles, notamment :

  • des informations d’identification et de connexion (credentials),
  • des données de navigation (données de navigateur),
  • des magasins d’authentification,
  • des portefeuilles de cryptomonnaies,
  • et d’autres fichiers sensibles.

Microsoft ne divulgue pas, dans l’analyse, le nombre de victimes, les secteurs ciblés ni l’identité des opérateurs. L’enquête se concentre sur la logique et l’infrastructure observée pendant la surveillance.

Pourquoi les domaines sont trompeurs : un grand cluster front-end

Microsoft indique avoir identifié plus de 250 domaines front-end pendant la période de suivi. Beaucoup d’entre eux suivent un schéma de noms mêlant le terme “file” à des mots dictionnaires. Des exemples mentionnés incluent filecopperbasket[.]sbs et applefilevault[.]com.

La société précise toutefois que ce motif de nommage n’est qu’un indicateur pour la chasse. Le signal plus robuste combine plusieurs éléments : des noms jetables, des comportements d’infrastructure similaires et, surtout, la porte de empreinte navigateur qui conditionne la réponse.

Défense : repérer la “gate” plutôt que courir après chaque domaine

Face à des pages qui changent en fonction du contexte, Microsoft recommande de ne pas se limiter à bloquer une liste de domaines. L’approche la plus efficace consiste à chercher la logique de filtrage et ses artefacts techniques.

Les points d’attention proposés incluent :

  • des formulaires soumis automatiquement liés à l’empreinte,
  • des champs d’empreinte cachés ou non évidents,
  • la présence d’un artefact de mode mode: »php » dans l’échange,
  • et des marqueurs partagés côté infrastructure, notamment les chemins de type /curl/ utilisés après exécution de la commande.

Dans les systèmes défensifs, il est aussi conseillé de surveiller les séquences typiques : navigation suivie d’une activité Terminal inhabituelle, par exemple des scénarios où curl est pipé dans zsh, puis une décodification Base64, l’usage de osascript, et la création d’archives, le tout avec des requêtes HTTP POST sortantes.

Ce que macOS change et comment la victime est avertie

Microsoft mentionne que Apple a publié macOS 26.4 le 24 mars 2026 et a documenté des protections le 3 août. Parmi les protections décrites, Terminal peut afficher une invite de confirmation lorsque l’utilisateur ne l’a pas ouvert depuis plus de 30 jours, ou lorsque des conditions semblent correspondre à un scénario à risque (par exemple absence d’outils de développement courants et collage depuis des applications comme des navigateurs ou des messageries).

En complément, XProtect peut tracer des commandes collées dans un émulateur de terminal, inspecter l’arbre des processus et les artefacts réseau, puis bloquer des activités associées à des logiciels malveillants connus.

Ce qu’il faut faire si vous voyez cette instruction

Le message de fond est simple : ne suivez aucune consigne trouvée sur un site (qu’il s’agisse d’une “captcha”, d’un chat, ou d’une page de téléchargement) si l’instruction vous demande de copier et coller du texte dans Terminal et de l’exécuter.

Dans le cadre de cette campagne, l’exigence de la commande obfusquée agit comme une étape bloquante : refuser cette action empêche la chaîne d’exécution de se mettre en place.

Conclusion : l’empreinte navigateur comme rempart contre l’analyse

En résumé, la campagne décrite par Microsoft combine un grand cluster de domaines et une porte conditionnelle basée sur l’empreinte navigateur. Cette logique rend le leurre plus difficile à observer pour les outils d’analyse, car les pages peuvent changer en fonction du contexte de visite.

La meilleure stratégie de défense consiste à repérer la “gate” et ses artefacts (signaux d’empreinte, scripts, chemins d’infrastructure comme /curl/) plutôt qu’à ne chasser qu’une poignée de domaines. Et surtout : si Terminal vous demande de coller et d’exécuter une commande fournie par un site, considérez-le comme un indicateur de risque majeur.

Source: https://thehackernews.com/2026/08/over-250-clickfix-domains-use-browser.html