Délégations Kerberos : non contrainte, contrainte et RBCD

Concept

Dans une architecture multi-tiers (ex: Serveur Web frontal $\rightarrow$ Serveur SQL arrière-plan), le serveur web doit souvent accéder aux données SQL sous l’identité réelle de l’utilisateur final pour respecter les autorisations. C’est le rôle de la délégation Kerberos.

Active Directory propose trois générations de délégation :

Délégation non contrainte (unconstrained delegation - Windows 2000) : le client confie une copie complète de son TGT au serveur frontal. Le serveur peut ensuite se faire passer pour l’utilisateur auprès de n’importe quel service du domaine ou de la forêt.
Délégation contrainte classique (constrained delegation avec S4U - Windows Server 2003) : le compte de service frontal est configuré par un administrateur avec une liste fermée de SPNs vers lesquels il est autorisé à déléguer (attribut msDS-AllowedToDelegateTo).
Délégation contrainte basée sur les ressources (RBCD - Windows Server 2012) : la configuration est inversée : c’est le serveur de ressource cible qui définit dans son propre attribut msDS-AllowedToActOnBehalfOfOtherIdentity quels comptes ont le droit de lui déléguer du trafic.

Pourquoi c’est important en DFIR

L’abus des délégations Kerberos figure au cœur des chaînes de compromission avancées :

Capture de TGTs de comptes Tier 0 : un serveur web compromis configuré en délégation non contrainte agit comme un piège à tickets. Les attaquants utilisent des attaques par coercition (PetitPotam, PrinterBug / MS-RPRN) pour forcer le contrôleur de domaine à s’authentifier dessus, capturant ainsi le TGT du DC en mémoire !
Attaques par protocol transition (S4U2SELF / S4U2PROXY) : dans la délégation contrainte avec transition de protocole, un attaquant peut obtenir un ticket de service pour n’importe quel utilisateur (y compris un administrateur de domaine) même si cet utilisateur ne s’est jamais connecté au service frontal.
Persistance furtive via RBCD : l’attaquant qui obtient des droits en écriture sur un objet ordinateur (GenericWrite, WriteProperty) peut configurer RBCD pour autoriser un compte de machine qu’il contrôle, lui garantissant un accès administrateur local permanent sur la cible.

Comment ça fonctionne

1. Délégation non contrainte (unconstrained)

Attribut Active Directory : userAccountControl contient le drapeau TRUSTED_FOR_DELEGATION (0x80000).
Lorsqu’Alice demande un TGS pour ce service, son KDC insère dans le ticket une copie de son propre TGT chiffrée avec la clé de session.
Le serveur extrait le TGT d’Alice et le dépose dans sa mémoire LSASS locale.

2. Délégation contrainte classique (constrained / S4U)

Attributs AD : msDS-AllowedToDelegateTo (liste des SPNs cibles) et TRUSTED_TO_AUTH_FOR_DELEGATION (si transition de protocole autorisée).
Utilise les extensions Kerberos Microsoft S4U2Self (le service demande un TGS pour lui-même au nom d’un utilisateur) et S4U2Proxy (le service échange ce TGS contre un TGS vers le service d’arrière-plan autorisé).

3. Resource-based constrained delegation (RBCD)

Attribut AD : msDS-AllowedToActOnBehalfOfOtherIdentity (descripteur de sécurité binaire DACL sur l’objet cible).
N’exige aucun droit Domain Admins pour être configuré si l’utilisateur possède des droits délégués sur la machine cible.

Ce qui est possible

Extraire les TGTs accumulés dans LSASS : sur un serveur à délégation non contrainte, exécuter sekurlsa::tickets permet de récolter tous les TGTs des utilisateurs ayant accédé au serveur depuis son dernier redémarrage.
Forcer un DC à s’authentifier sur un hôte non contraint : utiliser SpoolSample ou PetitPotam permet de récupérer immédiatement le compte machine DC01$ et de conquérir le domaine via DCSync.
Protéger les comptes sensibles : positionner l’attribut Account is sensitive and cannot be delegated (NOT_DELEGATED / 0x100000) ou ajouter le compte dans le groupe Protected Users bloque formellement la délégation de son TGT.

Ce qui n’est pas possible

Déléguer l’identité d’un membre de Protected Users : les membres de ce groupe ne peuvent jamais voir leur TGT délégué, quel que soit le type de délégation configuré.
Exploiter la délégation contrainte vers un SPN non listé : le KDC vérifie strictement l’attribut msDS-AllowedToDelegateTo. Tout TGS vers un autre service est refusé par KDC_ERR_BADOPTION.
Configurer RBCD sans disposer d’un compte avec un SPN : S4U2Proxy exige que le compte agissant possède au moins un SPN enregistré (un compte d’ordinateur ou un compte de service géré gMSA).

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« Tous les serveurs utilisent la délégation non contrainte par défaut. »	Seuls les contrôleurs de domaine ont la délégation non contrainte par défaut. Tout autre serveur qui l’active présente une anomalie architecturale majeure.
« Le groupe Protected Users empêche le vol de hash NTLM. »	Il empêche l’usage de NTLM et la délégation Kerberos, mais n’empêche pas l’extraction de secrets déjà présents dans la base NTDS.
« RBCD exige d’être Domain Admin. »	Faux. N’importe quel utilisateur ayant la permission d’écriture sur l’objet machine (ex: le créateur de la machine, `Validated write to DNS host name`) peut configurer RBCD.

Exemple concret d’investigation

Dans une enquête DFIR, un serveur d’impression secondaire PRINT-SRV est compromis :

L’attaquant constate que PRINT-SRV possède le drapeau TRUSTED_FOR_DELEGATION.
Il déclenche PetitPotam contre le contrôleur de domaine DC01 : python3 petitpotam.py PRINT-SRV 10.0.1.1
Le DC01 tente de se connecter via EFS RPC sur PRINT-SRV, fournissant son TGT machine DC01$.
L’attaquant extrait le TGT de DC01$ dans LSASS avec Rubeus.
L’attaquant injecte ce TGT dans sa session et exécute un DCSync sur l’annuaire.
Bilan DFIR : compromission totale du domaine en moins de 10 minutes à partir d’un simple serveur d’impression.

Artefacts et traces forensiques

Attributs Active Directory :
- userAccountControl : drapeaux 0x80000 (TRUSTED_FOR_DELEGATION) ou 0x1000000 (TRUSTED_TO_AUTH_FOR_DELEGATION).
- msDS-AllowedToDelegateTo : liste textuelle des SPNs autorisés.
- msDS-AllowedToActOnBehalfOfOtherIdentity : descripteur de sécurité binaire.
Journaux de sécurité DC :
- Event ID 4769 (TGS request) : détection de requêtes S4U2Self et S4U2Proxy. La présence du nom du service dans le champ client indique une impersonation S4U.
- Event ID 4738 / 4742 : modification d’un compte utilisateur ou ordinateur (surveillance des modifications de msDS-AllowedToDelegateTo ou userAccountControl).

Méthodes d’investigation

Inventorier tous les comptes à délégation non contrainte : Exécuter Get-ADComputer -Filter {TrustedForDelegation -eq $True} pour isoler les machines à risque d’accumulation de TGTs.
Auditer les modifications de l’attribut RBCD : Rechercher les objets ordinateurs dont l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity n’est pas null (Get-ADComputer -Filter 'msDS-AllowedToActOnBehalfOfOtherIdentity -like "*"').
Surveiller les flux RPC anormaux vers les serveurs à délégation : Analyser les connexions entrantes sur les ports 445/RPC issues des DC vers des serveurs membres (signature de coercition).

Outils d’investigation

PowerView :

Get-DomainComputer -Unconstrained
Get-DomainUser -TrustedToAuth
Get-DomainComputer | Where-Object { $_.'msds-allowedtoactonbehalfofotheridentity' -ne $null }

BloodHound : Filtres Cypher dédiés :
- MATCH (c:Computer {unconstraineddelegation:true}) RETURN c
- MATCH p=(u)-[:AllowedToAct]->(c:Computer) RETURN p

Points clés à retenir

La délégation non contrainte stocke les TGTs complets des clients dans LSASS.
Les attaques par coercition (PetitPotam) couplées à l’Unconstrained Delegation permettent la prise de contrôle immédiate du domaine.
RBCD permet de conférer des droits d’administration sur une machine sans être administrateur de domaine.
Les comptes sensibles doivent impérativement être configurés avec Account is sensitive and cannot be delegated.