Menace sur les domaines placeholder : comment « third-party.com » est devenu un vecteur d'attaque ClickFix

Saviez-vous qu’un simple domaine utilisé comme exemple dans la documentation technique, présent dans plus de 1 700 dépôts GitHub, peut désormais servir du code malveillant sans éveiller le moindre soupçon ? C’est la triste réalité de « third-party.com » - un domaine générique, non réservé par l’IANA, qui a été enregistré par un attaquant et transformé en plateforme d’attaque ClickFix. Cette technique d’ingénierie sociale, couplée au détournement de marqueurs de confiance, expose développeurs, utilisateurs et infrastructures à des risques d’infection par PowerShell, de vol de données et de compromission de systèmes entiers. Dans cet article, nous analysons en détail cette campagne, ses implications pour la cybersécurité des dépôts open source et des skills d’IA, et surtout comment vous protéger efficacement.

ClickFix : une technique d’ingénierie sociale redoutable qui exploite la confiance

L’attaque ClickFit - parfois appelée pastejacking - repose sur un leurre visant à faire exécuter une commande arbitraire à la victime, via le presse-papiers ou une saisie directe. Concrètement, un site web compromis affiche un message d’erreur factice, une fausse vérification Cloudflare ou un CAPTCHA invitant l’utilisateur à copier une commande et à la coller dans la boîte de dialogue « Exécuter » de Windows ou dans le Terminal macOS. Ce qui semble être une simple étape de sécurité est en réalité un piège.

Le mécanisme du pastejacking et du détournement de presse-papiers

Le site malveillant injecte automatiquement une commande PowerShell ou Bash dans le presse-papiers de la victime (clipboard hijacking). L’utilisateur, pensant résoudre un problème, exécute la commande sans vérifier son contenu. Celle-ci télécharge et exécute une charge utile à distance, offrant un accès complet à l’attaquant.

« Un scan de fichier ne peut pas voir ce qu’un site web décide d’envoyer. Le signe n’apparaît qu’au moment de la requête, depuis l’appelant qui compte. » - Manifold Security, Head of Research, Ax Sharma.

Cette technique contourne les analyses statiques traditionnelles : un fichier semble inoffensif, mais le serveur peut délivrer un contenu différent selon le navigateur, le système d’exploitation ou l’utilisateur.

Le cas « third-party.com » : un domaine de confiance devenu vecteur d’attaque

« third-party.com » était depuis des années un domaine générique utilisé dans la documentation technique, exactement comme « example.com », mais contrairement à ce dernier, il n’est pas réservé par l’IANA. N’importe qui pouvait l’enregistrer - et quelqu’un l’a fait. Selon Manifold Security, le domaine sert un leurre ClickFit depuis au moins juin 2026.

Comportement sélectif : Windows vs macOS

Ce ciblage permet à l’attaque de rester sous les radars des analystes qui testent depuis un environnement Linux ou macOS. Une analyse statique du code HTML ne révélera rien de suspect si le script côté serveur conditionne l’affichage.

« third-party.com a été un placeholder générique pendant des années, le même rôle que joue example.com. Mais contrairement à example.com, third-party.com n’est pas réservé par l’IANA. Quiconque pouvait l’enregistrer, et quelqu’un l’a fait. Chaque doc, test et skill qui l’a codé en dur pointe désormais les lecteurs vers une infrastructure d’attaque. » - Ax Sharma, Manifold Security.

Selon VirusTotal et Google Safe Browsing, le domaine est désormais marqué comme malveillant et non sûr. Pourtant, il était encore référencé dans plus de 1 700 dépôts GitHub publics au moment de la révélation.

Quels risques pour les développeurs et les utilisateurs ?

La contamination ne se limite pas aux sites web. Elle touche directement l’écosystème open source et les outils d’IA.

Menace sur les skills d’IA et les agents MCP

Les dépôts concernés incluent des skills pour agents d’IA (AI agent skills) et des documents MCP (Model Context Protocol) qui citent « third-party.com » comme endpoint d’exemple. Si un agent d’AI interroge ce domaine, il peut recevoir du contenu malveillant, ouvrant la voie à des injections de prompt (prompt injection) et à des comportements non désirés. En effet, un agent qui suit un lien vers un serveur compromis peut exécuter des actions dangereuses sans contrôle humain.

Impact sur les pipelines CI/CD et les tests

Les développeurs qui utilisent ce domaine dans des tests automatisés, des scripts de déploiement ou des configurations de CI/CD exposent leur environnement à une compromission. Le simple fait de résoudre le nom de domaine et de suivre une redirection peut déclencher l’attaque.

« Vous pouvez scanner le skill, lire le fichier, résoudre le domaine depuis votre boîte d’analyse et conclure qu’il est inoffensif, et vous tromper complètement sur ce que l’agent d’un utilisateur Windows reçoit lorsqu’il suit le même lien. » - Manifold Security.

13 autres domaines placeholder non réservés identifiés

Manifold Security a depuis identifié 13 domaines supplémentaires, tous passant les vérifications statiques, mais dont certains présentent déjà un comportement suspect.

Liste des domaines à risque (non réservés IANA)

1. your-domain.com
2. yourdomain.com
3. your-site.com
4. yoursite.com
5. your-app.com
6. yourapp.com
7. myapp.com
8. mysite.com
9. acme.com
10. company.com
11. mycompany.com
12. vendor.com
13. foo.com

Des scams et scarewares en plus du ClickFix

Deux d’entre eux - yoursite.com et your-domain.com - servent déjà du contenu malveillant :

• ** yoursite.com** : affiche une fausse page « MacOS Security Center » annonçant quatre virus et vendant un abonnement McAfee factice à 55 % de réduction (scareware).
• ** your-domain.com** : présente un faux article ZDF (chaîne allemande) faisant la promotion d’un système d’investissement frauduleux.

« Scareware et fraude à l’investissement sont une menace moindre que le malware via presse-papiers, mais l’exposition qu’ils exploitent est bien plus large, et rien de cela n’est apparu dans les vérifications statiques que nous avons effectuées. » - Cody Nash, chercheur en sécurité, Manifold Security.

Ces deux domaines sont présents dans des centaines de milliers de fichiers GitHub et des centaines de skills d’IA.

Comment se protéger de ces attaques par domaine placeholder ?

Face à cette menace, les bonnes pratiques de développement et de sécurité doivent évoluer. Voici les recommandations clés, alignées sur les préconisations de l’ANSSI et les normes ISO 27001.

1. Utiliser exclusivement des domaines réservés par l’IANA

Seuls example.com, example.org, example.net (et quelques autres) sont officiellement réservés et ne seront jamais enregistrés. Tout autre placeholder - surtout ceux qui semblent plausibles comme yourcompany.com ou myapp.com - est susceptible d’être squatté. Bannissez-les de vos documentations, tests et exemples.

2. Auditer vos dépôts et vos skills d’IA

Recherchez dans vos codebases les domaines non réservés listés plus haut, et remplacez-les par des URIs valides de test (par exemple https://example.com/endpoint). Utilisez des outils d’analyse comme grep ou des scanners dédiés.

3. Mettre en place des contrôles d’exécution

• Pour les utilisateurs finaux : ne jamais exécuter de commande copiée depuis un site web sans vérification. Utilisez un gestionnaire de mots de passe ou un terminal sécurisé.
• Pour les administrateurs : bloquez au niveau du proxy ou du pare-feu les domaines suspects listés ici. Activez la détection de pastejacking via des solutions EDR.
• Pour les développeurs : dans vos skills d’IA, n’utilisez que des endpoints sous votre contrôle ou des domaines réservés. Ajoutez une validation du schéma et des redirections.

4. Référencez-vous aux bonnes pratiques de l’ANSSI et du guide RGPD

L’ANSSI recommande, dans son guide de sécurisation des développements, de ne pas faire confiance aux ressources externes non réservées. De plus, la compromission d’un domaine placeholder peut entraîner une fuite de données personnelles (adresses IP, logs) - ce qui engage la responsabilité RGPD de l’organisation qui a référencé le domaine.

Le rôle des autorités et des bonnes pratiques de cybersécurité

Cette affaire illustre une faille systémique : la confiance aveugle en des domaines qui n’ont jamais été sécurisés. Les autorités comme l’ANSSI ou le CERT-FR pourraient émettre des alertes publiques, mais la responsabilité revient d’abord aux développeurs et aux équipes sécurité.

« 1 700 dépôts GitHub, des centaines de skills d’IA… le nombre de cibles potentielles est immense. Et ce n’est que la partie visible de l’iceberg. » - Analyse de Manifold Security, septembre 2026.

En complément, nous recommandons de mettre en place un processus de vérification proactive des placeholders dans les dépôts internes et open source, en utilisant des outils de sécurité du cycle de développement (DevSecOps).

Conclusion : agissez maintenant pour sécuriser vos codes et vos utilisateurs

L’affaire « third-party.com » n’est pas un incident isolé : c’est un signal d’alarme pour toute la communauté technique. Les domaines placeholder non réservés sont devenus des vecteurs d’attaque crédibles, capables de contourner les analyses statiques et de cibler des utilisateurs Windows tout en épargnant les analystes. En tant que professionnel de la cybersécurité ou développeur, vous devez immédiatement auditer vos références, former vos équipes et adopter des placeholders sécurisés.

Ne laissez pas un simple nom de domaine compromettre votre infrastructure. Utilisez example.com et ses variantes réservées, vérifiez vos dépendances, et sensibilisez vos utilisateurs aux techniques de pastejacking. La prochaine cible pourrait être votre site mycompany.com ou yourapp.com. Prenez les devants dès aujourd’hui.