Assumed Breach : évaluer l’impact réel d’un accès compromis

Introduction

Lors des différentes missions de test d’intrusion qu’AlgoSecure réalise, il arrive qu’un composant du SI mérite une analyse de type post-compromission. Dans ce cas, une mission Assumed Breach permet de partir d’un accès supposé (fourni et cadré avec le client) pour mesurer l’impact réel : possibilités de pivot, exposition des secrets, efficacité de la segmentation, et cohérence des permissions effectives (notamment IAM). L’enjeu est de produire une évaluation post‑compromission cadrée, utile à la fois pour prioriser les remédiations et pour renforcer davantage les contrôles de défense. Dans cette logique, nous considérons que la question n’est pas de savoir quand le SI va être compromis, mais si le SI est compromis, quels seront les impacts pour le client. Une approche qui s’inscrit dans un constat désormais largement partagé en cybersécurité : la question n’est plus de savoir si l’on sera attaqué, mais quand.

Définition et contexte de l’approche Assumed Breach

Chez AlgoSecure, nous décrivons l’approche Assumed Breach comme une évaluation post-compromission : nous partons d’un accès supposé dans une zone donnée du SI. Le plus souvent une identité qui peut prendre la forme d'un compte utilisateur avec un certain niveau de privilège, mais cela peut aussi être un poste, un serveur, un rôle IAM cloud ou une session applicative. De là, nous analysons ce que cet accès permet réellement. L’objectif n’est pas de tester la sécurité périmétrique de l'entreprise ni de démontrer comment l'obtenir, mais de mesurer l’impact suite à la compromission de cette identité.

Pentest classique vs Assumed Breach

Contrairement à un pentest plus classique, où le point de départ est souvent une surface à explorer (externe, interne, applicative) et où l’accès initial fait partie des éléments évalués, la mission Assumed Breach fixe volontairement l’hypothèse de départ pour se concentrer sur des objectifs précis. Ce format est particulièrement utile lorsque l’enjeu n’est pas de vérifier comment peut-on entrer sur le SI mais jusqu’où peut-on aller et qu’est-ce qui limite réellement la propagation sur le SI.

Dans certains contextes, cette logique existe aussi en mission red team : lorsqu’un exercice est très contraint en temps, ou que l’entrée par l’externe n’est pas l’objet principal, un démarrage en Assumed breach permet de focaliser l’évaluation sur la capacité de l’organisation à contenir et détecter une présence post‑compromission.

Exemple d’une approche Assumed Breach dans un environnement On-Prem AD

Lors d'un test d’intrusion interne, le périmètre peut vite devenir très large : Active Directory, serveurs métiers, différentes zones réseau, applications internes, etc. Il est alors rarement réaliste d’observer en profondeur l’ensemble de l’environnement dans une fenêtre de temps limitée.

Dans ce contexte, l’approche Assumed Breach est particulièrement pertinente. Plutôt que de chercher à tout couvrir, un point de départ est fixé et l’audit se concentre sur l’analyse d’une zone spécifique, avec une question directrice simple : si cette brique est compromise, quel est l’impact réel sur le SI ?

Un cas que nous avons rencontré récemment est l’audit d’une solution d’ordonnancement qui s’intègre à un Active Directory pour lancer des tâches planifiées sur l’ensemble des serveurs du domaine, mais aussi sur des machines déployées sur Azure. À partir de là, les auditeurs ont démarré l’audit avec un compte présent sur l’un des serveurs recevant des tâches planifiées.

Au cours de l’audit, suite à l’analyse des bibliothèques de la solution d’ordonnancement, les auditeurs sont parvenus à découvrir la clé de chiffrement permettant de gérer l’ensemble des secrets de la solution. Par ailleurs, des fichiers de configuration contenaient des mots de passe chiffrés donnant accès à la console principale de l’application ainsi qu’à une base de données MS SQL. Grâce à la clé obtenue, les mots de passe ont pu être récupérés en clair.

Dans un premier temps, l’accès à la console d’administration a permis de confirmer que les auditeurs étaient en mesure de lancer des tâches planifiées sur l’ensemble des machines du réseau. Ensuite, avec l’accès à la base de données de la solution, de nombreux autres identifiants ont pu être récupérés, notamment des comptes de service à privilèges dans l’AD, mais aussi des comptes permettant d’accéder à l’infrastructure Azure.

Cet audit en mode Assumed Breach a ainsi permis de démontrer l’impact de la compromission d’un serveur recevant des ordres de la solution d’ordonnancement : il devenait possible de compromettre l’environnement Active Directory, mais également de se déplacer latéralement vers la partie cloud du SI, avec des accès privilégiés sur Azure. Nous avions réalisé des missions de test d’intrusion interne pour ce client auparavant, mais aucune n’avait permis de remonter les informations découvertes lors de ce test Assumed Breach.

Exemple d’une approche Assumed Breach dans un environnement cloud

Si nous nous plaçons dans le cadre d’un pentest web classique ou d’un test d’intrusion externe sur un périmètre hébergé sur une plateforme cloud (AWS, Azure ou GCP), l’audit va se concentrer principalement sur la surface applicative : API, authentification, logique métier, gestion des sessions, exposition de données, etc. Il arrive cependant que la mission n’aboutisse pas à un accès direct au socle cloud : seules des failles web « classiques » sont identifiées, sans permettre d’atteindre l’infrastructure sous-jacente ni les composants managés (stockage, fichiers, secrets, fonctions serverless…).

Dans ce scénario, à noter le contexte était le suivant : la sécurité de l’environnement cloud n’a pas réellement été éprouvée, ni même la robustesse des identités et des permissions qui font fonctionner l’application (rôles, comptes techniques, comptes CI/CD, workloads). Ainsi, l’audit n'aurait pas permis de démontrer concrètement l’impact si un attaquant parvenait à obtenir un accès au cloud (par exemple via l’obtention d’un jeton d’authentification ou la compromission d’un compte).

C’est ici que l’approche Assumed Breach prend tout son sens. En démarrant avec un compte disposant de droits plus ou moins privilégiés sur l’infrastructure (par exemple un rôle IAM, un compte d’exploitation ou une identité de déploiement), l’auditeur peut se concentrer sur l’analyse des chemins de compromission au sein de l’environnement : validation des permissions effectives, identification des risques d’élévation de privilèges, et évaluation des accès indirects à des données sensibles via les services managés.

Un outil comme CloudPEASS peut être utilisé pour avoir une première vision sur les permissions associées au compte avec un inventaire des droits et des services accessibles afin d’orienter l’analyse sur les scénarios les plus pertinents en termes d’impact et de propagation, sans se limiter au seul périmètre applicatif.

Conclusion

Qu’il s’agisse d’un pentest interne ou d’un pentest web/externe sur une application hébergée dans le cloud, le même constat revient souvent : le périmètre réel est trop vaste pour être analysé partout en profondeur dans un temps contraint.

L’approche Assumed Breach répond précisément à cette limite en fixant un point de départ réaliste avec par exemple un serveur interne déjà compromis ou bien un compte disposant de droits sur l’infrastructure cloud pour mesurer l’impact concret : jusqu’où un attaquant peut-il aller, quelles données sont atteignables, et quels chemins de compromission sont réellement exploitables.

Ainsi, en complément d’un pentest “classique”, ces missions permettent donc de passer d’une logique de couverture à une logique d’impact, et d’orienter les priorités de sécurisation sur ce qui compte le plus : réduction des privilèges, maîtrise des secrets, cloisonnement, et capacité de détection/réaction face à une compromission plausible.