Rançongiciels et IA : ce qui est observé, ce qui reste à démontrer

Un rançongiciel chiffre ou rend des données indisponibles pour faire pression sur sa victime ; l’extorsion peut aussi s’appuyer sur leur vol. L’intelligence artificielle peut aider un attaquant à écrire, comprendre ou adapter des outils. Cela ne signifie pas que toutes les attaques sont désormais conduites de bout en bout par un modèle autonome. Pour décider où investir, il faut distinguer les faits, les capacités démontrées et les projections.

Trois niveaux à ne pas confondre

Un LLM est un modèle de langage qui produit une réponse à partir de son contexte. Un agent associe ce modèle à des outils, une mémoire éventuelle et une boucle de décision. Sans accès au système visé, le modèle ne possède pas magiquement les moyens d’y agir. Dans un incident, les droits et les secrets obtenus restent donc déterminants.

L’autonomie doit être décrite : quelle partie a été réalisée automatiquement, combien d’interventions humaines ont été nécessaires, dans quel environnement et avec quels échecs ? Le mot « autonome » sans ces précisions masque davantage qu’il n’explique.

Lire les cas publiés avec leurs limites

Dans son rapport d’août 2025 sur les usages abusifs, Anthropic décrit notamment une utilisation de Claude pour développer et commercialiser du code de rançongiciel par un acteur disposant de compétences limitées. C’est une observation de fournisseur sur les abus qu’il a détectés, pas un recensement de toutes les campagnes ni la preuve d’une chaîne universellement autonome.

Le NCSC britannique décrit l’IA comme un facteur susceptible d’améliorer les capacités des attaquants, avec des effets inégaux selon les acteurs et les tâches. Une prospective éclaire la préparation ; elle ne doit pas être présentée comme la mesure d’un incident déjà arrivé.

Pour chaque nouvelle publication, conservez la source originale, la date, les éléments directement observés et les incertitudes. Une démonstration sur un laboratoire préparé a de la valeur, mais ne mesure ni le taux de réussite en entreprise ni la diffusion d’une technique. Les affirmations « contourne tous les EDR en quelques secondes » exigeraient des preuves que ces sources ne fournissent pas.

Ce qui change pour une organisation

La vitesse de préparation et la capacité à adapter un texte ou du code peuvent augmenter le volume d’essais. Les équipes doivent donc réduire les délais entre une alerte utile, sa qualification et la première décision de protection. Cela ne se résout pas seulement en achetant un autre outil : il faut savoir qui a autorité pour isoler un poste et comment joindre cette personne.

Un attaquant plus rapide profite surtout des chemins déjà ouverts : un compte trop privilégié, un jeton durable oublié, une sauvegarde administrée avec les mêmes identifiants que la production. Ces dépendances sont des points de travail concrets, quelle que soit la technologie utilisée pour préparer l’attaque.

Les contrôles à examiner en priorité

• Identités : séparer comptes quotidiens et comptes d’administration, examiner les droits et réduire les secrets durables.
• Accès : restreindre l’administration distante, corriger les systèmes exposés et inventorier les accès des prestataires.
• Détection : collecter des traces utiles sur les identités, les postes et les changements sensibles, avec une chaîne de remontée testée.
• Sauvegardes : séparer leur administration, protéger les versions et restaurer dans un environnement de reprise maîtrisé.
• Crise : préparer les contacts, les décisions de confinement, la conservation des éléments et les critères de remise en service.

Un EDR aide à détecter et traiter des comportements sur les terminaux. Il ne remplace ni la maîtrise des comptes cloud ni le contrôle d’une sauvegarde. Inversement, ajouter un modèle d’IA à un SOC ne garantit pas une meilleure décision : une donnée trompeuse peut aussi déclencher une mauvaise action automatique.

Un exercice simple pour le comité de direction

Scénario fictif : un prestataire signale un compte compromis, puis plusieurs dossiers deviennent indisponibles. Une alerte indique une activité sur les sauvegardes. Demandez au groupe de décider successivement qui dirige la crise, quels accès suspendre, quelles preuves conserver et quel service remettre en route en premier. N’introduisez pas de logiciel malveillant pour cet exercice de discussion.

À chaque étape, notez ce que l’équipe sait et ce qu’elle suppose. Une mention d’IA dans une demande de rançon ne prouve pas son utilisation. Le choix d’isoler un équipement doit reposer sur les faits et l’impact, pas sur la sophistication affichée de l’adversaire.

Le compte rendu doit produire des corrections : contacts manquants, droits trop larges, dépendances de restauration, décisions impossibles à prendre rapidement. Mesurez ensuite si ces corrections réduisent réellement le temps de réaction au prochain exercice.

Faut-il une défense entièrement autonome ?

Certaines actions répétitives se prêtent bien à l’automatisation : enrichir une alerte, ouvrir un dossier ou collecter des métadonnées. Les actions qui coupent un service nécessitent un périmètre, une limite de durée et un mécanisme de reprise. Une erreur répétée automatiquement peut transformer un faux positif en indisponibilité générale.

Commencez par un mode qui propose les décisions, puis un pilote sur des postes de test. N’étendez l’automatisation qu’après mesure des erreurs, vérification du retour arrière et désignation du responsable. La bonne question reste : quelle décision devient plus fiable et plus rapide, avec quelle preuve ?

Sources et références

Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.

• Anthropic - Detecting and countering misuse of AI, août 2025
• NCSC - The near-term impact of AI on the cyber threat