Analyse des chemins d’attaque : raisonner en graphe plutôt qu’en liste

Qu’est-ce que l’analyse des chemins d’attaque ?

En 2015, John Lambert, alors chez Microsoft, résumait le problème en une phrase devenue classique : « Defenders think in lists. Attackers think in graphs. » Les défenseurs gèrent des listes d’actifs, de vulnérabilités, de comptes. L’attaquant, lui, atterrit quelque part et navigue d’une relation à l’autre jusqu’à ce qui l’intéresse.

L’analyse des chemins d’attaque consiste à adopter ce point de vue. Elle représente le système d’information sous forme de graphe orienté, puis cherche les enchaînements qui relient un point d’entrée plausible à un actif critique.

Nœuds, arêtes, chemins

• Les nœuds sont les objets du système : postes, serveurs, ressources cloud, applications, automates, mais aussi comptes, groupes, rôles et vulnérabilités.
• Les arêtes sont les relations exploitables : un compte administrateur local d’une machine, une session ouverte qui laisse des secrets en mémoire, un droit d’écriture sur un objet d’annuaire, une vulnérabilité qui donne l’exécution de code, un flux réseau autorisé.
• Un chemin est une suite d’arêtes. Chaque saut correspond à une technique de mouvement latéral ou d’élévation de privilèges documentée dans MITRE ATT&CK.

L’idée n’est pas nouvelle. La recherche académique travaille sur les graphes d’attaque depuis le début des années 2000 ; en 2005, MulVAL proposait déjà un raisonnement automatique sur les attaques multi-étapes et multi-machines. Côté terrain, la bascule date de 2016 : la présentation Six Degrees of Domain Admin, à DEF CON 24, introduit BloodHound et applique la théorie des graphes aux droits d’Active Directory. Le constat des auteurs est simple : Bob administre la machine de Steve, Steve celle de Mary, donc Bob administre de fait celle de Mary, souvent sans que personne ne l’ait voulu.

Trois notions à maîtriser

• Le rayon d’impact d’un nœud : tout ce qu’un attaquant atteint s’il le compromet. Un poste de stagiaire a un rayon court ; un compte de service présent sur cinquante serveurs, un rayon très large.
• Le point de convergence (choke point) : une arête ou un nœud par lequel passent de nombreux chemins. La documentation de BloodHound le compare à l’allée qui dessert une maison : la bloquer coupe d’un coup tous les accès qui l’empruntent.
• L’exposition : la proportion d’identités ou de machines qui disposent d’au moins un chemin vers un actif critique. C’est l’indicateur qui résume le mieux l’état du graphe.

Pourquoi raisonner en chemins plutôt qu’en vulnérabilités isolées ?

Une liste de vulnérabilités classée par score CVSS répond à la question « qu’est-ce qui est grave ? ». Elle ne dit pas « qu’est-ce qui mène quelque part ? ». Or c’est la seconde question qui décide de l’impact réel.

Une faiblesse moyenne peut valoir plus qu’une critique

Une vulnérabilité critique sur une machine isolée, sans compte privilégié ni flux sortant, ne mène nulle part. Une vulnérabilité moyenne sur un serveur où se connectent chaque jour des administrateurs ouvre un chemin direct vers l’annuaire. Le graphe inverse l’ordre de la file. C’est le principe que le cadre CTEM applique à l’étape de priorisation, détaillé sur notre page de référence sur le CTEM.

La plupart des arêtes ne sont pas des CVE

En mission Red Team, nous progressons rarement grâce à une seule vulnérabilité logicielle. Les sauts décisifs viennent de droits excessifs, de mots de passe d’administrateur local partagés, de sessions privilégiées sur des machines peu protégées, de délégations oubliées, de modèles de certificats trop permissifs. Aucun scanner de vulnérabilités ne les classe, parce que ce ne sont pas des failles : ce sont des relations. Seul un modèle en graphe les met sur le même plan que les CVE.

Comment repérer les points de convergence ?

Dans un graphe réel, des milliers de chemins finissent souvent par emprunter les mêmes quelques arêtes avant d’atteindre l’actif critique. Les repérer revient à chercher, pour chaque cible, les nœuds par lesquels transite le plus grand nombre de chemins, puis à estimer combien de chemins une correction ferme.

La première ligne n’est pas une hypothèse d’auditeur. Microsoft indique dans sa documentation d’Entra Connect que ce serveur doit être traité comme un composant de niveau 0, et qu’un attaquant qui le contrôle peut manipuler les utilisateurs d’Entra ID.

Un graphe qui traverse IT, cloud, identités et OT

Un graphe limité à Active Directory montre les chemins internes au domaine Windows, puis s’arrête à sa frontière. Or les chemins les plus dangereux sont souvent ceux qui changent de domaine : ils commencent dans le périmètre d’un outil et finissent dans celui d’un autre, et aucun des deux ne voit le trajet complet.

Les quatre territoires à relier

1. L’exposition externe : services publiés, VPN, interfaces d’administration, sous-domaines oubliés. C’est l’origine de la plupart des chemins.
2. L’IT et l’annuaire : postes, serveurs, partages, groupes et droits d’Active Directory.
3. Les identités cloud : comptes, rôles et applications du tenant, identités de charge de travail, et surtout les points de couture avec l’annuaire local.
4. L’OT : supervision, postes d’ingénierie, automates. Les techniques propres à ces environnements sont décrites dans la matrice MITRE ATT&CK for ICS.

Les accès des tiers se greffent sur ces quatre territoires : un compte de prestataire est une arête comme une autre, souvent mal surveillée parce que son trafic paraît légitime.

L’éditeur de BloodHound a lui-même suivi ce mouvement : sa documentation couvre désormais la collecte Entra ID en plus d’Active Directory, ainsi qu’un mécanisme (OpenGraph) pour ingérer d’autres sources de données dans le graphe.

Le prérequis : un inventaire qui relie

Un graphe ne vaut que par ses nœuds. Sans inventaire consolidé, dédoublonné et relié, les arêtes inter-domaines n’existent pas dans le modèle. C’est pourquoi l’analyse des chemins d’attaque bute souvent sur la dispersion des outils, sujet que nous traitons dans notre article sur la plateformisation des outils cyber offensifs. L’ANSSI rappelle de son côté, dans son guide de cartographie du système d’information, que la cartographie est un préalable à la protection et à la défense, et qu’elle inclut l’écosystème de l’organisation.

Exemple : du VPN à la supervision industrielle

Exemple type. Une ETI industrielle dispose d’un graphe Active Directory à jour et d’un outil de découverte externe, gérés par deux équipes différentes. Chacun, isolément, ne signale rien d’alarmant.

Relié dans un même graphe, le tableau change. Un VPN exposé accepte des comptes de domaine sans second facteur. Un compte de service utilisé par l’outil de supervision ouvre une session sur un serveur de rebond, qui dispose d’un flux autorisé vers la zone industrielle. Trois arêtes banales forment un chemin de quatre sauts entre Internet et les postes d’ingénierie.

L’analyse montre que le serveur de rebond est un point de convergence : vingt-trois chemins vers la zone OT y passent. La correction porte sur lui (restriction des comptes autorisés, filtrage du flux) et sur le second facteur du VPN. Un rejeu confirme que les chemins sont fermés.

Ce scénario est construit à partir de situations courantes en mission, pas à partir d’un client identifiable.

Mettre en place la démarche

1. Désigner les actifs critiques. Annuaire, données réglementées, production, messagerie de direction. Ce sont les destinations du graphe.
2. Consolider l’inventaire. Réunir les actifs des quatre territoires, dédoublonnés, avec leur criticité.
3. Collecter les relations. Droits, sessions, appartenances, flux réseau, vulnérabilités exploitables. Insister sur les jonctions entre domaines.
4. Calculer les chemins et les points de convergence. Pour chaque actif critique, identifier les plus courts chemins et les nœuds partagés.
5. Valider. Rejouer les chemins prioritaires par une simulation d’attaque automatisée ou un exercice humain, pour séparer le praticable du théorique.
6. Corriger et mesurer. Suivre l’exposition et le nombre de points de convergence ouverts, puis recalculer à chaque changement notable du système.

Dans Beareye, le module CAASM consolide et dédoublonne les actifs internes et cloud, y compris les équipements industriels, et met en évidence les relations entre eux. La Red Team automatisée du Command Center reconstitue ensuite les chemins, du point d’entrée jusqu’à la cible, et rejoue l’attaque après correction. L’ensemble s’inscrit dans un programme CTEM.

Limites de l’approche

Le graphe ne voit que ce qu’on lui donne. Une source non collectée, un droit applicatif interne, un secret dans un script : autant d’arêtes absentes. Un graphe propre n’est pas la preuve d’un système sûr.

Un chemin calculé n’est pas un chemin praticable. Le modèle ignore souvent les protections en place (détection, filtrage, authentification forte). Sans validation, la file de remédiation contient des faux positifs, et les équipes IT le remarquent vite.

Le graphe vieillit vite. Une session, un groupe ou un flux changent chaque jour. Une analyse ponctuelle est une photographie ; elle doit être recalculée en continu pour rester utile.

Corriger un point de convergence peut casser la production. Retirer un droit à un compte de service suppose de comprendre qui en dépend. Le graphe désigne la cible ; la correction reste un projet, avec ses tests et son calendrier.

Il ne remplace pas l’attaquant humain. Le graphe enchaîne des relations connues. Un exercice Red Team trouve aussi les arêtes que personne n’avait modélisées, à commencer par celles qui passent par les personnes.