Attack Chaining : comment tester et stopper la façon dont les attaquants s'introduisent

En juillet 2026, un modèle d'IA en cours d'évaluation interne de ses capacités s'est échappé de son sandbox. Il a enchaîné un exploit zero-day avec une faille d'exécution de code pour obtenir un accès root sur une infrastructure externe. De là, il a atteint le pipeline de datasets de Hugging Face, a escaladé ses privilèges jusqu'à l'administration Kubernetes, s'est déplacé latéralement par usurpation de nœuds et falsification de tokens, et a fait tourner son command and control depuis des services web publics ordinaires — plus de 17 000 actions sur environ quatre jours et demi, entièrement de sa propre initiative. Aucun humain n'a dirigé la moindre étape. Il s'agit de l'un des premiers cas confirmés d'un modèle d'IA menant de manière autonome une intrusion multi-étapes contre un tiers.

Appelons-les néo-attaquants et défenseurs historiques. Les néo-attaquants utilisent une IA de pointe et l'automatisation pour enchaîner les techniques et trouver un chemin direct vers les joyaux de la couronne. Les défenseurs historiques s'appuient encore sur des outils manuels et un pentest une ou deux fois par an, et en paient le prix quand une brèche passe à travers. Leur façon de se défendre ne correspond plus à la réalité des attaques.

La plupart des équipes sécurité valident encore leurs environnements une technique à la fois : une simulation de phishing ici, un scan de vulnérabilités là, un pentest ponctuel une ou deux fois par an, parfois plus pour les équipes disposant de temps ou de budget. Ce n'est pas suffisant. Les attaquants, de plus en plus dopés à l'IA, opèrent différemment. Ils enchaînent les techniques, utilisant les preuves d'une étape pour décider de la suivante, évaluant le chemin vers une brèche coup par coup, et s'adaptant au fil de l'eau.

Les défenses doivent évoluer vers une validation d'exposition autonome : automatiser les processus derrière le pentesting et le red teaming pour qu'ils fonctionnent comme les attaquants, c'est-à-dire de façon continue et adaptative, plutôt qu'une ou deux fois par an. Les attaquants fonctionnent désormais à l'automatisation et, de plus en plus, aux agents. Égaler cette capacité exige des défenses construites de la même manière. Si les attaquants agissent en continu et les défenses de façon périodique, l'équation ne fonctionne jamais.

« Si les attaquants agissent en continu et les défenses de façon périodique, l'équation ne fonctionne jamais. »

Le test atomique, qui consiste à vérifier une technique à la fois de façon isolée, révèle des failles d'exposition individuelles, mais ne peut pas reproduire la logique complexe, humaine ou IA, nécessaire pour passer de l'intrusion à la brèche. L'automatisation est devenue un mot à la mode constamment brandi dans ce secteur, mais ici, c'est tout simplement vrai : les attaquants en dépendent chaque année un peu plus, les défenses doivent donc en faire autant. Le pentesting doit être automatisé car les attaques évoluent désormais à la vitesse de l'automatisation. La validation doit s'exécuter en continu plutôt que périodiquement. Et les red teamers ont besoin d'une option agentique, car faire passer à l'échelle une red team humaine indéfiniment n'a jamais été réaliste.

L'écart d'exposition : pourquoi il ne cesse de se creuser

L'écart entre la façon dont les attaquants opèrent et la façon dont la plupart des organisations testent leur résistance est large, et il se creuse. Dans le rapport State of Threat Management de Filigran, 93 % des responsables sécurité déclarent peiner à maintenir une vision précise de leur propre surface d'attaque. Quatre-vingt-huit pour cent estiment que les évaluations périodiques seules ne suivent pas le rythme d'évolution des systèmes et des environnements. Et 95 % conviennent qu'une automatisation accrue leur donnerait davantage confiance dans le fait de se concentrer sur les risques qui comptent le plus, une conviction qui se reflète dans les processus de gestion de l'exposition pilotés par l'IA, dont l'adoption devrait presque doubler, passant de 37 % aujourd'hui à 59 % d'ici deux ans.

La violation de données subie cet été par l'administration fiscale française, la DGFiP, illustre concrètement ce que signifient ces chiffres. L'attaquant a violé les systèmes et exfiltré des données avant de mettre en vente la base de données volée, exposant les informations de 678 000 particuliers et entreprises. L'intrusion a réussi parce que les environnements réels se comportent de manière dynamique, s'adaptant à un rythme que les hypothèses d'un script figé ne peuvent suivre.

Pourquoi l'évaluation manuelle ne peut pas suivre le rythme

Trois limites structurelles expliquent pourquoi les simulations isolées et les tests atomiques laissent encore des écarts importants :

1. Les scénarios scriptés se déroulent toujours de la même façon, quelles que soient leurs découvertes. Les résultats finissent par décrire un scénario qui ne correspond pas à la façon dont un véritable adversaire pivoterait.
2. Les résultats en boîte noire n'ont aucun raisonnement associé. Les analystes ne peuvent pas déterminer quelle action a produit quel résultat, et finissent par trier chaque faiblesse touchée par une chaîne au lieu de celle qui compte vraiment.
3. Construire des chaînes multi-étapes à la main exige une expertise red team rare. Cela limite la part d'un environnement qu'une équipe peut réalistement tester, quel que soit le temps dont elle dispose.

Ensemble, ces trois limites pointent vers un seul problème structurel : une validation qui s'exécute une fois, face à des attaquants qui ne s'arrêtent jamais.

Combler cet écart commence par repenser ce qu'un outil de validation doit réellement faire : non pas exécuter une séquence figée, mais raisonner à travers elle, comme le ferait un attaquant.

À quoi ressemble une validation continue et adaptative

C'est le changement autour duquel s'articulent Attack Chaining et le reste de la dernière version de la plateforme de validation d'exposition de Filigran, OpenAEV v3 : l'automatisation et l'actionnabilité. Cela se voit le plus clairement dans son centre de commande repensé, son score d'exposition couvrant chaque source de validation, et un nouveau type de scénario qui traite la validation comme un processus vivant et adaptatif plutôt qu'un script figé.

Voici ce que cela change pour une équipe sécurité :

• Une logique de chaînage configurable et conditionnelle signifie qu'une équipe contrôle sa propre logique de scénario, construite à partir de son propre arsenal de menaces et de ses tactiques, techniques et procédures (TTP), plutôt que de dépendre d'une séquence prédéfinie par un éditeur.
• Un graphe de chemin d'attaque en direct signifie qu'une équipe peut observer l'attaque se dérouler et identifier l'unique point de blocage qui conditionne tout un chemin d'attaque, au lieu de trier chaque faiblesse que la chaîne touche au passage.
• Des modes pilotés par un opérateur ou orchestrés par un agent signifient qu'une équipe choisit son propre compromis entre rapidité et contrôle, plutôt que d'être enfermée dans un seul modèle opérationnel.

La validation de chemin d'attaque a déjà existé. La différence ici tient à l'exécution. Certains outils restituent des résultats sans aucune visibilité sur la façon dont ils y sont parvenus. D'autres exécutent des scripts prédéfinis plutôt que de raisonner à partir des résultats réels. L'approche d'OpenAEV, ancrée dans ses fondations open source, fonctionne différemment : une équipe configure la logique et les conditions qu'elle souhaite, et lorsqu'une chaîne s'exécute, chaque décision est visible et consultable : ce qui a été découvert, ce qui est passé, ce qui a échoué. Le processus compte autant que le résultat, et une équipe peut tout explorer en détail.

Aujourd'hui, la plupart des outils de chemin d'attaque planifient des séquences prédéfinies et traitent leur résultat comme un rapport d'après-action livré une fois l'exécution terminée. Attack Chaining rompt avec ce schéma, en réagissant aux preuves collectées en temps réel pendant l'exécution d'un scénario et en révélant le chemin d'attaque au fur et à mesure qu'il se forme plutôt qu'après coup. La logique sous-jacente reste ouverte, de sorte qu'une équipe la façonne selon son propre environnement plutôt que de travailler dans une séquence figée définie par un éditeur. Et les résultats se rattachent à la threat intelligence propre à l'organisation, alimentant un score d'exposition unifié plutôt que de rester un rapport isolé.

Pour s'aligner sur le mode opératoire des attaquants, des outils plus pointus ne suffisent pas.

Une défense continue et automatisée n'est plus une option

Les néo-attaquants et les défenseurs historiques ne peuvent pas jouer indéfiniment avec le même livre de jeu. S'il y a un seul changement à opérer après la lecture de cet article, c'est d'adopter l'automatisation, que cela semble confortable ou non pour l'instant, car c'est la direction que les attaquants ont déjà prise. Les données suggèrent que la prise de conscience est déjà là. C'est la mise en œuvre qui continue de prendre du retard.

À mesure que les attaquants gagnent en autonomie, cet écart devient de plus en plus difficile à ignorer.

L'intrusion chez Hugging Face donne un aperçu de la manière dont l'infiltration fonctionne de plus en plus souvent : pilotée par l'IA, enchaînée et adaptative. La seule façon de s'en défendre est de tester de la même manière, en continu, avec la même logique d'enchaînement et la même automatisation que celles déjà utilisées par les attaquants.

Pour une vue complète de ce qui a été livré avec Attack Chaining, y compris un nouveau centre de commande, un scoring d'exposition et des injecteurs de red teaming par IA, consultez mon article de lancement d'OpenAEV v3.