Ariovis

Chemin d'attaque Active Directory · Credentials alternatifs / PKINIT

Shadow Credentials : comprendre, détecter et prévenir l'attaque Active Directory

Shadow Credentials ne consiste ni à voler ni à réinitialiser le mot de passe d'une cible. L'attaque abuse d'un mécanisme légitime de Windows qui permet d'associer du matériel cryptographique à une identité Active Directory : l'attribut msDS-KeyCredentialLink, introduit avec Windows Server 2016, qui peut notamment contenir les clés publiques utilisées dans certains scénarios Windows Hello for Business.

Si une identité dispose des permissions lui permettant de modifier cet attribut sur un utilisateur ou un ordinateur, elle peut y ajouter une Key Credential qu'elle contrôle. Dans un environnement supportant PKINIT, la clé privée correspondante permet ensuite de demander un Ticket Granting Ticket Kerberos en tant que cible, sans que le mot de passe légitime soit connu ni modifié. Le mécanisme perturbe peu l'utilisateur légitime, mais laisse des traces détectables dans Active Directory.

La vraie question

Qui peut écrire msDS-KeyCredentialLink sur vos objets sensibles, et quel actif ces objets permettent-ils d'atteindre ?

Comprendre vos chemins d'attaque Active Directory
Catégorie
Credentials alternatifs / PKINIT
Attribut central
msDS-KeyCredentialLink
Mécanisme détourné
Key Credentials · authentification Kerberos PKINIT
Signal Windows
Event ID 5136 — sous réserve d'audit configuré

Le chemin d'attaque, étape par étape

Chaque étape dépend de ce que l'environnement autorise réellement. Rien dans cette séquence n'est automatique.

  1. 01Identité compromise
  2. 02Droit permettant de modifier l'objet cible
  3. 03Écriture d'une Key Credential dans msDS-KeyCredentialLink
  4. 04Authentification PKINIT
  5. 05Obtention d'un TGT Kerberos au nom de la cible
  6. 06Utilisation des privilèges de cette identité
  7. 07Mouvement latéral / élévation éventuelle vers un actif critique

Le point réellement dangereux n'est donc pas uniquement l'existence de msDS-KeyCredentialLink. Le chemin commence avec une relation de contrôle : une ACL, une délégation ou un droit trop large permettant à une identité de modifier le credential d'une autre. C'est exactement la logique développée sur la page parente : une technique isolée n'est pas encore un chemin d'attaque.

Pourquoi cette technique intéresse un attaquant

Trois propriétés expliquent sa place dans les chemins d'attaque Active Directory.

  • Discrétion élevée

    Le mot de passe de la cible n'est pas réinitialisé. L'utilisateur ou le service peut donc continuer à fonctionner normalement alors qu'un second mécanisme d'authentification a été ajouté.

  • Persistance

    Une rotation du mot de passe ne retire pas automatiquement la Key Credential ajoutée. La persistance disparaît lorsque la valeur non légitime est supprimée ou rendue inutilisable.

  • Élévation et mouvement latéral

    L'impact dépend entièrement de la cible. Ajouter une Key Credential sur un compte peu privilégié n'a pas le même impact que prendre le contrôle d'un compte de service sensible, d'un ordinateur critique ou d'une identité Tier 0.

Une technique qui n'est pas universellement exploitable

Plusieurs conditions doivent être réunies, notamment :

  • la présence de la fonctionnalité de Key Credential dans l'environnement Active Directory ;
  • un environnement Kerberos permettant l'authentification PKINIT ;
  • un KDC disposant des éléments cryptographiques nécessaires à PKINIT ;
  • une identité attaquante capable, directement ou indirectement, de modifier msDS-KeyCredentialLink sur la cible.

La présence d'AD CS peut rendre PKINIT disponible dans de nombreux environnements, mais une PKI vulnérable n'est pas un prérequis de Shadow Credentials, et ESC1 non plus. AD CS et Shadow Credentials sont deux sujets distincts qui se rencontrent autour de la PKI et de l'authentification Kerberos.

Le vrai sujet : les ACL

Une Shadow Credential est d'abord une attaque de contrôle d'objet Active Directory. Lors d'un audit, il faut donc rechercher les identités capables de modifier msDS-KeyCredentialLink, directement ou par l'intermédiaire de droits plus larges.

Trouver une valeur dans msDS-KeyCredentialLink n'explique pas le risque : c'est en comprenant qui peut l'écrire, et quel actif cette cible permet ensuite d'atteindre, que l'on reconstitue le chemin d'attaque.

Catégories de droits à analyser

  • WriteProperty sur l'attribut concerné ;
  • GenericWrite ;
  • GenericAll ;
  • droits permettant de modifier la DACL ou de reprendre le contrôle d'un objet ;
  • délégations historiques ou héritées ;
  • appartenance et gouvernance des groupes habilités à administrer les clés.

Cette liste n'est pas exhaustive : l'analyse doit porter sur les droits effectifs et sur leur héritage.

Détecter une Shadow Credential

Le signal principal se trouve dans les journaux des contrôleurs de domaine.

Événement principal

Event ID 5136 — A directory service object was modified

Filtrer en particulier : AttributeLDAPDisplayName = msDS-KeyCredentialLink

L'Event ID 5136 n'est pas automatiquement une preuve de Shadow Credentials, et sa génération suppose que l'audit Active Directory soit correctement configuré.

Il faut notamment disposer de

  • Audit Directory Service Changes ;
  • SACL adaptées aux objets et attributs surveillés ;
  • centralisation des événements des contrôleurs de domaine.

Pour chaque changement suspect, corréler au minimum

  • l'identité qui a réalisé la modification ;
  • l'objet cible ;
  • la classe de l'objet ;
  • la date et le contexte ;
  • le poste ou la source lorsque cette information est disponible ;
  • l'OpCorrelationID lorsqu'il est disponible ;
  • l'activité Kerberos et les authentifications qui suivent.
Alerter sur tous les 5136 ne suffit pas : Windows Hello for Business, Microsoft Entra Connect et d'autres mécanismes légitimes de provisioning peuvent modifier msDS-KeyCredentialLink. Il faut construire une baseline des writers et des workflows légitimes, puis identifier les modifications qui sortent de ce modèle.

Prévenir : supprimer les conditions du chemin

La prévention vise les relations qui rendent l'écriture possible, pas seulement l'attribut.

  1. 01

    Revoir les ACL

    Identifier qui possède réellement des droits permettant de modifier msDS-KeyCredentialLink sur les utilisateurs et les ordinateurs.

  2. 02

    Réduire les délégations

    Supprimer les GenericWrite, GenericAll et WriteProperty non nécessaires, particulièrement sur les comptes privilégiés et les objets sensibles.

  3. 03

    Gouverner les administrateurs de clés

    Vérifier les usages et les appartenances des groupes ou comptes légitimement autorisés à gérer les Key Credentials, sans supprimer aveuglément des droits nécessaires à Windows Hello for Business ou aux mécanismes de synchronisation.

  4. 04

    Inventorier les Key Credentials

    Contrôler les valeurs présentes sur les comptes sensibles et sur les objets qui ne devraient normalement pas utiliser d'authentification par clé.

  5. 05

    Surveiller dans la durée

    Journaliser les changements et distinguer les opérations issues de workflows d'enrôlement connus des modifications inattendues.

Pour prolonger la lecture sur votre propre annuaire, un diagnostic gratuit de sécurité Active Directory est disponible.

Si une Shadow Credential est découverte

Un simple changement de mot de passe n'est pas suffisant. La réponse doit comprendre :

  • l'identification de la Key Credential non autorisée ;
  • la conservation des éléments nécessaires à l'investigation ;
  • la suppression de la valeur malveillante concernée ;
  • l'analyse des authentifications et actions réalisées depuis son ajout ;
  • la recherche du droit ou de la délégation qui a permis l'écriture ;
  • la correction de ce chemin de permissions ;
  • la vérification que d'autres objets n'ont pas subi le même type de modification.

Ces deux niveaux ne se confondent pas : retirer la Shadow Credential ferme la persistance, tandis que corriger l'ACL qui a permis son ajout casse le chemin d'attaque et empêche qu'une autre clé soit écrite demain par la même identité.

Ne jamais effacer aveuglément toutes les valeurs msDS-KeyCredentialLink : certaines peuvent être légitimes.

Casser les chemins qui mènent aux actifs critiques

Shadow Credentials illustre pourquoi une analyse Active Directory ne peut pas se limiter à rechercher une technique isolée. Notre démarche couvre l'ensemble du chemin, dans le cadre de l'offre Sécurité des identités et Active Directory.

  • audit des comptes, groupes, délégations et droits sensibles ;
  • cartographie des chemins d'attaque ;
  • priorisation selon les actifs réellement atteignables ;
  • durcissement ;
  • supervision ;
  • remédiation.
Comprendre et supprimer vos chemins d'attaque Active DirectoryRevenir aux chemins d'attaque Active Directory

Techniques liées

D'autres techniques de la même collection. Elles ne constituent pas des étapes obligatoirement successives : chacune s'insère dans un chemin d'attaque selon ce que l'environnement autorise.

Sources techniques

Références utilisées pour étayer cette fiche.