Teknik - L'histoire d'un honeypot GenAI - Parce que... c'est l'épisode 0x366! — PolySécure Podcast

Teknik - L'histoire d'un honeypot GenAI - Parce que... c'est l'épisode 0x366!

PolySécure Podcast · 11/11/2026 05:00 · 26 min
Informatique

Contenu de l'épisode

Parce que… c’est l’épisode 0x366! Shameless plug Description

Cette description a été faite à l’aide de GLM 5.3 Flash, à partir de la transcription qui a été effectuée par ElevenLabs Scribev2. Aucune vérification humaine n’a été faite. Si vous découvrez des erreurs ou des inexactitudes, vous pouvez m’en faire part afin que je procède aux modifications appropriées.

La genèse du projet

Jérémy Scion présente une recherche de son équipe, qui expose quotidiennement des honeypots dans le monde pour suivre différentes menaces. Avec l’essor de l’IA, il est apparu nécessaire de monitorer cet écosystème, que ce soient des LLM directement exposés comme Ollama ou des orchestrateurs s’interfacant avec ces technologies. L’investigation porte sur un honeypot Flowise, un outil low code no code pour fabriquer des workflows basés sur l’IA, déployé notamment au Japon et en Europe à une période où plusieurs CVE affectaient ce produit et étaient exploitées par des botnets, surtout pour du minage de cryptomonnaie.

Une émulation réaliste plutôt qu’un vrai logiciel

Contrairement à certaines pratiques, l’équipe n’a pas exposé un vrai Flowise vulnérable mais un outil interne émulant son comportement. Exposer un vrai modèle comme Ollama risque de voir le serveur utilisé comme vecteur d’attaque, ce qui pose des difficultés légales, et un attaquant consomme des ressources de calcul réelles. L’émulation reproduit donc un comportement assez exhaustif, avec des faux chat flows ressemblant à des usages réels de l’IA en entreprise, dont un interfacé avec une fausse base PostgreSQL simulant des données financières. Une gestion d’état de session renforce le réalisme. Si un attaquant crée un fichier puis lance un LS, le fichier apparaît dans les résultats tout en restant purement virtuel. Le moteur d’inférence est également factice, avec des réponses préconstruites imitant les refus typiques des LLM, retournées aléatoirement, et des temps de réponse variables pour renforcer la crédibilité.

Le déroulement de l’attaque

Sur les trois honeypots déployés, seul celui du Japon a été ciblé rapidement. L’attaquant a d’abord mené une reconnaissance automatisée, interrogeant l’API pour identifier les endpoints accessibles, volontairement vulnérables. Il a ensuite entamé une phase de loot, tentant de voler un maximum d’identifiants, notamment des clés API de modèles frontières comme Claude ou ChatGPT, mais aussi d’outils internes. Puis il a tenté d’utiliser le honeypot comme point d’entrée pour scanner un réseau interne et exécuter des commandes de recon, avant de chercher à exploiter le workflow lié à la fausse base financière. Face à ces échecs, il a pivoté vers une autre stratégie.

Le pivot vers les plateformes de jeux en ligne

L’attaquant a alors tenté d’abuser du moteur d’inférence pour lancer de la reconnaissance et des scripts d’attaque contre des cibles externes, apparemment des sites de paris et de casinos en ligne. Plusieurs indices convergent vers un attaquant sinophone. D’abord l’usage d’un argot chinois très précis, le mot « bocai », littéralement « épinard argent », terme argotique désignant les jeux d’argent et marque, selon des analystes sinophones, d’un locuteur maîtrisant parfaitement le chinois. Ensuite le ciblage exclusif du honeypot japonais, ceux d’Europe étant ignorés. Enfin l’intérêt pour Nightingale, un outil de supervision principalement utilisé en Asie et notamment en Chine.

Automatisation et intervention manuelle

L’analyse révèle deux phases distinctes. La reconnaissance des instances Flowise semble scriptée, avec un enchaînement rapide d’accès aux différentes API. L’interaction par prompts avec le moteur d’inférence paraît entièrement manuelle. Les délais varient entre les re

Plus d'informations