_1715178265.png)
Cette série d’articles du blog couvre les différentes techniques que les attaquants peuvent utiliser pour compromettre les comptes de service de l’Active Directory. Nous avons tout d’abord expliqué en détails comment ils peuvent reconnaître les comptes de service en utilisant la reconnaissance LDAP ; ensuite, nous vous avons révélé comment ils peuvent extraire les mots de passes des comptes grâce au Kerberoasting ; après quoi, nous vous avons expliqué comment ils élèvent les droits d’un compte avec des Silver Tickets afin d’ activer des accès et des activités additionnelles.
Sélection de contenu connexe :
Dans ce dernier post, nous allons nous intéresser au compte le puis puissant de tout environnement Active Directory : le compte krbtgt, qui est utilisé pour émettre les tickets Kerberos nécessaires à l’accès à des systèmes et données informatiques. En obtenant le hachage du mot de passe de ce compte auprès du centre de distribution de clés (KDC), un attaquant est en mesure de compromettre chaque compte dans l’Active Directory, ce qui lui donne un accès illimité et pratiquement impossible à détecter à tout système connecté au réseau de l’AD.
Qu’est-ce que le compte krbtgt dans l’AD ?
Les contrôleurs de domaine de l’Active Directory de Windows sont responsables du traitement des demandes de ticket Kerberos, qui sont utilisés pour authentifier les utilisateurs et leur accorder l’accès à des ordinateurs et des applications. Le mot de passe du compte krbtgt est utilisé pour chiffrer et déchiffrer les tickets Kerberos. Ce mot de passe est rarement modifié et le nom du compte est le même sur tous les domaines, il s’agit donc d’une cible privilégiée des attaquants.
Créer des Golden tickets (« tickets d’or »)
En utilisant Mimikatz, il est possible d’exploiter le mot de passe du compte krbtgt pour créer de faux tickets d’octroi de ticket Kerberos (TGT), qui peuvent être utilisés pour demander au serveur d’octroi de tickets (TGS) des tickets pour n’importe quel service, sur n’importe quel ordinateur du domaine.
Pour créer des Golden tickets Kerberos, un adversaire à besoin des informations suivantes :
- Le mot de passe haché du compte krbtgt
- Le nom et le SID du domaine auquel appartient le compte krbtgt
Voyons comment obtenir ces informations pas à pas pour créer des Golden tickets Kerberos.
Étape 1. Obtenir le mot de passe haché du compte krbtgt, ainsi que le nom de domaine et le SID.
Le plus difficile est d’obtenir le mot de passe haché du compte krbtgt, car il faut pour cela obtenir un accès privilégié à un contrôleur de domaine (DC). Une fois qu’un adversaire est capable de se connecter de façon interactive ou à distance à un DC, il peut utiliser Mimikatz pour extraire les informations requises à l’aide des commandes suivantes :
privilege::debug lsadump::lsa /inject /name:krbtgt
Cela lui fournira le mot de passe haché, ainsi que le nom de domaine et le SID :
Étape 2. Créer des Golden tickets.
Maintenant, le hacker peut créer des Golden tickets à volonté. Les paramètres utiles de Mimikatz pour la création de Golden tickets incluent :
- Utilisateur— Le nom du compte utilisateur sur lequel le ticket sera créé. Notez qu’il peut s’agir d’un nom de compte valide, mais pas obligatoirement.
- ID— Le RID du compte pour lequel l’attaquant va se faire passer. Il peut s’agir d’une ID de compte réelle, comme l’ID d’administrateur par défaut, 500, ou d’une fausse identité.
- Groupes— Une liste de groupes auxquels le compte du ticket appartiendra. Le groupe Domain Admins y est inclus par défaut, de façon que le ticket sera créé avec le maximum de privilèges.
- SID— Insertion d’un SID dans l’attribut SIDHistory du compte dans le ticket. Cela est utile pour s’authentifier d’un domaine à l’autre.
L’exemple ci-dessous montre la création d’un ticket pour un faux utilisateur fournissant l’ID d’administrateur par défaut. Nous verrons dans un instant comment ces valeurs entrent en jeu lorsque ce ticket est utilisé. Le déclencheur /ptt (« Pass the Ticket ») injecte le Golden Ticket en cours de création dans la session en cours.
Étape 3. Passer le ticket.
Le moment est venu d’utiliser le Golden Ticket qui a été chargé dans la session actuelle. Lançons une invite de commande sous le contexte de ce ticket en utilisant la commande misc::cmd.
Vous pouvez voir dans l’invite de commande que l’attaquant agit comme un utilisateur de domaine ordinaire sans appartenance à un groupe de domaine, ce qui signifie qu’il ne devrait avoir aucun droit sur les autres ordinateurs du domaine.
Cependant, comme le ticket Kerberos est en mémoire, il est possible de se connecter à un DC et d’avoir accès à tous les fichiers qui y sont stockés.
En utilisant PSExec, l’attaquant peut ouvrir une session sur le DC cible, et d’après cette session, il est maintenant connecté en tant qu’administrateur.
Le système croit que l’attaquant est l’administrateur en raison de l’ID 500 qu’il a utilisé pour générer le Golden Ticket. Les logs d’événements du contrôleur de domaine montrent également que le système croit que l’attaquant est administrateur, mais les données d’identification sont celles qui ont été usurpées lors de l’attaque Golden Ticket. Cela peut être particulièrement utile pour les attaquants cherchant à éviter d’être détectés ou à créer des logs de sécurité trompeurs.
Se protéger contre les attaques par Golden Ticket
Les attaques de l’Active Directory par Golden Tickets sont très difficiles à détecter car les « tickets d’or » ressemblent comme deux gouttes d’eau à des TGT parfaitement valides. Cependant, dans la plupart des cas, ils sont créés avec des durées de vie de 10 ans ou plus, ce qui dépasse largement les valeurs par défaut de l’Active Directory pour la durée des tickets. Bien que les horodatages TGT ne soient pas enregistrés dans les logs d’authentification Kerberos, les solutions de sécurité appropriées pour l’Active Directory sont capables de les surveiller. Si vous constatez que des Golden Tickets sont utilisés au sein de votre organisation, vous devez réinitialiser deux fois le compte krbtgt. Cela peut avoir de lourdes conséquences, il faut donc procéder donc avec prudence.
La protection la plus importante contre les Golden Tickets consiste à restreindre les droits de connexion aux contrôleurs de domaine. Il devrait y avoir le nombre minimum absolu de Domain Admins et de membres d’autres groupes qui fournissent des droits de connexion aux DC, comme les opérateurs d’impression et de serveur. De plus, un protocole d’ouverture de session à plusieurs niveaux devrait être mis en place, afin d’empêcher les administrateurs de domaine de se connecter à des serveurs et à des postes de travail où le hachage de leur mot de passe pourrait être extrait de la mémoire et utilisé pour accéder à un DC et extraire le hachage du compte krbtgt.
