Chemins d’attaque Active Directory · Délégation Kerberos

Resource-Based Constrained Delegation (RBCD) : sécuriser la délégation Kerberos dans Active Directory

La Resource-Based Constrained Delegation, ou RBCD, est un mécanisme de délégation Kerberos d’Active Directory. Elle permet à un service d’agir au nom d’un utilisateur auprès d’un service cible, mais c’est l’objet de la ressource qui définit quels comptes peuvent effectuer cette délégation. Le contrôle est porté par l’attribut "msDS-AllowedToActOnBehalfOfOtherIdentity".

Cette logique distingue la RBCD de la délégation contrainte classique : dans ce dernier cas, la liste des services autorisés est configurée du côté du compte qui délègue. Avec la RBCD, la décision est attachée à l’objet cible. Cette différence est utile pour l’administration de services, mais elle rend les droits d’écriture sur les objets ordinateurs particulièrement sensibles.

Comprendre les chemins d'attaque Active Directory

Pourquoi la RBCD peut-elle créer un chemin d’attaque ?

Le risque ne vient pas du mécanisme seul. Il apparaît lorsqu’une identité dispose de droits trop larges sur l’objet d’un serveur, qu’un principal non attendu est autorisé à déléguer, ou que la ressource visée est critique. En combinant ces permissions avec les capacités Kerberos prévues pour la délégation, un attaquant déjà présent dans l’environnement peut chercher à atteindre un service avec l’identité d’un autre utilisateur. L’impact dépend alors des droits de cette identité et de la ressource concernée.

C’est pourquoi l’analyse doit porter sur le chemin complet : qui peut modifier l’objet cible, quels comptes sont autorisés à déléguer, et quelles ressources sensibles deviennent atteignables ? Une permission isolée ne suffit pas à mesurer le risque ; les relations entre objets, ACL et identités privilégiées font la différence.

Visualiser le chemin d’attaque

Chaque étape est conditionnelle. La simple existence de RBCD, d’un droit d’écriture ou d’un principal autorisé ne constitue pas une preuve de compromission.

  1. 01

    Étape conditionnelle

    Identité compromise

    Un attaquant dispose initialement d'une identité dans l'environnement.

  2. 02

    Étape conditionnelle

    Permission sur l'objet cible

    Cette identité possède directement ou indirectement des droits permettant de modifier la configuration RBCD de la ressource.

  3. 03

    Étape conditionnelle

    Relation RBCD modifiée

    Un principal contrôlé par l'attaquant, présentant les prérequis Kerberos nécessaires, est autorisé sur l'objet cible.

  4. 04

    Étape conditionnelle

    Délégation Kerberos

    Le mécanisme S4U2Proxy peut permettre d'obtenir un ticket de service au nom d'un utilisateur, sous réserve des conditions et protections applicables.

  5. 05

    Étape conditionnelle

    Accès au service cible

    Le service traite l'accès selon l'identité représentée et les contrôles effectivement appliqués.

  6. 06

    Étape conditionnelle

    Impact éventuel

    Selon les privilèges concernés et les ressources atteignables, le chemin peut conduire à une ressource critique, voire au Tier 0.

Précisions techniques

Mécanisme
Resource-Based Constrained Delegation
Protocole
Kerberos, extensions S4U
Attribut principal
"msDS-AllowedToActOnBehalfOfOtherIdentity"
Nature de l’attribut
Descripteur de sécurité NT, et non simple liste de SPN
Ressource décisive
Objet Active Directory portant la configuration de délégation
Facteur de risque
Permissions effectives permettant de modifier cette relation
Signal de surveillance
Modifications de l’attribut, notamment via l’événement 5136 si l’audit est configuré
Recommandation ANSSI
R65 — Traiter les risques inhérents aux délégations Kerberos

Comment réduire le risque ?

Limitez strictement les droits de modification des objets Active Directory et de l’attribut RBCD ; vérifiez régulièrement les principaux autorisés et supprimez les délégations devenues inutiles. Évitez les délégations vers des ressources de Tier 0 depuis des zones moins fiables. L’ANSSI recommande notamment de proscrire la RBCD vers les services de Tier 0 depuis les autres zones de confiance. Protégez également les comptes d’administration contre la délégation, impérativement pour les comptes Tier 0 et, autant que possible, pour les comptes Tier 1 et Tier 2.

ANSSI — R65 : Traiter les risques inhérents aux délégations Kerberos (pp. 91–92)

Détection et journalisation

Côté détection, surveillez les modifications inattendues de "msDS-AllowedToActOnBehalfOfOtherIdentity", en particulier celles initiées par un compte machine, puis corrélez-les avec les authentifications Kerberos vers la ressource. Dans le scénario KrbRelayUp, Microsoft Defender for Identity documente notamment deux alertes : la modification suspecte de l’attribut RBCD par un compte machine et une tentative suspecte de délégation Kerberos par un ordinateur récemment créé. Ces alertes ne constituent pas une garantie de détection exhaustive des abus RBCD.

Événement 5136 : les conditions de journalisation

Surveiller la modification d'un attribut suppose d'avoir configuré sa journalisation. L'événement Windows 5136 permet d'observer certaines modifications d'objets Active Directory à condition que la sous-catégorie Audit Directory Service Changes et les SACL pertinentes soient configurées. Il faut ensuite corréler le compte à l'origine du changement, la ressource concernée et les événements Kerberos pour qualifier le risque.

La RBCD illustre une règle centrale de la sécurité Active Directory : une délégation doit être justifiée, limitée à son besoin et surveillée dans le temps. Cartographier les droits sur les objets et prioriser ceux qui ouvrent un chemin vers le Tier 0 permet de corriger la cause, plutôt que de traiter chaque événement séparément.

Vos délégations Kerberos ouvrent-elles un chemin vers le Tier 0 ?

Une analyse des ACL, des comptes de service et des relations de délégation permet d'identifier les chemins réellement exploitables et de prioriser les corrections.

Analyser les délégations et les chemins d'attaque de votre Active Directory