Attaques de Délégation Kerberos : de Non Contrainte à l'Abus RBCD

Qu'est-ce Qu'une Attaque de Délégation Kerberos ?

Les attaques de délégation Kerberos exploitent des fonctionnalités de délégation légitimes d'Active Directory qui permettent à un service d'accéder à un autre service au nom d'un utilisateur. La délégation existe pour des flux applicatifs réels, comme une couche web qui se connecte à une couche base de données avec l'identité de l'utilisateur. Le problème de sécurité commence lorsque le périmètre de la délégation est plus large que ce dont l'application a réellement besoin, ou lorsqu'un attaquant peut modifier la relation de délégation.

Les trois modèles de délégation que les défenseurs doivent généralement examiner sont :

• La délégation non contrainte, où un service de confiance peut recevoir du matériel Kerberos délégable et l'utiliser au-delà d'un seul service backend.
• La délégation contrainte, où le service frontend est limité à des noms de principal de service spécifiques répertoriés dans Active Directory.
• La délégation contrainte basée sur les ressources (RBCD), où la ressource cible contrôle quels principals sont autorisés à agir au nom des utilisateurs vis-à-vis de cette ressource.

Ces modèles ne doivent pas être traités comme un risque équivalent. La délégation non contrainte est généralement la priorité la plus haute, car la compromission de l'hôte délégué peut exposer des identifiants délégués réutilisables. La délégation contrainte et RBCD peuvent tout de même être dangereuses, en particulier lorsque les services autorisés sont trop larges ou lorsque des permissions d'écriture permettent à un attaquant de modifier les attributs de délégation.

Comment Fonctionne la Délégation Kerberos

La délégation Kerberos étend l'authentification de service Kerberos normale. Dans un flux Kerberos standard, un utilisateur obtient un ticket-granting ticket auprès du Key Distribution Center (KDC) puis demande des tickets de service pour des services spécifiques. La délégation ajoute la capacité pour un service d'obtenir ou d'utiliser des tickets au nom de l'utilisateur pour un autre service.

Avec la délégation non contrainte, le compte ou l'ordinateur est marqué comme approuvé pour la délégation. Si un utilisateur s'authentifie auprès de ce service avec la délégation activée, le service peut recevoir du matériel Kerberos délégable. Si l'hôte est compromis, l'attaquant peut être en mesure de réutiliser cet accès délégué. C'est pourquoi Microsoft Defender for Identity traite la délégation Kerberos non contrainte comme un élément d'évaluation de sécurité : ce paramètre peut exposer des identifiants privilégiés lorsque des utilisateurs sensibles s'authentifient auprès de services délégués.

La délégation contrainte réduit le périmètre. Au lieu d'autoriser la délégation vers n'importe quel service, le compte n'est autorisé à déléguer que vers des services configurés, représentés par des valeurs comme msDS-AllowedToDelegateTo. Le protocol transition modifie de nouveau le risque, car le service peut obtenir un ticket délégué pour un utilisateur sans que celui-ci se soit authentifié au préalable par Kerberos auprès de ce service frontend, lorsque la configuration autorise n'importe quel protocole d'authentification.

RBCD inverse une partie du modèle administratif. La ressource stocke elle-même la liste des principals autorisés à agir au nom des utilisateurs vis-à-vis de cette ressource dans msDS-AllowedToActOnBehalfOfOtherIdentity. Cela rend RBCD utile pour certains scénarios applicatifs, mais signifie aussi que le contrôle en écriture sur un objet ordinateur peut devenir un chemin de délégation.

Conditions Préalables à l'Abus de Délégation

Les paramètres de délégation ne sont pas automatiquement exploitables en eux-mêmes. Les cas dangereux combinent généralement plusieurs conditions :

• un serveur ou un compte de service est configuré pour la délégation non contrainte et plus facile à compromettre que les utilisateurs qui s'y authentifient
• des utilisateurs privilégiés ou des Contrôleurs de Domaine s'authentifient auprès de systèmes pouvant recevoir des identifiants délégués
• des objets ordinateur ont des ACL faibles qui permettent à des principals non administratifs de modifier des attributs liés à la délégation
• des comptes de service ont des cibles de délégation contrainte trop larges qui ne correspondent plus au besoin applicatif
• des entrées RBCD existent sans propriétaire documenté, sans dépendance applicative ni processus d'expiration
• des Contrôleurs de Domaine exposent des chemins de coercition qui font que l'authentification de comptes machine atteint des systèmes où le matériel délégué peut être capturé ou réutilisé

La conclusion défensive est pratique : une revue de délégation n'est pas qu'une simple liste d'attributs. Elle doit inclure le durcissement des hôtes, les chemins de connexion des comptes privilégiés, les ACL des objets et l'ownership applicatif.

La Chaîne d'Attaque

Une attaque de délégation suit normalement une séquence plutôt qu'un événement unique.

1. L'attaquant identifie les ordinateurs ou comptes de service configurés pour la délégation.
2. L'attaquant compromet un hôte délégué, un compte de service, ou une identité disposant d'un accès en écriture sur un objet ordinateur.
3. L'attaquant attend ou provoque l'authentification d'un compte de valeur, ou modifie RBCD afin qu'un principal contrôlé par l'attaquant puisse usurper des utilisateurs vis-à-vis d'une ressource cible.
4. L'attaquant réutilise l'accès délégué obtenu pour atteindre un service plus sensible.
5. Si le chemin atteint les droits de réplication d'un Contrôleur de Domaine, des systèmes Tier-0 ou des services administratifs privilégiés, l'attaque peut se transformer en compromission complète du domaine.

Pour la délégation non contrainte, les cas les plus graves impliquent des comptes privilégiés ou des comptes machine de Contrôleur de Domaine s'authentifiant auprès d'un serveur délégué compromis. Pour RBCD, la question clé est différente : qui peut écrire l'attribut de délégation de l'objet ordinateur cible, et la relation de confiance qui en résulte correspond-elle à une dépendance applicative légitime ?

Détection

Aucun événement Windows unique ne prouve à lui seul une attaque de délégation Kerberos. La détection vient de la corrélation entre l'inventaire de délégation, les modifications d'objets, l'activité des tickets de service Kerberos, les événements de connexion et la télémétrie des hôtes.

Signaux de l'Inventaire de Délégation

Commencez par les données de configuration :

• comptes ou ordinateurs avec délégation non contrainte activée
• comptes avec TrustedToAuthForDelegation activé
• valeurs msDS-AllowedToDelegateTo renseignées
• valeurs msDS-AllowedToActOnBehalfOfOtherIdentity renseignées
• comptes privilégiés non marqués comme sensibles et donc toujours éligibles aux chemins de délégation
• ACL faibles sur des objets ordinateur permettant à des principals inattendus d'écrire des attributs liés à la délégation

L'inventaire seul ne suffit pas, mais il donne aux détections le contexte dont elles ont besoin. Un événement 4769 de ticket de service est plus significatif lorsque l'on sait que le compte de service est configuré pour une délégation risquée.

Événements Windows à Corréler

L'événement 5136 nécessite la bonne politique d'audit et la bonne couverture SACL. Microsoft documente qu'il est généré lorsqu'un objet Active Directory est modifié, mais une détection utile dépend de la conservation des détails d'objet, d'attribut et d'opération.

Schémas de Détection à Fort Signal

Priorisez ces détections avant d'écrire des règles d'anomalie larges :

• une valeur msDS-AllowedToActOnBehalfOfOtherIdentity nouvelle ou modifiée sur un objet ordinateur
• délégation non contrainte activée sur un système non-DC
• un compte privilégié s'authentifiant auprès d'un système configuré pour la délégation non contrainte
• activité de connexion de comptes machine de Contrôleur de Domaine vers des serveurs membres inattendus
• modifications d'attributs liés à la délégation effectuées par des comptes qui ne possèdent pas l'application
• entrées RBCD où le principal agissant est récemment créé, rarement utilisé, ou sans lien avec le service cible

L'alerte doit inclure les deux côtés de la relation : le compte ou l'ordinateur autorisé à déléguer, et le service ou la ressource vers lequel la délégation s'exerce.

Remédiation

Traitez la délégation non contrainte sur les systèmes non-DC comme un constat de haute priorité. Si une application a encore besoin de délégation, migrez vers un modèle plus restreint et prouvez que la liste des cibles est correcte.

1. Supprimer la Délégation Non Contrainte Quand C'est Possible

Identifiez les ordinateurs et comptes approuvés pour la délégation non contrainte, confirmez l'ownership applicatif et retirez le paramètre des systèmes qui n'ont pas de besoin métier actuel.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, DistinguishedName, TrustedForDelegation

Ne désactivez pas la délégation aveuglément sur les serveurs applicatifs de production sans tester. Certaines applications legacy peuvent dépendre de la délégation pour l'authentification utilisateur vers backend. Le chemin de remédiation sûr est : inventaire, confirmation du propriétaire, staging, changement, puis validation.

2. Restreindre la Délégation Contrainte

Pour les services qui ont encore besoin de délégation, restreignez les services cibles autorisés à l'ensemble minimal viable. Revoyez les valeurs msDS-AllowedToDelegateTo et supprimez les SPN obsolètes. Si le protocol transition est activé, vérifiez que l'application en a réellement besoin et que le compte de service est protégé comme une identité privilégiée.

3. Revoir et Nettoyer RBCD

Pour RBCD, examinez chaque valeur msDS-AllowedToActOnBehalfOfOtherIdentity renseignée. Chaque entrée doit correspondre à une dépendance applicative documentée. Si l'entrée n'existe que parce qu'un dépannage l'a exigée il y a des mois, supprimez-la. Vérifiez également qui peut écrire sur l'objet ordinateur cible, car le contrôle en écriture est souvent la véritable vulnérabilité.

4. Protéger les Comptes Privilégiés de l'Exposition à la Délégation

Les utilisateurs privilégiés ne devraient pas s'authentifier de manière interactive sur des serveurs de moindre confiance. Utilisez l'administration par niveaux, des postes de travail d'administration dédiés et des restrictions de connexion afin que les identifiants Tier 0 ne se retrouvent pas sur des hôtes délégués. Pour les comptes sensibles, examinez les paramètres du compte et le modèle opérationnel qui empêche l'exposition à la délégation.

5. Réduire l'Exposition à la Coercition sur les Contrôleurs de Domaine

Si le service Print Spooler n'est pas nécessaire sur les Contrôleurs de Domaine, le désactiver supprime un vecteur d'authentification de compte machine bien connu, utilisé dans les chaînes d'abus de délégation. Traitez cela comme une couche parmi d'autres, pas comme l'unique correctif. Le problème racine reste la délégation non sécurisée et l'exposition des identifiants.

Validation Après Remédiation

La remédiation de la délégation n'est pas terminée tant que vous n'avez pas validé à la fois la sécurité et le comportement applicatif :

• confirmez que les systèmes non-DC n'ont plus de délégation non contrainte, sauf approbation explicite
• confirmez que les SPN cibles restants de la délégation contrainte correspondent à la conception applicative
• confirmez que les entrées RBCD ont des propriétaires documentés et aucun principal agissant inattendu
• testez le flux applicatif qui nécessitait auparavant la délégation
• surveillez l'événement 5136 pour détecter de nouvelles écritures d'attributs de délégation après le nettoyage
• surveillez les connexions privilégiées vers des hôtes délégués pendant au moins une fenêtre de changement après la remédiation
• revoyez les ACL des objets ordinateur pour vous assurer que les attaquants ne peuvent pas reconstruire le chemin de délégation

La question finale de validation est simple : si un attaquant compromet le même serveur applicatif demain, peut-il encore collecter ou créer un accès délégué vers une ressource de plus haute confiance ?

Comment EtcSec Détecte Cela

EtcSec audite les paramètres de délégation sur les ordinateurs et comptes de service à chaque scan AD.

UNCONSTRAINED_DELEGATION identifie les systèmes et comptes configurés pour la délégation non contrainte.

CONSTRAINED_DELEGATION met en évidence les paramètres de délégation contrainte risqués ou trop larges.

RBCD_ABUSE révèle les relations de délégation contrainte basée sur les ressources qui méritent un examen car elles peuvent offrir un chemin d'usurpation inattendu.

Contrôles Connexes

La revue de délégation doit être menée aux côtés de Detection prevention kerberoasting : comment identifier et protéger les comptes de service crackables, Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, Supervision Sécurité AD : Événements Clés, Mauvaises Configurations GPO : Vecteur d'Attaque AD et Golden Ticket : Les Clés de Votre Domaine. Dans des environnements réels, ces chemins sont généralement enchaînés plutôt qu'exploités isolément.

Références Principales

• Microsoft Defender for Identity : évaluation de la posture de sécurité des comptes (délégation Kerberos non sécurisée)
• 5136 : un objet du service d'annuaire a été modifié
• 4738 : un compte utilisateur a été modifié
• Configurer l'audit des événements Windows pour Microsoft Defender for Identity
• Délégation contrainte Kerberos avec Microsoft Entra ID (application proxy)