Squattage fantôme : la nouvelle menace d'hameçonnage induite par l'IV qui invente des domaines inexistants

Les grands modèles de langage génèrent un nouveau vecteur d'attaque qui mérite une attention immédiate : ils inventent des adresses web plausibles qui n'existent pas, et les criminels les achètent sur le vol pour les transformer en pièges à phishing. Palo Alto Networks Unit 42 a baptisé cette tactique comme Squattage fantôme et a trouvé qu'il fonctionnait déjà dans des conditions réelles, avec des cas où les modèles suggéraient des domaines non existants et, des semaines plus tard, ces mêmes noms ont été enregistrés et utilisés pour voler des données financières et des références.

Le danger central est le transfert automatique de confiance: les développeurs, les assistants et les agents automatisés ont tendance à traiter un lien qui leur donne un modèle comme s'il était vrai. Lorsque le domaine n'existait pas au moment de la génération, qui enregistre d'abord qu'il hérite cette confiance sans avoir besoin de campagnes de masse ou de publicités malveillantes; il suffit pour un outil fiable de rediriger la victime. L'unité 42 a posé à des modèles des questions sur des centaines de marques et a obtenu des millions de liens, dont beaucoup étaient des inventions cohérentes entre les modèles et les ajustements, les rendant prévisibles pour un attaquant.

Que ces domaines ne proviennent pas de souvenirs directs de la formation, mais des schémas statistiques du modèle est particulièrement inquiétant: cela signifie que l'apparition répétée de la même direction fictive n'est pas une erreur aléatoire mais un comportement reproductible. Cette cohérence transforme la menace en quelque chose d'utilisable à grande échelle : un attaquant qui suit les sorties d'un modèle ou qui sait que les modèles de génération peuvent anticiper et enregistrer des domaines devant n'importe qui.

La nature éphémère d'un domaine nouvellement enregistré joue en faveur de l'attaquant. Les services de réputation, les listes de blocage et les flux de menaces nécessitent des preuves d'abus pour réagir; domaine nouvellement créé n'a pas d'histoire ni de signes et passe donc inaperçu jusqu'à ce qu'il fasse du mal. Dans les incidents documentés par l'unité 42, les domaines prédits par les modèles ont été convertis en clones exacts de magasins et de banques, avec des kits d'hameçonnage qui ont capturé des cartes et des documents, et même des opérations qui ont distribué des applications malveillantes pour Android.

Ce n'est pas un phénomène isolé: il y a une histoire dans les écosystèmes de développement où les modèles générateurs de code proposent des noms de paquets qui n'existent pas et les attaquants enregistrent ces noms pour distribuer des malwares ou des backdoors - un vecteur appelé slopsquatting -. La leçon est la même lorsque la sortie du modèle devient une entrée opérationnelle : si elle est effectuée sans vérification, la fenêtre de réaction temporaire est courte et coûteuse.

Pour les entreprises de sécurité et les équipements, des options défensives existent et doivent être appliquées d'urgence. Il est possible de cartographier de façon prédictive les directions dans lesquelles un modèle aura tendance à inventer et à surveiller ses enregistrements, ainsi que d'établir des alertes précoces contre les nouveaux enregistrements qui correspondent à ces profils. Il est également efficace d'imposer des contrôles aux agents et aux assistants afin que ne pas ouvrir ou télécharger le contenu des liens générés par les modèles sans validation humaine ou automatisée préalable et utiliser des contrôles de réputation en temps réel (par exemple avec des API de navigation sûres et des consultations DNS/WHOIS) avant de permettre des interactions sensibles.

Pour les utilisateurs individuels et les développeurs, la règle la plus pratique est claire: ne faites pas confiance aveuglément à un lien fourni par une IA. Confirmer que le domaine correspond au site officiel avant d'entrer des mots de passe ou des clés, revoir les certificats TLS, et activer de bonnes pratiques telles que l'authentification multifactorielle et permettre les politiques de liste dans les agents automatisés. Les organisations devraient également envisager des achats défensifs sélectifs, des accords avec les registraires et des services de protection de la marque, bien qu'une telle stratégie puisse être coûteuse à l'échelle.

Les fournisseurs de modèles et de plates-formes doivent assumer la responsabilité technique : mettre en œuvre les extrants pour marquer les liens générés par l'IV, fournir des outils intégrés de vérification du domaine et concevoir des mécanismes pour réduire la probabilité que des modèles produisent des noms viables mais inexistants. Au niveau architectural, certaines limites des modèles rendent la génération de ces faux positifs difficiles à éradiquer complètement, de sorte que l'atténuation opérationnelle et des processus sera essentielle.

La bonne nouvelle est que la prédictibilité du phénomène laisse une opportunité défensive : les entreprises peuvent aller de l'avant en cartographiant les "modèles d'invention" des modèles qu'elles utilisent, en surveillant les enregistrements et en déployant des blocs ou des puits avant que les domaines ne soient exploités. Pour les ressources et les lignes directrices pratiques sur la façon de protéger contre l'hameçonnage et les abus de domaine, voir les enquêtes sur les incidents de sécurité, telles que celles publiées par Unité 42 des réseaux Palo Alto et les recommandations opérationnelles de la sécurité Internet en tant que guides de navigation sûrs des fournisseurs et des autorités, par exemple la documentation technique de Google Safe Browsing développés.

En fin de compte, le problème essentiel est la confiance : l'IA amplifie à la fois l'utilité et le risque de raccourcis non vérifiés. Si les défenseurs n'anticipent pas et ne surveillent pas ces domaines inventés, le prix pour arriver en premier sera pour les attaquants. La réponse consiste à combiner les contrôles techniques, les processus de vérification et de formation : traiter la production d'un modèle comme un avant-projet qui nécessite une validation avant d'agir.