[Un jour, en parcourant YouTube, nous sommes tombés sur une présentation de Tal Be'ery et Michael Cherny dans le cadre de Black Hat 2015. Dans leur exposé et le mémoire qui en découle, Watching the Watchdog : Protecting Kerberos Authentication with Network Monitoring, Be'ery et Cherny ont décrit quelque chose dont nous n'avions jamais entendu parler ... l'attaque Diamond Privilege Attribute Certificate (PAC). Nous nous sommes tous deux intéressés à la falsification de tickets au cours de l'année écoulée. Cette technique a donc immédiatement attiré notre attention et nous a entraînés dans un voyage d'examen et d'armement de PoC. Le résultat ? Le Diamond Ticket.
Lire la suite
Billet d'or ou billet de diamant
Les attaques Golden et Diamond Ticket nécessitent toutes deux l'accès à la clé KRBTGT. Cependant, les attaques Diamond Ticket nécessitent presque certainement aussi l'accès à la clé AES256. Alors que les attaques Golden Ticket tirent parti de la possibilité de forger un ticket d'octroi de ticket (TGT) à partir de zéro, les attaques Diamond Ticket tirent parti de la possibilité de décrypter et de recrypter des TGT authentiques demandés à un contrôleur de domaine (DC).
Diamond PAC vs Diamond Ticket
L'attaque originale du Diamond PAC :
- Demande un TGT sans PAC
- S'assure que le compte de service pour le service auquel il faut accéder n'a pas le bit NA dans son attribut UserAccountControl (UAC)
- Forge un PAC et le signe avec la clé KRBTGT
- Injecte le PAC dans le ticket de service résultant en incluant le PAC dans le champ enc_authorization_data du TGS-REQ
Le bit NA de l'attribut UAC a la valeur suivante 33554432 (voir figure 1).
Après avoir défini le bit NA dans l'attribut UAC d'un compte de service, les demandes de tickets de service adressées à ce compte de service n'ont pas de PAC (voir Figure 2).
Chaque fois que des données d'autorisation sont incluses dans l'élément enc_authorization_data d'un TGS-REQ (voir figure 3), elles sont copiées dans la section données_autorisation de la partie chiffrée du ticket de service qui en résulte.
Diamond PAC a profité de ce comportement pour injecter un PAC dans le ticket de service résultant lorsque le compte de service cible n'avait pas le bit NA (voir la figure 4).
Notez la différence de taille de la sortie du ticket entre la figure 2 et la figure 4.
Comme le montre la figure 5, le billet appartient à Loki, mais le PAC contient des informations d'utilisateur différentes ( Thor).
Grâce auxcorrectifs Kerberos/AD de novembre 2021 , l'utilisation d'un TGT sans PAC n'est plus possible sur les DCs à jour. Nous savions donc immédiatement que cette version de l'attaque ne fonctionnerait plus. Cependant, après avoir lu ce document, nous nous sommes demandés pourquoi l'attaque devait être aussi complexe. En simplifiant l'attaque, nous avons supprimé la plupart de ses exigences, ce qui l'a rendue possible sur des DC entièrement à jour.
La clé KRBTGT était une exigence, et l'attaque a utilisé n'importe quel autre compte valide pour demander un TGT. Pourquoi ne pas simplement décrypter ce TGT, le modifier à notre guise, recalculer les signatures PAC et le recrypter ? Nous avons baptisé cette approche l'attaque Diamond Ticket.
L'armement de Rubeus
Nous avons implémenté notre ticket diamant dans Rubeus avec une nouvelle commande - diamond
-dans le cadre de cette RP. Dans la démonstration suivante, nous utilisons cette nouvelle commande pour créer et utiliser un ticket Diamant.
Nous commençons l'attaque en tentant d'accéder à la base de données C$ (CIFS) sur un DC, en utilisant notre utilisateur à faible privilège(Loki). Comme le montre la figure 6, nous obtenons une réponse " Accès refusé" .
En supposant que nous ayons déjà compromis la clé KRBTGT, nous pouvons utiliser le nouveau diamant de commande
dans Rubeus pour créer un ticket diamant. Cette commande demande d'abord un TGT normal pour l'utilisateur à faible privilège Loki (voir la figure 7). La commande décrypte ensuite le TGT, modifie les parties concernées, recalcule les signatures et recrypte le TGT (voir figure 8).
Le ticket résultant peut alors être utilisé comme n'importe quel autre TGT, mais avec des modifications. Comme le montre la figure 9, nous avons ensuite demandé un ticket de service au service CIFS sur notre DC cible(Earth-DC).
Enfin, dans le même terminal, nous pouvons maintenant accéder à la base de données C$ sur le DC, en s'authentifiant en tant qu'utilisateur différent du compte qui a demandé le TGT (voir Figure 10).
Avantages OPSEC
Il existe de nombreuses façons de détecter l'utilisation d'un ticket d'or ou les actions nécessaires pour accéder à la clé KRBTGT (comme DCSync). Une technique : Surveiller les demandes de tickets de service (TGS-REQ) qui n'ont pas de demande de TGT correspondante (AS-REQ). Cependant, il faut savoir que la technique du ticket diamant est plus susceptible de contourner ce type de détection en demandant un TGT valide avant d'utiliser le ticket qui en résulte. En outre, comme le ticket est d'abord créé par un DC, certaines valeurs (par exemple, les heures du ticket) sont plus susceptibles d'être correctes par défaut, plutôt que de nécessiter le calcul des heures appropriées pour la création d'un ticket d'or OPSEC.
Conseils en matière de détection
La recherche originale de Diamond PAC a énuméré les éléments suivants en tant que conseils pour la détection basée sur le réseau :
- Un AS-REQ avec une PA-PAC-REQUEST est réglé sur false (faux)
- L'ajout de données d'autorisation dans un message TGS ultérieur
- Le service cible bit NA mis à faux, nécessitant un PAC pour l'autorisation
Compte tenu de l'amélioration de notre technique, ces conseils ne s'appliquent pas. L'attaque Diamond Ticket ne nécessite pas de demander un TGT sans PAC, ni d'envoyer un PAC falsifié dans un message de type enc_authorization_data d'un TGS-REQ, ou de placer le bit NA bit sur les comptes de service.
Cependant, certaines logiques de détection des attaques par ticket d'or (par exemple, les actions requises pour obtenir l'accès à la clé KRBTGT ) peuvent également s'appliquer à la détection d'une attaque par ticket de diamant. De nombreuses autres techniques pouvant être utilisées pour détecter n'importe quel type de faux ticket (Golden, Silver ou Diamond) dépendent en grande partie du niveau de soin apporté à la création du ticket - par exemple, la fixation d'heures de ticket différentes de ce qu'elles devraient être.
Aucune de ces méthodes n'est un remède miracle pour détecter cette attaque, tout comme il n'existe pas de remède miracle pour détecter les billets d'or.
Un nouveau regard sur les billets
Ce billet a cherché à démontrer un PoC minimal d'armement des Diamond Tickets, bien qu'il s'agisse d'une implémentation de type Mimikatz. Cette recherche peut être facilement étendue pour permettre le contrôle et la manipulation de n'importe quel ticket, avec les bonnes clés.
Après avoir terminé nos recherches et créé une arme PoC, Elad Shamir nous a envoyé la conférence DerbyCon 2014 de Tim Medin, Attacking Microsoft Kerberos Kicking the Guard Dog of Hades (Attaquer Microsoft Kerberos en donnant un coup de pied au chien de garde de Hades). Dans cet exposé, Tim aborde la même technique dans le contexte des tickets de service.
Bien que notre technique soit légèrement différente des billets d'or et d'argent, elle peut constituer une alternative utile et préférée dans certains environnements.
