Délégation Kerberos : Non Contrainte à RBCD

Qu'est-ce que la Délégation Kerberos ?

La délégation Kerberos permet à un service de s'authentifier auprès d'autres services au nom d'un utilisateur. Il existe trois types de délégation Kerberos, chacun avec des implications de sécurité très différentes :

Délégation Non Contrainte — le service peut se faire passer pour n'importe quel utilisateur auprès de n'importe quel service du domaine
Délégation Contrainte — le service ne peut se faire passer pour des utilisateurs qu'auprès de services spécifiques prédéfinis
Délégation Contrainte Basée sur les Ressources (RBCD) — la ressource cible contrôle qui peut déléguer vers elle

La délégation non contrainte est la configuration la plus dangereuse dans Active Directory après un Golden Ticket. Elle est trivialement exploitable et mène directement à Domain Admin.

Comment ca Fonctionne

Quand un utilisateur s'authentifie auprès d'un service configuré pour la délégation non contrainte, le KDC inclut une copie du TGT complet de l'utilisateur dans le ticket de service. Si un attaquant compromet une machine avec délégation non contrainte et peut forcer un Contrôleur de Domaine à s'y authentifier, il capture le TGT du DC — ce qui donne accès de niveau Domain Admin.

La technique pour déclencher l'authentification du DC est appelée printer bug ou SpoolSample.

La Chaine d'Attaque

Etape 1 - Trouver les Machines avec Délégation Non Contrainte

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
    Where-Object {$_.Name -notlike "*DC*"} |
    Select-Object Name, TrustedForDelegation

Etape 2 - Compromettre la Machine Déléguée

L'attaquant compromet la machine avec délégation non contrainte. Il contrôle désormais une machine qui collecte des TGTs.

Etape 3 - Forcer l'Authentification du DC (Printer Bug)

# SpoolSample — forcer le DC à s'authentifier auprès de la machine de l'attaquant
SpoolSample.exe DC01.corp.local SERVEUR-COMPROMIS.corp.local

Etape 4 - Capturer le TGT du DC et Escalader

# Sur la machine compromise — capturer le TGT du DC depuis la mémoire
Rubeus.exe monitor /interval:5 /filteruser:DC01$

# Une fois capturé, utiliser le TGT pour DCSync
Rubeus.exe ptt /ticket:doIFXDCCBVig...
lsadump::dcsync /domain:corp.local /user:krbtgt

Détection

Event IDs Windows

Event ID	Source	Ce qu'il faut surveiller
4769	DC - Security	Ticket de service demandé pour un compte DC depuis une source inattendue
4624	Serveur délégué	Connexion réseau (Type 3) depuis le compte machine DC
5145	Serveur cible	Accès au partage réseau — accès au pipe spoolss depuis une coercition DC

💡 Conseil : Désactivez le service Print Spooler sur tous les Contrôleurs de Domaine. Il n'est pas nécessaire sur les DCs et son suppression élimine le principal vecteur de coercition.

Requete SIEM (Elastic KQL)

event.code: "4769" AND
winlog.event_data.ServiceName: "*$" AND
winlog.event_data.TargetUserName: (*DC* OR *DOMCON*)

Remédiation

⚠️ Critique : La délégation non contrainte sur tout serveur autre que les Contrôleurs de Domaine est une mauvaise configuration critique. Remplacez par la délégation contrainte ou RBCD immédiatement.

1. Supprimer la Délégation Non Contrainte

Get-ADComputer -Filter {TrustedForDelegation -eq $true} |
    Where-Object {$_.Name -notlike "*DC*"} | ForEach-Object {
        Set-ADComputer -Identity $_ -TrustedForDelegation $false
        Write-Host "Corrigé : $($_.Name)"
    }

2. Désactiver le Print Spooler sur les DCs

Invoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock {
    Stop-Service -Name Spooler -Force
    Set-Service -Name Spooler -StartupType Disabled
}

3. Auditer les Configurations RBCD

Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
    Where-Object {$_."msDS-AllowedToActOnBehalfOfOtherIdentity" -ne $null} |
    Select-Object Name

Comment EtcSec Détecte Cela

UNCONSTRAINED_DELEGATION identifie tous les ordinateurs et comptes de service non-DC configurés avec la délégation non contrainte.

CONSTRAINED_DELEGATION signale les paramètres de délégation contrainte mal configurés.

RBCD_ABUSE détecte les ordinateurs où l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity est configuré de façon à permettre une escalade de privilèges.

ℹ️ Note : EtcSec audite tous les paramètres de délégation automatiquement lors de chaque scan AD. Lancez un audit gratuit pour identifier les mauvaises configurations de délégation.

Articles connexes : Golden Ticket : Les Clés de Votre Domaine | Kerberoasting

Priorites de Revue

Attaques de Délégation Kerberos : De la Délégation Non Contrainte à l'Abus RBCD doit etre traite comme une exposition reelle dans votre environnement Active Directory, pas comme un simple parametre isole. La premiere etape consiste a definir le vrai perimetre de revue : quels groupes privilegies, comptes de service, ACL, liens GPO, trusts, delegations, templates de certificats et postes d'administration sont concernes, quelles dependances metier existent, quels privileges sont exposes et quelles exceptions d'urgence ont ete ajoutees avec le temps. Ce cadrage evite une remediation superficielle, car le symptome technique est souvent plus petit que le rayon d'impact operationnel. En documentant le chemin complet entre configuration, privilege et usage reel, l'equipe peut prioriser des changements qui reduisent le risque sans bloquer l'activite.

Controles Adjacents a Revoir

Quand un attaquant arrive dans votre environnement Active Directory, il ne s'arrete presque jamais au premier point faible. Autour de Attaques de Délégation Kerberos : De la Délégation Non Contrainte à l'Abus RBCD, il cherche en general a enchainer avec comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees. Cela signifie que la defense doit revoir non seulement la faiblesse principale, mais aussi toutes les dependances qui transforment un acces initial en persistance ou en escalation. Verifiez quelles identites, quels roles, quelles permissions et quelles hypotheses de confiance peuvent etre reutilises. Si le correctif ferme un seul objet mais laisse intactes les voies adjacentes, le risque reel change peu. Une revue des chaines d'abus est donc indispensable pour obtenir un resultat durable.

Preuves et telemetry a collecter

Une bonne reponse a Attaques de Délégation Kerberos : De la Délégation Non Contrainte à l'Abus RBCD repose sur des preuves que l'ingenierie et la detection peuvent relire ensemble. Collectez Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, comparez les changements recents avec les fenetres de maintenance attendues et isolez les comptes ou objets qui ont change de comportement sans justification claire. Ces elements doivent permettre de repondre a trois questions simples : quand l'exposition est apparue, qui peut encore l'utiliser, et si des variantes similaires existent ailleurs dans votre environnement Active Directory. La collecte de preuves aide aussi a distinguer une dette technique ancienne d'un usage actif. Cette distinction est essentielle pour choisir le bon niveau d'urgence et la bonne sequence de remediation.

Faiblesses voisines a revoir

Tres peu d'environnements contiennent Attaques de Délégation Kerberos : De la Délégation Non Contrainte à l'Abus RBCD seul. Dans la pratique, la meme zone du tenant ou de l'annuaire contient souvent aussi comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees, et ce sont ces faiblesses voisines qui determinent si l'exposition reste limitee ou devient critique. Revoyez les owners communs, les permissions heritees, les exceptions dupliquees et les raccourcis administratifs qui n'ont jamais ete retires. Verifiez si la meme logique de contournement a ete approuvee a plusieurs endroits, car cela revele souvent une faille de processus plus qu'un bug unique. Cette revue elargie donne une meilleure chance d'eliminer le chemin d'attaque complet.

Ordre de remediation recommande

Pour Attaques de Délégation Kerberos : De la Délégation Non Contrainte à l'Abus RBCD, l'ordre de remediation doit privilegier la reduction de risque avant la perfection. Commencez par fermer les chemins qui augmentent le plus vite le privilege, puis verrouillez les objets ou identites a plus forte valeur, et ensuite seulement traitez les ecarts de hygiene secondaires. Utilisez tiering, nettoyage des delegations, revue ACL, hygiene des comptes de service, revue des permissions GPO et durcissement ADCS comme ensemble de controles cible. Chaque changement doit avoir un owner, une note de rollback et une etape de validation. Cette discipline evite que les programmes de correction s'arretent apres le premier gain technique. Si une refonte complete n'est pas possible tout de suite, formalisez des controles intermediaires et planifiez le travail structurel dans le prochain revue hebdomadaire des privileges et validation mensuelle des controles.

Validation apres chaque changement

Apres toute modification liee a Attaques de Délégation Kerberos : De la Délégation Non Contrainte à l'Abus RBCD, validez le resultat sous deux angles : administration legitime et chemin d'attaque. Confirmez que les utilisateurs et systemes attendus continuent de fonctionner, puis prouvez que la voie dangereuse ne donne plus le meme levier. Rejouez la collecte sur Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, relisez les approbations et verifiez qu'aucun objet voisin ne conserve une voie de contournement. La validation doit aussi inclure une definition ecrite du succes, afin que tout le monde sache ce qui constitue une fermeture acceptable. Dans les equipes matures, un correctif n'est accepte que lorsque le chemin risque est ferme et que l'etat final correspond vraiment a l'objectif de durcissement.

Ownership, escalade et gouvernance

Les sujets comme Attaques de Délégation Kerberos : De la Délégation Non Contrainte à l'Abus RBCD echouent quand le symptome technique est corrige mais que personne n'assume le controle long terme. Assignez des responsabilites claires entre ingenierie annuaire, analystes SOC, administrateurs identite et equipes serveurs, definissez qui approuve les exceptions et decidez quelle equipe doit signer avant qu'un objet risqué soit reintroduit. Cette gouvernance n'est pas de la bureaucratie inutile : elle sert a empecher qu'une urgence, une migration ou une integration tierce recree la meme exposition quelques semaines plus tard. Documentez les points de decision qui ont permis la faiblesse, puis mettez a jour le processus voisin pour que la prochaine demande soit evaluee selon la nouvelle baseline.

Lectures Connexes

Pour traiter ce sujet correctement, reliez-le a Golden Ticket : Les Clés de Votre Domaine, Kerberoasting : Cracker les Mots de Passe des Comptes de Service, Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, Attaques de Confiance AD : Du Domaine Enfant à la Racine et Chemins d'Attaque AD : Mauvaises Configurations en Chaîne. Cet ensemble montre comment les memes erreurs d'identite, de privileges et de configuration se combinent dans une revue reelle au lieu d'apparaitre comme des constats isoles.

Ces liens internes gardent la remediaton centree sur le chemin d'attaque complet et pas seulement sur un controle pris separement.

Questions a Trancher Avant la Validation Finale

Avant qu'une equipe considere un sujet identite comme vraiment traite, elle devrait pouvoir repondre a quelques questions simples avec des preuves concretes. Quel compte, quel groupe ou quel systeme reste aujourd'hui le chemin d'exception le plus sensible ? Quelle dependance operationnelle a empeche une remediation plus complete, et qui a accepte ce risque de facon explicite ? Quel controle compensatoire, quelle regle de supervision ou quelle frequence de revue couvre desormais l'exposition residuelle en production ? Ces questions comptent parce qu'une faiblesse d'identite revient souvent lorsque la note de remediaton est plus forte que la realite d'exploitation. Si l'organisation ne peut pas expliquer clairement le proprietaire, la dependance metier et la prochaine date de revue, le controle n'est generalement pas aussi stable qu'il en a l'air.

Preuves a Conserver pour la Revue Suivante

Les equipes les plus solides conservent juste assez de preuves pour rendre la revue suivante plus rapide et plus fiable. Cela inclut en general le proprietaire actuel de l'actif concerne, le changement de configuration exact qui a reduit le risque, la liste des exceptions encore acceptees et la preuve technique montrant que le nouvel etat est bien applique en production. Cette discipline est utile parce que les problemes d'identite et de privilege ne sont presque jamais des decouvertes uniques. Ils reviennent plutot via le turnover administrateur, la derive applicative ou des dependances historiques mal comprises au premier passage. En documentant a la fois la correction et la raison pour laquelle elle a ete acceptee, les equipes reduisent le risque de refaire la meme analyse a chaque cycle ou de reintroduire la meme faiblesse en corrigeant un autre sujet operationnel.