Une architecture commune pour les tests offensifs agentiques

Le paysage actuel est composé d’outils hétérogènes aux stratégies produit et cas d’usage très variés : tests de sécurité web externe, revues d’infrastructure interne et Active Directory, évaluations de sécurité cloud, ou analyse de code source proche du pipeline CI/CD.

Dans leurs meilleures configurations, les systèmes les plus aboutis sont aujourd’hui capables de mener des revues de sécurité statiques et dynamiques autonomes avec de fortes capacités de raisonnement, et un workflow qui ressemble souvent à la posture analytique d’un pentesteur humain.

L’efficacité de beaucoup de ces outils est évaluée en interne ou via des environnements de capture-the-flag, les CTF offrant un moyen objectif de comparer la profondeur de raisonnement, les capacités d’exploitation et l’usage des outils. Malgré la diversité des architectures, on retrouve les composants essentiels suivants dans la plupart des solutions :

• Un orchestrateur : Cette couche coordonne les agents et leur parallélisme, gère les blocages et timeout, orchestre les workflows préconfigurés, et relie les composants en une chaîne d’exécution cohérente.
• Un LLM sous-jacent : Le modèle constitue le noyau cognitif du système, alternant boucles de raisonnement, invocation d’outils et création de sous-agents selon les besoins. La capacité à utiliser des outils est indispensable et les LLM « state-of-the-art » donnent généralement de meilleurs résultats.
• Une boîte à outils offensive : La plupart des plateformes s’appuient sur un kit d’outils conteneurisé globalement aligné sur un standard de type Kali. Le contenu exact varie selon les cas d’usage, mais l’outillage typiquement requis pour des tests web reste par exemple assez standard et limité. De nombreuses solutions permettent également à l’agent de télécharger des outils supplémentaires ou de cloner des dépôts GitHub à la demande.
• Un ensemble de « skills » ou packs de connaissance : Ces bibliothèques locales formalisent une expertise réutilisable, incluant des techniques d’attaque spécifiques à certaines technologies, des cheatsheet de pentesteurs, des workflows d’exploitation standards, ou bien des détails sur les vulnérabilités ou scénarios d’attaque récents

Cette dernière couche est souvent celle où les éditeurs peuvent se différencier le plus clairement. Des capacités solides de veille cyber, de Threat Hunting et de Cyber Threat Intelligence permettent d’actualiser en continu cette base de connaissances et d’améliorer la confiance dans la couverture réelle assurée par ces agents automatisés.

Ces agents étant capables d’exécuter des actions offensives en environnements de production, l’observabilité et la supervision sont essentielles. La plupart des implémentations incluent donc journalisation, télémétrie, et rejeu de session, ainsi que des mécanismes d’approbation humaine pour certaines actions, ou des garde-fous distinguant les modules à faible risque des commandes ou chemins d’exploitation plus dangereux.

Il est également important de distinguer les systèmes pleinement agentiques des produits qui n’utilisent l’IA que de façon sélective. En pratique, de nombreuses plateformes éditeurs reposent sur des workflows majoritairement déterministes, parfois orchestrés par des modèles plus petits et spécialisés, avant de déléguer uniquement les étapes d’exploitation les plus ambiguës à un modèle généraliste plus capable.

Étude de cas : efficacité

Étude de cas : CTF

Pour évaluer l’efficacité actuelle du pentest agentique, nous avons réalisé des tests d’une telle solution (Strix) avec plusieurs modèles différents sur un ensemble interne de challenges CTF Wavestone pour lesquels aucun write-up public n’était disponible. L’objectif n’était pas de comparer des produits entre eux, mais de comprendre comment la qualité du modèle influence les résultats, sur un cas d’usage web.

Le choix de l’exploitation web est pertinent, combinant une large couverture thématique avec des niveaux de difficulté variés. Toutefois, l’exercice ne doit pas être sur-généralisé : il ne représente pas fidèlement d’autres contextes spécifiques tels que les tests internes ou les évaluations Active Directory.

Plusieurs conclusions ont émergé de cet exercice :

• Les résultats ne deviennent véritablement impressionnants que lorsque le système est associé à un modèle LLM de pointe.
• À l’inverse, les modèles pouvant réaliste​ment tourner sur un poste de travail haut de gamme tendent encore à produire des performances médiocres en test offensif, ce qui fait des fournisseurs IA SaaS la seule solution effective aujourd’hui.
• Des modèles puissants peuvent toutefois manquer des vulnérabilités exploitables, tandis que certains modèles de grande taille, mais moins optimisés, peuvent sous-performer, potentiellement car Strix n’a pas été conçu et calibré pour eux.
• Des modèles plus petits font parfois preuve d’éclairs de génie, résolvant des challenges qui résistent aux modèles plus puissants.
• Sans surprise, on observe une tendance persistante à l’hallucination de chemins d’exploitation, notamment lorsque les LLM atteignent une impasse (dans les CTF, cela se manifeste souvent par des flags inventés).
• Pour ne pas polluer leur contexte avec de grands volumes de données, les agents ont tendance à tronquer massivement les données (pages web, fichiers de code, …) et à être trop spécifiques dans leurs recherches (“grep” ou “find”). Dans les deux cas, ce comportement peut limiter leur couverture du périmètre et leur efficacité globale.

Ces résultats doivent être interprétés avec prudence. Pour chaque modèle et chaque challenge, le benchmark a été limité à au plus deux exécutions. Dans plusieurs cas, un modèle pouvait être très proche de la solution avant d’halluciner la dernière étape, ou nécessiter une intervention humaine pour clore l’investigation. Typiquement, ces cas pourraient être rattrapés par une revue humain.

Il est clair que les meilleurs résultats du benchmark ont été obtenus avec des modèles propriétaires de pointe. D’après nos observations, ces modèles peuvent résoudre une part substantielle des tâches offensives tout en restant opérationnellement abordables; du moins tant que les sessions convergent rapidement.

Ce que cela nous montre :

• Le coût par challenge peut rester relativement modeste, de l’ordre de quelques euros lorsque l’agent converge efficacement.
• L’exécution peut être étonnamment rapide, avec de nombreux CTF résolus en moins de cinq minutes lorsque le modèle identifie le bon chemin tôt dans son investigation.
• Les échecs peuvent se révéler coûteux. Sans garde-fous stricts sur la durée et le budget, la consommation de tokens peut augmenter considérablement, et ce sur quelques heures.
• Dans notre configuration, le taux de réussite des modèles commerciaux de pointe étaient identiques, mais l’efficacité variait substantiellement en termes de temps, de consommation de tokens et de nombre d’invocations d’outils. De façon surprenante, dans ce contexte CTF, malgré un prix au token plus élevé pour Sonnet 4.6, le coût total des sessions tend à s’équilibrer avec GPT-5, le modèle d’Anthropic compensant par une meilleure efficacité en tokens. 

Étude de cas : application web réelle

Pour compléter les benchmarks CTF, nous avons également testé l’une de nos applications web développées en interne (utilisée pour la gestion des RH et des performances). Le système a été évalué avec plusieurs approches, notamment des modes authentifiés dans lesquels l’agent se voit fournir des identifiants ou des jetons d’authentification.

Au cours d’une session représentative, 25 agents et sous-agents ont été déployés, 366 appels d’outils ont été exécutés, pour un coût total d’environ 5 USD, la session ayant duré environ une heure. Le rapport généré automatiquement affichait une synthèse managériale, une section méthodologique orientée OWASP, des conclusions techniques avec scoring CVSS v3, ainsi qu’une feuille de route de remédiation priorisée.

Les résultats sont mitigés, mais globalement instructifs après revue humaine et re-test :

• L’agent a identifié plusieurs axes d’amélioration mineurs mais pertinents, bien que les conclusions n’aient pas toujours été bien contextualisées et aient pu devenir excessivement alarmistes.
• Lacune critique : l’agent a complètement manqué une interface d’administration exposée avec des identifiants par défaut; une vulnérabilité qu’aucun pentesteur humain n’aurait ignorée. C’est l’illustration la plus nette du plafond de fiabilité actuel de ces systèmes.
• De plus, le rapport présentait également une vulnérabilité inexistante (confusion d’algorithme JWT) relevée comme critique, accompagné de scripts Proof-of-Exploitation ne fonctionnant logiquement pas. Cela illustre le risque persistant de faux positifs au sein des LLM.

Plusieurs remarques complémentaires :

• Comme pour les benchmarks CTF, la qualité de la revue s’améliore significativement avec un modèle SaaS de pointe.
• La nature non déterministe des LLM reste visible : deux exécutions peuvent produire des conclusions et des rapports substantiellement différents pour une même cible.
• Si les contrôles de périmètre sont insuffisants, certains modèles ont une tendance à élargir le périmètre du pentest, sondant des ports, applications ou sous-domaines adjacents.
• La couverture et la pertinence s’améliorent nettement en modes boîte blanche ou hybride boîte blanche/boîte grise, où l’agent peut inspecter le code source, identifier des faiblesses candidates, puis tenter de les valider dynamiquement sur l’application en production. Même dans ce cas, certains agents peuvent encore se focaliser sur des problèmes inexistants. De plus, en boîte blanche, de très grandes bases de code peuvent saturer le système et réduire l’efficacité globale.
• Les capacités de ces solutions à émuler un comportement humain a nettement progressé, notamment les interactions pilotées avec les navigateurs web. Toutefois, certains types d’applications restent difficiles à évaluer de manière autonome, notamment des cas de figures « multi-fenêtres » ou les clients lourds, pour lesquels une interaction navigateur en mode headless peut ne pas suffire.
• Ces systèmes construisent rarement une compréhension approfondie de la logique métier. Leurs résultats restent fortement alignés sur des patterns génériques de type OWASP et ne challengent pas les risques métier réels ou les scénarios d’attaque de manière suffisamment contextuelle.

On notera que la majorité de ces reproches peuvent également être applicables à des pentesters humains, ces derniers restant toutefois davantage responsabilisable.

Le problème de passage à l’échelle reste central. Les CTF ne sont que partiellement représentatifs des applications réelles. Un CTF aura généralement tendance à guider le participant vers un chemin d’attaque étroit et délibéré, alors que même une application métier modeste exposera une surface bien plus large. Aujourd’hui, garantir une couverture exhaustive pour des applications réelles reste complexe.

Verdict et limites actuelles

Verdict

Si l’on considère des solutions reposant entièrement sur un LLM pour leur arbre de décision, la conclusion est claire à ce stade : seuls les modèles de pointe des principaux fournisseurs IA produisent systématiquement des résultats à la fois pertinents et raisonnablement vérifiables.

Nous pouvons considérer quatre options de déploiement pratiques :

• Les services LLM SaaS, qui offrent actuellement la meilleure qualité via des LLM avancés (>1T paramètres), sur une base de paiement à l’utilisation.
• Les déploiements en grands datacenters privés, capables de faire tourner des modèles puissants (500b) et pouvant devenir de plus en plus pertinents pour le pentest, mais restant encore sensiblement en deçà des meilleurs systèmes frontier commerciaux.
• Les déploiements en datacenters privés plus modestes, capables de faire tourner des modèles compétents (300b), mais clairement insuffisants pour orchestrer efficacement des pentests autonomes.
• Les postes de travail dédiés, qui, même avec des spécifications très élevées, peinent rapidement au-delà de 100b de paramètres et restent largement insuffisants aujourd’hui.

La dépendance aux fournisseurs SaaS soulève des questions inévitables de souveraineté et de confidentialité. Les tests d’intrusion consolident souvent des informations techniques très sensibles sur les faiblesses cyber d’une organisation. L’externalisation des prompts, traces, conclusions ou hypothèses d’attaque nécessite ainsi une gouvernance rigoureuse. En complément, l’anonymisation des données en amont du LLM n’est pas une solution fiable : elle dégrade les performances de l’agent tout en laissant fuiter des métadonnées potentiellement exploitables vers le fournisseur SaaS.

Dans leur état actuel, même équipés des LLMs les plus capables, ces systèmes présentent également des limitations structurelles qui affectent directement la fiabilité :

• Des phénomènes de “tunnel”, avec une fixation trop prolongée de l’agent sur un unique chemin d’attaque non pertinent.
• Une tendance à lancer des activités de bruteforce chronophages et consommatrice sans appréciation de la complexité ou du coût computationnel.
• La problèmatique des hallucinations, sur laquelle d’immenses progrès ont été réalisés, mais qui peut encore affecter les LLM, y compris les plus complexes.

• La nature non déterministe des LLM, rendant certaines exécutions bien moins efficaces et pertinentes que d’autres, confirmant l’utilité de ces agents dans une approche continue ou régulière.
• Des difficultés de passage à l’échelle liées aux contraintes de fenêtre de contexte : ces outils permettent un passage à l’échelle dans le sens où l’on peut lancer autant de sessions parallèles que de cibles. Cependant, le passage à l’échelle est plus complexe lorsqu’une session unique est lancée contre une unique application hautement complexe. Il devient alors beaucoup plus difficile de maintenir une couverture exhaustive et une continuité de mémoire sur des applications larges et riches en contenu. D’importantes améliorations sont possibles sur ce volet, une gestion efficace de la mémoire à long terme permettant des exécutions plus cohérentes pour les grandes applications et améliorant la confiance dans le couverture.
• Une verbosité élevée et une furtivité limitée, qui rendent ces systèmes peu adaptés dans leur configuration par défaut aux opérations Red Team, qui nécessitent davantage de discrétion. Cela peut toutefois être amélioré par une configuration dédiée, sans toutefois promettre d’égaler les capacités d’un Red Teamer humain.

De manière plus générale, un processus autonome piloté en SaaS et ayant la capacité d’exécuter des commandes à distance dans vos SI pose d’emblée la question de la responsabilité :

• Classer les modules comme dangereux ou sûrs peut ne pas suffire, par exemple avec des outils couteaux-suisses, capables d’une reconnaissance anodine et d’exploits agressifs et potentiellement dangereux. Le niveau de menace de chaque commande devrait être évalué dynamiquement, en tenant compte du contexte et des tests précédents.
• S’appuyer sur une approbation humaine peut également avoir ses limites : au même titre que pour les solutions de vibe coding, une « fatigue » humaine peut rapidement s’installer, où les utilisateurs deviennent trop confiants et cessent de remettre en question les conclusions de l’agent.

Et bien entendu, toute vulnérabilité au niveau du LLM, telle qu’une susceptibilité au prompt injection ou à l’empoisonnement, pourrait être exploitée pour détourner l’agent de pentest automatisé. En substance, ces outils autonomes, s’ils sont déployés en interne, doivent être considérés comme des actifs critiques, très interessants pour de potentiels attaquants.

Où l’architecture peut s’améliorer

Au-delà de la qualité du modèle lui-même, une part substantielle des améliorations possibles réside dans la conception globale du système. Plusieurs directions architecturales apparaissent prometteuses :

• Multiplier les sessions et les passes de validation, en utilisant une exploration continue, des phases de zoom ciblées et des boucles de confirmation explicites. La fiabilité s’en voit améliorée, au prix d’une augmentation du coût, de la durée, et de la complexité de la solution.
• Introduire des instances de validation dédiées pour confirmer l’exploitabilité dans un environnement contrôlé avant que les conclusions ne soient intégrées dans un rapport.
• Utiliser des arbres de décision plus légers ou des modules spécialisés en amont de l’exploitation, en réservant les modèles haut de gamme uniquement pour les parties du workflow qui nécessitent vraiment adaptabilité et raisonnement.
• Faire précéder la phase autonome d’une phase préliminaire de tests scriptés, puis alimenter l’agent avec les sorties structurées. C’est approche apparait bien plus rentable que de dépenser du contexte et des tokens LLM sur des tâches déjà faciles à automatiser sans IA. Le principe de base doit être simple : ne pas utiliser l’IA là où l’automatisation conventionnelle fonctionne déjà bien. Déléguer au LLM uniquement les taches véritablement ambiguës, et éviter de surcharger le modèle avec un long historique de commandes.

En pratique, ce dernier point est déjà la direction prise par de nombreuses plateformes éditeurs. Elles ne s’appuient pas entièrement sur l’IA agentique ; elles combinent plutôt une logique déterministe avec une exploitation agentique.

Enfin, une réflexion intéressante : ces solutions automatisées pouvant être utilisées par de vrais attaquants, nous pourrions voir émerger des mécanismes “anti-IA” intégrés dans les applications, tels que des “labyrinthes de liens” et des honeypots draineurs de tokens conçus spécifiquement pour induire en erreur ou épuiser les systèmes de test automatisés.

Avec des modèles suffisamment puissants, les systèmes agentiques peuvent déjà exceller dans des environnements contraints comme les CTF. Leurs performances dans les évaluations d’applications réelles sont plus mitigées : souvent utiles, parfois impressionnantes, mais encore trop incohérentes pour être utilisées sans supervision humaine.

La voie la plus pragmatique aujourd’hui est donc un modèle opérationnel hybride : un système agentique réalisant la majorité des tests et proposant des directions d’investigation, accompagné de pentesters humains arbitrant, validant et prenant le relai dans les cas les plus complexes. On a ainsi une évaluation sécurité bien moins longues, tout en garantissant un degré de couverture et de pertinence des résultats.

L’IA agentique ne s’annonce donc pas comme remplacement à l’humain. À son niveau de maturité actuel, elle est mieux appréhendée comme un multiplicateur de force, capable d’accélérer l’exploration et le tri, mais qui dépend encore de la supervision d’experts pour transformer une activité autonome brute en résultats de sécurité fiables. Dans tous les cas, ces systèmes doivent être considérés comme hautement sensibles en raison de leur nature autonome, et les contraintes actuelles liées aux modèles hébergés en SaaS doivent être prises en compte, en termes de confidentialité des données et de souveraineté numérique.

Sans être encore pleinement matures, ces solutions commencent à laisser une empreinte dans le paysage de la cybersécurité, et modifieront très probablement la trajectoire du marché du pentest, vers un écosystème davantage centré autour d’outils et de ressources de calcul, tout en conservant une approche hybride. Nous pourrions même voir des audits suivre un modèle “Bring Your Own Compute”, où les audités fournissent le LLM, et les auditeurs fournissent les outils et « skills ».

Cet article IA Agentique pour la Sécurité Offensive est apparu en premier sur RiskInsight.

Kerberos est un protocole d’authentification réseau reposant sur un mécanisme de clés secrètes (chiffrement symétrique) et l’utilisation de tickets. Il fait partie intégrante des système d’exploitation Windows depuis la version Serveur 2000. Différents termes spécifiques sont utilisés pour détailler ce protocole :

• KDC (Key Distribution Center) : Le KDC est un service installé sur les contrôleurs de domaine et permettant l’obtention des différents tickets par un utilisateur.
• TGT (Ticket-Granting Ticket) : Le TGT est un ticket attribué par le KDC à un utilisateur. Ce ticket représente l’identité de l’utilisateur, et lui permet d’effectuer des demandes de TGS auprès du KDC.
• TGS (Ticket-Granting Service) : Le TGS est également un ticket attribué par le KDC pour représenter un utilisateur. Il permet à l’utilisateur de s’authentifier auprès d’un service spécifique, dont le nom est inscrit dans le ticket. Un exemple d’un tel ticket est le suivant :

Le schéma d’une authentification Kerberos classique est le suivant :

Dans la première étape, l’utilisateur envoi au contrôleur de domaine un timestamp chiffré à l’aide du hash NTLM de son mot de passe. Ayant accès à ce hash, le contrôleur de domaine, et plus précisément le KDC, peut déchiffrer l’information reçue et vérifier le timestamp, ce qui prouve l’identité de l’utilisateur. Le KDC fournit alors à l’utilisateur son TGT (étape 2).

L’utilisateur peut alors fournir le TGT préalablement récupéré pour effectuer une demande de TGS (étape 3). Le TGT étant représentatif de l’utilisateur, le KDC peut valider son identité et lui fournir un TGS pour le service demandé (étape 4).

Enfin, l’utilisateur transmet ce TGS comme preuve de son identité auprès du service (étape 5).

Dans le protocole Kerberos, ce sont donc bien les tickets qui permettent d’assurer l’identité d’un utilisateur, au même titre qu’un couple nom d’utilisateur / mot de passe le fait dans une authentification classique.

Introduction aux délégations Kerberos

Microsoft a introduit les délégations Kerberos dans l’objectif de permettre à une application de réutiliser l’identité d’un utilisateur pour accéder à une ressource hébergée sur un serveur différent. Un cas d’usage est par exemple l’accès à des documents hébergés sur un serveur dédié depuis une plateforme SharePoint :

L’utilisateur n’ayant pas d’accès direct au serveur de fichiers, il s’authentifie sur la plateforme SharePoint qui doit alors transmettre l’identité de l’utilisateur au serveur de fichiers.

Cependant, les tickets de service étant délivrés pour une application spécifique, le SharePoint ne peut transmettre directement le ticket qu’il a reçu de l’utilisateur. C’est donc pour répondre à cette problématique que Microsoft a mis en place les délégations Kerberos, qui existent sous deux formes :

• Les délégations non contraintes, apparues avec le système d’exploitation Windows Serveur 2000, et qui donnent l’autorisation à un compte de service de réutiliser l’identité de l’utilisateur sur n’importe quel service du domaine ou de la forêt.
• Les délégations contraintes, apparues avec le système d’exploitation Windows Serveur 2003, et qui permettent un meilleur contrôle en limitant les services sur lesquels un compte de service donné peut s’authentifier en tant que l’utilisateur.

Les délégations Kerberos non contraintes

Le schéma d’authentification d’un utilisateur désirant accéder à une ressource dans le cas d’une délégation Kerberos non contrainte est le suivant :

Lors de la première étape de ce schéma, l’utilisateur effectue une demande de TGT auprès du contrôleur de domaine, en lui transmettant un timestamp chiffré avec le hash NTLM de son mot de passe. Après avoir validé son identité, le contrôleur de domaine fournit un TGT à l’utilisateur (étape 2), comme il le ferait pour une authentification Kerberos classique.

Pour s’authentifier auprès de l’application SharePoint, l’utilisateur demande alors un TGS au contrôleur de domaine, en lui fournissant le TGT précédemment récupéré (étape 3). Dans le cas d’une délégation Kerberos non contrainte, le contrôleur de domaine construit le TGS de l’utilisateur à partir de son TGT, qu’il chiffre à l’aide du hash NTLM du mot de passe du compte de service utilisé par l’application SharePoint (étape 4).

L’utilisateur s’authentifie alors sur l’application SharePoint (étape 5) en transmettant le TGS que lui a fourni le contrôleur de domaine lors de l’étape précédente.

Le compte de service de l’application SharePoint peut déchiffrer ce TGS étant donné qu’il est chiffré avec son propre hash. Il récupère ainsi le TGT de l’utilisateur, qu’il peut fournir au contrôleur de domaine pour effectuer une demande de TGS pour le serveur de fichier (étape 6). Le TGT étant celui de l’utilisateur, le TGS renvoyé par le contrôleur de domaine (étape 7) représente son identité, et non celle du compte de service.

Le compte de service de l’application SharePoint peut alors transmettre ce TGS (étape 8), que le serveur de fichiers validera comme s’il provenait de l’utilisateur lui-même, donnant accès au document demandé (étape 9).  Ayant récupéré ce document, l’application SharePoint peut le fournir à l’utilisateur, pour lequel les phases d’authentification intermédiaires auront été transparentes.

Les délégations Kerberos contraintes

Dans le cas d’une délégation Kerberos contrainte, deux extensions de protocole sont utilisées pour permettre à une application de réutiliser l’identité de l’un de ses utilisateurs :

S4U2Self (Server-for-User-to-Self) qui autorise un service à obtenir un TGS pour lui-même en tant qu’un utilisateur.

S4U2Proxy (Server-for-User-to-Proxy) qui autorise un service à obtenir un TGS pour un autre service en tant qu’un utilisateur.

La cinématique d’authentification et d’accès aux ressources dans le cas d’une telle délégation est alors la suivante :

Dans la première étape de cette cinématique, l’utilisateur s’authentifie après du premier service en lui transmettant ses identifiants. L’authentification n’utilisant pas Kerberos, l’utilisateur n’a pas besoin de s’authentifier auprès du contrôleur de domaine.

Le compte de service demande alors un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès de son propre service (étape 2). Le compte de service possédant l’extension S4U2Self, le contrôleur de domaine accorde ce ticket (étape 3).

Ce même compte de service demande ensuite un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès du second service (étape 4). Après validation de l’extension S4U2Proxy, le contrôleur de domaine accorde ce TGS (étape 5)

Grâce à ce second ticket de service, le compte de service du SharePoint peut accéder aux ressources du serveur de fichier avec l’identité de l’utilisateur (étape 6). Le serveur de fichiers valide les privilèges de l’utilisateur, et transmet le document demandé au compte de service SharePoint (étape 7), qui le transmet à l’utilisateur (étape 8).

Contrairement au cas des délégations non contraintes, l’utilisation de l’extension de protocole S4U2Proxy permet de spécifier les services accessibles au compte de service SharePoint. Ainsi, même si l’utilisateur dispose des privilèges nécessaires pour accéder à un autre serveur, le compte de service ne pourra récupérer de TGS valide représentant l’identité de l’utilisateur. Dans le cas d’une délégation contrainte, cette restriction se fait à l’aide d’un paramètre du compte de service, appelé SPN pour Service Principal Name.

Il est à noter que depuis la version Serveur 2012 du système d’exploitation Windows, un troisième type de délégation Kerberos est proposée, les délégations Kerberos contraintes basées sur les ressources. Le fonctionnement de ces délégations est similaire à celui des délégations contraintes, mais la restriction est effectuée en spécifiant explicitement le compte ayant accès aux ressources.

Exploiter les délégations non contraintes

Les faiblesses induites par les délégations Kerberos non-contraintes sont connues depuis plusieurs années. Sean Metcalf a, par exemple, présenté les dangers de telles délégations à la Black Hat USA 2015. Dans la cinématique d’authentification présentée précédemment, il est en effet évident que le compte de service de l’application SharePoint peut, une fois que l’utilisateur lui a transmis un TGS contenant son TGT, accéder à l’ensemble des services pour lesquels l’utilisateur dispose de privilèges nécessaires.

L’objectif d’un attaquant est alors d’obtenir le TGT d’un administrateur du domaine, ce qui lui permet de se connecter au contrôleur de domaine avec les privilèges maximum pour changer le mot de passe du compte krbtgt afin de pouvoir forger ses propres tickets à la demande.

Pour parvenir à cela, il est d’abord nécessaire d’identifier les services qui disposent de délégations non contraintes. Pour cela, il suffit de filtrer les objets de l’Active Directory à la recherche de paramètres TrustedForDelegation valant True. Ce paramètre indique en effet la présence d’une délégation non contrainte, et est de plus accessible sans privilège particulier, par exemple à l’aide de la commande Get-ADComputer du module ActiveDirectory :

Une fois les services disposant d’une délégation Kerberos non contrainte identifiés, il est nécessaire d’obtenir des privilèges administrateur sur l’un des serveurs sur lesquels ils sont utilisés. Les méthodes de compromission classiques peuvent alors être utilisées, mais ne seront pas abordées dans cet article.

En cas d’accès au service par un administrateur du domaine, l’attaquant sera en mesure d’extraire le TGS fourni à l’aide par exemple de l’outil mimikatz et de la commande suivante :

Comme indiqué dans le scénario d’authentification, ce TGS contient le TGT de l’administrateur, que l’attaquant pourra extraire afin de réaliser une attaque Pass-The-Ticket pour se connecter au contrôleur de domaine.

Les recommandations pour protéger un domaine d’une telle attaque sont alors les suivantes :

• Utiliser des délégations Kerberos contraintes qui sont plus restrictives
• Configurer l’ensemble des comptes à privilèges avec le paramètre « Le compte est sensible et ne peut être délégué » qui empêche la réutilisation de l’identité du compte par une application possédant une délégation

Dans le cas d’un domaine au niveau fonctionnel supérieur à Windows Serveur 2012 R2, le groupe de sécurité « Utilisateurs protégés » peut être utilisé pour les comptes à privilèges étant donné que les délégations ne sont pas autorisées pour les comptes de ce groupe.

Qu’en est-il des délégations contraintes ?

L’utilisation de délégations contraintes semble être une alternative plus sécurisée. Cependant, différents éléments sont à noter concernant ce mécanisme d’authentification, comme l’a présenté Matan Hart lors de la Black Hat 2017. En effet, les deux extensions de protocole utilisées ont été pensées avec les principes suivants :

• Les deux extensions permettent à un service Kerberos d’obtenir des TGS sans même que l’utilisateur n’ait besoin de s’authentifier auprès du contrôleur de domaine.
• L’extension S4U2Self permet au service d’obtenir un TGS pour l’utilisateur sans qu’aucun mot de passe ne soit nécessaire.

De ce fait, un service qui possèderait les deux extensions pourrait obtenir un TGS pour n’importe quel autre service en se faisant passer pour un utilisateur, et ce sans nécessiter son mot de passe.

Matan Hart a publié son outil « Mystique[1] » qui permet d’identifier des configurations à risque pour les délégations. Pour cela, il liste les comptes qui disposent du paramètre TrustedToAuthForDelegation valant True, indiquant une délégation contrainte, ainsi que d’un paramètre MsDS-AllowedToDelegateTo non nul, indiquant l’utilisation d’un SPN, ce qui est obligatoire pour les comptes de délégation.

Il est également à noter que les TGS sont validés selon deux critères, le hash du mot de passe de l’utilisateur, et le SPN possédé par le compte de service qui possède la délégation contrainte. En cas de multiples SPNs associés à un même compte de service, et de mot de passe partagé entre différents comptes, les tickets pour deux services distincts seront complétement interchangeables, ce qui pourrait permettre à un service de réutiliser l’identité d’un utilisateur de manière illégitime.

Ces faiblesses ne sont pas considérées comme des vulnérabilités par Microsoft, et ne sont donc pas amenées à changer. Lors de la création d’une délégation Kerberos contrainte, il est alors nécessaire de faire attention aux points suivants pour se protéger des attaques :

• Configurer les services à l’aide de comptes de service dédiés, évitant ainsi le partage des comptes qui pourrait aboutir à des tickets interchangeables. Il est également important d’assurer une bonne complexité des mots de passe, ainsi qu’une rotation régulière.
• Configurer des SPNs uniques comme étant autorisés pour la délégation, en évitant les SPNs par défaut de Microsoft, et en spécifiant les ports utilisés.
• Comme pour les délégations non contraintes, configurer les comptes à privilèges comme étant des comptes sensibles ne pouvant être délégués.

Conclusion

L’utilisation de délégations contraintes n’est pas totalement à proscrire. Il est cependant nécessaire de bien maitriser leur configuration et les ressources auxquelles elles permettent d’accéder afin d’éviter les travers détaillés dans cet article.

Cet article Compromission d’un domaine Windows à l’aide des délégations Kerberos est apparu en premier sur RiskInsight.

La sécurité informatique a fait du chemin ces dernières années. Désormais, toute entreprise de taille respectable dispose de sa politique de sécurité des systèmes d’information. Des sessions de sensibilisation des utilisateurs à la sécurité sont réalisées. Une gouvernance sécurité s’est même mise en place : le RSSI pilote, définit des KPI, analyse ses tableaux de bords SSI. Mais la technique n’est pas non plus oubliée ; on sait désormais que rien ne vaut un test d’intrusion pour vérifier, en imitant les méchants hackers, le niveau de sécurité d’une application ou d’un SI. Et ils vécurent heureux et ne subirent aucune attaque ? Pas si sûr…

Cet article Le fardeau du pentesteur est apparu en premier sur RiskInsight.