Le paradigme de la cybersécurité vient de basculer. Jusqu’à présent, nos défenses reposaient majoritairement sur la détection de codes malveillants statiques ou de comportements connus. La découverte de PromptLock par les chercheurs d’ESET en août 2025 prouve qu’un modèle de langage peut générer dynamiquement le code d’un ransomware au moment de l’exécution, rendant la détection par signature en grande partie inopérante. Précision importante, et souvent absente des articles publiés dans la foulée : ce n’est pas une attaque réelle. Une dizaine de jours après l’alerte d’ESET, il a été établi que l’échantillon provenait d’une équipe de recherche de la NYU Tandon School of Engineering, autrice du papier Ransomware 3.0: Self-Composing and LLM-Orchestrated. Aucune victime, aucun groupe criminel derrière. Cela ne rend pas la démonstration moins sérieuse pour autant : ce que le prototype prouve, c’est que l’automatisation offensive est désormais à portée de budget et réduit drastiquement le temps de réaction accordé aux SOC. En tant qu’expert IT, j’ai disséqué son architecture pour vous livrer une analyse approfondie et les contre-mesures à déployer en urgence sur vos infrastructures.
Qu’est-ce que PromptLock et pourquoi change-t-il la donne ?
La découverte de PromptLock par ESET marque un tournant dans l’évolution des cybermenaces. À ce stade, il s’agit d’une Preuve de Concept (PoC) : aucune victime n’a été recensée dans la nature et les routines de destruction de fichiers, bien que présentes dans le code, ne sont pas implémentées. Cependant, dans mon expérience de l’analyse des menaces, c’est précisément le moment où les équipes IT doivent réagir. Ce prototype démontre qu’il est désormais possible de transformer une machine cible en sa propre usine d’armement numérique.
La chronologie mérite d’être rappelée, parce qu’elle a été largement déformée. Les échantillons Windows et Linux sont téléversés sur VirusTotal depuis les États-Unis fin août 2025. ESET les repère et publie son alerte les 26 et 27 août, en parlant du premier ransomware piloté par IA. Début septembre 2025, l’origine est identifiée : il s’agit du prototype accompagnant le papier académique Ransomware 3.0: Self-Composing and LLM-Orchestrated (arXiv 2508.20444), publié par une équipe de la NYU Tandon School of Engineering. ESET a corrigé sa communication en conséquence. Retenez donc la nuance quand vous relayez le sujet en interne : PromptLock est une démonstration universitaire, pas une campagne criminelle. Plusieurs indices le trahissaient d’ailleurs dès l’analyse initiale, à commencer par l’adresse Bitcoin codée en dur dans le prompt d’extorsion, qui est celle attribuée à Satoshi Nakamoto.
La rupture technologique : de la signature statique au polymorphisme absolu
Pour comprendre la révolution qu’incarne PromptLock, il faut se pencher sur le fonctionnement d’un ransomware classique. Traditionnellement, un attaquant compile un code pré-écrit (souvent en C++, Rust ou Go). Ce binaire contient en dur les instructions de chiffrement, les clés publiques, et le texte de la demande de rançon. Conséquence : bien que les attaquants utilisent des « packers » pour masquer le code, l’empreinte reste prévisible et les signatures sont identifiables par n’importe quel antivirus moderne.
La rupture technologique de PromptLock réside dans l’absence totale de code malveillant en dur lors de l’infection initiale. Au lieu de transporter une arme prête à l’emploi, l’attaquant déploie un simple script contenant des « prompts » (instructions textuelles). Ce script va forcer une intelligence artificielle, hébergée directement sur la machine de la victime, à concevoir l’arme sur mesure. Cette approche modifie drastiquement l’asymétrie attaque/défense : elle abaisse la barrière à l’entrée technique pour les cybercriminels, qui n’ont plus besoin d’être des développeurs aguerris pour concevoir des malwares sophistiqués.
Analyse structurelle : Ransomware classique vs Ransomware piloté par IA (PromptLock)
Pour matérialiser ce changement de paradigme, j’ai synthétisé les différences fondamentales entre ces deux approches dans le tableau comparatif ci-dessous. Cette vue d’ensemble permet de comprendre pourquoi nos paradigmes de détection doivent évoluer.
| Caractéristique | Ransomware Classique (ex: LockBit, Conti) | PromptLock (Piloté par IA) |
|---|---|---|
| Nature du code | Statique et pré-compilé | Généré dynamiquement à la volée |
| Dépendance réseau | Connexion à un serveur C&C distant requise | Appel à une API LLM compatible OpenAI (Ollama en local, ou serveur distant via proxy/tunnel) |
| Détection par signature | Élevée (fichiers binaires connus) | Quasi-nulle (polymorphisme extrême) |
| Langage d’exécution | Binaire compilé (.exe, .elf) | Scripts interprétés (Lua, Python) générés in-situ |
| Ciblage OS | Spécifique à un système d’exploitation | Multiplateforme et adaptatif (reconnaissance IA) |
Analyse de l’architecture technique : la chaîne d’attaque sous le capot
L’ingéniosité redoutable de PromptLock réside dans sa capacité à pratiquer le « Living off the Land » (vivre sur le pays) à une échelle inédite. Il assemble des outils totalement légitimes et les détourne de leur usage initial pour orchestrer une attaque furtive et dévastatrice. Décortiquons ensemble la mécanique de cette chaîne d’attaque.
Le moteur central : l’intégration d’un LLM local
La pierre angulaire de PromptLock est l’exploitation d’une API d’intelligence artificielle interrogée via le protocole d’Ollama, un outil open source très populaire chez les développeurs pour exécuter des modèles de langage (LLM) en local. Le prototype cible spécifiquement gpt-oss:20b, le modèle open-weight publié par OpenAI en août 2025. Le module de transport est en réalité un simple client HTTP/HTTPS compatible avec n’importe quelle API de type OpenAI, ce qui rend le prototype indifférent à l’endroit où tourne réellement le modèle.
C’est ici qu’il faut corriger une idée reçue qui circule beaucoup sur ce sujet. Non, PromptLock ne fait pas tourner l’IA sur la machine de la victime dans le cas général, et ESET le dit explicitement : plutôt que de télécharger un modèle de plusieurs gigaoctets sur le poste compromis, l’attaquant établit un proxy ou un tunnel vers un serveur distant qui héberge déjà l’API Ollama et le modèle préchargé. La contrainte est matérielle et facile à vérifier : gpt-oss:20b pèse environ 13 Go en quantification MXFP4 et demande de l’ordre de 16 Go de mémoire pour tourner correctement, ce qui exclut d’emblée l’immense majorité des postes bureautiques d’un parc d’entreprise. Si le sujet du dimensionnement mémoire des modèles vous intéresse, je l’ai détaillé dans mon guide sur le calcul de VRAM pour les LLM.
La conséquence défensive est à l’opposé de ce qu’on lit souvent. Le trafic n’est pas invisible : il existe bel et bien un flux sortant, mais il ressemble à un appel d’API HTTPS parfaitement banal vers un service d’inférence, et non à une balise C2 connue de vos flux de renseignement. Le problème n’est donc pas l’absence de signal réseau, c’est sa légitimité apparente. Le scénario réellement 100 % local, avec un appel confiné à localhost:11434, ne concerne que les postes de développement où un LLM est déjà installé. Ces postes existent dans presque toutes les DSI, et ce sont eux qu’il faut inventorier en premier.
Le vrai basculement : 0,70 dollar par attaque
Le chiffre le plus parlant du papier de la NYU n’est pas technique, il est économique. Une exécution complète de la chaîne d’attaque, des quatre phases (cartographie du système, identification des fichiers de valeur, exfiltration ou chiffrement, rédaction de la note de rançon), consomme environ 23 000 tokens, soit à peu près 0,70 dollar avec une API commerciale de modèle haut de gamme. Avec un modèle open-weight auto-hébergé comme gpt-oss:20b, le coût marginal tombe à celui de l’électricité.
C’est cette ligne-là qui devrait retenir l’attention des RSSI. Le prototype a été évalué par les chercheurs sur trois profils d’environnement distincts : poste personnel, serveur d’entreprise et système de contrôle industriel. Ce qui coûtait auparavant des semaines de développement et un affilié compétent devient une dépense négligeable et reproductible à volonté. La barrière à l’entrée ne baisse pas, elle disparaît.
Génération dynamique et multiplateforme avec Lua
Une fois le LLM interrogé via des prompts spécifiques, celui-ci ne génère pas de lourds fichiers exécutables, mais des scripts en langage Lua. Pourquoi Lua ? Parce que c’est un langage de script extrêmement léger, conçu pour être embarqué, et dont l’interpréteur passe souvent inaperçu dans les environnements d’entreprise (très utilisé dans le gaming ou certaines applications métier).
Le prototype embarque directement son propre interpréteur Lua et exécute le bytecode en mémoire, sans jamais écrire le script sur le disque : il ne laisse donc aucun artefact exploitable en analyse forensique classique. L’IA dote ce script d’une capacité de reconnaissance avancée. Avant de frapper, le script analyse son environnement (architecture processeur, arborescence des fichiers, privilèges actuels) et adapte dynamiquement ses commandes pour frapper indifféremment des cibles sous Windows, Linux ou macOS. C’est cette adaptabilité contextuelle qui rend la menace particulièrement redoutable pour les parcs hétérogènes.
La phase finale : chiffrement et extorsion
L’orchestration globale de l’attaque est maintenue par un « lanceur » (stager) écrit en langage Go (Golang), réputé pour sa facilité de cross-compilation. C’est ce lanceur qui va piloter l’exécution des scripts Lua et déclencher la phase de destruction. Pour la note de rançon, l’IA est de nouveau mise à contribution : elle génère à la volée un texte d’extorsion unique, personnalisé selon ce que la phase de reconnaissance a trouvé sur la machine, ce qui augmente la pression psychologique sur la victime. Dans le prototype, l’adresse Bitcoin est en revanche codée en dur, et c’est celle attribuée à Satoshi Nakamoto : un clin d’oeil de chercheurs, et l’un des indices qui ont permis de conclure au PoC. Notez enfin que les routines de destruction de fichiers sont présentes dans le code mais non implémentées, ce qui confirme le caractère inachevé de la démonstration.
L’outil est neutre, c’est l’usage qui le rend destructeur. PromptLock nous prouve que les LLM locaux, initialement conçus pour booster la productivité des développeurs, peuvent être militarisés en quelques secondes.
Focus Algorithme : Pourquoi le chiffrement SPECK 128 bits ?
Le choix de l’algorithme de chiffrement est loin d’être anodin. Développé par la NSA, SPECK est un algorithme de chiffrement par blocs dit « léger » (lightweight cryptography). Contrairement à l’AES (Advanced Encryption Standard) couramment utilisé, SPECK est optimisé de manière agressive pour les processeurs disposant de très peu de ressources.
Son utilisation par PromptLock démontre une volonté stratégique claire : chiffrer les données à une vitesse fulgurante, même sur des machines cibles peu performantes (comme des capteurs IoT ou de vieux serveurs d’entreprise). Cette vélocité réduit drastiquement le « Time-to-Encrypt », limitant mécaniquement le temps d’intervention des équipes de sécurité avant que les dégâts ne soient irréversibles.
Pourquoi les défenses traditionnelles (Antivirus, EDR) sont-elles mises en échec ?
L’apparition des ransomwares générés par IA expose de manière crue les failles structurelles de nos modèles de protection actuels, qui demeurent majoritairement réactifs. Comme je l’explique souvent lors de mes audits, si votre sécurité repose uniquement sur la connaissance des menaces passées, vous êtes structurellement vulnérable aux menaces de demain.
L’aveuglement comportemental et la vitesse d’exécution
Le premier obstacle est l’obsolescence immédiate de la détection par signature. Face à un code généré dynamiquement en RAM et unique à chaque exécution (polymorphisme extrême), l’antivirus classique cherche une aiguille qui change de forme toutes les millisecondes. Pire encore, les solutions EDR (Endpoint Detection and Response) souffrent ici d’un aveuglement comportemental. L’action initiale (l’appel à l’API locale d’Ollama via http://localhost:11434/api/generate) semble parfaitement légitime dans un environnement de développement.
Ensuite se pose le problème de la vitesse. L’automatisation locale de l’ensemble de la chaîne d’attaque (reconnaissance, création de l’arme, exécution du chiffrement SPECK) s’effectue en quelques secondes. C’est infiniment plus rapide que le temps de tri, de corrélation et d’analyse d’une alerte par un analyste SOC humain, même assisté par les outils EDR et XDR de nouvelle génération.
Enfin, PromptLock met en lumière le danger critique du « Shadow AI ». Le manque de visibilité des DSI sur les outils d’intelligence artificielle installés localement (et parfois discrètement) par les collaborateurs crée des vecteurs d’attaque dormants que ce malware exploite à la perfection.
Checklist de sécurité : SOC & SIEM, 4 IOCs comportementaux à surveiller
Puisque la signature statique est inutile, la défense doit se porter sur la détection des comportements anormaux au sein du système. Voici les 4 Indicateurs de Compromission (IOCs) comportementaux à intégrer urgemment dans vos règles SIEM :
- ✓ Trafic vers une API d’inférence, locale ou distante : Détecter les requêtes répétées sur
localhost:11434(le port par défaut d’Ollama) provenant de processus inhabituels, mais aussi les appels sortants vers des endpoints compatibles OpenAI (/api/generate,/v1/chat/completions) depuis des postes qui n’ont aucune raison métier d’en émettre. - ✓ Présence non autorisée de LLM : Tracer l’installation ou l’exécution de composants liés à des LLMs locaux ou de l’exécutable Ollama sur des postes qui n’appartiennent pas au département R&D/Développement.
- ✓ Exécutions d’interpréteurs inhabituels : Surveiller l’exécution soudaine de scripts Lua (
.lua) ou Python créant, lisant ou modifiant massivement des fichiers en peu de temps. - ✓ Pics de ressources incohérents : Une activité CPU/RAM inhabituellement élevée liée à des processus locaux d’IA, immédiatement suivie d’une activité d’I/O disque intensif (caractéristique d’une phase de chiffrement).
Plan d’action : comment adapter votre infrastructure face aux menaces IA
Puisque PromptLock n’est, pour le moment, qu’un PoC entre les mains de chercheurs, les entreprises disposent d’une courte fenêtre de tir pour moderniser leur posture de sécurité. Il est impératif d’anticiper la professionnalisation de cette attaque. Voici les axes prioritaires que je recommande de déployer sans attendre.
Contrôle technique et monitoring des environnements
La première urgence est de reprendre le contrôle sur les environnements d’exécution locaux. Vous devez restreindre strictement l’exécution d’outils comme Ollama, LM Studio ou GPT4All aux seuls postes de développement, et s’assurer que ces postes sont correctement isolés du reste du réseau d’entreprise. Mettez en place une surveillance spécifique via votre EDR pour alerter sur toute tentative de liaison sur les ports locaux utilisés par ces API (comme le port 11434) par des processus parents non reconnus.
Gouvernance et politique « Zero Trust » pour l’IA
Le risque technologique est exacerbé par un déficit de gouvernance. Il est indispensable de cartographier les usages d’IA en entreprise pour endiguer le Shadow AI. Une gouvernance efficace passe par la mise à disposition de solutions centralisées, monitorées et validées par la DSI, plutôt que par une interdiction qui pousse les équipes à contourner. En parallèle, l’application stricte du principe du moindre privilège limitera drastiquement la capacité de propagation d’un script malveillant généré localement si un poste venait à être compromis. Pour les entités concernées, cette exigence recoupe directement les obligations de gestion des risques posées par la directive NIS 2, et l’unification de la visibilité sur les environnements cloud relève de la même logique que celle des plateformes CNAPP.
Résilience ultime : repenser la stratégie de sauvegarde
Face à un malware capable de déjouer les protections proactives avec une telle vélocité, la résilience de vos données devient votre ultime filet de sécurité. L’importance vitale des stratégies de sauvegarde immuable et isolées du réseau principal (air-gap) n’a jamais été aussi critique. La règle 3-2-1-1-0 reste la référence : trois copies, deux supports, une copie hors site, une copie immuable ou hors ligne, zéro erreur de restauration vérifiée par un test.
Je préconise également de privilégier les plateformes de sauvegarde qui embarquent une détection d’anomalie de chiffrement sur les flux entrants : Veeam, Rubrik, Druva et Commvault proposent tous une fonction de ce type dans leurs offres actuelles. Le principe est le même partout : mesurer l’entropie et le taux de variation des blocs sauvegardés, et lever une alerte quand une altération massive apparaît, typiquement ce que produirait un chiffrement SPECK sur un volume entier. Le système isole alors les snapshots suspects avant qu’ils ne contaminent les archives saines. Un point d’attention, en revanche, que les fiches produit passent sous silence : cette détection intervient après le chiffrement, au moment de la sauvegarde. Elle protège votre capacité à restaurer, elle n’empêche pas l’incident.
Conclusion
PromptLock n’est pas un simple malware de plus à ajouter à une base de données virale ; c’est un signal d’alarme. L’intégration de l’intelligence artificielle locale dans la chaîne de conception d’une attaque rend caduques de nombreuses certitudes en matière de détection. La fenêtre de tir dont disposent les entreprises pour adapter leur supervision (monitoring des API locales) et renforcer leur résilience (Zero Trust, backups immuables) est étroite. Ne subissez pas cette évolution technologique : anticipez-la en cartographiant dès aujourd’hui vos vulnérabilités liées au Shadow AI.
Vos outils EDR/XDR actuels intègrent-ils des heuristiques capables de détecter le détournement d’une IA locale légitime ? Comment gérez-vous le ‘Shadow AI’ au sein de votre parc informatique ?
