Quand les ransomwares s’attaquent aux actifs critiques de l’IA

Le rançongiciel IA fait de la reprise un risque de premier ordre

Le même serveur Langflow exposé sur internet a été compromis deux fois en juillet 2026, mais la seconde intrusion a changé ce que peut coûter un incident de rançongiciel visant une infrastructure IA. L’équipe Threat Research de Sysdig a documenté la première campagne le 1er juillet et la seconde le 20 juillet. Les deux sont passées par la même vulnérabilité connue de Langflow. En moins de trois semaines, toutefois, l’attaquant est passé d’un chiffrement improvisé basé sur Python à un locker compilé conçu autour des modèles entraînés et d’autres artefacts IA.

Cette évolution est importante parce que la charge utile la plus récente ciblait délibérément des actifs dont la reconstruction peut être coûteuse, voire impossible, par une restauration ordinaire. Michael Clark, qui dirige l’équipe de recherche sur les menaces de Sysdig, a décrit la cible comme « la seule chose qu’une organisation ne peut pas simplement restaurer ». L’attaquant que Sysdig suit sous le nom de JADEPUFFER n’a eu besoin d’aucune nouvelle technique d’intrusion pour y parvenir. Des faiblesses bien connues ont suffi à déployer un rançongiciel conçu pour les systèmes IA rattachés à un framework exposé.

Ces actifs ciblés changent l’hypothèse de reprise, car une restauration classique peut récupérer des données connues, tandis que les artefacts entraînés incarnent aussi du calcul et du travail d’ingénierie. Les poids de modèle, checkpoints, adaptateurs, index vectoriels et jeux de données d’entraînement impliquent des coûts de reprise différents, car une partie de leur valeur provient d’un travail d’entraînement qu’un simple snapshot de stockage ne peut pas recréer. Le cas JADEPUFFER montre à quelle vitesse la compromission d’une application ordinaire peut devenir une destruction délibérée de ces actifs.

ENCFORGE a été conçu pour rendre les actifs IA inutilisables

La première compromission montrait déjà un comportement destructeur, même si sa technique était relativement improvisée. Sysdig a constaté que JADEPUFFER avait chiffré 1 342 éléments de configuration Alibaba Nacos à l’aide de la propre fonction de chiffrement de MySQL, puis supprimé les tables. Lorsque l’attaquant est revenu sur le même serveur Langflow, Sysdig a constaté que la charge utile était ENCFORGE, un programme Go compilé qui recherchait environ 180 extensions de fichiers. Sa sélection rend concret l’objectif spécifique à l’IA.

Cette sélection comprend des checkpoints PyTorch et TensorFlow, des poids Hugging Face SafeTensors, des fichiers GGUF, des index vectoriels FAISS et des données d’entraînement stockées aux formats Parquet et NumPy. GGUF sous-tend la plupart des déploiements locaux de LLM, de sorte que le chiffrement de ces fichiers peut désactiver directement des modèles déployés. L’option du programme permettant d’ajouter des formats supplémentaires utilise même comme exemple les adaptateurs LoRA, qui stockent des modifications légères de fine-tuning de modèle, ainsi que les anciens poids GGML. Ces choix montrent une connaissance délibérée des artefacts utilisés dans le développement et le déploiement de l’IA.

Le locker crée une pression par le chiffrement destructeur plutôt que par le vol de données. ENCFORGE ne contient aucun code réseau, et Sysdig n’a observé ni comportement de connexion sortante, ni site de fuite, ni portail de paiement. L’agent d’intrusion a collecté des identifiants avant l’exécution du locker, tandis qu’ENCFORGE lui-même ne dispose d’aucun mécanisme pour exfiltrer des fichiers. Les deux campagnes utilisaient la même adresse Proton Mail dans leurs notes de rançon, ce qui fait partie des éléments que Sysdig a utilisés pour les relier à JADEPUFFER.

Cette approche destructrice repose sur le fait de rendre rapidement inutilisables de gros fichiers. ENCFORGE chiffre des régions à l’intérieur des fichiers au lieu de traiter chaque octet, en utilisant AES-256-CTR avec une clé générée pour chaque exécution et encapsulée avec une clé RSA-2048 intégrée. Les familles de rançongiciels établies utilisent le chiffrement partiel parce que cela permet de neutraliser beaucoup plus vite les gros fichiers. Les poids IA et les jeux de données peuvent être volumineux, ce qui rend cette optimisation directement utile contre les fichiers sélectionnés par ENCFORGE.

La première campagne montre aussi pourquoi une demande de rançon ne garantit pas un mécanisme de reprise exploitable. Sa clé de chiffrement a été générée aléatoirement, affichée une seule fois dans la console et jamais stockée, de sorte que l’attaquant ne conservait aucune clé permettant ensuite de restaurer les données chiffrées. Le paiement ne pouvait donc pas produire de déchiffrement dans cette campagne. ENCFORGE utilise un schéma de clés différent, ce qui montre aussi que l’attaquant a modifié son implémentation entre les intrusions.

L’activité ENCFORGE observée fournit aux défenseurs des signatures pour cette implémentation. Sysdig a observé une phase active de chiffrement et publié une règle YARA, une règle fondée sur des motifs utilisée pour identifier des fichiers malveillants correspondants, ainsi que les hash des deux binaires. Aucun des deux hash n’était couvert par les antivirus lorsque Sysdig les a analysés. Sysdig vend des produits de sécurité cloud et bénéficie commercialement lorsque les organisations investissent dans la détection de ce type de menace ; sa télémétrie et ses éléments de détection doivent donc être lus en gardant cet intérêt à l’esprit.

L’avantage de l’attaquant était la vitesse

La voie d’entrée dans cet environnement a commencé avec CVE-2025-3248, une vulnérabilité d’absence d’authentification dans le point de terminaison de validation de code de Langflow. Un utilisateur pouvant y accéder pouvait faire exécuter du Python par ce point de terminaison, ce qui a valu à la vulnérabilité un score CVSS de 9,8. La CISA l’a inscrite dans le catalogue Known Exploited Vulnerabilities, ou KEV, le 5 mai 2025 ; le KEV est la liste de la CISA des vulnérabilités connues pour être exploitées dans la nature. Les agences fédérales avaient jusqu’au 26 mai pour corriger, et Langflow 1.3.0 contenait le correctif.

Au moment où JADEPUFFER est revenu en juillet 2026, cette exposition persistait depuis plus de 14 mois après l’inscription au KEV. Le même serveur avait aussi déjà été publiquement documenté comme compromis. La chronologie dissocie la vitesse d’exécution de la nouveauté de la vulnérabilité, car une faille connue depuis longtemps et corrigée fournissait toujours l’exécution de code initiale. La suite montre à quelle vitesse l’automatisation peut transformer ce point d’appui en compromission plus profonde.

Une fois l’exécution de code obtenue, l’agent d’intrusion a recherché sur l’hôte des clés cloud, des tokens API et des chaînes de connexion, puis a essayé ces identifiants contre des services internes de base de données et de cache. Au cours de ce processus, il a trouvé /var/run/docker.sock, le socket Unix par lequel les logiciels locaux peuvent contrôler Docker. L’accès au socket Docker est fonctionnellement équivalent à un accès root, car un processus qui contrôle Docker peut manipuler les conteneurs et leur relation avec l’hôte. Cette découverte a donné à l’attaquant une voie possible au-delà du conteneur Langflow.

La première tentative d’utiliser cette voie a échoué lorsque l’agent n’a pas pu télécharger le binaire du rançongiciel depuis l’infrastructure de commande et contrôle. Sysdig a observé qu’il avait alors changé d’approche et généré six scripts Python via Langflow, chaque script corrigeant un problème rencontré par le précédent. Cinq minutes et 24 secondes après le début de cette séquence, il avait produit une évasion d’hôte fonctionnelle. La vitesse venait de l’adaptation répétée de l’action suivante à l’échec précédent.

Le script final a transformé cette adaptation en exécution au niveau de l’hôte. Il a utilisé l’API Docker pour identifier l’ID de processus de l’hôte, copié le binaire du rançongiciel à travers la frontière d’espace de noms et exécuté le chiffrement. Il a ensuite compté les fichiers pour vérifier que l’opération avait réussi. Sysdig a observé la même correction rapide dans la campagne précédente sur un problème plus limité, l’agent diagnostiquant un échec de connexion et le corrigeant en 31 secondes.

Cette séquence compressée est ce que Sam Evans, alors CISO chez Clearwater Analytics, a relié à la gravité de l’incident. « En sécurité, tout est une question de dwell time », a-t-il déclaré à VentureBeat, en soutenant qu’une intrusion plus durable élargit le rayon d’impact et augmente la probabilité qu’un événement devienne significatif. L’exécution agentique, dans laquelle des agents logiciels réalisent une séquence d’actions avec une intervention humaine continue limitée, crée la pression inverse pour les défenseurs, car un attaquant peut accomplir un travail plus lourd de conséquences pendant une courte période d’accès. Un processus de réponse conçu autour de la vitesse opérationnelle humaine dispose donc de moins de temps pour interrompre la séquence.

Cette même compression crée un problème opérationnel pour les défenseurs, selon Heath Renfrow, cofondateur et CISO de Fenix24, une société de reprise après compromission. Lorsque des agents réduisent à quelques minutes des heures de travail d’opérateur, « les défenseurs perdent un temps précieux », a-t-il déclaré à Infosecurity Magazine. Cette différence affecte le patching, la détection et le confinement, car plusieurs décisions qui exigeaient autrefois qu’un opérateur inspecte un échec et tente manuellement l’action suivante peuvent désormais se produire en une seule exécution continue. Fenix24 vend des services de reprise après compromission et a donc un intérêt commercial à ce que les organisations considèrent les incidents plus rapides et la préparation à la reprise comme des risques significatifs.

Les éléments observés étayent un modèle opératoire dirigé par l’humain avec une activité automatisée après la configuration initiale. TechCrunch a rapporté le 6 juillet que la première opération dépendait encore d’une personne pour sélectionner la cible et mettre en place l’infrastructure, tandis que Sysdig n’a pas pu déterminer l’origine des identifiants root. Après cette orientation, l’activité pouvait se poursuivre sans qu’une personne travaille en continu au clavier. Les équipes de sécurité doivent donc interrompre la séquence observée, qu’elles classent ou non l’opération comme « pilotée par l’IA ».

Cette séquence dépendait aussi de faiblesses familières plus loin dans la chaîne. Lors de la première campagne, JADEPUFFER a forgé un token administrateur Nacos à l’aide d’une clé de signature par défaut publique depuis 2020. Il a exploité CVE-2021-29441, un contournement d’authentification Nacos corrigé par Alibaba en 2021, et a rencontré un object store MinIO configuré avec minioadmin:minioadmin. Sysdig a compté plus de 600 charges utiles reposant sur des erreurs de configuration connues ou des vulnérabilités pour lesquelles des correctifs existaient déjà.

La seconde campagne a ajouté le socket Docker exposé au même schéma de faiblesses. Des failles existantes, des identifiants divulgués ou faibles, des services internes et des interfaces locales puissantes pouvaient être combinés rapidement après le premier point d’appui, sans nécessiter une série de nouveaux zero-days. Cette combinaison est importante pour la priorisation des correctifs, car l’assemblage à vitesse machine augmente les conséquences de faiblesses que les organisations traitent peut-être déjà comme du backlog de routine. Une seule ancienne exposition peut devenir le point de départ de plusieurs pivots rapides.

Cette vitesse sous-tend aussi la fenêtre de patching décrite par Riemer, vice-président senior du Network Security Group et Field CISO chez Ivanti. « Si je publie un correctif et qu’un client ne l’applique pas dans les 72 heures suivant cette publication, il est exposé à l’exploitation, parce que c’est à cette vitesse qu’ils peuvent désormais le faire », a-t-il déclaré, tout en notant que la plupart des clients ont besoin d’une semaine pour patcher manuellement. Un processus opérationnel sur sept jours est déjà mal aligné avec la fenêtre d’exposition de trois jours qu’il décrit ; une instance laissée vulnérable pendant plus de 14 mois se situe bien au-delà. Ivanti vend des logiciels de sécurité et d’infrastructure et bénéficie donc commercialement lorsque les clients donnent la priorité à un patching plus rapide, ce qui constitue un contexte pertinent pour le cadrage en 72 heures de son dirigeant.

Une fois les identifiants disponibles, cette même séquence réduit aussi la protection fournie par la frontière externe. Riemer a décrit des attaquants obtenant un accès qui fonctionne comme une « clé de maison » légitime après que les fournisseurs ont renforcé les voies d’entrée externes les plus évidentes. Des services présumés sûrs parce qu’« ils ne sont pas directement exposés sur internet et qu’ils se trouvent derrière une barrière de protection » peuvent malgré tout devenir accessibles via une charge de travail compromise et ses identifiants. La séquence JADEPUFFER démontre ce mécanisme : l’exécution initiale dans Langflow a conduit vers des services internes puis vers un contrôle au niveau de l’hôte.

Pourquoi un modèle IA change l’équation de la reprise

Ce contrôle au niveau de l’hôte devient un problème métier différent lorsque les fichiers chiffrés incarnent un travail d’entraînement coûteux. Restaurez une base de données à partir d’un snapshot du vendredi et l’écart direct correspond aux transactions du week-end, qui peuvent exister ailleurs sous forme d’enregistrements rejouables. Restaurez le checkpoint du vendredi d’un modèle affiné, et tout ce que le modèle a appris après vendredi est absent. Il n’existe pas de lignes transactionnelles équivalentes qui reproduisent simplement l’état ultérieur du modèle.

L’état entraîné manquant a un coût direct de reconstruction. Sysdig estime que la récupération directe d’un modèle affiné prêt pour la production peut coûter entre 75 000 et 500 000 dollars. L’estimation combine les coûts cloud de GPU sur les exécutions d’entraînement répétées nécessaires pour obtenir un résultat exploitable avec le temps d’ingénierie derrière ce travail. Cette fourchette s’applique par modèle, alors que les équipes peuvent conserver plusieurs variantes sur un stockage partagé ; un rançongiciel atteignant cet emplacement peut donc transformer la reconstruction en dépense importante de calcul et de main-d’œuvre.

Cette dépense peut augmenter lorsque les artefacts nécessaires à la reconstruction partagent le même domaine de défaillance. Lorsque le jeu de données d’entraînement et les poids du modèle résident sur le même hôte compromis, la reconstruction du modèle ne peut pas commencer tant que le jeu de données lui-même n’a pas été récupéré ou reconstruit. Les checkpoints, les poids et les données d’entraînement ont donc des relations de reprise que les équipes d’infrastructure doivent représenter explicitement. Une politique de sauvegarde qui classe les artefacts entraînés comme des sorties pouvant toujours être régénérées fait en pratique du réentraînement une partie du plan de reprise.

Une fois le réentraînement intégré au plan, son coût donne à la finance un moyen d’évaluer l’exposition. Kayne McGladrey, membre senior de l’IEEE ayant une expérience en sécurité des identités, a déclaré à VentureBeat que les entreprises « devraient se concentrer sur les risques métier plutôt que sur, vous savez, un risque de cybersécurité », parce que c’est la perte financière qui conduit les organisations à budgéter des actions et des contrôles préventifs. Une fourchette de reconstruction de 75 000 à 500 000 dollars donne à un DAF une exposition concrète à comparer au coût du stockage, de l’isolation et d’une reprise testée. Cette comparaison transforme la reprise de modèle en décision de résilience budgétisable.

La première campagne JADEPUFFER rend la récupérabilité particulièrement importante parce que sa clé de chiffrement générée aléatoirement n’a jamais été conservée. La reprise dans cet incident ne pouvait pas dépendre du paiement pour obtenir un outil de déchiffrement ; l’organisation avait donc besoin d’une autre voie vers les données chiffrées. Lorsque les artefacts entraînés ont des coûts de remplacement significatifs, leur récupérabilité doit être conçue avant l’incident. La question de planification est de savoir quel état entraîné l’organisation doit pouvoir restaurer et quelles entrées cette restauration exige.

Les recommandations de sécurité IA mettent l’accent sur l’intégrité, tandis que le rançongiciel ajoute la disponibilité

Les recommandations existantes en matière de sécurité de l’IA traitent déjà la protection des données comme un problème sérieux, et ENCFORGE ajoute une question de reprise autour de la disponibilité. En mai 2025, le NSA Artificial Intelligence Security Center, la CISA et le FBI ont publié « AI Data Security », cosigné avec des autorités du Royaume-Uni, d’Australie et de Nouvelle-Zélande. Ces recommandations sont les plus autorisées sur le sujet et identifient trois risques majeurs : la chaîne d’approvisionnement des données, les données modifiées de manière malveillante et la dérive des données. Ces risques concernent l’intégrité des informations qui alimentent et façonnent les systèmes d’IA.

ENCFORGE ajoute la question complémentaire de savoir si les artefacts de modèle et les données de support restent disponibles et récupérables après un chiffrement délibéré. Ce problème de disponibilité étend l’accent opérationnel tout en laissant intactes les préoccupations d’intégrité. Pour les équipes responsables de la résilience, la sécurité des données IA inclut donc la capacité à restaurer l’état entraîné dont dépend la production. L’intégrité détermine si cet état est digne de confiance ; la disponibilité détermine si l’organisation peut l’utiliser ou le récupérer.

L’exposition dépasse un seul serveur laissé sans correctif à plusieurs reprises

Le serveur compromis à plusieurs reprises constitue un cas, tandis que Langflow présente une surface exposée plus large. VentureBeat a rapporté en juin qu’environ 7 000 instances Langflow étaient accessibles sur internet, la plupart en Amérique du Nord. De telles instances peuvent contenir des clés API de fournisseurs et des identifiants cloud, ainsi que des connexions actives à des vector stores, qui figurent parmi les actifs qu’ENCFORGE a été conçu pour chiffrer. L’exposition de la couche d’orchestration peut donc créer une voie vers des systèmes contenant des actifs IA de plus grande valeur.

Cette empreinte s’ajoute à un historique plus large de vulnérabilités Langflow. La CISA avait placé cinq failles Langflow dans son catalogue KEV, dont deux ajoutées en juillet 2026. Le 7 juillet, elle a ajouté CVE-2026-55255, un contournement inter-tenant permettant à tout utilisateur authentifié sur une instance partagée d’exécuter les flows d’un autre tenant en utilisant les identifiants de ce dernier. Les mainteneurs de Langflow ont attribué à la vulnérabilité la note de 9,9 et l’ont corrigée dans la version 1.9.1.

L’ajout suivant au KEV a montré une autre voie via le point de terminaison de validation. La CISA a ajouté CVE-2026-0770 le 21 juillet ; découverte par Trend Micro et notée 9,8, la vulnérabilité fournit une voie non authentifiée vers une exécution de code root via le paramètre exec_globals sur le même point de terminaison de validation utilisé par JADEPUFFER. KEVIntel a enregistré le début de l’exploitation le 27 juin, avec plus de 220 tentatives provenant de 64 adresses. Le fondateur Ryan Dewhurst a déclaré à BleepingComputer que les charges utiles observées allaient au-delà de la reconnaissance pour rechercher des identifiants AWS et des métadonnées de conteneur ; les agences fédérales avaient jusqu’au 24 juillet pour corriger.

Ces expositions renforcent l’avertissement de Riemer contre le placement d’applications sensibles pour la sécurité à la frontière internet. « Quand vous placez votre sécurité à la périphérie de votre réseau, vous invitez le monde entier à la périphérie de votre réseau », a-t-il déclaré. Pour un framework IA, les conséquences peuvent s’étendre via les identifiants stockés et l’infrastructure connectée après la compromission du service exposé. L’accessibilité depuis internet doit donc être évaluée en même temps que ce que le framework peut lui-même atteindre.

Cette portée devient plus difficile à gouverner lorsque les organisations ont aussi des agents IA non gérés. Une enquête de la Cloud Security Alliance menée auprès de 418 professionnels, commandée par Token Security, a révélé que 82 % avaient découvert des agents IA dont personne n’avait connaissance, tandis que 65 % avaient traité un incident lié à un agent au cours de l’année précédente. Ces résultats indiquent une exposition aux agents non gérés et montrent que les équipes de sécurité peuvent accorder des identités puissantes opérées par machine sans en maintenir un inventaire complet. Token Security vend une technologie de sécurité des identités et a commandé l’enquête ; l’entreprise bénéficie donc commercialement d’une plus grande inquiétude autour des identités d’agents non gérés.

Les autorisations attachées à ces identités peuvent amplifier le même problème de vitesse observé dans JADEPUFFER. McGladrey rattache une partie du problème à la pratique ancienne consistant à copier le profil d’accès d’un employé lors du provisionnement d’un autre utilisateur, une habitude que les organisations étendent désormais aux agents. Un agent « fait tout ce dont il a besoin pour accomplir sa tâche », a-t-il déclaré, et à grande échelle et à grande vitesse, il peut utiliser plus d’autorisations que sa mission ne l’exige. L’excès de privilèges devient plus lourd de conséquences lorsque les actions se produisent rapidement, car un agent compromis ou mal orienté peut exercer ces autorisations à travers les systèmes avant toute intervention manuelle.

À mesure que ces incidents deviennent visibles, le problème technique devient aussi un sujet de direction. Evans a déclaré que les conseils d’administration réagissent à une nouvelle campagne de rançongiciel signalée en demandant : « Qu’est-ce que nous faisons à ce sujet ? » et qu’une composante IA élève le niveau d’inquiétude. Une réponse utile doit relier cette inquiétude aux mécanismes observés : logiciels exposés, identifiants, privilèges excessifs, accès hôte et récupérabilité. Ces mécanismes donnent aux équipes de sécurité et d’infrastructure des domaines concrets dans lesquels réduire l’exposition.

La préparation à la reprise rend explicites les artefacts de modèle

La réponse à court terme s’appuie sur les contrôles de sécurité existants, en commençant par l’application exposée. Chaque déploiement Langflow accessible depuis internet doit passer à la version actuellement prise en charge, puis faire l’objet d’un examen des requêtes historiques vers /api/v1/validate/code à la recherche de motifs exec_globals. L’installation d’un correctif ferme un point d’entrée, tandis que l’examen historique traite la possibilité qu’une exploitation ait eu lieu avant la remédiation. Ces deux actions répondent à des aspects différents de la même exposition.

Une fois l’application corrigée, les privilèges du conteneur doivent être traités avec la même franchise, car le socket Docker a créé la voie de JADEPUFFER vers l’hôte. Langflow fonctionne sans avoir besoin de créer des conteneurs ; son conteneur applicatif doit donc s’exécuter sans le socket Docker. Lorsqu’une architecture exige réellement un montage du socket, l’accès doit passer par un proxy limité aux appels dont l’application a besoin. La suppression du contrôle Docker général casse la voie spécifique utilisée pour l’évasion d’hôte.

Une fois les privilèges hôte limités, les plans de reprise doivent nommer explicitement les chemins des artefacts de modèle. Les équipes doivent maintenir des snapshots immuables des checkpoints, des index vectoriels et des données d’entraînement, et tester que ces snapshots peuvent réellement être restaurés. Les données d’entraînement doivent aussi résider à l’écart de l’hôte qui contient les poids du modèle, afin de réduire la probabilité qu’un seul événement destructeur supprime à la fois l’artefact et les éléments nécessaires à sa reconstruction. Cette conception transforme la reprise de modèle en processus d’ingénierie testé avec des entrées connues.

Ce même processus de reprise doit tenir compte des identifiants qui peuvent survivre à la compromission initiale. La première campagne a obtenu des identifiants OpenAI, Anthropic et cloud en quelques secondes ; corriger Langflow ensuite ne peut donc pas révoquer des éléments déjà capturés par l’attaquant. Tous les identifiants accessibles depuis l’hôte doivent être renouvelés, les clés fournisseur doivent être retirées du runtime, et les remplacements doivent être fournis via un gestionnaire de secrets. Ces étapes contiennent un accès qui peut rester utile après la fermeture du point d’entrée vulnérable.

La détection peut alors se concentrer directement sur le comportement destructeur produit par ENCFORGE. Les équipes peuvent déclencher des alertes sur la création massive de fichiers .locked dans des répertoires contenant des fichiers .gguf, .safetensors, .ckpt ou .faiss, tout en utilisant la règle YARA et les hash publiés par Sysdig. Ces signaux placent les poids de modèle, les checkpoints et les index vectoriels dans l’inventaire de reprise surveillé comme des actifs dont le chiffrement soudain constitue une condition d’incident. Les données d’entraînement appartiennent au même inventaire, car la reprise du modèle entraîné peut en dépendre.

Recap

JADEPUFFER n’exige pas que les dirigeants partent du principe que les rançongiciels alimentés par l’IA remplaceront les attaques conventionnelles. Son importance est plus immédiate : l’automatisation peut compresser en quelques minutes des chaînes d’attaque familières, tandis qu’un rançongiciel visant les poids de modèle, les checkpoints et les données d’entraînement peut rendre la reprise sensiblement plus coûteuse. Les anciennes vulnérabilités, les services exposés et les privilèges excessifs deviennent plus lourds de conséquences lorsque les attaquants peuvent les enchaîner rapidement.

Pour les dirigeants d’entreprise, cela change la manière dont les actifs IA doivent apparaître dans la planification de la résilience. Un modèle de production n’est pas simplement un autre fichier à sauvegarder. Sa récupérabilité peut dépendre des données d’entraînement, des checkpoints, des connaissances d’ingénierie, de la capacité de calcul et d’identifiants répartis sur plusieurs systèmes. Si la reconstruction de cet état coûte de 75 000 à 500 000 dollars par modèle, le temps de reprise et le coût de reconstruction doivent figurer dans la même analyse d’impact métier que les autres systèmes critiques.

Le test pratique consiste à savoir si l’organisation peut restaurer un modèle de confiance sans dépendre de l’environnement compromis ni d’un outil de déchiffrement de rançongiciel. Cela signifie savoir quels artefacts IA sont critiques pour l’activité, isoler des copies immuables, protéger les données nécessaires à leur reconstruction, limiter les privilèges de l’infrastructure IA et renouveler les identifiants après une compromission. Ces contrôles sont familiers, mais les actifs et les délais qu’ils protègent évoluent.

La question pour la direction est donc plus large que celle de savoir si le rançongiciel IA constitue une nouvelle catégorie de menace. Elle est de savoir si les processus existants de sécurité et de reprise correspondent encore à la vitesse de l’attaque et au coût de remplacement des actifs désormais à risque.