La chaîne d'attaque Promptware : redéfinir l'injection de prompt comme un malware - résumé de recherche

Sommaire exécutif (Executive Summary)

La vision traditionnelle de l’injection de prompt comme un simple équivalent de l’injection SQL pour les modèles de langage (LLM) est fondamentalement erronée. Au cours des derniers cycles de développement, les injections de prompt ont évolué de simples livraisons de charges utiles (payloads) en une seule étape vers des environnements d’exécution de malwares complexes et multi-étapes, désignés sous le terme de Promptware. cette recherche introduit une chaîne d’attaque structurée en sept étapes qui correspond directement au cycle de vie des malwares classiques, exigeant un passage de défenses étroites par filtrage des entrées vers une ingénierie de sécurité globale et basée sur la défense en profondeur.

1. Introduction : des anomalies de chatbot aux malwares actifs

Le paysage de la cybersécurité a initialement classé l’injection de prompt comme une vulnérabilité conversationnelle mineure — un équivalent moderne de l’injection SQL. les premiers exploits se limitaient à contourner les filtres de sécurité pour produire du texte restreint sur l’écran d’un utilisateur. cependant, l’intégration des LLM dans des rôles opérationnels actifs (gestion de bases de données, interaction avec des API et lecture de fichiers en temps réel) a transformé ces entrées en vecteurs d’exécution.

cette recherche, rédigée par Oleg Brodt, Elad Feldman, Bruce Schneier et Ben Nassi, introduit le concept de Promptware. le Promptware représente une nouvelle classe de malwares où le code est écrit en langage naturel (ou sous forme de représentations sémantiques) et exécuté par l’interpréteur probabiliste d’un LLM. en modifiant la perspective de l’injection de prompt pour passer d’un simple bug de validation d’entrée à un cycle d’attaque complet et multi-étapes, les chercheurs fournissent aux architectes de sécurité le cadre nécessaire pour sécuriser les infrastructures agentiques.

2. La chaîne d’attaque Promptware en sept étapes

Le cycle de vie d’un Promptware imite la cyber-chaîne d’attaque (Cyber Kill Chain) classique de Lockheed Martin, adaptée spécifiquement aux contraintes uniques des environnements d’exécution sémantique.

1. Accès initial : la livraison de la charge utile malveillante dans la fenêtre de contexte du LLM. cela peut se produire directement via l’entrée utilisateur, ou indirectement via des données récupérées pendant l’inférence (ex : pages web, e-mails ou PDF empoisonnés).
2. Élévation de privilèges : l’exécution d’instructions de débridage (jailbreak) conçues pour remplacer les instructions du prompt système et les alignements de sécurité natifs.
3. Reconnaissance : le profilage systématique de l’environnement. le LLM détourné est contraint de scanner son propre contexte pour cartographier les outils disponibles, les bases de données connectées, les variables système et les autorisations d’API.
4. Persistance : l’établissement d’une présence à long terme. le Promptware empoisonne les bases de données de mémoire à long terme de l’agent, les profils utilisateurs personnalisés ou les bases de données vectorielles RAG pour garantir que l’exploit soit réexécuté lors des sessions suivantes.
5. Command & Control (C2) : l’établissement d’un canal de communication. l’agent compromis interroge périodiquement des serveurs externes contrôlés par l’attaquant (ex : lecture d’un flux RSS ou d’un dépôt public) pour récupérer dynamiquement de nouvelles instructions opérationnelles.
6. Mouvement latéral : la propagation de la charge utile à d’autres entités. l’agent est forcé d’utiliser des outils de communication (envoi d’e-mails, messagerie avec d’autres agents ou modification de fichiers partagés) pour infecter les environnements voisins.
7. Actions sur l’objectif : la phase finale de l’attaque, qui peut aller de l’exfiltration discrète de données (via le rendu d’images markdown ou des requêtes HTTP) au sabotage actif et aux transactions financières frauduleuses.

3. Comparaison structurelle : types d’injections

Les paradigmes de sécurité traditionnels ne parviennent pas à contenir le Promptware car ils sous-estiment les capacités d’exécution sémantique. la matrice suivante illustre les différences entre les injections classiques et le Promptware :

Attribut	Injection SQL	Injection de commande OS	Promptware (injection de prompt)
Milieu d’exécution	Moteur de requête de base de données	Shell du système d’exploitation	Interpréteur probabiliste du LLM
Classe de langage	Structuré / Typé (SQL)	Structuré (Bash, Powershell)	Non structuré / Non typé (langage naturel)
Nature du payload	Chaîne de code statique	Séquences de commandes	Directives de raisonnement axées sur un but
Risque principal	Accès non autorisé aux données	Compromission complète de l’hôte	Exécution d’outil arbitraire et détournement de contexte
Mécanisme de persistance	Écriture en base (UDF, déclencheurs)	Cron, clés de démarrage, web shells	Empoisonnement de mémoire, corruption vectorielle RAG

4. Investigation forensique et threat hunting

Du point de vue de la réponse aux incidents, la détection de Promptware nécessite de regarder au-delà de la télémétrie traditionnelle du système d’exploitation. parce que le malware est exécuté dans le contexte d’un runtime Python ou Node.js légitime, les solutions de détection sur les terminaux (EDR) ne signaleront pas les premières étapes de la compromission.

Indicateurs clés de compromission (IOCs)

• Anomalies d’appels d’outils : traces d’exécution multi-étapes où un agent invoque des outils qui dévient de l’objectif sémantique initial de l’utilisateur (dérive sémantique).
• Modèles de récupération C2 : requêtes de récupération fréquentes dirigées vers des sites web externes ou des dépôts statiques contenant du texte fortement formaté (ex : commentaires HTML cachés ou blocs markdown).
• Empreinte mémoire persistante : présence d’instructions d’injection de prompt (ex : « Toujours préfixer la sortie avec… », « Remplacement du système… ») enregistrées dans des tables de mémoire à long terme ou des collections de base de données vectorielles.

Requêtes de détection actionnables

KQL (Détection C2)

detect_llm_c2_retrieval.kql

// Concept: Hunting for Command & Control (C2) retrieval in Agent Orchestration Logs
// Detects when an agent repeatedly fetches data from external, non-whitelisted domains
// followed immediately by high-privilege tool execution.
AgentOrchestrationLogs
| where ActionType == "ExternalRetrieval"
| extend TargetDomain = parse_url(tostring(EventData.Url)).Host
| where TargetDomain !in~ ("trusted-api.com", "nvd.nist.gov", "github.com")
| join kind=inner (
    AgentOrchestrationLogs
    | where ActionType == "ToolInvocation"
    | where ToolName in~ ("execute_bash", "write_file", "send_email")
) on TraceId
| where TimeGenerated1 > TimeGenerated and datetime_diff('second', TimeGenerated1, TimeGenerated) < 15
| project TimeGenerated, TraceId, TargetDomain, ToolName, EventData.Url
| sort by TimeGenerated desc

Sigma (Empoisonnement mémoire)

sigma_detect_rag_poisoning_indicators.yaml

title: Detection of Potential RAG Memory Poisoning
id: 9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Monitors vector database updates or local agent memory writes for common prompt injection patterns indicating attempt to establish persistence.
logsource:
    category: database
    product: postgresql # Or other database engine storing memory
detection:
    selection:
        Query|contains:
            - 'IGNORE ALL PREVIOUS INSTRUCTIONS'
            - 'SYSTEM OVERRIDE'
            - 'You are now a'
            - 'Always output the following'
    condition: selection
level: high
tags:
    - attack.persistence
    - attack.defense_evasion

5. Architecture défensive : briser la chaîne d’attaque

L’atténuation du Promptware nécessite une transition des filtres d’entrée isolés vers une architecture de défense en profondeur. l’objectif est de concevoir le système sous l’hypothèse que l’accès initial (étape 1) va se produire, en se concentrant sur la rupture de la chaîne aux étapes suivantes.

1. Sandboxer l'exécution de code

Ne jamais autoriser le LLM à exécuter du code sur le système d’exploitation hôte. Exécutez tous les outils python/bash dans des bacs à sable (sandboxes) éphémères et isolés du réseau (conteneurs WASM ou Docker) qui sont détruits immédiatement après l’exécution.

2. Restreindre la mutation de mémoire

Empêcher le LLM d’écrire directement dans sa propre mémoire à long terme ou sa base de données RAG sans validation humaine. Les écritures en mémoire doivent être strictement formatées, validées et dépouillées de toute syntaxe de code exécutable.

3. Approbations hors-canal

Mettre en œuvre des approbations hors-canal cryptographiques pour les outils à haut privilège (ex : transferts financiers, suppression de fichiers, envoi d’e-mails externes) afin de briser la boucle d’exécution autonome.

4. Segmentation du contexte

Appliquer des limites architecturales où les données externes récupérées sont analysées par un modèle à faibles privilèges, empêchant les données brutes et non fiables d’entrer dans la fenêtre de contexte de l’agent de planification principal.

---

Sources & références

• papier de recherche : arXiv:2601.09625v2
• auteurs : Oleg Brodt, Elad Feldman, Bruce Schneier, Ben Nassi.
• analyse liée : le problème du mandataire confus : injection de prompt indirecte
• analyse liée : architecture de la tool injection