En septembre 2026, le Google Threat Intelligence Group a signalé un cas dans lequel un pirate avait utilisé un workflow basé sur l’IA pour planifier, mettre en place et mener à bien une collecte massive d’identifiants en moins de six heures après avoir obtenu un accès de type « cloud ». Il s’agissait là d’une campagne observée, et non d’une durée d’attaque typique. Cela illustre la préoccupation opérationnelle que suscitent les attaques de type « malware » basées sur l’IA: l’IA peut raccourcir certaines étapes du cycle d’attaque, même lorsque la compromission sous-jacente repose toujours sur des failles bien connues.
Les attaques par « IA malware » sont des intrusions dans lesquelles un attaquant utilise l’IA pour concevoir, modifier, diffuser ou exploiter des logiciels malveillants. Ce terme recouvre différents niveaux d’implication de l’IA. Un développeur peut utiliser un modèle pour écrire du code, tandis qu’un implant plus inhabituel peut interroger un modèle pendant son exécution afin de décider de la suite des opérations. Il s’agit là de menaces distinctes, présentant des indices et nécessitant des défenses différentes. Ce guide les distingue, examine des cas documentés et propose aux équipes de sécurité une approche pratique pour les détecter et y répondre.
La question pertinente est de savoir à quel stade de la chaîne d'attaque l'IA intervient. Malware ne devient pas un nouveau type de technique simplement parce qu'un modèle a contribué à son écriture. L'impact sur la sécurité dépend de ce que fait le code, de ce que contrôle l'attaquant et du fait que le modèle reste ou non impliqué après le déploiement.
Ces catégories peuvent se recouper. Il ne faut pas non plus les confondre avec la détection des menaces par l'IA, qui relève d'une utilisation défensive de l'IA, ni avec les attaques visant une application d'IA, comme celles décrites sur prompt injection. Pour une définition générale et une taxonomie, consultez le guide «malware ».
L'expression « généré par l'IA » donne des indications sur l'origine du développement. Le terme « autonome » en dit long sur le contrôle opérationnel. Aucun de ces deux termes, pris isolément, ne permet de déterminer si une attaque a abouti. Un programme de vol de données écrit à partir d'un modèle peut fonctionner entièrement à partir d'instructions fixes. À l'inverse, un programme relativement petit peut déléguer une tâche spécifique, telle que la navigation dans une interface, à un modèle lors de l'exécution.
MITRE ATT&CK décrit le code polymorphe comme un logiciel qui modifie son empreinte d'exécution tout en conservant son objectif. Les moteurs de mutation existaient déjà avant l'apparition des grands modèles linguistiques. L'IA peut accélérer la variation du code ou sélectionner des variantes, mais un hachage variable ne constitue pas une preuve que l'IA ait généré l'échantillon.
Le modèle de menace le plus solide repose sur des étapes concrètes plutôt que sur l'affirmation selon laquelle toutes les attaques seraient entièrement automatisées. Les recherches actuelles mettent en évidence le recours à l'IA pour le développement, l'obfuscation et les décisions opérationnelles, avec différents niveaux de maturité et de visibilité.
Un attaquant peut utiliser un modèle de codage pour concevoir des composants, expliquer des erreurs, porter du code d’un langage à un autre, écrire une logique de leurre ou automatiser des tests. Dans son analyse de mai 2026, le Google Threat Intelligence Group a décrit CANFAIL et LONGSTREAM, deux familles d’ malware s utilisées dans le cadre d’activités ciblant des organisations ukrainiennes. Les chercheurs ont découvert du code qu’ils ont évalué comme étant du code de remplissage généré par un modèle, conçu pour masquer des fonctions malveillantes. Dans LONGSTREAM, ils ont identifié 32 requêtes inactives concernant le statut de l’heure d’été, ce qui constitue un exemple de volume de code d’apparence inoffensive plutôt qu’un nouvel objectif d’attaque. Ces 32 instances décrivent une famille de code analysée, et non une mesure de prévalence.
Pour les défenseurs, la question qui se pose immédiatement est de savoir si un fichier binaire ou un script malveillant peut s'exécuter, s'implanter durablement, voler des identifiants ou communiquer avec l'extérieur. Le fait que l'IA soit à l'origine de ces actions peut compliquer l'attribution de la responsabilité, mais cela n'élimine pas ces comportements.
L'IA peut aider à réécrire du code, à ajouter des branches inactives et à modifier le formatage afin de contrecarrer la détection statique. Le groupe Google Threat Intelligence a décrit PROMPTFLUX, un dropper expérimental en VBScript conçu pour interroger un modèle en vue de son auto-modification. L'analyse de Google a explicitement indiqué que la version observée était en cours de développement ou de test et ne démontrait pas la capacité de compromettre un appareil ou un réseau. Il s'agit d'une preuve d'une méthode en cours d'expérimentation, et non d'une preuve d'une utilisation répandue et réussie.
Les hachages et les signatures de fichiers statiques restent utiles pour les échantillons connus. Associez-les aux données de télémétrie relatives aux processus, à la mémoire, à l'identité et au réseau afin qu'une modification de l'apparence d'un fichier ne devienne pas un angle mort.
Certaines « malware s » intègrent un service d’IA dans leur workflow d’exécution. Google a indiqué que PROMPTSTEAL, utilisé contre l’Ukraine, interrogeait un modèle via une API afin de générer des commandes permettant de collecter des informations système et des documents. L’ malware exécutait ces commandes et envoyait les données collectées vers l’infrastructure des attaquants. Google a qualifié cela de première observation d’une « malware » interrogeant un modèle dans le cadre d’opérations en temps réel. Il s’agit d’une preuve opérationnelle plus solide que l’échantillon expérimental PROMPTFLUX, mais cela ne permet pas pour autant d’établir que ce type d’ malware est courant.
Dans son analyse de mai 2026, Google a décrit PROMPTSPY, une porte dérobée Android qui utilisait un modèle pour interpréter l'état de l'interface et renvoyer des actions permettant la navigation sur l'appareil. Il s'agit d'un exemple spécifique à cet appareil. Ses mécanismes d'accessibilité Android et de persistance des applications ne doivent pas être généralisés aux environnements d'malware d'entreprise sous Windows ou Linux.
L’IA peut également intervenir en dehors de l’ malware. Un opérateur humain peut utiliser des agents pour hiérarchiser les cibles, déboguer des outils ou gérer les analyses et la collecte d’identifiants. L’affaire Google de septembre 2026 concernait une campagne menée à l’aide d’agents et menée à bien en moins de six heures. Cette rapidité est importante, car elle permet de réduire le temps d’attente lié aux décisions manuelles des opérateurs. Cette affaire ne prouve pas que toutes les intrusions assistées par l’IA soient plus rapides, ni que l’ malware ait pris toutes les décisions à elle seule.
Le passage de l'aide à la programmation à l'utilisation d'un modèle d'exécution est avéré dans certains cas documentés, mais il ne faut pas confondre ces exemples avec une prévalence générale. Les preuves sont d'autant plus solides que les chercheurs peuvent examiner des échantillons, des artefacts de développement ou des données télémétriques relatives aux incidents, et décrire ce qui a été réellement observé.
La tendance observée sur le terrain est un champ d’application plus large de l’IA, allant de l’aide au développement à l’appel de modèles lors de l’exécution. Cela facilite la détection des modifications apportées au code et accélère les flux de travail. Cela ne justifie toutefois pas l’affirmation générale selon laquelle l’ malware e serait désormais autonome, que les signatures seraient inutiles ou que la plupart des infections seraient générées par l’IA. Le résumé du rapport « M-Trends 2026 » de Google soulignait d’ailleurs que la grande majorité des intrusions réussies qu’il avait observées restaient imputables à des défaillances humaines et systémiques bien connues.
Même un implant inédit doit pouvoir accéder au système, s'exécuter et produire des effets. Les défenseurs peuvent organiser leur analyse autour de ces étapes observables sans s'appuyer sur un seul nom de famille « malware ».
1. Intrusion et exécution. Une pièce jointe malveillante, un paquet compromis, un service exposé ou des identifiants volés permettent à l'attaquant de s'introduire dans le système. Déterminez ce qui a été exécuté, sous quelle identité et sur quelle ressource.
2. Détection et adaptation. Le code ou l’opérateur recense les logiciels, les contrôles de sécurité, les fichiers ou les services d’ cloud . L’IA peut aider à interpréter ces observations, mais toute détection inhabituelle reste perceptible.
3. Persistance et privilèges. Les tâches planifiées, les modifications apportées aux services, l'utilisation de jetons ou l'octroi non autorisé de privilèges élargissent les possibilités d'accès. Vérifiez si une modification est autorisée avant de la considérer comme malveillante.
4. Mouvements et commandes. Surveillez les nouvelles sessions à distance, les chemins d'accès inhabituels, les appels sortants vers des modèles ou des API, ainsi que le trafic de commande et de contrôle. Une simple requête vers une API de modèle ne constitue pas à elle seule une preuve de compromission ; il faut la replacer dans le contexte du processus et des actions qui ont suivi.
5. Collecte et impact. L'accès aux fichiers, la collecte d'identifiants, la préparation des données, l'exfiltration, le chiffrement ou la perturbation des services révèlent l'objectif visé. Conservez les horodatages et les relations entre les entités afin de pouvoir reconstituer la séquence des événements.
Cette approche par étapes s'avère particulièrement utile lorsque la charge utile change de forme. Elle permet également à l'équipe de rester concentrée sur l'impact si l'origine de l'IA reste incertaine.
La détection doit associer des contrôles basés sur desmalware s connues à l’analyse des comportements sur l’ensemble des terminaux, des identités, des réseaux et des services d’ cloud . L’objectif est de confirmer l’existence d’une chaîne d’attaque, et non de qualifier systématiquement tout processus inconnu d’« malware par l’IA ».
Maintenez la protection contre l endpoint , l'application des correctifs, les vérifications de la provenance des logiciels et la comparaison avec des indicateurs connus. Les échantillons et variantes connus peuvent toujours être bloqués. Ajoutez l'historique des processus, la télémétrie des scripts et de la mémoire, ainsi que des contrôles de politique d'exécution pour les techniques qui contournent la simple comparaison de fichiers. L'entrée « code polymorphe » de MITRE recommande explicitement d'utiliser des méthodes basées sur le comportement en complément des contrôles anti-malware.
Examinez les combinaisons telles qu’un processus récemment lancé lisant des magasins d’identifiants, contactant un service externe inconnu, initiant un accès à distance et préparant des données. Reliez l’hôte au compte qu’il a utilisé et aux actions « cloud » ou SaaS qui ont suivi. Le contexte réseau et d’identité peut révéler la progression lorsqu’un hachage de fichier change ou qu’un agent d’ endpoint s manque de visibilité. Le cas d’utilisation de détection des failles EDR de Vectra AI décrit cette visibilité complémentaire ; les équipes doivent valider la couverture réelle dans leur environnement.
Dans la mesure où la politique le permet, enregistrez le processus appelant, la destination, le compte, l'heure, le volume de requêtes et les commandes en aval pour les services d'IA d'entreprise. Un outil de développement légitime peut générer un trafic similaire. Signalez tout incident lorsqu'un processus suspect effectue des appels vers des modèles, puis exécute les commandes générées, modifie la persistance ou accède à des données sensibles. Évitez de collecter des invites ou des charges utiles au-delà des politiques approuvées en matière de confidentialité et de conservation des données.
Si les journaux d'utilisation du modèle ne sont pas disponibles, précisez que l'implication de l'IA n'est pas confirmée. La réponse peut néanmoins être élaborée à partir du comportement malveillant observé.
Les contrôles les plus utiles limitent les actions qu'un « malware » ou un opérateur assisté par l'IA peut effectuer après avoir pénétré dans le système. Privilégiez l'accès basé sur l'identité, les chemins d'exécution, les sorties et la vitesse de réponse, parallèlement à la prévention.
1. Réduisez l'exposition. Appliquez les correctifs aux services vulnérables, limitez l'utilisation des paquets et scripts non fiables, vérifiez les autorisations des outils de développement et protégez les clés API ainsi que les identifiants des agents. Appliquez le principe du « privilège minimal » aux identités « cloud » et SaaS.
2. Mettre en place un suivi du parcours de l'attaque. Conserver les journaux relatifs à l'endpoint, au réseau, à l'identité, à l'cloud ainsi que ceux des services d'IA concernés, en veillant à ce que leur horodatage soit synchronisé. Définir qui est habilité à consulter les preuves d'utilisation des modèles et déterminer la durée de conservation de ces données.
3. Tester les détections basées sur le comportement. Simuler la découverte d'entités autorisées, l'accès aux identifiants, l'exécution à distance et la préparation des données. Vérifier si l'équipe est capable de relier des événements pour former un incident unique sans s'appuyer sur un hachage connu.
4. Contenir la chaîne d'infection observée. Isoler les hôtes affectés le cas échéant, révoquer les sessions actives et les jetons exposés, bloquer les destinations malveillantes confirmées et préserver les preuves techniques avant de procéder à un nettoyage à grande échelle.
5. Récupération et apprentissage. Rétablissez le système à partir de sources fiables, vérifiez que les traces de l’attaque ont bien été supprimées, renouvelez les identifiants concernés et comparez la chronologie des événements avec les horodatages de détection et de confinement. Mettez à jour les guides d’intervention pour toute étape manquée concernant l’identité, le réseau ou l’ cloud .
Une évaluation utile pose la question suivante : l'équipe serait-elle capable d'identifier suffisamment rapidement l'identité compromise, les ressources affectées et la prochaine action de l'attaquant pour pouvoir intervenir ? Enregistrez séparément le temps de détection, le temps d'investigation et le temps de confinement. Un exercice contrôlé permet de tester cette hypothèse sans se baser sur l'efficacité d'un fournisseur en particulier.
Vectra AISon positionnement en matière de sécurité et d’observabilité « natives à l’IA » s’avère pertinent lorsqu’une attaque se propage entre des identités, des réseaux, des services d’ cloud s et des terminaux. Son cas d’utilisation de détection des failles via l’EDR décrit une visibilité comportementale allant au-delà des terminaux gérés. Pour les enquêtes d’ malware basées sur l’IA, il convient d’évaluer si les signaux disponibles aident les analystes à établir un lien entre l’utilisation abusive d’identifiants, les mouvements latéraux et l’exfiltration, d’une part, et une intrusion en cours, d’autre part. L’adéquation du produit et les mesures de réponse dépendent du déploiement, des intégrations et des autorisations ; il convient donc de les vérifier dans le cadre d’une démonstration de valeur.
Si vous procédez à une cartographie de vos contrôles, commencez par consulter les principes fondamentaux de l'malware et le guide de détection des menaces par l'IA. Les équipes qui évaluent les lacunes au-delà des données télémétriques d'endpoint peuvent consulter le cas d'utilisation de détection des lacunes EDR. Pour une discussion spécifique à votre déploiement à l'issue de cette évaluation, demandez une démonstration d'Vectra AI .
Note sur la source et la méthodologie : Ce guide de recherche a été vérifié le 22 octobre 2026 à la lumière des rapports originaux des enquêteurs et du site MITRE ATT&CK. Les cas présentés ne constituent ni une enquête d'incidence ni un test indépendant de produit.
L'IA peut générer une quantité importante de code et contribuer à l'automatisation des tests, mais les exemples documentés impliquent toujours des décisions humaines en matière d'objectifs, d'accès, d'outils et de déploiement. Pour affirmer qu'une « malware » est entièrement autonome, il faut apporter la preuve que le système a sélectionné et exécuté ces actions au cours d'une opération réelle ou d'un test clairement identifié comme tel.
La détection statique peut s'avérer plus difficile lorsque l'IA contribue à faire varier le code ou le conditionnement. La détection dépend de la technique utilisée et des données de télémétrie disponibles. Les contrôles basés sur des échantillons connus, le comportement de l'endpoint , les événements d'identité, l'activité réseau et les journaux d'cloud s restent utiles lorsqu'ils sont utilisés conjointement.
Non. De nombreuses applications légitimes effectuent des appels vers des modèles. Les enquêteurs doivent établir un lien entre l’appel, le processus, le compte, l’action générée et le comportement qui en résulte avant de conclure qu’ malware a utilisé le service.
L'malware e polymorphe modifie son code ou son empreinte d'exécution tout en conservant le même objectif. Elle ne nécessite pas d'IA. L'malware e de l'IA décrit le rôle de l'IA dans le développement ou l'exploitation ; un exemple d'application utilisant l'IA peut également être polymorphe, mais ces catégories ne sont pas synonymes.
Procéder au triage de l'intrusion constatée : identifier le système et l'utilisateur concernés, préserver les preuves relatives aux processus et au réseau, évaluer l'accès aux identifiants et aux données, et contenir l'activité confirmée. Déterminer si l'IA a été impliquée une fois la réponse immédiate engagée ; cette étape ne doit pas retarder la mise en place des mesures de confinement.