Exploitez le protocole Kerberos
Le protocole Kerberos est le deuxième protocole d’authentification clé dans un Active Directory. C’est d’ailleurs le protocole utilisé par défaut quand c’est possible. Il existe plusieurs manières d’exploiter ce protocole pour du mouvement latéral. Pour bien les comprendre, nous allons faire un bref rappel du fonctionnement de ce protocole.
Kerberos
Lorsqu’un utilisateur veut utiliser un service, il doit pouvoir prouver auprès du service qui il est. Pour cela, au préalable, l’utilisateur va demander auprès du contrôleur de domaine un TGT, ou Ticket-Granting-Ticket. C’est l’équivalent d’un passeport. Ce document contient des informations sur l’utilisateur, notamment son nom et les groupes auxquels il appartient. D’ailleurs, comme un passeport, il doit être infalsifiable. L’utilisateur ne doit pas pouvoir changer son nom à son bon vouloir. Donc ce TGT est protégé par une clé que seul le contrôleur de domaine connaît.
Pour pouvoir récupérer ce ticket, l’utilisateur doit se préauthentifier auprès du contrôleur de domaine en prouvant qu’il connaît son mot de passe. Si cette préauthentification est validée par le contrôleur de domaine, alors celui-ci lui renvoie son TGT.
Une fois son TGT en main, l’utilisateur peut faire des demandes d’accès à n’importe quel service. Pour accéder à un service spécifique, il fera encore une fois une demande au contrôleur de domaine. Il présentera son TGT, et demandera un ticket pour un service. Le contrôleur de domaine vérifie alors que le TGT est valide, qu’il n’a pas été modifié, et renvoie à l’utilisateur un autre ticket, qui est un ticket de service, spécifique au service demandé. Cette fois-ci, ce ticket est protégé par le mot de passe du compte de service associé, donc le compte qui exécute le service demandé. Ce ticket contient une copie du TGT de l’utilisateur.
Une fois que l'utilisateur a reçu le ticket de service, comment peut-il l'utiliser ? Il présente ce ticket au service lui-même. Comme il est protégé avec le mot de passe du compte de service, lorsqu’il le reçoit, il peut l’ouvrir et voir qui fait une demande, pour vérifier si l’utilisateur a les droits ou non d’utiliser le service.
Kerberoasting
Une fois le TGT en main, un utilisateur peut faire une demande de ticket de service pour n’importe quel service du domaine. Or, un ticket de service est protégé par le mot de passe du compte de service demandé. Donc en théorie, si vous demandez un ticket de service, vous pouvez essayer vous-même de trouver la clé qui déchiffre le ticket. Il suffit d’en essayer beaucoup, et peut-être que vous tomberez sur la bonne.
Il se trouve que la majorité des services proposés dans un Active Directory sont portés par des ordinateurs, par des comptes machine. Or, le mot de passe d’un compte machine est très long et aléatoire. Vous n’aurez aucune chance de tomber sur le bon mot de passe par hasard.
En revanche, il y a aussi des comptes utilisateurs qui exécutent parfois des services. Et c’est là que repose l’attaque Kerberoasting. L’idée est de demander des tickets de service pour tous les services qui sont portés par des utilisateurs. Pour chaque ticket, vous tenterez de trouver le mot de passe qui le protège. Si vous y parvenez, vous aurez trouvé le mot de passe du compte en question !
Un outil de la suite Impacket permet d’automatiser ce processus. Il s’appelle GetUserSPNs.py.
GetUserSPNs.py -request medic.ex/pixis:P4ssw0rd -outputfile hashes.kerberoast
Une fois les tickets récupérés, l’outil les mettra sous une forme compréhensible pour des outils comme hashcat, pour tenter de retrouver le mot de passe associé.
hashcat -m 13100 ./hashes.kerberoast /home/pixis/wordlist.txtPass-the-ticket
Vous vous souvenez de la technique du pass-the-hash que vous avez découverte avec le protocole NTLM ? Ici, il est question de tickets, donc ce que vous pouvez passer, ce sont des tickets ! Si vous compromettez une machine, ou un compte administrateur sur un poste, vous pouvez tenter de retrouver des tickets Kerberos en mémoire pour les réutiliser. En effet, si vous trouvez le ticket TGT d’un autre compte, vous pourrez potentiellement le réutiliser pour vous faire passer pour ce compte, sous réserve qu’il ne soit pas expiré. C’est ce qu’on appelle la technique du pass-the-ticket.
L’outil lsassy permet de récupérer à distance des informations d’authentification sur un poste compromis, notamment les TGT.
lsassy -u pixis -p P4ssw0rd -d medic.ex 10.10.10.2
Dans la sortie de l’outil, vous trouverez des lignes comme :
[...] MEDIC.EX\Administrateur [TGT] Domain: MEDIC.EX - End time: 2023-11-09 12:46 (TGT_MEDIC.EX_Administrateur_krbtgt_MEDIC.EX_bcb82275.kirbi) [...] 24 Kerberos tickets written to /home/pixis/.config/lsassy/tickets
Cela signifie que sur le poste distant, le TGT du compte Administrateur est présent, et qu’il est valide jusqu’à une certaine date. Par défaut, ce ticket est enregistré au format .kirbi, mais vous pouvez le convertir en .ccache pour l’utiliser avec la suite Impacket.
ticketConverter.py ~/.config/lsassy/tickets/TGT_MEDIC.EX_Administrateur_krbtgt_MEDIC.EX_bcb82275.kirbi /tmp/Administrateur.ccache
Pour l’utiliser, il faut l’exporter dans la variable d’environnement KRB5CCNAME puis vous pourrez utiliser tous les outils de la suite impacket avec le paramètre -k pour utiliser ce ticket.
export KRB5CCNAME=/tmp/Administrateur.ccache smbclient.py -k DC01.medic.ex
Dans l’authentification utilisant Kerberos, les vrais noms de machine doivent être utilisés, notamment dans la dernière commande (ici smbclient.py ). Si vous testez cette commande dans l’environnement root-me depuis votre machine d’attaque, il faudra au préalable trouver l’IP publique de la machine de CTF, et enregistrer dans votre fichier hosts la ligne suivante :
XXX.XXX.XXX.XXX DC01 DC01.medic.ex medic.ex
Ainsi, lorsque vous tenterez d’accéder à DC01.medic.ex , votre machine d’attaque saura retrouver l’adresse IP associée.
Exploitez les autres protocoles
Dans un environnement Active Directory, de nombreux autres protocoles cohabitent. Certains d’entre eux permettent de prendre la main à distance sur une machine, comme SMB, RDP, SSH, WinRM, VNC, WMI et bien d’autres.
Si vous avez des identifiants, vous pouvez les utiliser pour vous propager latéralement. Voici quelques exemples d’outils qui peuvent être utilisés pour ce déplacement latéral.
Avec SMB, vous avez la possibilité de créer à distance un service et de l’exécuter. Un service, ce n’est rien d’autre qu’une application qui fonctionne en arrière-plan. C’est ce que fait l’outil psexec lorsque vous l’utilisez pour exécuter des commandes à distance. Cet outil a été porté dans la suite Impacket que vous connaissez maintenant. Il s’appelle psexec.py.
psexec.py medic.ex/pixis:P4ssw0rd@dc01.medic.exRDP permet d’avoir un bureau déporté sur une machine cible. C’est comme si vous étiez devant l’écran, mais à distance. C’est très pratique pour les tâches d’administration ! C’est également utile pour vous si vous voulez accéder à de nouveaux postes avec des identifiants compromis. Vous pouvez utiliser le client RDP de Windows, mais également des clients sous Linux avec FreeRDP. Il en existe d’autres, mais celui-ci a une fonctionnalité intéressante : il prend en charge le fait de n’utiliser que le hash NT pour s’authentifier. Cela fonctionne quand une connexion RDP se fait en mode Restricted Admin, une sécurité proposée par Windows qui a pour effet de bord d’autoriser le pass-the-hash en utilisant le protocole RDP.
freerdp /u:pixis /d:medic.ex /pth:ac1dbef8523bafece1428e067c1b114f /v:dc01.medic.exExploitez les partages réseau
Pour terminer, les partages réseau sont très souvent oubliés ou négligés lors d’audits. C’est pourtant une mine d’informations pour vous, notamment lors de la phase de reconnaissance. Dans les partages réseau, vous trouverez très régulièrement des documents personnels, sensibles, relatifs à des projets internes, des configurations d’applications, voire leur code source, des sauvegardes, etc.
Lors de la phase de reconnaissance, vous avez appris à identifier où se trouvent les partages réseau, tout en identifiant ceux qui vous sont accessibles. Cela vous permet d’aller chercher par vous-même à la main les documents qui peuvent être intéressants pour votre phase d’attaque.
Il existe un outil complémentaire à la phase de recherche manuelle, qui vous permettra potentiellement de découvrir des informations sensibles dans les partages réseau de l’entreprise. Cet outil s’appelle Snaffler, et automatise une partie des recherches. Pour cela, il va se connecter à un contrôleur de domaine pour extraire la liste de tous les ordinateurs présents sur le domaine. Pour chacun d’eux, il va le contacter, lister les partages réseau s’il y en a, puis les parcourir de manière récursive pour accéder à tous les fichiers dans tous les dossiers. Pour éviter que cela ne prenne trop de temps, une série de filtres sont utilisés pour ne scanner que les fichiers qui seront à priori intéressants.
snaffler.exe -s -o snaffler.logPersonnellement, je lance Snaffler lors de mes audits, mais je fais également beaucoup de recherches à la main. Il y a beaucoup de données, notamment métier, qu’il est très difficile pour un outil automatique d’identifier comme critiques ou sensibles.
En résumé
En plus de l'exploitation du protocole NTLM vu au chapitre précédent, pour effectuer du mouvement latéral au sein d’un Active Directory, vous avez plusieurs options :
Utiliser le Kerberoasting pour découvrir de nouveaux identifiants.
Découvrir des informations sensibles dans les partages réseau.
Le mouvement latéral vous permet de découvrir de nouveaux identifiants, de compromettre de nouvelles machines, mais votre but est de compromettre le domaine. À partir de toutes les informations récoltées, et des comptes et machines compromis, vous allez maintenant découvrir comment vous pouvez élever vos privilèges pour devenir administrateur du domaine.
