Profitez de la délégation Kerberos
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.
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.
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.
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.
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 monitorLorsque 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[...]Est-on obligé d’attendre qu’un utilisateur se connecte sur le serveur pour exploiter la délégation non contrainte ?
Effectivement, attendre que des utilisateurs accèdent à votre machine compromise, c’est bien, mais forcer une authentification, c’est bien mieux ! Et si vous forciez un contrôleur de domaine à s’authentifier sur ce poste en délégation non contrainte ? Vous pouvez utiliser la technique de coercition d’authentification pour inciter le compte machine du contrôleur de domaine à s’authentifier. Étant donné que le poste que vous avez compromis est en délégation sans contrainte, vous récupérerez le TGT du compte du contrôleur de domaine. Et oui, ça veut dire que vous pourrez ensuite effectuer des actions en temps qu’un contrôleur de domaine. Et sachez que dans cette position, vous avez compromis le domaine ! Vous verrez dans le chapitre suivant ce que ça implique.
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.
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:P4ssw0rdRécupérez des identifiants sur un poste compromis
Dans la vidéo, 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.2Il 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.2Si 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.
Exploitez les GPO pour compromettre de nouveaux comptes
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.
Le chapitre du cours Centralisez et sécurisez votre annuaire Active Directory vous permettra de prendre en main les stratégies de groupe.
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 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.
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.logExploitez une PKI (Public Key Infrastructure)
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.exSi 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é.
Il existe plein d’attaques possibles. Certaines marquent plus que d’autres. Et si nous demandions à Lionel le chemin d’attaque dont il se souvient plus particulièrement ?
En résumé
Lorsqu’une machine est en délégation sans contrainte, vous pouvez extraire les copies des TGT des utilisateurs pour vous faire passer pour eux.
Windows permet d’enregistrer des mots de passe à différents endroits, et savoir les trouver ou les extraire vous permettra de compromettre des comptes à privilèges.
Si vous pouvez modifier une GPO, vous pourrez alors prendre la main sur les ordinateurs ou utilisateurs sur lesquels elle s’applique.
Lorsqu’une PKI est installée dans un Active Directory, il y a des chances pour qu’un modèle de certificat ne soit pas correctement configuré, et qu’il vous permette d’élever vos privilèges.
Lorsqu’un attaquant compromet des machines, voire un domaine, il passe par la phase de persistance, lui permettant de ne pas perdre les accès durement acquis. Bien comprendre les techniques de persistance vous permettra par ailleurs de vérifier qu’il n’y en a pas dans votre environnement.
