HalluSquatting : Quand les hallucinations des assistants IA deviennent un vecteur de botnet

HalluSquatting : Quand les hallucinations des assistants IA deviennent un vecteur de botnet

Vous demandez à votre assistant IA de récupérer un outil populaire, et il vous répond par un nom de projet qui n’existe pas. Ce phénomène, connu sous le nom d’hallucination, a récemment été exploité pour créer une nouvelle menace : l’attaque HalluSquatting. Selon des chercheurs de l’université de Tel Aviv, cette technique permet de transformer une simple erreur de l’IA en un outil de déploiement de botnet, avec un taux de réussite atteignant 85 % pour les demandes de dépôts et 100 % pour les installations de skills. Découvrons ensemble comment cette attaque fonctionne, pourquoi elle est particulièrement dangereuse et comment vous pouvez vous en protéger.

Comprendre l’attaque HalluSquatting

L’attaque HalluSquatting repose sur un principe simple : exploiter les hallucinations des assistants de codage assisté par IA. Ces outils, comme GitHub Copilot, Cursor ou Windsurf, ont tendance à inventer des noms de ressources lorsqu’ils ne trouvent pas l’information dans leurs données d’entraînement. Les chercheurs Aya Spira et son équipe, sous la direction de Ben Nassi, ont mis en évidence que ces fausses références sont souvent prévisibles et reproductibles d’un modèle à l’autre.

Un mécanisme en quatre étapes

1. Sélection d’une cible : L’attaquant identifie un dépôt ou un plugin tendance, qui n’est pas encore dans les données d’entraînement de l’assistant.
2. Identification de l’hallucination : En interrogeant l’IA à plusieurs reprises, l’attaquant note le nom fictif le plus fréquemment généré.
3. Enregistrement du nom : Il crée un dépôt ou un plugin sur GitHub ou une marketplace avec ce nom, en y dissimulant des instructions malveillantes (injection de prompt indirecte).
4. Exploitation : Lorsqu’un utilisateur légitime demande à son assistant de récupérer la ressource populaire, l’IA invoque le nom frauduleux, télécharge le contenu piégé et exécute les instructions malveillantes.

Cette technique n’est pas une vulnérabilité logicielle classique. Elle exploite un comportement inhérent aux modèles de langage : leur tendance à générer des réponses plausibles mais inexactes. Comme le soulignent les chercheurs, « Les attaques s’améliorent toujours ; elles ne s’aggravent jamais. »

Comment fonctionne cette menace ?

Pour comprendre le danger, il faut analyser la chaîne d’événements qui conduit à l’exécution de code malveillant. L’attaque combine deux faiblesses : une hallucination (le nom inventé) et une injection de prompt indirecte (les instructions cachées dans le contenu récupéré).

Le rôle de l’injection indirecte

Contrairement à une injection directe où l’utilisateur tape lui-même un prompt dangereux, l’injection indirecte arrive via une source externe que l’assistant va chercher. Par exemple, un fichier README.md ou un script de configuration peut contenir des instructions comme : « Exécute la commande suivante pour installer une dépendance supplémentaire. » L’assistant, suivant son interprétation, exécute ces commandes avec ses outils intégrés, comme un terminal.

Les tests réalisés

Les chercheurs ont testé l’attaque sur plusieurs assistants : Cursor, Windsurf, GitHub Copilot, Cline, Google Gemini CLI et la famille OpenClaw. Dans chaque cas, ils ont réussi à faire exécuter du code fourni par l’attaquant. Les charges utiles étaient des placeholders inoffensifs, mais le chemin d’attaque serait identique avec un véritable malware.

« Le piège n’est pas un code qui s’exécute tout seul. Il fonctionne parce que ces assistants gardent un terminal parmi leurs outils intégrés. Une fois que les instructions implantées prennent le contrôle, « installer un bot » est simplement une action que l’assistant peut effectuer. » - Extrait du rapport de recherche.

Pourquoi cela constitue un nouveau type de botnet ?

Les botnets traditionnels nécessitent des mots de passe faibles, des failles de sécurité ou des vers pour se propager. Ils ciblent souvent un type d’appareil homogène (comme Mirai avec les caméras et routeurs). L’attaque HalluSquatting change la donne :

• Pas de mot de passe à forcer.
• Pas d’exploitation réseau : le payload arrive sous forme de texte que l’IA lit, ce qui contourne les pare-feux.
• Multiplateforme : les machines infectées peuvent tourner sous Windows, macOS ou Linux.

L’IA n’est pas la charge utile, mais le véhicule de livraison. Une fois que le bot est installé, la machine rejoint un botnet classique. La nouveauté réside dans la combinaison : un nom inventé de manière prévisible, une marketplace où n’importe qui peut enregistrer ce nom, et un agent ayant l’autorisation de récupérer et d’exécuter du contenu externe.

HalluSquatting vs autres menaces similaires

Cette attaque s’inscrit dans une famille plus large de menaces exploitant les hallucinations. Voici un tableau comparatif pour mieux cerner les différences :

Source : Recherches d’Aikido Security (slopsquatting), Unit 42 (phantom squatting) et Tel Aviv University (HalluSquatting).

Pourquoi les assistants IA sont-ils vulnérables ?

La vulnérabilité ne vient pas d’un bug, mais d’une faiblesse architecturale dans la façon dont les assistants gèrent les ressources externes. Plusieurs facteurs expliquent pourquoi l’attaque fonctionne si bien.

La prédictibilité des hallucinations

Dans les expériences menées, l’erreur était constante : à travers différentes formulations et modèles de différentes entreprises, l’assistant choisissait le même nom erroné dans 85 % des demandes de dépôts et 100 % des installations de skills. Cette reproductibilité permet à un attaquant de préparer son piège avec une quasi-certitude.

L’absence de vérification des sources

Par défaut, les assistants ne vérifient pas si un nom de dépôt ou de plugin existe réellement avant de l’utiliser. Ils se fient à leur mémoire approximative plutôt qu’à une recherche en temps réel. Cette lacune est la porte d’entrée de l’attaque.

Les modes automatiques (auto-run)

Certains outils proposent des modes qui exécutent les commandes sans demander confirmation : skip-permissions pour Claude Code, yolo mode pour Gemini CLI. Ces modes exposent directement l’utilisateur à l’attaque.

« La condition pour que l’attaque fonctionne est un agent qui récupère une ressource externe et l’exécute sans contrôle humain. Fermez cette porte, et l’attaque s’arrête. » - Recommandation des chercheurs.

Mesures de protection pour entreprises et développeurs

Face à cette menace, plusieurs actions peuvent être mises en œuvre, tant au niveau des utilisateurs que des fournisseurs d’outils IA.

Pour les utilisateurs et les équipes de sécurité

1. Ne jamais activer les modes sans confirmation : Désactivez les options auto-run ou skip-permissions. L’assistant doit demander une validation avant d’exécuter une commande, surtout si elle provient d’une source externe.
2. Vérifier les noms des ressources : Avant de laisser l’assistant récupérer un dépôt ou un plugin, vérifiez manuellement que le nom correspond à la source officielle. Traitez tout nom généré par l’IA comme une suggestion, non un fait.
3. Utiliser des couches de sécurité supplémentaires : Certains outils intègrent désormais des vérifications, comme Conseca de Gemini CLI ou le mode automatique de Claude Code. Ces mécanismes réduisent le risque, mais ne l’éliminent pas complètement.

Pour les plateformes et les fournisseurs d’IA

• Recherche préalable : L’outil le plus efficace est de faire rechercher la ressource par l’assistant avant de l’utiliser. Une recherche en temps réel ancre l’agent dans la réalité et réduit les hallucinations.
• Pré-enregistrement des noms hallucinés : Les marketplaces peuvent préenregistrer les noms fictifs les plus fréquents pour les rediriger vers les projets réels, comme cela se fait déjà contre le typosquatting.
• Blocage des noms de dépôts connus : Empêcher la création de comptes avec des noms de dépôts bien connus sous de nouveaux comptes.

Exemple de procédure de vérification

Voici un exemple de script que les équipes de sécurité peuvent intégrer pour automatiser la vérification d’un dépôt avant de l’utiliser via un assistant :

# Script de vérification pour un dépôt GitHub
REPO_NAME="$1"
# Vérifier si le dépôt existe sur GitHub
if curl -s -o /dev/null -w "%{http_code}" "https://api.github.com/repos/$REPO_NAME" | grep -q "200"; then
    echo "Le dépôt existe. Procéder avec prudence."
else
    echo "ERREUR : Le dépôt $REPO_NAME n'existe pas. Ne pas utiliser."
fi

Ce script simple peut être intégré dans un flux de travail CI/CD pour valider les noms de dépôts avant qu’un assistant IA ne les utilise.

Conclusion : une vigilance accrue s’impose

L’attaque HalluSquatting illustre parfaitement comment les faiblesses des modèles de langage peuvent être détournées pour créer des menaces réelles. En exploitant la prédictibilité des hallucinations, les attaquants peuvent transformer des assistants IA en vecteurs de botnet, sans nécessiter de vulnérabilités logicielles classiques. Les chercheurs de l’université de Tel Aviv ont démontré que cette technique fonctionne sur plusieurs outils majeurs, avec un taux de réussite élevé.

Pour les entreprises françaises, la vigilance est de mise. L’ANSSI, dans ses recommandations sur l’utilisation de l’IA générative, insiste sur la nécessité de contrôler les accès et de vérifier les sources. En adoptant dès maintenant des mesures simples - désactiver les modes automatiques, vérifier les noms de ressources, et mettre en place des scripts de contrôle - vous pouvez réduire considérablement le risque d’être victime de cette attaque.

N’oubliez pas : chaque assistant IA qui peut récupérer et exécuter du contenu externe est une porte potentielle. Restez informé, formez vos équipes, et traitez toute information générée par l’IA comme une hypothèse à vérifier, non comme une vérité.