Shadow Credentials : comment les ACLs mal configurées exposent vos données – Partie 1

Dans le monde de la cybersécurité, la quête des privilèges administrateurs est souvent l’élément clé d’un test d’intrusion réussi ouvrant un éventail de possibilités telles que le mouvement latéral, l’extraction de secrets ou l’exécution de commandes. Cet article de blog explore la technique du « Shadow Credentials » utilisée pour obtenir rapidement les droits d’administrateurs locaux sur un ordinateur ou compromettre un utilisateur si les droits ACLs sont mal configurés.

Qu’est-ce que la technique du Shadow Credentials ?

Dans un Active Directory, NTLM et Kerberos servent de protocoles d’authentification principaux au sein des domaines Active Directory, garantissant la vérification des identités. Kerberos repose sur la cryptographie symétrique entre le client et le serveur, utilisant des tickets pour authentifier les différentes entités (compte utilisateur ou compte machine).

Les tickets d’authentification Kerberos :

Kerberos fonctionne avec deux principaux types de tickets, chacun jouant un rôle distinct dans l’authentification :

1. Ticket Granting Ticket (TGT) : suite à une authentification réussie, un TGT est émis par le KDC (Key Distribution Center), symbolisant l’identité vérifiée du compte.
2. Ticket de service : utilisé par le compte, ce ticket sert à l’authentification auprès des services au sein du domaine. Il garantit qu’un compte peut accéder aux services nécessaires du domaine sans authentifications répétées.

💡L’émission d’un TGT est basée sur une étape de préauthentification où le client doit valider son identité (sans la préauthentification, le compte deviendrait vulnérable aux attaques ASREP-Roasting). 

• Validation symétrique : communément, le flux d’authentification Kerberos implique le chiffrement d’un horodatage (timestamp) avec une clé symétrique dérivée du mot de passe. Des algorithmes de chiffrement tels que RC4, DES ou AES128-256 sont couramment utilisés, garantissant un processus de validation sécurisé.
• Validation asymétrique (PKINIT) : une alternative au chiffrement symétrique au sein d’un Active Directory existe et se nomme PKINIT. Elle permet l’authentification via des méthodes asymétriques, où le client utilise une paire de clés (une clé publique et une clé privée). L’infrastructure de Public Key Infrastructure (PKI) permet au KDC et au client d’échanger leurs clés publiques à l’aide de certificats numériques signés par une entité avec laquelle les deux parties ont préalablement établi un accord de confiance : l’Autorité de Certification (AC). Il s’agit du modèle Certificate Trust, le plus couramment utilisé pour l’authentification par carte à puce.

Le service LDAP offre un attribut s’associant à ce protocole connu sous le nom de msDS-KeyCredentialLink :

• Introduit avec Windows Server 2016, il fonctionne comme un stockage pour la clé publique liée soit à un objet ordinateur, soit à un objet utilisateur au sein du domaine.
• Lorsqu’un certificat est lié à un compte, il est stocké dans le msDS-KeyCredentialLink, assurant son association sécurisée avec le compte respectif.

Voici à quoi ressemble l’attribut msDS-KeyCredentialLink dans la documentation de Microsoft.

Cependant, pour mieux comprendre de quoi est composé l’attribut msDS-KeyCredentialLink nous vous suggérons la lecture de cet article de blog : Parsing the msDS-KeyCredentialLink Value for ShadowCredentials Attack écrit par @Podalirius.

Gérer et modifier l’attribut msDS-KeyCredentialLink est une action qui, souvent, nécessite des permissions spécifiques, généralement détenues par des comptes membres de groupes hautement privilégiés. Ces groupes incluent entre autres :

• Key Admins : les membres de ce groupe peuvent effectuer des actions administratives sur les objets clés au sein du domaine comme décrit dans les Groupes de sécurité par défaut d’Active Directory.
• Enterprise Key Admins : les membres de ce groupe peuvent effectuer des actions administratives sur les objets clés au sein de la forêt (i.e. au sein d’une collection d’un ou de plusieurs domaines Active Directory qui partagent des éléments communs).
• Domain Admins : les membres de ce groupe ont presque tous les privilèges au sein d’un domaine, dont la modification d’attributs.

💡Ainsi, dans un scénario où un compte est compromis et a des permissions GenericAll ou GenericWrite sur un objet, il pourra être utilisé pour réaliser une attaque par Shadow Credentials.

Il est important de noter que les objets utilisateurs ne peuvent pas modifier leur propre attribut msDS-KeyCredentialLink, tandis que les objets ordinateurs eux, le peuvent. D’autre part, les objets ordinateurs peuvent éditer leur propre msDS-KeyCredentialLink, mais peuvent seulement en ajouter s’il n’en existe pas déjà.

Lorsqu’un utilisateur possède les droits GenericAll, GenericWrite, ou WriteAccountRestrictions dans la liste de contrôle d’accès discrétionnaire (DACL) pour un objet (cela peut être un compte ordinateur ou utilisateur), il acquiert la capacité de modifier les attributs de l’objet. Cela inclut la possibilité de peupler l’attribut msDS-KeyCredentialLink de l’objet ciblé avec la clé publique associée.

L’attaquant peut ensuite demander un certificat pour le compte d’ordinateur ciblé et s’authentifier en utilisant le certificat acquis au format PFX, qui peut être utilisé, entre autres, pour l’authentification client (attention ici, un modèle permettant l’authentification client est utilisé et doit être actif).

Avec ce fichier PFX, l’attaquant pourrait extraire le hash NT du compte ciblé ou obtenir un Ticket Granting Ticket (TGT).

Si l’attaque de Shadow Credentials est réalisée vers un compte machine, il sera alors possible en utilisant le protocole S4U2Self, d’usurper l’identité de n’importe quel utilisateur sur la machine cible (si celui-ci n’est pas protégé contre la délégation ou appartenant au groupe Protected Users).

Cette méthode, reconnue comme l’approche classique de l’exploitation des Shadow Credentials, a été détaillée pour la première fois début 2021 dans un article écrit par Elad Shamir: Shadow Credentials.

Cette action peut entraîner, entre autres, l’exécution de code et donc un mouvement latéral. Voici les étapes de cette attaque de Shadow Credentials :

1. Un attaquant compromet un utilisateur de domaine et énumère les DACLs GenericWrite/GenericAll pour l’hôte ciblé.
2. L’attaquant peuple l’attribut msDS-KeyCredentialLink sur le compte utilisateur ciblé.
3. L’attaquant demande un certificat PFX pour cet utilisateur cible.
4. L’attaquant s’authentifie avec le certificat PFX et peut ainsi récupérer un TGT ou le hash NT de l’utilisateur en utilisant le protocole U2U.

Comprendre l’exploitation de l’attaque de Shadow Credentials via les DACLs

Comment un attaquant peut-il exploiter les DACLS ?

L’exploitation de la technique du Shadow Credentials via les listes de contrôle d’accès discrétionnaires (DACLs) requiert à l’attaquant d’ :

• Être dans un domaine qui prend en charge PKINIT et contenant au moins un contrôleur de domaine sous Windows Server 2016 ou une version ultérieure.
• Être dans un domaine où le(s) contrôleur(s) de domaine possède(nt) leur propre paire de clés (pour l’échange de clés de session), par exemple lorsque ADCS – Active Directory Certificates Services est activé ou lorsqu’une Autorité de Certification (CA) est en place.
• Avoir le contrôle sur un compte qui peut modifier l’attribut msDs-KeyCredentialLink de l’objet cible à travers les ACLs GenericAll, GenericWrite ou WriteAccountRestrictions.

Quelles sont les mauvaises configurations des DACLs qui peuvent mener à une attaque de Shadow Credentials ?

La manière la plus simple d’énumérer les mauvaises configurations des DACLs est d’utiliser BloodHound. Après avoir importé les données collectées, il est possible d’exécuter les requêtes de recherche intégrées pour énumérer les chemins entre les différents objets.

Une mauvaise configuration classique des DACLs menant à une attaque de Shadow Credentials pourrait ressembler à ceci :

💡Cette attaque de Shadow Credentials fonctionne à la fois sur des objets machines et des objets utilisateurs. De plus, si la valeur de l’attribut ms-DS-MachineAccountQuota est supérieure à 0, tout utilisateur du domaine aura la capacité de créer ses propres machine et l’approche de l’attaque par Resource Based Constrained Delegation (RBCD) pourrait être utilisée à la place de Shadow Credential. L’attaque de Shadow Credentials exposée ici est souvent utilisée lorsque le paramètre MachineAccountQuota est défini sur 0.

Pour une énumération plus détaillée et pratique, PyWhisker peut être utilisé depuis une machine Linux. Il permet l’énumération de l’attribut msDS-KeyCredentialLink :

pywhisker.py -d "$DOMAIN" -u "$USER" -p "$PASSWORD" --target "$TARGET" --action "list"

Comment exploiter les mauvaises configurations DACLS avec Shadow Credentials ?

La phase d’exploitation commence par le peuplement de l’attribut msDS-KeyCredentialLink. PyWhisker simplifie ce processus :

PyWhisker demandera automatiquement un certificat et l’enregistrera localement. Il vous guide même sur les étapes suivantes pour obtenir un Ticket Granting Ticket (TGT).

À présent, deux voies s’offrent à vous :

Acquisition d’un TGT pour le compte utilisateur (william.turner)

Utilisez PKINITOOLS de Dirk-jan pour obtenir un TGT en utilisant la commande :

python3 PKINITtools/gettgtpkinit.py -cert-pfx "$PFX_CERTIFICATE" -pfx-pass "$PFX_PASSWORD" "$DOMAIN"/"$USER" output_TGT.ccache

Récupération du hash NT du compte utilisateur (william.turner) avec U2U

Tout d’abord, ôtez la protection du certificat en utilisant Certipy car il ne peut pas gérer les certificats protégés par mot de passe pour l’authentification :

certipy cert -export -pfx "$PFX_CERTIFICATE" -password "$PFX_PASSWORD" -out unprotected_pfx.pfx

Ensuite, authentifiez vous en utilisant Certipy et récupérez le hash de l’utilisateur via le protocole U2U:

certipy auth -pfx unprotected_pfx.pfx -username "$USER" -domain "$DOMAIN"

Une alternative plus rapide existe. Certipy peut automatiser ces étapes en une seule commande, simplifiant le processus d’exploitation:

certipy shadow auto -u "$USER"@"$DOMAIN" -p "$PASSWORD" -account "$TARGET_ACCOUNT"

Vous obtenez ainsi le hash NT du compte utilisateur. Rappelez-vous que cette exploitation peut également être utilisée pour les comptes machine, comme nous le verrons dans la deuxième partie de cet article.

Conclusion 

Il est recommandé d’auditer les droits et permissions des utilisateurs dans un Active Directory. Il est important de vérifier les permissions sur les objets Active Directory, en commençant par les unités organisationnelles (OU) et en allant jusqu’aux utilisateurs et machines. De plus, tous les utilisateurs et groupes d’Active Directory devraient suivre le modèle du moindre privilège, basé sur l’octroi des seules autorisations nécessaires à l’opération souhaitée. 

Ainsi, il est recommandé de vérifier les points suivants :  

• Énumérer les différents droits ACLs d’un objet vers des comptes utilisateurs ou machines. 
• Énumérer les membres des groupes par défaut (y compris les sous-groupes) et identifier les droits nécessaires et supprimer les autres. 
• Analyser l’Active Directory (en particulier les OU et les groupes de sécurité) à la recherche de délégations de droits. 

---

Références

• https://eladshamir.com/2021/06/21/Shadow-Credentials.html 
• https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab 
• https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials 
• https://www.fortalicesolutions.com/posts/shadow-credentials-workstation-takeover-edition 
• https://github.com/ShutdownRepo/pywhisker 
• https://github.com/dirkjanm/PKINITtools 
• https://github.com/ly4k/Certipy  
• https://learn.microsoft.com/fr-fr/windows-server/identity/ad-ds/manage/understand-security-groups#default-active-directory-security-groups 

Auteur

Nathan Duverger, Audit Sécurité Offensive

03 juin 2024