Le LLMjacking évolue : du compute Ollama volé pour des agents d'attaque autonomes

De quoi s’agit-il ?

Le 17 juin 2026, l’équipe Sysdig Threat Research (TRT) a publié l’analyse d’un incident observé le 12 juin 2026 : un acteur malveillant a branché un serveur de modèles Ollama mal configuré et exposé sur Internet à une chaîne automatisée de sécurité offensive. L’acteur ne discutait pas avec le modèle et ne revendait pas l’accès : il utilisait la capacité d’inférence volée comme « cerveau » décisionnel d’un outil multi-étapes qui cartographie une cible, l’associe à des vulnérabilités connues, rédige du code de preuve de concept, puis tente l’intrusion.

C’est la convergence de deux tendances que Sysdig suit depuis qu’il a forgé le terme LLMjacking en mai 2024. La première est le vol de compute : abuser de la capacité IA payée ou auto-hébergée d’un tiers, qui en règle la facture. La seconde est l’outillage offensif autonome, longtemps cantonné à la recherche. Ici, les deux se rejoignent dans une seule campagne capturée.

Comment ça marche

La condition habilitante est banale. Ollama écoute sur le port 11434 sans authentification par défaut : un serveur lié à une interface publique répond à quiconque le trouve. Une étude SentinelLABS/Censys du 29 janvier 2026 a recensé environ 175 000 hôtes Ollama exposés dans 130 pays, près de la moitié annonçant des capacités d’appel d’outils — transformant un point de terminaison de génération de texte en un point capable d’exécuter du code.

Comme l’outil de l’attaquant envoie l’intégralité de ses instructions au modèle à chaque requête, Sysdig a capturé tout le framework. Il pilote le modèle à travers des étapes discrètes et au format strict : normalisation d’une bannière de service pour la recherche de CVE, appariement de vulnérabilités, reconnaissance web, synthèse de preuve de concept, fabrication d’injection SQL aveugle, extraction d’identifiants et de secrets, et un orchestrateur autonome qui boucle jusqu’à l’exécution de commande. Fait notable, chaque étape ordonne au modèle de traiter le contenu capturé sur la cible comme une donnée non fiable, jamais comme une instruction — une défense délibérée contre l’injection de prompt depuis les pages mêmes que l’outil lit.

La signature la plus durable du framework est son oracle de compromission : il injecte une commande encadrée par deux chaînes sentinelles uniques (VAPTb3gin … VAPTfin) et confirme l’exécution de code à distance en retrouvant ces marqueurs autour de la sortie d’id. Encadrer la sortie d’une commande par des marqueurs de début/fin pour qu’un parseur l’extraie du bruit est un indice récurrent d’outillage d’attaque généré par IA : un humain qui lit un terminal n’encadre pas sa sortie pour une machine.

Deux détails confirment qu’il s’agit d’un véritable logiciel, pas d’une démonstration. L’outil a demandé au moins sept modèles par leur nom, dont des modèles commerciaux (gpt-4o-mini, claude-3-5-sonnet, gemini-2.0-flash-exp) qu’il a simplement repointés vers le backend Ollama gratuit, et il a été pris en plein développement : des étapes ont été ajoutées et réécrites au fil d’une session de huit heures, toutes dirigées vers des plages d’entraînement privées (adresses RFC 1918 et espace des labos HackTheBox), et non vers des victimes réelles.

Pourquoi c’est important

Des chercheurs avaient prévenu il y a deux ans qu’un modèle compétent, doté de la description d’une vulnérabilité, pouvait exploiter de façon autonome 87 % d’un jeu de vulnérabilités one-day (Fang et al., avril 2024). Cet avertissement est désormais opérationnel, et l’économie s’est effondrée : quand l’inférence est volée, le coût marginal d’un attaquant autonome tend vers zéro pour quiconque accepte d’abuser du compute d’autrui.

Il existe aussi un angle mort défensif. Une détection qui surveille les journaux du serveur de modèles suppose que l’opérateur le possède et le surveille. Un serveur exposé découvert par un tiers est, par définition, un serveur que personne ne surveille : son propriétaire voit un compute élevé et un port ouvert, pas une chaîne d’attaque multi-étapes tournant sur son matériel.

Défenses

Traitez un point de terminaison d’inférence auto-hébergé exactement comme une base de données exposée :

• N’exposez pas le port 11434. Liez Ollama (et les serveurs similaires comme vLLM) à localhost ou à une interface interne. Tout accès distant doit passer derrière un pare-feu et un reverse proxy authentifiant.
• Ajoutez l’authentification au niveau du proxy ou du réseau. Ollama n’en fournit aucune ; elle doit être imposée devant chaque point de terminaison.
• Auditez vos propres plages. Scannez le port 11434 comme le ferait un attaquant et inventoriez les serveurs de modèles fantômes montés hors du périmètre de sécurité.
• Surveillez le trafic d’inférence à la recherche de volumes anormaux et de signatures d’outillage offensif — contrats de sortie structurés rigides et motifs de commandes encadrées par marqueurs. Sysdig a publié les chaînes sentinelles (VAPTb3gin, VAPTfin, __VAPTCMD__) et la sonde de confirmation comme ancres de détection.
• Méfiez-vous des modèles aux garde-fous retirés. Les premières sondes de la campagne demandaient une version Llama « abliterated » ; la présence de gabarits de modèles non censurés sur un point de terminaison est en soi un signal de risque.

Statut

Élément	Détail
Auteur du rapport	Sysdig TRT
Observé	12 juin 2026 (revenu le 14 juin)
Publié	17 juin 2026
Cause racine	Ollama exposé et non authentifié (port 11434)
CVE	Aucune — exposition de configuration, pas une faille logicielle
Ampleur de l’exposition	~175 000 hôtes Ollama exposés (SentinelLABS/Censys, janv. 2026)

Cet article est éducatif et défensif. Il résume des travaux de recherche divulgués publiquement et ne reproduit ni les charges utiles opérationnelles ni les prompts d’étapes du framework capturé.