Domaine placeholder compromis : la menace ClickFix via third-party[.]com

Saviez-vous qu’un simple domaine générique, utilisé comme exemple dans plus de 1 700 dépôts GitHub, peut désormais transformer votre navigateur en vecteur d’attaque ? Ce scénario n’est plus une hypothèse : depuis juin 2026, le domaine third-party[.]com, longtemps considéré comme un domaine placeholder inoffensif, sert un piège ClickFit à toute personne l’ouvrant depuis un poste Windows. Pour les professionnels de la cybersécurité, cet incident révèle une faille de confiance silencieuse : l’habitude d’utiliser des noms de domaine non réservés dans la documentation, les tests et les compétences d’agents IA. Cet article détaille le fonctionnement de l’attaque, son impact sur l’écosystème du développement, et les mesures concrètes pour éviter de devenir la prochaine victime.

Le cas third-party[.]com : un domaine de confiance détourné

Un piège ClickFit sophistiqué

Le domaine third-party[.]com était, depuis des années, un place holder standard dans les exemples de code, les tutoriels et les spécifications d’API. Contrairement à example.com, réservé par l’IANA, ce domaine pouvait être enregistré par n’importe qui. Un acteur malveillant l’a fait, et a configuré le site pour délivrer un contenu différent selon le navigateur et le système d’exploitation du visiteur.

Selon les recherches de Manifold Security, le domaine sert désormais un ClickFix lure aux utilisateurs de Windows. Lorsqu’une victime accède à la page, elle voit apparaître une fausse vérification de sécurité imitant Cloudflare. L’attaque procède en deux temps :

1. Piratage du presse-papiers (clipboard hijacking) : un script injecte automatiquement une commande PowerShell malveillante dans le presse-papiers de l’utilisateur.
2. Incitation à exécuter la commande : la page affiche un message demandant à la victime d’ouvrir la boîte de dialogue Windows (Win+R) et de coller le contenu du presse-papiers pour « résoudre le problème ».

« third-party[.]com a été un domaine générique de documentation pendant des années, au même titre que example.com. Contrairement à example.com, il n’est pas réservé par l’IANA. N’importe qui pouvait l’enregistrer, et quelqu’un l’a fait. Chaque doc, test et compétence qui l’avait codé en dur pointe désormais vers une infrastructure attaquante. » - Ax Sharma, Head of Research, Manifold Security.

Un test de vérification trompeur

Pour les utilisateurs macOS, la page affiche un message d’erreur : « macOS n’est pas pris en charge. Ce site nécessite un PC Windows pour y accéder. » Cette approche sélective rend l’attaque discrète : les analyses de sécurité statiques, qui ne consultent pas le site avec un agent Windows, ne détectent rien d’anormal. Comme le souligne Manifold Security : « Vous pouvez scanner la compétence, lire le fichier, résoudre le domaine depuis votre boîte d’analyse et conclure que tout va bien, tout en étant complètement dans l’erreur quant à ce qu’un agent d’un utilisateur Windows reçoit lorsqu’il suit le même lien. »

La technique ClickFix : mécanisme et enjeux

ClickFix est une technique d’ingénierie sociale qui exploite la confiance de l’utilisateur dans les fenêtres système. Elle repose sur l’affichage de faux messages d’erreur, alertes de navigateur ou vérifications CAPTCHA pour convaincre la victime d’exécuter une commande système. Ce mode opératoire s’apparente au pastejacking : l’utilisateur colle sans le savoir un script malveillant dans le terminal.

Dans le cas de third-party[.]com, la commande collée est conçue pour extraire et exécuter une charge utile PowerShell distante. Une fois exécutée, celle-ci peut installer un rançongiciel, un voleur d’informations ou un accès persistant - avec les conséquences que l’on imagine pour une entreprise.

« Une analyse de fichier ne peut pas voir ce qu’un site décide d’envoyer. Le signe distinctif n’apparaît qu’au moment de la requête, depuis l’appelant qui compte. » - Manifold Security.

L’élément clé est que ce type d’attaque contourne les défenses classiques : antivirus, sandbox, et même certaines solutions de détection d’intrusion. Elle cible le maillon le plus faible - l’humain - en utilisant un vecteur de confiance : un domaine qui figure dans des milliers de références de documentation.

Impact sur les développeurs et les agents IA

Un rayon d’exposition massif

Une recherche sur GitHub montre que third-party[.]com est référencé dans plus de 1 700 dépôts publics. Parmi eux figurent des skills d’agents IA, des fichiers de configuration de serveurs MCP (Model Context Protocol), et des tutoriels d’API. Dans chaque cas, le domaine est utilisé comme un exemple d’endpoint - exactement ce à quoi il ressemble : un place holder. Mais aujourd’hui, ce place holder est une porte ouverte.

« Dans chacun de ces endroits, c’est exactement ce qu’il semble être : un place holder, un exemple, un substitut, et une utilisation tout à fait raisonnable de la part des équipes concernées. C’est aussi, désormais, un pointeur en direct vers un serveur ClickFix. » - Ax Sharma.

Le risque d’injection de prompt

Pour les agents IA qui utilisent ces domaines comme endpoints de test, la compromission ouvre la voie à des injections de prompt et autres comportements non prévus. Un agent qui interroge third-party[.]com pour récupérer une documentation ou exécuter une action peut recevoir des instructions malveillantes, qui seront ensuite exécutées dans l’environnement de l’entreprise. Le risque dépasse donc le simple poste utilisateur : il touche l’automatisation, les pipelines CI/CD, et les systèmes de décision automatisés.

Au-delà de third-party[.]com : 13 autres domaines non réservés identifiés

Suite à cette découverte, Manifold Security a identifié 13 autres domaines placeholder qui ne sont pas réservés par l’IANA. Parmi eux, deux - yoursite[.]com et your-domain[.]com - diffusent déjà des escroqueries et des scarewares aux visiteurs macOS, tandis que les autres affichent une page de parking anodine. Le chercheur Cody Nash précise : « Sur un navigateur macOS, your-domain[.]com a affiché un faux “MacOS Security Center” annonçant quatre virus et vendant un renouvellement McAfee contrefait à 55 % de réduction. Sur un autre rendu macOS, yoursite[.]com montrait un faux article de ZDF faisant la promotion d’un système d’investissement frauduleux. »

Voici la liste complète des domaines identifiés, chacun capable de passer des vérifications statiques :

• your-domain[.]com
• yourdomain[.]com
• your-site[.]com
• yoursite[.]com
• your-app[.]com
• yourapp[.]com
• myapp[.]com
• mysite[.]com
• acme[.]com
• company[.]com
• mycompany[.]com
• vendor[.]com
• foo[.]com

Ces domaines sont présents dans des centaines de milliers de fichiers GitHub et des centaines de compétences d’agents. Leur présence dans la documentation et les tests représente un risque bien plus large que celui de third-party[.]com. Pire encore, les deux sites diffusant des scarewares et des fraudes à l’investissement ne déclenchent aucun indicateur lors d’une analyse statique traditionnelle.

Tableau comparatif : domaines réservés vs non réservés

Mesures de protection et bonnes pratiques

Face à cette menace, les équipes de développement et de sécurité doivent agir immédiatement. Voici les étapes recommandées :

Audit des dépôts et des compétences

1. Rechercher dans l’ensemble des dépôts de code, documentations et fichiers de configuration les occurrences des domaines listés ci-dessus, ainsi que tout domaine générique non réservé.
2. S’assurer qu’aucun agent IA ou skill MCP ne référence ces domaines comme endpoints valides.
3. Remplacer toute occurrence par un domaine réservé par l’IANA (example[.]com, example[.]org, example[.]net) ou par un domaine appartenant à l’organisation.

Privilégier les place holders réservés

Les développeurs travaillant sur des skills, de la documentation ou des cas de test doivent uniquement utiliser les domaines réservés par l’IANA. Évitez les noms qui sonnent plausibles mais qui ne sont pas sous votre contrôle, comme mycompany[.]com ou yourapp[.]com. Un bon réflexe : vérifier si le domaine est réservé auprès de l’IANA avant de l’inclure dans un exemple.

Tester dynamiquement avec les bons clients

Les analyses de sécurité statiques ne suffisent plus. Comme le montre le cas de third-party[.]com, un serveur peut adapter sa réponse en fonction du client HTTP. Effectuez des tests dynamiques en utilisant un navigateur Windows réel, et en vérifiant le comportement complet du site depuis l’environnement de votre utilisateur final. Si vous développez un skill pour un agent IA, testez l’appel depuis l’agent lui-même, pas depuis une requête curl.

Surveiller les signaux faibles

Mettez en place une veille sur les domaines non réservés utilisés dans votre écosystème. Des outils de threat intelligence peuvent vous alerter lorsqu’un domaine précédemment inoffensif commence à servir du contenu suspect. L’apparition soudaine d’une page de vérification ou d’un CAPTCHA sur un domaine de documentation doit être considérée comme un indicateur de compromission potentiel.

« La menace des scarewares et des fraudes à l’investissement est inférieure à celle des malwares de type clipboard, mais leur surface d’exposition est bien plus large, et rien de tout cela n’apparaît dans les vérifications statiques que nous avons menées. » - Cody Nash, Manifold Security.

Conclusion : agir avant que la confiance ne soit exploitée

L’histoire de third-party[.]com n’est pas un cas isolé. Elle révèle une vulnérabilité systémique : la confiance aveugle que nous accordons aux domaines génériques dans notre documentation, nos tests et nos agents IA. En 2026, alors que les attaques ClickFix et pastejacking se multiplient, il est impératif de revoir l’usage des place holders dans l’ensemble de la chaîne de développement.

Le mot d’ordre : n’utilisez jamais un domaine placeholder non réservé. Même s’il semble inoffensif aujourd’hui, demain il pourrait servir une charge utile à vos utilisateurs ou à vos agents. Auditez vos dépôts, remplacez les domaines suspects, et formez vos équipes à cette nouvelle surface d’attaque. La prochaine fois que vous écrirez third-party[.]com dans un exemple, souvenez-vous que ce simple nom de domaine peut être la porte d’entrée d’une compromission grave. Prenez les devants : la sécurité de votre organisation en dépend.