Article

Du Cybermois au Black October

Par: Jean-Michel Besnard

L'IA n'a pas inventé de nouvelles attaques, elle a supprimé le délai de réaction
Sommaire

Octobre devait être le mois de la sensibilisation à la cybersécurité. Il restera celui où l’intelligence artificielle a montré, à grande échelle, ce qu’elle change pour les attaquants : pas de nouvelles techniques, mais des délais qui s’effondrent. Pour les DSI, les RSSI et les directions des risques, la question n’est plus seulement « sommes-nous protégés ? », mais « pouvons-nous réagir à temps ? ».

Le 1er octobre, la 14e édition du Cybermois s’ouvrait en France avec plus de 2 400 partenaires mobilisés autour des bons réflexes numériques. Le même jour, Microsoft publiait son Digital Defense Report 2026 et son constat principal : grâce à l’IA, le délai médian entre la découverte d’une vulnérabilité et son exploitation passe désormais sous les 24 heures.

Les semaines suivantes ont donné corps à ce chiffre : failles critiques découvertes par l’IA dans PHP, campagnes menées par des agents autonomes, intrusions via des fournisseurs de confiance. La presse anglo-saxonne a rapidement rebaptisé le mois « Black October ».

Pris isolément, aucun de ces événements n’est un basculement. Ensemble, ils confirment ce que les équipes de tests d’intrusion constatent sur le terrain : l’IA ne réinvente pas l’attaque, elle la rend plus rapide, moins chère et accessible à des acteurs moins compétents.

L’essentiel en trois points

  • Le délai d’exploitation s’effondre : sous les 24 heures en médiane selon Microsoft, quand les cycles de correctifs se comptent encore en semaines.
  • Les agents d’IA mènent désormais des intrusions de bout en bout : environ 50 dollars par intrusion réussie pour Cairn, un accès cloud privilégié en moins de trois heures pour Storm-0940.
  • Le risque se déplace vers les tiers et les identités non humaines : le sujet devient organisationnel, avec un objectif réaliste de moins de 48 heures pour corriger ou isoler le périmètre exposé.

Octobre 2026 en six dates

Date Événement Rôle de l’IA
  1er oct
Lancement du Cybermois ; publication du Microsoft Digital Defense Report 2026
Délai médian d'exploitation passé sous 24 h
19-20 oct
Campagne Cairn : plus de 1 200 sites visés, plus de 100 entreprises touchées
Agents autonomes, environ 50 $ par intrusion réussie
21 oct
PHP2Shell : correctifs d’urgence pour deux failles critiques de PHP
Failles trouvées par des modèles d’IA
21 oct
Microsoft attribue l’attaque ConnectWise à Storm-0940
Framework agentique ARTEX, 2 250 tenants visés
21 oct
CrowdStrike documente quatre groupes utilisant des agents d’IA
Objectifs souvent atteints en moins d’une heure
26 oct
Cathedral annonce avoir atteint des systèmes internes d’Anthropic
Agents d’IA, via des logiciels tiers

 

PHP2Shell : l’IA exhume des failles que personne ne savait exploiter

Le 21 octobre, les mainteneurs de PHP ont publié en urgence des correctifs pour deux vulnérabilités critiques, regroupées sous le nom de PHP2Shell (CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10). Elles permettent d’exécuter du code à distance sur un serveur, sans authentification. PHP fait tourner une large part du web, dont les sites WordPress, Drupal ou Magento.

Une faille ancienne, rendue exploitable par l’IA

Les équipes de Calif et de Wiz ont trouvé ces failles indépendamment en août, avec l’aide de modèles d’IA de pointe. Le défaut à l’origine de la première était même connu depuis 2024, mais personne n’avait su l’exploiter.

Il s’agit d’une erreur de gestion de la mémoire, dite use-after-free. Pour la comprendre, imaginez une bibliothèque qui retire un livre de ses rayons mais oublie de mettre à jour sa fiche de catalogue. Quelqu’un d’autre peut glisser un ouvrage de son choix à cet emplacement : le système continuera de le prendre pour l’original. Dans PHP, une fonction activée par défaut, le suivi de progression des téléchargements de fichiers, pouvait laisser ce type de « fiche périmée » d’une requête à l’autre.

Transformer ce défaut en attaque fiable demandait d’enchaîner des étapes d’une grande complexité. C’est précisément ce travail que l’IA a rendu praticable.

En France, des services publics mis hors ligne

La réaction a été inhabituelle. Selon l’ANSSI, plus de 600 000 serveurs utilisent PHP sur l’internet français. Le CERT-FR a recommandé de mettre hors ligne les serveurs concernés lorsque c’était possible, en attendant le correctif. Les sites de la DGFIP, de la CAF, de la CPAM, et de nombreux autres ont été temporairement débranchés. Dans les Hauts de France, il n’était plus possible de valider un titre TER en raison de l’arrêt de la plateforme, le temps d’appliquer les correctifs. Et, en plein Cybermois, le site cybermalveillance.gouv.fr a lui-même été coupé.

Reste un angle mort : les versions anciennes de PHP, hors support, encore très répandues. Pour elles, la consigne du CERT-FR est d’isoler les systèmes puis de migrer, un chantier qui ne se boucle pas en quelques jours.

Une exploitation plus lente que prévu, mais bien réelle

Une semaine après l’alerte, les chercheurs constataient que l’exploitation était plus difficile qu’annoncé : la vague de compromissions massives n’a pas eu lieu. Certains ont parlé d’un nouveau « bug de l’an 2000 ».

La comparaison est trompeuse. L’agence américaine CISA a confirmé une exploitation active, GreyNoise a observé ses premières compromissions réussies le 28 octobre, et un acteur soupçonné d’être lié à la Chine a combiné PHP2Shell avec une autre faille pour prendre le contrôle de 24 pare-feu en Asie et aux États-Unis. Et si les dégâts sont restés limités, c’est aussi parce que de nombreuses organisations ont coupé avant de corriger.

Les agents d’IA passent à l’acte

Jusqu’ici, l’IA servait surtout d’assistant aux attaquants : rédiger un courriel de phishing, expliquer une faille, produire un script. Octobre a montré autre chose : des agents qui mènent eux-mêmes l’opération.

Le principe est simple. L’opérateur fixe un objectif, par exemple « trouver une faille sur ce site et y installer un accès ». Un agent « superviseur » découpe la tâche, des agents « exécutants » lancent de vrais outils (scanners, requêtes, tentatives de connexion), et les résultats alimentent une mémoire commune. Le système itère seul, jour et nuit.

Trois cas, publiés en l’espace de quelques jours, en donnent la mesure :

  • Cairn, l’attaque à 50 dollars. Un chercheur de NorForge a découvert des tableaux de bord laissés exposés sur internet et a pu observer en direct un opérateur sinophone. Ses agents ont visé plus de 1 200 sites marchands et atteint ceux de plus de 100 entreprises, dont Deere, SharkNinja et Cummins. Coût estimé : environ 50 dollars de consommation d’IA par intrusion réussie.
  • CrowdStrike, l’attaque à la portée de tous. L’éditeur a documenté quatre groupes jusque-là inconnus confiant leurs intrusions à des agents. L’un d’eux a compromis au moins 15 établissements de santé en Argentine. Dans un cas, un agent bloqué a trouvé seul un autre chemin et atteint un contrôleur de domaine en une vingtaine de minutes. CrowdStrike estime que l’IA agentique est en train de banaliser les opérations offensives de base.
  • Storm-0940, l’attaque à la vitesse de la machine. Microsoft attribue à ce groupe lié à l’État chinois la compromission de ConnectWise Cloud Backup. Avec le framework ARTEX, il a d’abord tenté de deviner des mots de passe en masse (plus de 151 000 tentatives, jusqu’à 2 900 par minute), sans succès. Il a alors changé de méthode : en utilisant les identités des applications ConnectWise, il a tenté d’accéder à plus de 2 250 environnements Microsoft 365, et obtenu sur certaines cibles un accès cloud privilégié en moins de trois heures. Point clé : les attaquants se sont présentés comme une application que les clients avaient eux-mêmes autorisée. L’authentification multifacteur des utilisateurs n’entrait pas en jeu.

Cairn et ARTEX sont des outils open source, conçus au départ pour des tests d’intrusion légitimes. Microsoft constate déjà l’usage d’ARTEX par des groupes de plusieurs régions du monde.

Personne n’est à l’abri, pas même les laboratoires d’IA

Le 26 octobre, le Washington Post a révélé que Cathedral, une jeune entreprise de cybersécurité, avait atteint des systèmes internes d’Anthropic, l’éditeur de Claude, dans le cadre de son programme de recherche de vulnérabilités. Ses agents d’IA seraient entrés en moins de 12 heures. Anthropic conteste la durée et le périmètre, mais confirme un accès à un ensemble limité de systèmes commerciaux, RH et informatiques. Ni les modèles, ni le code, ni les conversations des clients n’ont été touchés.

Le détail le plus instructif tient au chemin emprunté : les agents ne sont pas passés par les produits d’Anthropic, mais par des logiciels d’administration et de vente fournis par des tiers.

C’est le fil rouge du mois. Les attaquants visent de plus en plus les outils qui entourent l’entreprise plutôt que son cœur :

  • les prestataires et applications SaaS disposant d’accès permanents, comme ConnectWise ;
  • les briques de l’écosystème IA elles-mêmes. La chaîne de publication de LiteLLM, passerelle open source vers les modèles d’IA, a été compromise le 21 octobre : pendant environ deux heures, la version distribuée contenait un logiciel qui volait identifiants et clés, aussitôt réutilisés selon Wiz. Chez OpenCode, assistant de code, une partie des clés d’API des utilisateurs a été exposée.

Ces clés d’API sont devenues une monnaie recherchée. Elles permettent de consommer des ressources aux frais de la victime, mais surtout d’accéder aux données et aux systèmes auxquels les agents d’IA de l’entreprise sont connectés. Dans beaucoup d’organisations, ces outils ont été adoptés plus vite que la gouvernance qui devrait les encadrer.

Le vrai sujet : une asymétrie de temps

Pendant des années, la gestion des vulnérabilités a reposé sur un délai implicite. Entre la publication d’un correctif et l’apparition d’une attaque fonctionnelle, il s’écoulait généralement des jours, voire des semaines. Ce délai permettait d’analyser, de tester en préproduction, puis de déployer. Il n’a jamais été garanti : certaines failles étaient exploitées avant même d’être corrigées. Mais l’IA accélère désormais plusieurs étapes à la fois.

Des outils d’IA peuvent analyser un correctif publié, en déduire la faille corrigée et produire une méthode d’exploitation en quelques heures. Des agents peuvent ensuite rechercher sur internet tous les serveurs non mis à jour.

Face à cela, le temps de l’entreprise reste celui de l’organisation :

  • identifier les systèmes concernés, ce qui peut prendre des jours si l’inventaire est incomplet ;
  • qualifier le risque, en tenant compte des dépendances applicatives ;
  • décider, souvent après plusieurs niveaux de validation, de couper un service ou d’appliquer un correctif en urgence ;
  • agir, dans des fenêtres de maintenance contraintes.

L’attaquant, lui, n’a ni comité, ni fenêtre de maintenance, ni horaires de bureau. Le problème n’est donc pas seulement technique : il est organisationnel. Un cycle de correctifs mensuel ou trimestriel sur les systèmes exposés n’est plus une politique de sécurité, c’est une exposition programmée.

Ce que cela change pour les DSI et les RSSI

Répondre à cette accélération ne passe pas d’abord par de nouveaux outils. Les fondamentaux restent les bons ; c’est leur vitesse d’exécution qui doit changer. Six chantiers se dégagent.

  1. Connaître réellement son exposition. On ne corrige vite que ce que l’on connaît. L’inventaire doit couvrir les versions logicielles, les composants embarqués dans les produits tiers, les services hébergés par des prestataires et les versions hors support, que PHP2Shell a mises en lumière.
  2. Prioriser selon le risque réel. Tout corriger immédiatement est impossible. L’enjeu est de traiter en premier les failles activement exploitées sur les systèmes exposés à internet, dans une logique de gestion continue de l’exposition (CTEM).
  3. Préparer la décision avant la crise. Qui peut décider, un mercredi à 16 h, de couper un service client pour éviter une compromission ? Les organisations qui ont réagi vite en octobre avaient un processus d’urgence préarbitré : seuils, décideurs, communication. Les correctifs critiques sur le périmètre exposé doivent pouvoir être appliqués, ou les systèmes isolés, en moins de 48 heures.
  4. Gouverner les accès des tiers. Applications autorisées dans Microsoft 365 ou Google Workspace, comptes de service et autres identités non humaines, infogérants, outils de sauvegarde, logiciels SaaS : chaque accès doit être justifié, limité au strict nécessaire et surveillé. ConnectWise et Cathedral montrent que la porte d’entrée est souvent chez un fournisseur, et que l’authentification multifacteur des utilisateurs ne protège pas contre une application autorisée aux privilèges excessifs.
  5. Intégrer l’IA dans le périmètre de sécurité. Recenser les outils d’IA utilisés, y compris ceux adoptés sans validation ; inventorier et faire tourner les clés d’API ; limiter les droits des agents connectés aux systèmes internes, tracer leurs actions et soumettre les opérations sensibles à une validation humaine. Un agent doté d’accès étendus est une cible en soi.
  6. Défendre à la vitesse de la machine. Les mêmes capacités d’IA servent aussi les défenseurs : auditer son propre code, corréler des signaux faibles, automatiser les premières actions de réponse (révocation d’accès, isolement). La segmentation et la limitation des privilèges réduisent l’impact quand la fenêtre n’a pas pu être fermée à temps.

Pour les fonctions Risques et conformité, ces chantiers rejoignent les exigences de NIS2 et de DORA sur la gestion des vulnérabilités et des risques liés aux tiers. Black October leur donne une urgence nouvelle.

En conclusion : le temps devient un risque à part entière

Black October n’a pas été la catastrophe annoncée par certains. Il a plutôt servi de répétition générale. Les méthodes restent connues : exploitation de failles, vol d’identifiants, abus de relations de confiance. Ce qui change, c’est leur vitesse, et leur coût, en chute libre.

Le Cybermois rappelait l’importance des bons réflexes. Le mois qui vient de s’achever montre qu’ils doivent désormais s’exécuter à la vitesse des machines. La résilience cyber ne se mesure plus seulement à la capacité d’empêcher une attaque, mais à celle de détecter, décider et agir avant que l’attaquant n’atteigne son objectif.

Trois questions à poser dès votre prochain comité cyber

  1. Combien de temps nous faut-il aujourd’hui pour identifier, décider et corriger une faille critique sur notre périmètre exposé à internet ?
  2. Qui peut décider, un mercredi à 16 h, de couper un service client, et ce processus est-il arbitré à l’avance ?
  3. Quels fournisseurs, applications autorisées, identités non humaines et clés d’API d’agents d’IA disposent d’accès permanents à nos systèmes ?

Si les réponses sont floues, c’est là que se trouve votre exposition. Nous serions heureux d’échanger avec vous sur la manière de la réduire.

Sources