Le pentest Windows n’est pas le sujet. Et si nous l’apprenions simplement dans le mauvais ordre ?

par

Pendant des années, lorsqu’une personne me demandait comment débuter le pentest Windows, je donnais probablement la même réponse que beaucoup d’autres :

Installe Kali Linux, ouvre Hack The Box et commence à pratiquer.

Ce conseil n’est pas mauvais. Il m’a moi-même énormément appris, mais avec le temps, une question a commencé à me déranger.

Apprenons-nous réellement Windows… ou apprenons-nous surtout à utiliser des outils ?

La nuance peut sembler subtile.

Je pense pourtant qu’elle change complètement la manière de progresser.

Aujourd’hui, il existe d’excellents outils capables de cartographier Active Directory, manipuler Kerberos, exploiter Active Directory Certificate Services ou automatiser des attaques complexes en quelques commandes.

Ils sont devenus indispensables.

Mais ils peuvent aussi produire un effet inattendu : nous donner rapidement des résultats sans toujours nous obliger à comprendre les mécanismes que nous manipulons.

Au fil des années, je me suis rendu compte que chaque fois que je voulais réellement comprendre une attaque, je finissais par revenir aux protocoles et aux mécanismes Windows qui se cachaient derrière les outils.

C’est cette réflexion qui m’a conduit à remettre en question quelque chose que je considérais pourtant comme une évidence.

Et si nous apprenions simplement le pentest Windows dans le mauvais ordre ?

Les outils ne sont pas des connaissances

Je pense qu’il existe une confusion assez répandue dans notre métier : nous confondons parfois la maîtrise d’un outil avec la compréhension du système qu’il manipule.

Savoir lancer BloodHound ne signifie pas comprendre les ACL. Savoir utiliser Rubeus ne signifie pas comprendre Kerberos. Savoir identifier une ESC1 avec Certipy ne signifie pas comprendre Active Directory Certificate Services.

Ces outils sont extrêmement puissants, mais ils constituent avant tout des interfaces vers des mécanismes qui existaient bien avant eux.

Beaucoup moins sont capables d’expliquer précisément pourquoi un contrôleur de domaine accepte de délivrer le ticket demandé, pourquoi une partie de ce ticket est protégée avec une clé dérivée du secret du compte de service et, surtout, pourquoi ce mécanisme permet ensuite une attaque hors ligne.

Pour répondre à ces questions, Rubeus ne nous aide plus vraiment. Il faut comprendre Kerberos.

Comprendre Kerberos avant d’apprendre Kerberoasting

Il existe une phrase que j’entends souvent lorsqu’on attaque un lab Active Directory.

Kerberoasting, c’est quand on demande un ticket puis on le casse avec Hashcat.

C’est techniquement correct, mais cela n’explique pas pourquoi l’attaque fonctionne.

Pour le comprendre, oublions quelques minutes Rubeus, NetExec et Impacket et revenons au fonctionnement normal de Kerberos.

Son objectif est notamment de permettre à un utilisateur authentifié d’accéder à des services sans avoir à retransmettre son mot de passe à chacun d’eux.

Et c’est précisément dans ce mécanisme que Kerberoasting trouve sa place.

Comment fonctionne réellement Kerberos ?

Prenons un utilisateur classique, il ouvre une session Windows et au moment de l’authentification, son poste contacte le Key Distribution Center (KDC), qui est hébergé sur le contrôleur de domaine. Après vérification de ses identifiants, le KDC lui délivre un Ticket Granting Ticket (TGT). Ce ticket ne permet pas encore d’accéder aux ressources du domaine, il sert uniquement à prouver son identité auprès du KDC. À partir de ce moment-là, l’utilisateur n’a plus besoin de renvoyer son mot de passe, il présentera simplement son TGT.

Lorsqu’il souhaite accéder à un service, par exemple SQL Server, IIS ou un partage SMB, son poste envoie au KDC une requête TGS-REQ en présentant notamment son TGT. Le Ticket-Granting Service du KDC vérifie cette demande et retourne une TGS-REP contenant un ticket de service destiné au service demandé.

Jusqu’ici, rien d’anormal : c’est exactement ainsi que Kerberos est censé fonctionner.

Le détail qui change tout

Une question devient alors essentielle : comment le service peut-il faire confiance au ticket que lui présente le client ?

Le KDC construit un ticket de service contenant notamment l’identité du client et les informations nécessaires à la session. Mais surtout, la partie du ticket destinée au service est chiffrée avec une clé connue du KDC et du service concerné.

Dans le cas classique d’un compte de service Active Directory, cette clé est dérivée du secret de ce compte.

Ce choix est parfaitement logique : lorsque SQL Server reçoit le ticket, il doit pouvoir en déchiffrer la partie qui lui est destinée et vérifier les informations délivrées par le KDC. Le mot de passe de l’utilisateur n’a aucune raison d’intervenir ici.

Et c’est précisément cette propriété normale de Kerberos qui va rendre Kerberoasting possible.

Là où Kerberoasting apparaît

Un utilisateur authentifié peut demander un ticket de service pour un SPN auquel il souhaite accéder. Du point de vue du KDC, cette requête est parfaitement légitime : c’est exactement le fonctionnement attendu de Kerberos.

L’attaquant demande donc un ticket pour un service associé à un compte de domaine, récupère la réponse puis extrait les données cryptographiques intéressantes du ticket.

À partir de cet instant, le contrôleur de domaine n’est plus nécessaire.

C’est ce qui rend Kerberoasting particulièrement intéressant : la phase de recherche du mot de passe peut se dérouler entièrement hors ligne.

Hashcat ne « déchiffre » pas magiquement le ticket. Il prend un mot de passe candidat, applique les mécanismes de dérivation de clé correspondant au type de chiffrement Kerberos utilisé, puis vérifie si la clé obtenue produit une valeur cohérente avec les données du ticket.

Si ce n’est pas le cas, il essaie le candidat suivant, puis le suivant et ainsi de suite.

Aucun nouveau mot de passe n’est envoyé au contrôleur de domaine. Il n’y a donc pas de succession d’échecs d’authentification classiques susceptible de provoquer un verrouillage du compte. Le coût de l’attaque est essentiellement déplacé sur la machine de l’attaquant.

Et un autre détail devient alors fondamental : tous les types de chiffrement Kerberos ne présentent pas le même coût pour une attaque hors ligne.

Historiquement, RC4-HMAC est particulièrement favorable à ce type d’attaque, notamment parce que la clé repose directement sur le hash NT du mot de passe. Avec AES, la dérivation de clé est plus coûteuse et intègre notamment un salt, ce qui ralentit considérablement les essais. Cela ne rend pas un mot de passe faible invulnérable, mais cela change fortement l’économie de l’attaque.

Reste une question que l’on saute souvent : de quel type de compte parle-t-on ?

Un SPN peut être enregistré sur un compte machine comme sur un compte utilisateur, et le KDC délivrera le ticket dans les deux cas. Mais le secret qui protège la partie chiffrée n’a rien à voir.

Le mot de passe d’un compte machine est généré par le système : environ 120 caractères aléatoires, renouvelés par défaut tous les 30 jours. Le ticket se demande et s’extrait exactement de la même manière. Seulement, avec un tel secret, l’attaque hors ligne que nous venons de décrire n’a aucune chance d’aboutir.

Kerberoasting n’est donc pas une « faille de Kerberos » au sens classique. L’attaquant utilise une fonctionnalité normale du protocole et déplace ensuite l’attaque sur le secret qui protège le service. Dans le contexte du Kerberoasting, l’attaque hors ligne devient surtout réaliste lorsque le secret sous-jacent est suffisamment faible ou prévisible pour pouvoir être retrouvé.

Pourquoi les comptes de service sont-ils si souvent vulnérables ?

Historiquement, beaucoup de services Windows utilisaient des comptes de domaine classiques.

Ces comptes présentaient plusieurs caractéristiques problématiques :

  • Des mots de passe définis manuellement
  • Des mots de passe rarement modifiés
  • Des privilèges parfois très élevés
  • Des SPN enregistrés automatiquement

Autrement dit… Des candidats idéaux pour un Kerberoasting.

Un secret long et généré aléatoirement rend une attaque hors ligne rapidement irréaliste. À l’inverse, un mot de passe humain, prévisible et rarement renouvelé peut rester vulnérable même s’il respecte en apparence une politique de complexité.

En revanche, un compte de service nommé :

SQLService

avec le mot de passe :

P@ssw0rd2023!

ne survivra probablement pas longtemps face à une carte graphique moderne.

Pourquoi parle-t-on autant des cartes graphiques ?

Une attaque hors ligne repose sur un principe simple : répéter la même opération cryptographique sur un très grand nombre de mots de passe candidats.

Et ce type de calcul se parallélise particulièrement bien.

Un CPU possède relativement peu de cœurs, très puissants et conçus pour exécuter des tâches variées. Un GPU dispose au contraire de milliers d’unités de calcul capables d’effectuer simultanément un grand nombre d’opérations similaires.

C’est précisément ce dont Hashcat a besoin : tester de nombreux candidats en parallèle, dériver pour chacun la clé correspondante et vérifier si elle est compatible avec les données extraites du ticket Kerberos.

Les performances peuvent toutefois varier énormément selon le type de chiffrement utilisé. RC4-HMAC est nettement moins coûteux à attaquer hors ligne qu’AES, dont la dérivation de clé impose davantage de calculs.

C’est pourquoi la résistance d’un compte de service ne dépend pas seulement de la longueur de son mot de passe. Elle dépend aussi de son entropie, du type de chiffrement Kerberos utilisé et de la puissance de calcul que l’attaquant est capable de mobiliser.

Le problème ne vient donc pas du protocole lui-même, mais de la robustesse et de la gestion des secrets sur lesquels il s’appuie.

Les gMSA, ou comment déplacer le problème

Les Group Managed Service Accounts (gMSA) répondent notamment à ce type de problème.

Avec un gMSA, le protocole Kerberos ne change pas. Un utilisateur peut toujours demander un ticket de service pour un SPN associé au compte et le KDC continue de fonctionner selon les mêmes principes.

Ce qui change radicalement, c’est le secret sur lequel repose le compte de service.

Au lieu d’un mot de passe choisi par un administrateur, parfois conservé pendant plusieurs années pour éviter de casser un service, le mot de passe du gMSA est généré et renouvelé automatiquement par Active Directory. Il possède une entropie suffisamment élevée pour rendre une attaque de récupération du secret hors ligne irréaliste dans des conditions normales.

Autrement dit, le ticket peut toujours être demandé et récupéré. Ce qui disparaît pratiquement, c’est l’intérêt de tenter d’en retrouver le secret par cassage hors ligne.

C’est un point important : Microsoft n’a pas eu besoin de « corriger » Kerberos pour réduire fortement le risque de Kerberoasting. Il suffit de supprimer de l’équation l’élément le plus fragile : le mot de passe humain du compte de service.

Mais l’attaque ne disparaît pas, elle se déplace

Un secret devenu incassable ne rend pas le compte inintéressant. Il déplace simplement la question.

Le mot de passe d’un gMSA n’est pas stocké comme celui d’un compte classique. Il est exposé par l’attribut msDS-ManagedPassword, un attribut construit que le contrôleur de domaine calcule à la demande. Et cette demande n’est pas ouverte à tout le monde : seuls les principaux listés dans msDS-GroupMSAMembership peuvent l’obtenir.

Autrement dit, la protection du compte ne repose plus sur la robustesse d’un mot de passe. Elle repose sur une liste d’autorisation dans Active Directory.

Or une liste d’autorisation, ça se lit, ça s’audite… et ça se modifie. Si un principal que je contrôle figure dans cette liste, je n’ai plus besoin de Hashcat : je demande simplement l’attribut. Et si je dispose d’un droit d’écriture suffisant sur l’objet, je peux m’y ajouter.

Le mécanisme n’a donc pas supprimé toute possibilité de compromission. Il a déplacé une partie importante du risque du cassage de mot de passe vers le modèle d’autorisation d’Active Directory.

C’est exactement le genre de déplacement qu’un outil ne montre pas et qu’une compréhension du mécanisme rend évident.

Ce que cela change pour un pentester

Une fois le fonctionnement de Kerberos compris, Kerberoasting cesse d’être une commande à mémoriser. Il devient simplement une conséquence du fonctionnement normal de Kerberos.

Et surtout, d’autres techniques commencent à devenir beaucoup plus faciles à comprendre. AS-REP Roasting, Silver Tickets, Golden Tickets, S4U2Self, S4U2Proxy ou encore les différentes formes de délégation ne ressemblent plus à une collection d’attaques indépendantes qu’il faudrait apprendre une par une.

Elles deviennent différentes manières d’exploiter ou de détourner les mécanismes d’un même protocole.

C’est là que l’ordre d’apprentissage change réellement la donne : lorsqu’on comprend Kerberos, on n’apprend plus seulement à reproduire une attaque. On commence à comprendre pourquoi toute une famille d’attaques est possible.

BloodHound n’est pas un outil d’attaque

BloodHound illustre probablement mieux que n’importe quel autre outil l’idée que j’essaie de défendre dans cet article.

Lorsque l’on débute dans le pentest Active Directory, il donne presque une impression de magie. En quelques minutes, il peut dessiner un chemin reliant un simple utilisateur à Domain Admin et le réflexe devient alors presque naturel :

BloodHound a trouvé une vulnérabilité.

En réalité, BloodHound n’a rien créé. Il collecte des informations exposées par l’environnement Active Directory, les interprète selon son modèle puis représente les relations obtenues sous forme de graphe.

BloodHound ne crée pas la réalité. Il la rend visible.

Et pour comprendre ce que cela signifie réellement, il suffit d’observer ce qui se cache derrière une seule de ses arêtes.

Derrière chaque arête se cache Windows

Prenons un exemple très simple, BloodHound affiche :

 Alice
   │
GenericAll
   │
Serveur-01

Pour beaucoup de personnes, GenericAll devient rapidement une propriété de BloodHound : une arête rouge ou un droit qui signifie que l’on peut compromettre l’objet.

Mais GenericAll n’appartient pas à BloodHound.

Chaque objet Active Directory possède un Security Descriptor qui décrit notamment qui possède l’objet et quelles opérations peuvent être réalisées sur celui-ci. Il contient entre autres une Discretionary Access Control List (DACL), elle-même constituée d’Access Control Entries (ACE).

Une ACE associe notamment un principal, identifié par son SID, à un ensemble de droits représentés dans un Access Mask. Elle peut également contenir des informations supplémentaires, comme un GUID permettant de cibler un droit étendu, une propriété ou un type d’objet particulier, ainsi que des règles d’héritage.

En simplifiant, chaque ACE répond donc à une question :

Qui peut faire quoi sur cet objet et dans quelles conditions ?

BloodHound collecte ces informations puis les interprète. Lorsqu’il affiche une relation comme GenericAll, il ne vient donc pas de découvrir un privilège caché : il traduit une configuration d’autorisation Active Directory en une relation exploitable dans son modèle de graphe.

C’est une différence importante.

L’arête que nous voyons dans BloodHound n’est que la représentation graphique d’un mécanisme de sécurité Windows qui existe indépendamment de l’outil.

De l’arête à l’exploitation

Prenons maintenant une relation WriteDACL.

BloodHound nous indique qu’un principal possède le droit de modifier la DACL d’un objet.

Très bien, mais cette information ne constitue pas encore une attaque.

Quelles ACE peut-on ajouter ? À quel principal ? Sur quel objet ? Quel droit voulons-nous obtenir ? Comment l’héritage va-t-il modifier la portée de cette ACE ? Et surtout : quelle nouvelle relation de sécurité voulons-nous créer dans Active Directory ?

C’est là que la compréhension du modèle Windows devient beaucoup plus importante que l’arête affichée par BloodHound.

Un WriteDACL sur un objet n’est pas intrinsèquement synonyme de DCSync. Pour aboutir à ce résultat, il faut par exemple être en mesure d’obtenir sur la racine du domaine les droits étendus nécessaires à la réplication, tels que DS-Replication-Get-Changes et DS-Replication-Get-Changes-All.

BloodHound peut nous montrer qu’un chemin existe.

Comprendre les ACL permet d’expliquer pourquoi il existe et ce qu’il faudrait réellement modifier pour le parcourir.

BloodHound n’est pas la réalité

Il reste enfin une nuance essentielle : le graphe BloodHound n’est pas Active Directory lui-même. C’est une représentation d’Active Directory construite à partir des données collectées et des relations que BloodHound sait modéliser.

Une collecte incomplète produit nécessairement une vision incomplète. Certaines informations sont également dynamiques : les sessions utilisateurs, par exemple, peuvent apparaître ou disparaître entre deux collectes.

Et même avec une collecte parfaite, le graphe reste un modèle. Une relation techniquement exploitable ne signifie pas nécessairement qu’elle le sera dans les conditions réelles de l’environnement.

C’est pourquoi un chemin BloodHound doit être compris et validé, pas simplement suivi.

Le graphe est une carte du terrain. Il n’est pas le terrain.

C’est pour cette raison que BloodHound reste, à mes yeux, un formidable outil pédagogique. Non pas parce qu’il permet de mémoriser des chemins d’attaque, mais parce que chaque arête peut devenir une invitation à ouvrir Active Directory et à comprendre le mécanisme Windows qui l’a rendue possible.

Et c’est précisément cette réflexion qui m’a progressivement amené à me poser une autre question :

Si le système que j’essaie de comprendre est Windows, pourquoi est-ce que je passe autant de temps à l’étudier depuis Linux ?

Pourquoi apprendre Windows… depuis Windows

Il existe une conséquence assez logique à tout ce que nous venons de voir.

Si l’objectif est de comprendre Windows, pourquoi passons-nous autant de temps à l’étudier depuis Linux ?

La question peut sembler provocatrice, mais elle est sincère.

Pendant longtemps, cela ne m’a pas posé de problème. J’ouvrais Kali, je récupérais des tickets Kerberos, j’interrogeais LDAP, je collectais des ACL ou je réalisais des attaques DCSync.

Puis j’ai commencé à remarquer quelque chose.

Chaque fois que je voulais comprendre précisément ce qui venait de se produire, je revenais sous Windows. J’ouvrais ADSI Edit ou GPMC, je lançais PowerShell, j’observais les événements, les stratégies de sécurité, les propriétés des objets Active Directory ou la configuration DNS.

Linux me permettait souvent d’exécuter. Windows me permettait d’observer et de comprendre.

Cette différence a progressivement changé ma manière d’apprendre le pentest Windows.

Windows est le terrain de jeu

Reprenons notre exemple précédent : un utilisateur possède WriteDACL sur une unité d’organisation.

Depuis une machine offensive, quelques commandes suffisent pour modifier les permissions. L’opération fonctionne, mais une grande partie de ce qui vient réellement de se produire reste abstraite.

Sous Windows, je peux au contraire ouvrir les propriétés de l’objet, afficher ses paramètres de sécurité avancés, observer l’ACE ajoutée, comparer le Security Descriptor avant et après la modification et comprendre comment Active Directory interprète cette nouvelle ACL.

L’objectif n’est évidemment pas de prétendre qu’une interface graphique enseigne mieux qu’une ligne de commande.

L’intérêt est de pouvoir confronter immédiatement l’action offensive au mécanisme Windows qu’elle vient de modifier.

À cet instant, l’exercice ne consiste plus seulement à réussir une attaque. Il devient une manière d’étudier l’architecture du système.

Les outils natifs sont aussi des outils d’apprentissage

Lorsque l’on parle de pentest Windows, on pense naturellement à Mimikatz, Rubeus, BloodHound, Certipy ou NetExec.

Pourtant, lorsque j’essaie de comprendre pourquoi quelque chose fonctionne, je reviens très souvent aux outils du système lui-même : PowerShell, ADSI Edit, LDP.exe, Event Viewer, GPMC ou encore les outils Sysinternals comme ProcMon et Process Explorer.

Ils n’ont pas été conçus pour attaquer Windows. Ils ont été conçus pour l’administrer, l’observer, le diagnostiquer ou le déboguer.

Et c’est précisément ce qui les rend intéressants pour apprendre.

ProcMon permet d’observer ce qu’un processus touche réellement. LDP.exe permet de manipuler LDAP sans qu’un framework offensif traduise les opérations à notre place. Event Viewer montre les traces produites par nos actions. ADSI Edit expose directement les objets et attributs que nos outils offensifs manipulent.

Ils ne remplacent pas les outils de pentest. Ils permettent de regarder derrière eux.

L’effet « boîte noire »

Il existe néanmoins un paradoxe : plus nos outils deviennent efficaces, moins ils nous obligent à comprendre ce qu’ils font.

Une seule commande NetExec peut déclencher plusieurs opérations utilisant SMB, LDAP, RPC ou Kerberos. Pour l’utilisateur, le résultat peut parfois se résumer à :

[+] Success

C’est formidable lorsque l’objectif est d’être efficace.

Cela l’est beaucoup moins lorsque l’objectif est d’apprendre.

Un outil peut masquer la négociation réseau, les requêtes LDAP, les appels RPC, les mécanismes d’authentification et les objets Windows qu’il manipule. Rien de tout cela n’est problématique en soi : c’est précisément le rôle d’un bon outil que d’abstraire la complexité.

Mais lorsqu’on apprend, cette complexité est justement ce que l’on cherche à comprendre.

Il faut donc parfois volontairement ouvrir la boîte noire.

C’est là que Commando VM devient intéressant

Lorsque FireEye a publié Commando VM, l’objectif était de fournir un environnement Windows équipé pour les opérations offensives.

On peut donc facilement le considérer comme une sorte de pendant Windows à Kali Linux. Mais ce qui m’intéresse ici n’est pas de savoir lequel des deux est « meilleur ».

C’est ce qui se produit lorsque l’environnement offensif devient lui-même Windows.

PowerShell s’exécute dans son environnement natif. Les API Windows sont directement accessibles. WMI, COM, AMSI ou ETW ne sont plus seulement des mécanismes que l’on observe depuis l’extérieur : ils font partie du système depuis lequel nous travaillons.

Les journaux d’événements, les outils d’administration, le registre, les services, les processus ou encore les mécanismes de sécurité du système sont immédiatement accessibles pour observer ce que nos actions provoquent réellement.

Prenons un exemple simple. Lorsqu’un outil tente d’exécuter du PowerShell malveillant et se fait bloquer, travailler depuis Windows permet de ne pas s’arrêter à « Defender a bloqué mon payload ». On peut chercher à comprendre ce qui s’est passé : AMSI est-il intervenu ? Une détection comportementale de Defender ? Une règle ASR ? Quel événement a été généré ? Quel processus a déclenché la détection ?

L’échec de l’attaque devient lui-même une occasion d’étudier Windows et c’est probablement ce que je trouve le plus intéressant dans cette approche.

Commando VM ne rend évidemment pas automatiquement meilleur en pentest Windows. Il réduit simplement la distance entre l’étudiant, ses outils et le système qu’il cherche à comprendre.

Les outils passent, les concepts restent

Jusqu’ici, nous avons parlé de BloodHound, Rubeus, Hashcat, NetExec ou encore Commando VM. Pourtant, aucun de ces outils ne constitue réellement le sujet.

Derrière chacun d’eux se trouvent des mécanismes beaucoup plus durables : Kerberos, LDAP, les ACL, les Security Descriptors, la PKI, SMB, RPC ou encore les API Windows.

Les outils changent. Les mécanismes qu’ils manipulent évoluent beaucoup plus lentement.

C’est cette différence qui, à mes yeux, devrait guider l’apprentissage.

À première vue, cette liste ressemble à un catalogue d’outils.

Moi, j’y vois tout autre chose : j’y vois un programme de formation.

Pourquoi cette distinction est importante

L’écosystème offensif évolue extrêmement vite. Des projets apparaissent, changent de nom, sont abandonnés, forkés ou remplacés. CrackMapExec est devenu NetExec, BloodHound a profondément évolué et de nouveaux outils apparaissent régulièrement.

Les mécanismes qu’ils manipulent ont une temporalité très différente. Kerberos existe depuis plusieurs décennies. LDAP, les ACL Windows, les Security Descriptors ou les certificats X.509 évoluent eux aussi, mais beaucoup plus lentement que les interfaces utilisées pour les manipuler.

Cela ne rend pas les outils secondaires. Un bon pentester doit évidemment savoir les utiliser efficacement. Mais lorsqu’un nouvel outil apparaît, celui qui comprend déjà le protocole ou le mécanisme sous-jacent n’a pas besoin de tout réapprendre : il doit principalement comprendre comment ce nouvel outil l’expose et l’automatise.

C’est pour cette raison que je considère les concepts comme un investissement plus durable que la mémorisation des commandes.

L’illusion de la compétence

Au fil des années, j’ai eu la chance d’échanger avec beaucoup de personnes passionnées de cybersécurité : étudiants, administrateurs systèmes, pentesters, analystes SOC ou consultants.

Et j’ai fini par observer un phénomène dans lequel je me suis moi-même souvent reconnu : nous confondons parfois notre capacité à reproduire une technique avec notre compréhension de cette technique.

Le piège est particulièrement facile aujourd’hui, parce que nos outils sont devenus remarquablement efficaces.

Prenons un lab Hack The Box.

Vous récupérez des identifiants avec NetExec, lancez BloodHound et identifiez un chemin d’attaque. Certipy révèle ensuite une configuration AD CS exploitable, vous obtenez un certificat, demandez un TGT et finissez Domain Admin.

Félicitations, vous avez réussi la room.

Mais une autre question m’intéresse davantage : qu’avez-vous réellement compris de ce qui vient de se produire ?

Je ne pose pas cette question pour minimiser la performance. Je me la pose parce que j’ai commencé par me l’appliquer à moi-même.

Pendant longtemps, lorsque je terminais une room, le résultat constituait ma mesure de progression. J’avais obtenu le flag, trouvé le chemin d’attaque ou réussi l’élévation de privilèges : j’avais donc appris quelque chose.

Aujourd’hui, j’essaie d’utiliser une mesure différente.

Je me demande :

Si je devais refaire exactement la même chose sans l’outil qui vient de me donner la réponse, serais-je capable d’expliquer ce qui s’est produit ?

Pas nécessairement de tout reproduire manuellement. Ce serait une autre forme d’excès.

Mais au minimum d’expliquer quel protocole a été utilisé, quel objet a été modifié, quelle relation de confiance a été détournée et pourquoi Windows a accepté l’opération.

Il y a une différence importante entre savoir qu’une technique fonctionne et comprendre pourquoi le système l’autorise.

Les deux compétences sont utiles. Un pentester doit être capable d’avancer, d’utiliser efficacement ses outils et de produire un résultat.

Mais lorsque la seconde accompagne la première, quelque chose change : un échec devient plus facile à diagnostiquer, une variante inconnue devient plus simple à comprendre et un nouvel outil devient beaucoup moins intimidant.

C’est probablement le changement le plus important que cette manière d’apprendre a provoqué chez moi.

Lorsque je découvre aujourd’hui un nouvel outil, ma première question n’est plus seulement :

Comment est-ce que je l’utilise ?

J’essaie d’abord de comprendre :

Qu’est-ce qu’il fait réellement à Windows ?

Quel protocole utilise-t-il ? Quelle API appelle-t-il ? Quel objet modifie-t-il ? Quelle permission lui permet de le faire ? Quelle trace laisse-t-il derrière lui ?

L’outil reste important. Mais il devient progressivement un moyen d’observer et de manipuler le système plutôt que le sujet à apprendre lui-même.

L’outil cesse alors d’être le sujet de l’apprentissage. Il devient un moyen d’explorer et de comprendre le système.

Si je devais tout recommencer aujourd’hui…

Si je devais aujourd’hui recommencer l’apprentissage du pentest Windows depuis zéro, je ne commencerais probablement ni par Kali, ni par Commando VM.

Et je ne commencerais pas non plus par BloodHound, Rubeus ou Certipy. Je commencerais par Windows.

Pas dans l’objectif de devenir administrateur système avant de lancer mon premier lab, ni de connaître chaque protocole dans ses moindres détails. Mais suffisamment pour que, lorsque je commencerai à attaquer Active Directory, les objets et les mécanismes que mes outils manipulent aient déjà un sens.

Mon ordre d’apprentissage ressemblerait aujourd’hui plutôt à ceci.

1. Comprendre les fondamentaux de Windows

Avant même Active Directory, je commencerais par comprendre le système Windows lui-même.

Utilisateurs et groupes locaux, processus et services, registre, système de fichiers, permissions NTFS, tokens d’accès, UAC, tâches planifiées, journaux d’événements, PowerShell…

Pas besoin de maîtriser chacun de ces sujets en profondeur.

L’objectif serait surtout de comprendre comment Windows représente une identité, comment il décide qu’une opération est autorisée et comment les processus s’exécutent avec les privilèges qui leur sont accordés.

Beaucoup de techniques d’élévation de privilèges deviennent beaucoup moins mystérieuses dès que ces mécanismes sont compris.

2. Construire un Active Directory avant de l’attaquer

Ensuite, je construirais un petit domaine. Un contrôleur de domaine, quelques utilisateurs, des groupes, un ou deux postes membres, quelques GPO, des partages SMB et des comptes de service.

Je créerais volontairement des délégations et des permissions imparfaites. J’ajouterais des SPN. Je modifierais des ACL. Je regarderais ce que cela change dans ADSI Edit, dans PowerShell et dans les journaux d’événements.

Cette étape peut sembler étrange dans un parcours de pentest, mais je la considère aujourd’hui comme fondamentale.

Il est beaucoup plus facile de comprendre comment détourner Active Directory lorsque l’on a déjà essayé de l’administrer.

3. Comprendre les protocoles que l’on va attaquer

Une fois le domaine fonctionnel, je commencerais à regarder ce qui circule réellement entre ses composants. Kerberos en premier, puis LDAP, SMB, DNS et RPC.

Pas avec l’ambition de lire immédiatement toutes leurs RFC ou de connaître chaque champ d’un paquet réseau, mais suffisamment pour pouvoir répondre à quelques questions simples :

Qui parle à qui ? Pour demander quoi ? Avec quelle identité ? Et sur quelle base l’autre partie décide-t-elle de faire confiance à cette demande ?

Wireshark devient ici un formidable outil pédagogique.

Capturer soi-même une authentification Kerberos et retrouver un AS-REQ, un AS-REP, un TGS-REQ puis un TGS-REP permet de transformer des acronymes abstraits en échanges réellement observables.

C’est à ce moment-là seulement que je commencerais à étudier Kerberoasting, AS-REP Roasting, les différentes formes de délégation ou les attaques basées sur NTLM.

4. Comprendre le modèle d’autorisation d’Active Directory

Avant d’utiliser BloodHound sérieusement, je consacrerais du temps aux objets Active Directory, aux SID, aux Security Descriptors, aux DACL, aux ACE, aux Access Masks et à l’héritage.

Puis je créerais moi-même quelques relations :

GenericAll
GenericWrite
WriteDACL
WriteOwner

Je regarderais leur représentation directement dans Windows avant de lancer BloodHound.

Ensuite seulement, je collecterais le domaine.

À ce moment-là, une arête BloodHound ne serait plus seulement une instruction à suivre. Elle serait la représentation graphique d’un mécanisme que j’ai déjà manipulé moi-même.

5. Utiliser les outils pour accélérer ce que l’on comprend déjà

C’est seulement à ce stade que je commencerais réellement à travailler avec BloodHound, Rubeus, NetExec, Impacket, Certipy ou Mimikatz.

Mais avec une règle personnelle :

Chaque fois qu’un outil me donne un résultat que je ne suis pas capable d’expliquer, je m’arrête.

Si BloodHound affiche une arête inconnue, je cherche la permission Windows correspondante.

Si Rubeus obtient un ticket, je cherche à comprendre l’échange Kerberos qui l’a rendu possible.

Si Certipy identifie une configuration AD CS exploitable, je regarde le template, ses EKU, ses permissions et le mécanisme d’enrôlement concerné.

Il ne s’agit évidemment pas de tout reproduire manuellement avant d’avoir le droit d’utiliser un outil. L’outil reste là pour automatiser ce qui doit l’être.

Mais il devient un accélérateur de compréhension plutôt qu’un substitut à celle-ci.

6. Observer la même attaque du côté défenseur

Enfin, je referais certaines attaques en regardant cette fois le système depuis l’autre côté.

Quels événements Windows sont générés ? Que voit Defender for Identity ? Que remonte un EDR ? Quelles requêtes LDAP ou Kerberos peuvent être observées ? Qu’est-ce qui est réellement détectable et qu’est-ce qui ne l’est pas ?

Cette étape me semble essentielle parce qu’elle oblige à comprendre l’attaque autrement.

Pour détecter correctement un comportement, il faut savoir quel mécanisme légitime il détourne et à quel moment son utilisation devient anormale.

Et l’exercice fonctionne également dans l’autre sens : comprendre ce que voit le défenseur permet au pentester de mieux comprendre les traces laissées par ses propres actions.

C’est souvent à ce moment-là que les frontières entre pentest, administration système et défense commencent à devenir beaucoup moins nettes.

Ce parcours est évidemment plus lent au début.

Il est beaucoup plus rapide d’installer Kali, de suivre un walkthrough et de reproduire les commandes jusqu’à obtenir le flag.

Et il n’y a rien de mauvais à cela : c’est aussi comme ça que beaucoup d’entre nous ont commencé.

Mais je pense aujourd’hui que le temps investi dans les fondamentaux se récupère largement par la suite. Lorsqu’un nouvel outil, une nouvelle technique ou une nouvelle configuration apparaît, on dispose déjà du modèle mental nécessaire pour comprendre où elle vient s’insérer.

Si je devais tout recommencer, c’est donc probablement ainsi que j’apprendrais Windows avant d’apprendre à l’attaquer.

Une dernière réflexion

En écrivant cet article, je me suis rendu compte qu’il faisait étrangement écho au précédent, consacré à JadePuffer.

J’y défendais l’idée que, face à des attaques de plus en plus automatisées, les défenseurs devront progressivement apprendre à détecter des comportements plutôt que des outils.

Je crois que le raisonnement fonctionne aussi dans l’autre sens.

Lorsqu’on apprend le pentest, peut-être devrions-nous commencer par comprendre le comportement des systèmes avant les outils qui permettent de les détourner.

Kerberoasting n’est alors plus une commande Rubeus, mais une conséquence du fonctionnement de Kerberos. Une relation WriteDACL n’est plus une arête BloodHound, mais une permission inscrite dans un Security Descriptor. Une attaque AD CS n’est plus simplement une ESC remontée par Certipy, mais le détournement d’une infrastructure de confiance, de modèles de certificats et de mécanismes d’authentification.

Les outils restent indispensables. Ils nous permettent d’aller plus vite, d’automatiser ce qui doit l’être et de nous concentrer sur ce qui compte réellement.

Mais ils ne devraient peut-être pas constituer notre modèle mental du système.

Les outils vieillissent en mois. Les protocoles et les architectures vieillissent en années.

Je ne prétends évidemment pas détenir la bonne méthode d’apprentissage. Certains commenceront par Kali, d’autres par Commando VM, Hack The Box, un homelab ou une formation. Toutes ces portes d’entrée peuvent être excellentes.

La seule chose que je ferais différemment aujourd’hui serait de ne plus confondre la porte d’entrée avec ce que je suis venu apprendre.

Et si cet article devait finalement laisser une seule idée, ce serait celle-ci :

N’apprenez pas d’abord les outils. Apprenez pourquoi ils fonctionnent.

Plus d’informations:

Documentation Microsoft

Recherche offensive

Active Directory Certificate Services

Windows Internals

Pour s’entraîner

Laisser un commentaire