Exploitez les chemins d’attaque

• Sommaire
  I - Compromettez un premier compte 1 - Prenez la main sur une machine 2 - Profitez d’une politique de mot de passe faible 3 - Utilisez le réseau à votre avantage II - Propagez-vous latéralement avec le protocole NTLM 1 - Authentification NTLM 2 - Pass-the-hash 3 - Relais NTLM III - Effectuez un mouvement latéral avec le protocole Kerberos 1 - Exploitez le protocole Kerberos 2 - Exploitez les autres protocoles 3 - Exploitez les partages réseau IV - Compromettez le domaine en élevant vos privilèges 1 - Profitez de la délégation Kerberos 2 - Récupérez des identifiants sur un poste compromis 3 - Exploitez les GPO pour compromettre de nouveaux comptes 4 - Exploitez une PKI (Public Key Infrastructure) V - Maintenez un accès dans l’environnement compromis 1 - Créez un compte à privilèges 2 - Adoptez les techniques de persistance classiques 3 - Modifiez les droits des objets sensibles 4 - Forgez des tickets Kerberos

Lors de votre découverte du réseau, vous avez sans doute identifié des machines présentes sur le réseau, les services proposés par ces machines, ainsi que les versions des systèmes d’exploitation et des services.

Exploiter un défaut de mise à jour

Parmi ces services, voici quelques vulnérabilités qui me permettent de prendre la main sur la machine lorsqu’elle est exploitée :

MS17-010 est une vulnérabilité sur le service SMB des machines Windows. Elle a été corrigée en 2017, mais vous trouverez régulièrement des machines qui ne sont plus mises à jour dans un système d’information. Pour identifier des machines vulnérables, l’outil nmap vous sera utile.

nmap --script smb-vuln-ms17-010.nse -p445 10.10.10.0/24

Pour l’exploiter, le framework Metasploit sera d’une grande aide.

Utilisation de Metasploit pour exploiter MS17-010

Il existe d’autres vulnérabilités Windows permettant de prendre le contrôle à distance de la machine, comme la CVE-2019-0708, appelée BlueKeep et affectant le protocole RDP, ou encore la CVE-2020-1350, appelée SIGRed affectant le service DNS. Ces vulnérabilités, bien que critiques, sont cependant plus difficiles à exploiter que MS17-010.

Cette liste n’est bien sûr pas exhaustive, et il est très important de vous tenir informé via votre veille. Personnellement, je suis tous les matins sur Twitter pour voir s’il y a des nouveautés dans le monde de la sécurité informatique.

Utiliser des identifiants par défaut

Lorsque vous découvrez des serveurs et services, prenez soin de repérer les mires d’authentification web. Vous savez, ces pages internet sur lesquelles il faut renseigner un nom d’utilisateur et un mot de passe pour accéder au site. Vous aurez très souvent ce type de page lorsque vous voudrez accéder à la partie administration d’une application.

Or pour de nombreuses solutions, il existe des identifiants par défaut utilisables lorsque l’application est installée pour la première fois. Il faudrait bien sûr qu’ils soient changés, mais ce n’est pas toujours fait par les administrateurs. C’est pourquoi, dès que je tombe sur une interface d’authentification, je regarde le nom et la version de l’application web, et je cherche la documentation de cette application pour y découvrir les identifiants par défaut.

Vous pourrez alors vous connecter à des interfaces d’administration de plusieurs types d’applications :

• des serveurs d’application, ce qui vous permettra d’ajouter une application arbitraire sur le serveur, et ainsi exécuter du code à distance. Il y a par exemple les serveurs Tomcat, Jenkins ou JBoss ;
• des serveurs d’impression qui sont parfois connectés à l’Active Directory pour connaître les utilisateurs de l’entreprise et leurs adresses mail. Vous pourrez alors trouver les identifiants de l’imprimante ;
• des équipements réseau, comme des switchs ou des routeurs. Vous serez alors en mesure de lire leur configuration, et découvrir des VLAN cachés ;
• des outils d’administration comme des interfaces iLo, ou des serveurs vCenter.

Il y a beaucoup d’autres possibilités, mais quoiqu’il arrive, n’hésitez pas à chercher et tester des identifiants simples, classiques. Pour vous épauler, vous pouvez utiliser le dépôt GitHub DefaultCreds-cheat-sheet, qui recense des identifiants par défaut pour beaucoup d’applications.

Vous avez découvert la politique de mot de passe de l’entreprise lors de votre phase de reconnaissance. La connaître vous permettra de tenter de trouver des premiers identifiants valides mais faibles.

Pour cela, vous pouvez faire du password spraying. Cela signifie que vous allez tenter d’utiliser un mot de passe simple sur tout ou partie des utilisateurs du domaine.

Un mot de passe simple, c’est un mot de passe qui est très facile à retenir pour l’utilisateur, avec un nom commun ou un nom propre, et peut-être un chiffre et un symbole. Ça peut également être une suite de chiffres.

Voici donc quelques idées que l'on peut appliquer lors d'audits.

• Le nom de l’entreprise, auquel on ajoute l’année actuelle à la fin et une majuscule au début. Par exemple Medicex2022. Nous pouvons tester également avec un point d’exclamation à la fin, Medicex2022!.
• Nous pouvons faire pareil avec le nom de la ville dans laquelle se trouve l’entreprise, pour donner Paris2022 ou Paris2022!.
• Parfois nous pouvons tester des choses très simples qui sont des combinaisons des mots de passe les plus utilisés en France. Tester les mots de passe qui ne sont que des chiffres fonctionnent que très rarement.

Vous pouvez donner libre cours à votre imagination bien sûr, et adapter vos tests à votre contexte. Si vous savez que le mot de passe de tous les nouveaux arrivants est Welcome123 et qu’ils doivent le changer à leur arrivée, ça vaut le coup de l’essayer !

Il existe d’ailleurs beaucoup d’outils pour vérifier la validité d’un mot de passe sur plusieurs comptes. L’outil SprayHound en est un.

sprayhound -U ./utilisateurs.txt -p Medicex1 -d medic.ex -dc 10.10.10.2

Le mot de passe Medicex1 sera testé sur la liste des utilisateurs fournie dans le fichier utilisateurs.txt.

Si vous avez déjà compromis un compte du domaine, vous pouvez laisser SprayHound chercher tous les utilisateurs. Vous n’avez qu’à lui fournir le nom d’utilisateur ( -lu ) et le mot de passe ( -lp ) que vous connaissez. Par ailleurs, ayant un compte valide, l’outil a l’avantage de tester intelligemment, en prenant en compte la politique de mot de passe. Il ne testera pas les comptes qui seront bloqués au prochain échec.

sprayhound -p Medicex2022 -d medic.ex -dc 10.10.10.2 -lu pixis -lp P4ssw0rd

Exemple d’utilisation de SprayHound

Enfin, une technique qui peut parfois fonctionner, c'est le user-as-pass. Vous allez chercher les utilisateurs pour lesquels le mot de passe est exactement leur nom d’utilisateur. Cela arrive régulièrement, et vous pourrez trouver des comptes comme test ayant pour mot de passe test, ou encore servicesql ayant également comme mot de passe servicesql.

SprayHound est capable de faire ces tests. Pour cela, vous pouvez utiliser les mêmes lignes de commande que précédemment, sauf que vous ne précisez pas de mot de passe à tester. Vous pourrez alors fournir une liste de noms d’utilisateurs (-U), ou fournir un premier compte (-lu et -lp).

sprayhound -U ./utilisateurs.txt -d medic.ex -dc 10.10.10.2
sprayhound -d medic.ex -dc 10.10.10.2 -lu pixis -lp P4ssw0rd

Faites toujours attention lorsque vous faites du password spraying. La phase de reconnaissance est cruciale pour limiter les risques, mais vous n’êtes jamais à l’abri d’une configuration particulière chez un client. Si vous avez un doute, parlez-en avec la personne responsable du système d’information dans lequel vous êtes, pour vous assurer qu’elle est en mesure de débloquer rapidement un compte en cas de problème.

Si vous n’avez toujours pas récupéré de compte, ou si vous souhaitez en trouver de nouveaux pour avoir de nouveaux privilèges, vous pouvez exploiter des comportements par défaut de Windows au niveau du réseau.

LLMNR et NBT-NS

Le premier point concerne les protocoles LLMNR (Link-local Multicast Name Resolution) et NBT-NS (NetBIOS Name Service). Ce sont tous les deux des protocoles de résolution de nom. Quand une machine Windows cherche à trouver l’adresse IP associée à un nom de domaine ou de machine, elle va tenter plusieurs choses. Elle vérifiera s’il n’y a pas une entrée dans le fichier hosts, puis elle utilisera le protocole DNS, mais si ça ne fonctionne toujours pas, elle utilisera les protocoles NetBIOS et LLMNR. En utilisant ces protocoles, Windows enverra la demande de résolution de nom à toutes les machines qui l’entourent, ce qu’on appelle du broadcast.

Fonctionnement des protocoles NBT-NS et LLMNR

Phase 2 (suite) du fonctionnement des protocoles NBT-NS et LLMNR dans une attaque Man-In-The-Middle

Se mettre en position de man-in-the-middle (homme du milieu) n’est jamais anodin. Il existe un risque que vous interfériez avec le travail d’un collaborateur, en bloquant temporairement un accès à un serveur légitime, par exemple. Faites donc toujours attention lorsque vous faites des attaques au niveau du réseau.

L’outil Responder vous permet de faire ça automatiquement, en précisant l’interface réseau qu’il doit utiliser pour se mettre en écoute des sollicitations LLMNR et NBT-NS.

./Responder.py -I eth0

Vous récolterez parfois des identifiants en clair, mais plus souvent des hashs NTLMv1 ou NTLMv2, en fonction de la version de NTLM configurée pour les machines attaquées. Ces condensats doivent ensuite être cassés, avec l’outil hashcat, par exemple.

hashcat -m 5600 ./NTLMv2-hash.txt /home/pixis/wordlist.txt

Le protocole NTLMv1 est obsolète. Si vous capturez un échange NTLMv1, vous pourrez trouver le hash NT utilisé lors de l’authentification en quelques heures, quelle que soit la complexité du mot de passe d’origine. Vous allez voir dans le prochain chapitre que connaître le hash NT d’un compte est suffisant pour le compromettre.

IPv6

Windows a un comportement par défaut assez étonnant en entreprise. Alors que l’immense majorité des entreprises sont entièrement configurées pour utiliser IPv4, le système d’exploitation Windows fonctionne par défaut en IPv4 et IPv6. Mais ça ne s’arrête pas là. IPv6 est prioritaire par rapport à IPv4. Ainsi, dans une entreprise, toutes les machines reçoivent des configurations IPv4, mais vous pouvez venir en tant qu’attaquant proposer des configurations IPv6 à tous les postes, et ce sera votre configuration qui prendra le dessus.

Dans une configuration IPv6, on peut notamment indiquer où se trouve le serveur DNS, ou la route par défaut. C’est donc une manière très puissante de vous placer à nouveau en position d’homme du milieu.

L’outil mitm6 exploite ce comportement.

mitm6 -i eth0

Il se mettra en écoute sur l’interface réseau fournie, et répondra aux requêtes DHCPv6. L’outil Responder peut être lancé en parallèle pour récolter des condensats de mots de passe.

Vous avez vos premiers identifiants sur le réseau, ou un premier accès sur un poste ou serveur du domaine. Il vous faut alors continuer votre plan d’attaque, et compromettre d’autres utilisateurs ou machines pour tenter de récupérer de nouveaux accès.

Le protocole NTLM est l’un des deux protocoles d’authentification utilisés dans les environnements Microsoft. Il permet à un utilisateur de prouver qui il est auprès d’un serveur.

Le terme “serveur” est employé dans le sens client-serveur. Le “serveur” peut très bien être un autre poste de travail.

Voyons plusieurs manières de se propager latéralement avec le protocole NTLM.

L’authentification consiste en une phase de challenge-response (ou défi-réponse) entre le client et le serveur.

C’est une technique utilisée pour que le serveur vérifie que l’utilisateur connaît le mot de passe du compte avec lequel il s’authentifie, sans pour autant faire transiter le mot de passe sur le réseau.

Cette authentification se déroule en trois étapes. D’abord le client indique qu’il veut s’authentifier. Le serveur lui envoie alors un défi, ou un challenge. Ce n’est rien d’autre qu’une valeur aléatoire qui change à chaque demande d’authentification. Le serveur enregistre d’ailleurs cette valeur dans un coin. Le client reçoit ce challenge et le chiffre en utilisant le hash de son mot de passe comme clé. Il renvoie cette version chiffrée au serveur, ainsi que son nom d’utilisateur.

Protocole NTLM en trois étapes

Suite à ces échanges, le serveur est en possession de deux choses :

• Le challenge qu’il a envoyé au client ;
• La réponse du client qui a été chiffrée avec le hash de son mot de passe.

Pour finaliser l’authentification, il ne reste plus au serveur qu’à vérifier la validité de la réponse envoyée par le client. Pour ce faire, le serveur a une base de données des utilisateurs locaux appelée SAM (Security Accounts Manager). Il y a la liste des noms d’utilisateurs, et le hash de leur mot de passe, appelé hash NT. Cela permet d’éviter de stocker les mots de passe en clair sur la machine. Quand le serveur reçoit la réponse du client qui tente de s’authentifier, il reçoit le challenge chiffré avec ce hash. Le serveur va procéder à la même opération en cherchant le hash de l’utilisateur dans sa table, et il va chiffrer le challenge qu’il a envoyé avec ce hash.

S’il obtient la même chose que ce qu’a envoyé le client, c’est que le client a utilisé le même mot de passe, il est donc authentifié.

Validation de la réponse NTLM

1. Réception du challenge.
2. Envoi de la réponse.
3. Recherche du hash NT dans la base de données SAM.
4. Calcul de la réponse attendue avec le hash NT de la SAM et le challenge.
5. Comparaison avec la réponse du client.

Pour information, c’est aussi possible avec un compte de domaine. Le serveur ne connaît pas le secret du compte de domaine qui veut s’authentifier, il va donc déléguer la phase de vérification à un contrôleur de domaine.

Dans tous les cas l’utilisateur n’a utilisé que le hash NT de son mot de passe pour s’authentifier, jamais son mot de passe en clair. C’est le hash du mot de passe qui est stocké sur le serveur, pour éviter de stocker le mot de passe en clair, et c'est ce même hash suffit pour s’authentifier.

Avec le protocole NTLM, si vous volez le mot de passe en clair, ou si vous volez le hash NT du mot de passe, vous aurez toutes les billes en main pour vous authentifier. Finalement, on peut même dire qu’avoir le hash NT revient à avoir le mot de passe en clair, dans la majorité des cas.

Si lors de la phase de compromission du premier compte, vous avez exploité une vulnérabilité sur un poste de travail vous permettant de prendre la main dessus, il est possible que vous ayez les privilèges suffisants pour trouver le hash du mot de passe de l’administrateur local de ce poste.

Or, dans une entreprise, les postes des collaborateurs sont souvent des copies d’un même poste qui a été configuré une bonne fois pour toutes, c’est beaucoup plus simple. Mais ça veut dire que les utilisateurs locaux sont les mêmes partout, notamment le compte administrateur local.

C'est-à-dire, si vous avez compromis un seul de ces postes, et que vous avez trouvé le hash du compte administrateur, il y a de grandes chances pour que ce même hash soit valide sur tous les autres postes ! C’est ce qu’on appelle le pass-the-hash.

Pass-the-hash

Concrètement, si vous avez volé le hash de l’administrateur local d’un poste, vous pouvez tenter le pass-the-hash vers d’autres postes en utilisant l’outil CrackMapExec. C’est un excellent outil pour attaquer plusieurs machines en même temps, notamment en utilisant seulement le hash d’un utilisateur compromis.

Pour extraire les hash NT des utilisateurs locaux sur des machines, le paramètre --sam doit être fourni à CrackMapExec, ainsi que les identifiants d’un compte administrateur.

Si un signe [+] vert apparait dans la sortie de CrackMapExec pour une machine, c’est que le compte a le droit de s’authentifier sur cette machine. Si vous avez également le message (Pwn3d!), alors vous êtes administrateur de la machine.

Pour s’authentifier avec le hash NT d’un utilisateur, vous pouvez utiliser le paramètre -H de CrackMapExec. Il faut également ajouter le paramètre --local-auth si vous vous authentifiez avec un compte local, et non un compte du domaine.

cme smb 10.10.10.0/24 -u Administrateur -H aad3b435b51404eeaad3b435b51404ee:01a27c88a6c1bd0ab0944599129c58a6 --local-auth

Vous pouvez également utiliser le paramètre -hashes pour tous les outils propres à la suite Impacket. Par exemple l’outil psexec.py.

psexec.py Administrateur@dc01.medic.ex -hashes aad3b435b51404eeaad3b435b51404ee:01a27c88a6c1bd0ab0944599129c58a6

Attention, le compte administrateur local peut être Administrateur ou Administrator, en fonction de la langue utilisée sur la machine Windows. Pensez bien à essayer les deux !

Le protocole NTLM permet à un client de s’authentifier auprès d’un serveur. Vous avez vu que cette authentification se passe en trois étapes. Mais que se passe-t-il si un attaquant a réussi à se placer en position d’homme du milieu ? Il peut alors faire passe-plat, se faire passer pour le client auprès du serveur, et donc effectuer des actions sur le serveur en se faisant passer pour un client. C’est ce qu’on appelle le relais NTLM.

Relais NTLM

On se place dans le cadre où votre attaque Pass-the-hash réussit, vous êtes maintenant authentifié sur le serveur. Il faut maintenant passer à la deuxième phase : La phase de sessions.

Vous allez pouvoir, entre autres, lire les informations de l'AD via LDAP, ou des partages réseaux via SMB, et si vous avez des droits d'admin, vous pourrez compromettre le serveur cible en y exécutant des commandes.

Mais dans certains cas, il existe une protection qui pourra faire échouer ces attaques, il s'agit de la signature des flux. Cela consiste à ce que même après votre authentification, toutes vos demandes devront être signées avec le mot de passe du client utilisateur.

Et comme vous ne connaissez pas ce mot de passe, l'attaque sera immédiatement bloquée. Par défaut, aucun serveur ne requiert de signature, sauf les controleurs de domaine pour SMB.

Un outil très puissant permet de faire du relais NTLM : ntlmrelayx.py, un des outils de la suite Impacket.

Relais d’une connexion de MEDIC.EX\Administrateur vers 10.10.10.2

Dans cet exemple, l’outil a été lancé pour relayer les authentifications vers le serveur 10.10.10.2 avec l’option -t. Une authentification de l’utilisateur MEDIC.EX\Administrateur est reçue par l’outil puis relayée vers le serveur. Une fois l’authentification terminée grâce au relais, ntlmrelayx extrait automatiquement les identifiants des utilisateurs locaux du poste.

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.

Protocole Kerberos - Demande de 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.

Protocole Kerberos - Demande de ticket de service

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.

Protocole Kerberos - Utilisation du ticket de 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

Utilisation de GetUserSPNs pour trouver les comptes Kerberoastables

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.txt

Il existe des outils qui indiqueront que le compte krbtgt est Kerberoastable. En effet, ce compte est assimilé à un compte utilisateur, et possède un SPN (kadmin/changepw). Cependant, d’une part ce compte est désactivé, et d’autre part il existe sur toutes les versions d’Active Directory et possède un mot de passe long et complexe. Il n’est pas utile de perdre du temps à essayer de casser son mot de passe.

Pass-the-ticket

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.

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.ex

RDP 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.ex

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.log

L’outil permet de gagner du temps en faisant une première passe sur tous les partages, mais rien n’est magique ! Ce n’est pas parce qu’il ne trouve rien qu’il n’y a rien.

Dans un premier temps l'utilisation de Snaffler, lors d'audits permet de faire une première passe, mais il est important également de faire 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.

Dans un Active Directory, des utilisateurs peuvent utiliser des services. Il arrive parfois qu’un service dépende d’un autre service pour fonctionner. Par exemple, si dans l’intranet de l’entreprise, il y a un moyen d’accéder à ses fichiers stockés dans un partage réseau, cela veut peut-être dire que le service web de l’intranet accède à un partage réseau pour pouvoir l’afficher à l’utilisateur.

Accès d’un service à une autre ressource

Or, le service web ne sait pas quels sont les droits de l’utilisateur sur le partage réseau. C’est là qu’entre en jeu la délégation Kerberos.

Le principe est de permettre à un compte de service de se faire passer pour un utilisateur auprès d’un autre service.

Accès d’un service à une autre ressource

Ce mécanisme permet à l’intranet de se faire passer pour l’utilisateur, et de s’authentifier au nom de celui-ci auprès du serveur de fichiers. Ainsi, du point de vue du serveur de fichiers, c’est l’utilisateur qui fait la demande, et le serveur de fichiers va pouvoir vérifier les droits de cet utilisateur, puis envoyer les informations auxquelles ce compte a accès. C’est de cette manière que le serveur web peut ensuite afficher ces informations dans une jolie interface.

Exemple :   site du Transfert de fichier Orange

Pour ne pas nous mélanger les pinceaux, nous dirons qu’un utilisateur se connecte à un service, qui lui-même accède à une ressource. Cette ressource est également un service, c’est seulement un autre nom qu’on lui donne pour bien comprendre qui accède à quoi.

Nomenclature des différents éléments

Il existe trois types de délégations qui peuvent toutes être exploitées par un attaquant :

• la délégation non contrainte ;
• la délégation contrainte ;
• la délégation contrainte basée sur les ressources.

C’est cependant la délégation non contrainte la plus dangereuse pour une entreprise, et c’est donc sur celle-ci que nous allons le plus nous attarder.

Dans la délégation non contrainte, c’est le service qui en est responsable, et comme son nom l’indique, le compte de service n’a aucune contrainte. Dès qu’un utilisateur lui présente un ticket de service, il peut se faire passer pour cet utilisateur auprès de n’importe quelle autre ressource.

Délégation sans contrainte

Pour que cela fonctionne, quand un utilisateur accède à un service en délégation sans contrainte, il envoie non seulement son ticket de service, mais également une copie de son TGT. Vous le savez, le TGT, c’est la carte d’identité de l’utilisateur. Le service est donc en possession du TGT de l’utilisateur, et peut ainsi demander des tickets de service pour n’importe quelle ressource en se faisant passer pour l’utilisateur.

C’est très intéressant pour vous : cela signifie que si vous compromettez un service en délégation non contrainte, vous pouvez vous faire passer pour quelqu’un sans aucun problème ! Il suffit d’attendre qu’un utilisateur veuille utiliser le service compromis, et dès que ça arrive, vous pouvez extraire son TGT, qu’il va vous fournir.

Pour cette attaque, l’outil Rubeus peut être utilisé sur une machine Windows. Sachez que beaucoup de services sont exécutés par le compte machine. Donc si vous compromettez une machine qui est en délégation non contrainte, vous pouvez attendre les TGT des utilisateurs pour les extraire.

Rubeus.exe monitor

Lorsque vous récoltez des TGT, vous pouvez les utiliser dans votre session en utilisant l’option ptt (pour pass-the-ticket) de Rubeus.

Rubeus.exe ptt /ticket:doIFmjCCBZagAwIBBaEDAgEWoo[...]

Concernant la délégation contrainte, c’est également le service qui en est responsable. Lorsqu’un service est configuré en délégation contrainte, il pourra aussi se faire passer pour un utilisateur auprès de ressources, mais pour une liste de ressources bien définies.

Si vous compromettez un serveur en délégation contrainte, vous pourrez donc vous faire passer pour des utilisateurs auprès des ressources autorisées pour la délégation. Le périmètre d’attaque est moins large, mais il existe.

Enfin, en délégation contrainte basée sur les ressources (ou RBCD pour Resource Based Constrained Delegation), la responsabilité de la délégation est déplacée. Alors que dans la délégation non contrainte et dans la délégation contrainte, c’est au niveau du service qui délègue que l’on configure la délégation, dans le cas de la RBCD, c’est au niveau des ressources qu’on indique la liste des services qui peuvent communiquer avec elles via délégation.

Délégation contrainte basée sur les ressources

Pour cela, une liste de services autorisés à faire de la délégation est renseignée au niveau de la ressource. Donc si en tant qu’attaquant, vous avez le droit de modifier cette liste, vous pourrez y ajouter des services arbitraires.

Par exemple, si vous avez compromis un compte de service via Kerberoasting, ou si vous êtes administrateur d’un poste, vous pouvez les ajouter à la liste de confiance de la ressource, et ainsi vous faire passer pour des utilisateurs auprès de cette ressource.

Pour identifier les machines qui sont configurées pour de la délégation Kerberos, l’outil findDelegation.py de la suite Impacket peut être utilisé.

findDelegation.py medic.ex/pixis:P4ssw0rd

Nous avons vu que grâce au pass-the-hash, nous avons compromis notre premier domaine. Nous avons volé le hash du compte administrateur local d’une machine et nous l’avons rejoué sur tous les autres postes, ça nous a permis de voler le mot de passe d’un administrateur de domaine.

Pour faire cela, nous avons extrait les identifiants de tous les processus lsass des machines compromises.

Cette technique permet une élévation de privilège et est très commune.

Le matin quand vous vous connectez à votre ordinateur, vous renseignez votre nom d’utilisateur et votre mot de passe. Une fois authentifié, vous pouvez accéder à des ressources comme des partages réseaux sans avoir à les fournir à nouveaux (les credentials). Tout cela est possible, car Windows enregistre vos identifiants dans un processus appelé Local Security Authority Subsystem Service (LSASS).

En résumé, c’est lui qui gère toute la sécurité de Windows. Comment cela fonctionne concrètement ?

Quand le processus LSASS est en cours d’exécution, son contenu exécutable est copié dans la mémoire vive. Certains utilisateurs peuvent en faire une photographie à un instant T, le résultat est fourni sous forme de fichier qu’on appelle « fichier de vidage » ou « dump mémoire ».

Les informations récupérées permettent de faciliter un débogage. Pour faire un dump du processus LSASS vous avez 2 options. Chacune nécessite d’être Administrateur du poste compromis.

• Première option : vous avez besoin du privilège « SeDebugPrivilege » que vous ne pouvez activer qu’en tant qu’Administrateur.
• Seconde option : être le compte qui exécute le processus. LSASS est exécuté par le compte SYSTEM, qui est le compte d’administration intégré à Windows. Il faut donc impérativement être Administrateur pour ouvrir une session en tant que SYSTEM.

Une fois le dump de LSASS effectué vous avez en main un fichier précieux. Il contient les identifiants enregistrés d’utilisateurs de la machine. Le Graal pour vous en tant qu’attaquant est de récupérer ceux d’utilisateurs ayant des privilèges d’Administrateur du domaine.

Avec la technique du pass-the-hash que nous avons vu, plusieurs dizaines de machines ont été compromises, aller se connecter sur chacune d’entre elles pour lancer l’outil d’analyse peut être fastidieux. Nous pouvons alors utiliser un outil qui permet d’extraire les identifiants de LSASS à distance sur plusieurs machines en parallèle. L’outil s’appelle lsassy.

Vous avez découvert qu’il était possible d’extraire des identifiants du processus Lsass pour peut-être trouver des comptes de domaine à privilèges, notamment avec l’outil lsassy qui permet d’automatiser cette tâche sur plusieurs postes à distance.

Les recherches ne doivent pas s’arrêter là. Il existe beaucoup d’autres endroits dans lesquels sont stockés des identifiants pour simplifier la vie des utilisateurs.

Une des fonctionnalités de Windows, appelée DPAPI (Data Protection API), permet d’enregistrer de manière chiffrée des informations sensibles sur un ordinateur. Cette fonctionnalité est utilisée par plusieurs composants de Windows et logiciels. C’est le cas des tâches planifiées, des mots de passe des réseaux Wi-Fi ou encore des mots de passe de Chrome. Évidemment, si Windows est capable de les utiliser pour automatiquement se connecter à un réseau Wi-Fi, par exemple, ça veut dire que toutes les clés sont à portée pour que vous puissiez les extraire.

L’outil DonPAPI a été créé pour ça. Son but est d’extraire les secrets DPAPI (mais pas que) sur un ensemble de machines à distance. Il faut que vous soyez administrateur local des postes ciblés.

DonPAPI.py medic.ex/pixis:P4ssw0rd@10.10.10.2

Il y a un autre endroit dans lequel sont enregistrés des mots de passe : la base de registres. Cette base contient les données de configuration du système d'exploitation et des autres logiciels installés désirant s'en servir. Vous pourrez y trouver les identifiants des comptes locaux dans la ruche SAM. C’est ici qu’on peut extraire le hash NT de l’administrateur local de la machine. Il y a également les secrets LSA dans la ruche SECURITY. Ces secrets sont les mots de passe des comptes utilisés pour exécuter des services, par exemple.

Ces secrets peuvent être extraits à l’aide de l’outil secretsdump.py, toujours de la suite Impacket.

secretsdump.py medic.ex/pixis:P4ssw0rd@10.10.10.2

Si vous avez compromis un contrôleur de domaine, cet outil ira en plus extraire tous les secrets de tous les utilisateurs et postes du domaine. En effet, il utilisera le protocole DRS (Directory Replication Service) pour se faire passer pour un contrôleur de domaine, et demander à la cible une réplication complète. Cela s’appelle la technique du DCSync.

Enfin, comme la base de registre est utilisée par de nombreux logiciels pour y stocker des configurations, il est fort possible qu’ils enregistrent des mots de passe enregistrés par des utilisateurs.

Parmi les différents rôles d’un Active Directory se trouve le rôle de gestion du parc. Active Directory permet de gérer l’ensemble des machines et utilisateurs du système d’information, et pour cela les stratégies de groupe (Group Policy Objects – GPO) sont un outil indispensable.

Concrètement, les GPO sont un ensemble de règles/actions qui s’appliquent à un ensemble bien défini d’ordinateurs et d’utilisateurs. Une GPO permet de faire beaucoup, beaucoup de choses, comme modifier l’écran de veille, paramétrer des réseaux Wi-Fi, régler le pare-feu, modifier les administrateurs locaux, lancer des scripts au démarrage du poste, etc.

Vous comprenez bien que si vous avez le droit de modifier une GPO, vous serez capable de faire beaucoup de choses sur les objets sur lesquels elle s’applique. L’outil BloodHound vous permet de découvrir les utilisateurs ou groupes qui ont le droit de modifier une GPO. Si jamais vous en faites partie, alors le mieux est d’utiliser votre machine virtuelle Windows Server pour aller modifier la GPO.

Il existe des outils qui permettent de modifier des GPO pour des attaquants, mais le mécanisme de fonctionnement des GPO est très, très complexe. Il y a des chances que vous cassiez les règles en place sur la GPO que vous exploitez, si vous passez par des outils.

Je vous recommande fortement de plutôt passer par l’interface Windows de gestion des GPO pour toute modification (la GPMC, ou Group Policy Management Console). Idéalement, faites une sauvegarde de la GPO que vous exploitez avant de passer à l’action avec l’outil Backup-GPO de Microsoft, par exemple.

Il existe donc beaucoup de moyens de compromettre les utilisateurs ou machines sur lesquels s’appliquent des GPO, mais un exemple simple est d’ajouter un administrateur local. Pour cela, il suffit d’éditer la GPO que vous avez le droit de modifier, d’aller dans Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups, et de mettre à jour le groupe Administrators en y ajoutant un nouveau membre que vous contrôlez.

Ajout d’un administrateur local sur les postes

Sachez également qu’il arrive que des informations sensibles soient stockées dans les GPO, comme des mots de passe d’administrateurs locaux par exemple, ou que des paramètres dangereux soient positionnés. L’outil Group3r a été créé pour analyser le contenu de toutes les GPO afin d’extraire de potentielles informations intéressantes pour un attaquant.

Group3r.exe -s -f group3r_output.log

Une infrastructure de gestion de clés publiques permet de gérer l’ensemble des clés publiques des utilisateurs. Dans un Active Directory, cela permet notamment de délivrer des certificats aux utilisateurs pour différentes finalités. Ça peut être par exemple utilisé pour une authentification 802.1X, pour des accès VPN, pour chiffrer des flux, signer des scripts PowerShell ou encore pour renforcer des authentifications.

Lorsqu’un utilisateur fait une demande de certificat à une autorité de certification, il demande en fait une signature de certificat en précisant le modèle de certificat qu’il souhaite, ainsi que les informations nécessaires pour remplir ce modèle. Active Directory dispose en effet de modèles préenregistrés qui permettent de ne pas réinventer la roue. Il est évidemment possible d’ajouter de nouveaux modèles pour tout type d’application. L’autorité de certification va alors vérifier si l’utilisateur a le droit de demander ce type de certificat, avec les informations fournies, et si tout va bien, il renverra au client le certificat signé.

Le problème, c’est qu’il existe très souvent des erreurs de configuration dans ces modèles de certificats. Si un utilisateur a le droit de modifier un modèle, ou si le modèle est trop permissif et permet à un utilisateur de modifier plus d’informations que prévu, ça peut conduire à une vulnérabilité, voire une compromission du domaine.

Par exemple, il arrive qu’un modèle de certificat destiné à l’authentification des utilisateurs autorise de spécifier le nom associé au certificat. Cela signifie que vous pouvez demander ce certificat en spécifiant qu’il sera signé par un administrateur. Utiliser ce certificat signé vous permettra alors de vous authentifier en tant qu’administrateur.

Autre vulnérabilité, si vous avez le droit de modifier un modèle de certificat, vous pouvez le configurer comme expliqué précédemment, afin de pouvoir le demander avec un nom d’utilisateur arbitraire.

L’outil Certify a été conçu pour énumérer les vulnérabilités potentielles dans la mise en place d’une PKI Active Directory. Il a été écrit en C#, et donc doit être exécuté depuis une session Windows authentifiée.

certify.exe find /vulnerable /ca:dc01.medic.ex /domain:medic.ex

Si vous souhaitez en savoir plus sur ce sujet, sachez qu’il existe un papier de 143 pages (en anglais) intitulé Certified Pre-Owned - Abusing Active Directory Certificate Services, qui se focalise sur ce type de vulnérabilité.

Lorsque vous avez pris la main sur une machine, il peut être intéressant d’y ajouter une persistance pour pouvoir revenir dessus plus tard. En effet, si vous avez exploité une vulnérabilité propre à la machine, les équipes de sécurité peuvent potentiellement avoir détecté votre intrusion et mis à jour la machine dans la foulée. Il serait alors pertinent de garantir votre accès pour éviter de devoir tout refaire !

Une technique simple et efficace consiste à ajouter un nouvel utilisateur local à la machine compromise. Après avoir créé cet utilisateur, vous l'ajouterez au groupe d’administration. De cette manière, vous pourrez vous connecter à cette machine via ce compte, en utilisant les outils légitimes, comme RDP ou WinRM.

net user evil p4ssw0rd /add
net localgroup Administrateurs evil /add

Notez que dans cet exemple, nous ajoutons le compte evil au groupe local Administrateurs. Cela fonctionne parce que la machine compromise est configurée en français. Si vous êtes sur une machine anglaise, vous devrez changer le nom du groupe local en Administrators. La reconnaissance que vous aurez faite au préalable sur cette machine vous permettra de découvrir la langue du système d’exploitation compromis.

Cette technique permet de garder la main sur une machine compromise. Cependant, si vous avez compromis le domaine, vous pouvez aller plus loin, et ajouter un utilisateur à un groupe privilégié. Vous avez découvert ces groupes dans ce cours lors de la cartographie du domaine. Rappelez-vous, vous avez cherché les membres des groupes Admins du domaine ou Administrateurs de l’entreprise, par exemple. Ajouter un compte à l’un de ces groupes vous permettra donc de maintenir vos privilèges dans le domaine.

net user evil p4ssw0rd /add /domain
net group “Admins du domaine” evil /add

Ces exemples sont simples à mettre en place, mais sachez que beaucoup d’entreprises surveillent les membres des groupes privilégiés de très près. Ce sont donc des techniques pratiques, mais bruyantes. Le risque de lever des alertes du côté de la défense est très élevé.

Il existe quelques techniques classiques de persistance qui permettent de reprendre la main sur une machine sans dépendre d’une vulnérabilité ou d’un compte compromis.

Vous pouvez par exemple paramétrer la machine pour qu’elle exécute du code régulièrement, comme par exemple créer un compte administrateur local.

Tâches planifiées

Pour exécuter du code régulièrement, vous pouvez créer une tâche planifiée.

schtasks /create /tn EvilTask /tr "c:\windows\syswow64\WindowsPowerShell\v1.0\powershell.exe -WindowStyle hidden -NoLogo -NonInteractive -ep bypass -nop -c 'net user evil p4ssw0rd /add; net localgroup Administrateurs evil /add'" /sc onlogon /ru System

Tâche planifiée créée

Clés RUN

Une autre manière d’exécuter régulièrement du code consiste à utiliser certaines clés de registre permettant d’exécuter un programme dès qu’un utilisateur se connecte. Ces clés sont couramment appelées les clés RUN. Elles se trouvent à ces différents emplacements dans le registre :

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

Le contenu des clés Run sera exécuté à chaque fois qu’un utilisateur se connectera, tandis que celui des clés RunOnce sera exécuté une seule fois, puis le contenu de la clé sera automatiquement supprimé.

Vous pouvez créer ces clés via la ligne de commande avec l’utilitaire reg propre à Windows.

reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" /v OpenClassroomsEvil /t REG_SZ /d "C:\Windows\Temp\OC.exe"

Modification de services

Les services sont également une fonctionnalité que vous pouvez utiliser pour de la persistance. Ce sont des programmes qui peuvent être exécutés automatiquement au démarrage de la machine, et qui tournent en tâche de fond. Vous pouvez alors créer un service, ou mieux, en modifier un existant, pour que votre code malveillant soit exécuté automatiquement au démarrage de la machine.

sc config AxInstSV binPath= "C:\Windows\Temp\OC.exe" start= auto

Un œil avisé aura remarqué qu’il y a un espace après chaque signe = dans la ligne de commande. Ce n’est pas une faute de frappe, l’utilitaire sc attend bien un espace après binPath= et start=.

Vous avez pu observer que la gestion des droits chez Windows devenait assez vite complexe. Il y a des centaines d’objets, des milliers de droits, et peu de personnes sont capables d’avoir un œil sur tout, tout le temps.

Modifier des droits est donc une technique qui peut être assez discrète pour des fins de persistance. Il y a tellement de droits et d’objets qu’il serait impossible de décrire toutes les techniques ici, mais en voici une idée.

Le groupe Admins du domaine est un groupe à privilèges. Vous avez vu que vous pouviez ajouter un compte dans ce groupe pour de la persistance. Mais que se passe-t-il si un jour ce groupe est nettoyé par les administrateurs, pour ne garder que les comptes qu’ils connaissent ?

Eh bien, une autre possibilité consiste à modifier la liste des droits appliquée au groupe en question. Au lieu d’ajouter votre utilisateur au groupe, vous pouvez plutôt donner le droit à votre utilisateur d’ajouter des membres arbitraires au groupe. Comme ça, plus tard, vous pourrez soit vous ajouter vous-même, soit ajouter un autre compte que vous avez en votre possession.

Pour cela, vous devez vous rendre dans l’onglet Sécurité (ou Security) du groupe, et vous ajoutez le droit Écriture (ou Write) à l’utilisateur de votre choix.

Ajout d’une persistance pour l’utilisateur “Open Classrooms”

Enfin, deux techniques de persistance ont beaucoup fait parler d’elles. Ce sont les techniques du Silver Ticket et du Golden Ticket.

Alors pour rappel, il utilise des tickets (TGT et tickets de service) pour authentifier des utilisateurs voulant accéder à des services. Dans ces tickets, il y a toutes les informations de l’utilisateur. On y trouve son nom, par exemple, mais aussi l’appartenance à ses groupes. Il est donc important qu’un utilisateur ne puisse pas modifier arbitrairement ses tickets, sinon il pourrait prétendre faire partie du groupe “Admins du domaine” ou être le compte “Administrateur”. Les tickets sont donc protégés. Mais que se passe-t-il si les mots de passe qui protègent ces tickets sont volés ? C’est ce que nous allons voir.

Silver Ticket

La technique du Silver Ticket se focalise sur les tickets de service. Lorsque vous vous connectez, vous faites une première demande de TGT, c’est votre carte d’identité. Puis à chaque fois que vous voulez accéder à un service, vous allez présenter votre TGT au contrôleur de domaine, et celui-ci copiera vos informations dans un ticket de service. Pour éviter que vous puissiez le modifier, ce ticket est protégé avec le mot de passe du compte de service.

Mais alors, si vous avez compromis le domaine et que vous souhaitez maintenir un accès, vous pouvez tout à fait voler les mots de passe des comptes de service, notamment les mots de passe des comptes machine. Vous pouvez les voler en utilisant secretsdump.py sur un contrôleur de domaine. Vous avez vu en début de partie que cet outil allait effectuer une attaque DCSync pour voler tous les hashs des mots de passe de tous les comptes du domaine. Une fois ces mots de passe volés, vous pouvez ensuite forger des tickets de service de toutes pièces.

Ces tickets forgés sont des Silver Tickets. Vous indiquez dans ce ticket que vous appartenez à tous les groupes privilégiés, et vous le protégez ensuite avec le mot de passe du compte de service que vous avez dérobé. En présentant ces tickets aux services, ce sera open bar !

Pour créer un Silver Ticket, vous pouvez utiliser ticketer.py de Impacket. Mais il vous faudra l’identifiant du domaine. C’est une information nécessaire à l’outil pour forger le ticket. Vous pouvez le récupérer avec lookupsid.py.

$ lookupsid.py medic.ex/pixis:P4ssw0rd@dc01.medic.ex
[...]
[*] Domain SID is: S-1-5-21-3526105896-714836913-1342931244
[...]
$ ticketer.py -nthash  -domain-sid S-1-5-21-3526105896-714836913-1342931244 -domain medic.ex -spn CIFS/SRV01.medic.ex administrator

Golden Ticket

Les Silver Tickets sont pratiques, mais c’est fastidieux de devoir créer un ticket par service. En plus, les mots de passe des comptes de service risquent fortement de changer régulièrement, ce qui vous ferait perdre vos accès.

Pourquoi ne pas aller en amont, et forger un TGT ? C’est le principe du Golden Ticket. Au lieu de voler les secrets des comptes de service, vous allez tout simplement voler le secret absolu, celui qui permet de protéger les TGT. Ce secret, c’est le mot de passe du compte krbtgt. Ce compte est présent dans tous les environnements Active Directory, et est uniquement là pour que le contrôleur de domaine puisse signer et chiffrer les TGT avec son mot de passe. C’est tout. Et son mot de passe n’est pas changé automatiquement. Toutes les conditions rêvées pour maintenir un accès.

D’expérience, il arrive très souvent que la date de dernier changement de mot de passe du compte krbtgt corresponde à la date d’installation de l’Active Directory dans l’entreprise. Ça veut dire que si ce compte a été compromis une fois depuis, alors les Golden Tickets sont toujours valables aujourd’hui.

Les mêmes outils permettent de créer un Golden Ticket, sauf que cette fois-ci, c’est le secret du compte krbtgt qui doit être fourni, et il n’est pas nécessaire de fournir un nom de service.

$ lookupsid.py medic.ex/pixis:P4ssw0rd@dc01.medic.ex
[...]
[*] Domain SID is: S-1-5-21-3526105896-714836913-1342931244
[...]
$ ticketer.py -nthash  -domain-sid S-1-5-21-3526105896-714836913-1342931244 -domain medic.ex administrator