Ariovis

Chemin d'attaque Active Directory · NTLM · Relay · MITRE ATT&CK T1557.001

NTLM Relay : quand une authentification légitime est utilisée au mauvais endroit

NTLM repose sur un mécanisme de challenge-response : le mot de passe n'est pas directement transmis au service distant, qui vérifie une réponse calculée à partir du secret de l'identité. Cette propriété protège le secret lui-même, mais elle n'empêche pas certaines attaques de relais.

Si un attaquant parvient à se placer dans le chemin d'une authentification, ou à provoquer cette authentification, il peut dans certaines configurations transmettre l'échange vers un autre service sans jamais connaître le mot de passe de la victime. Le service destinataire authentifie alors une identité qui n'a pas voulu se connecter à lui.

Le risque ne dépend donc pas seulement de la présence de NTLM. Il vient de l'association entre une source d'authentification exploitable, une cible insuffisamment protégée contre le relay et les privilèges réels de l'identité relayée.

La vraie question

Quelles identités peuvent être amenées à s'authentifier, vers quelles destinations, et quels services acceptent encore cette authentification sans vérifier le contexte dans lequel elle a été produite ?

Comprendre les chemins d'attaque Active Directory
MITRE ATT&CK
T1557.001 — Name Resolution Poisoning and SMB Relay
Technique parente
T1557 — Adversary-in-the-Middle
Protocole concerné
NTLM, déprécié mais encore supporté par Windows
Déclencheurs analysés
Résolution de noms héritée et coercition d'authentification
Cibles analysées
SMB, LDAP, LDAPS, endpoints HTTP d'inscription AD CS
Protections associées
SMB signing, LDAP signing, channel binding, EPA
Signaux Windows
4776, 4624, 2886-2889, 3039-3041, 4886, 4887
Niveau
Tier 0 lorsque l'identité relayée le permet

Voler une réponse NTLM et relayer une authentification sont deux scénarios différents

NTLM authentifie une identité sans transmettre son secret au service distant : le serveur envoie un challenge, le client calcule une réponse à partir de son secret, et cette réponse est validée par le serveur ou par un contrôleur de domaine. L'échange est donc une preuve de possession, valable pour cette session et pour ce service.

Deux scénarios très différents peuvent partir de cet échange, et les confondre conduit à des analyses fausses, à des remédiations mal ciblées et à des détections inadaptées. Le premier cherche à retrouver un secret, le second cherche à utiliser une authentification pendant qu'elle a lieu.

La mécanique de l'échange

  1. 01Le client souhaite s'authentifier auprès d'un service.
  2. 02Le service lui adresse un challenge.
  3. 03Le client calcule une réponse à partir de son secret.
  4. 04Le service, ou un contrôleur de domaine, valide cette réponse.

  • Scénario A — Capture

    L'attaquant récupère du matériel d'authentification NTLM qu'il pourra éventuellement tenter d'attaquer hors ligne, avec une réussite qui dépend entièrement de la robustesse du secret et du temps dont il dispose. Ce scénario vise le secret de l'identité, pas la session en cours.

  • Scénario B — Relais

    L'attaquant ne cherche pas nécessairement à retrouver le secret : il transmet en temps réel l'échange d'authentification vers un autre service, qui accepte cette authentification et traite ensuite les actions comme celles de l'identité relayée. Le secret reste inconnu, mais l'identité est utilisée.

Le relay ne se confond ni avec la capture suivie d'un cassage hors ligne, ni avec le Pass-the-Hash, qui suppose déjà de détenir une empreinte de mot de passe. Dans un relay, l'attaquant n'a besoin que d'une authentification en cours et d'une cible qui l'accepte.

Le chemin d'attaque, étape par étape

Chaque flèche dépend de la configuration réelle du système : un déclencheur d'authentification ne produit un chemin que si une cible accepte le relay, et l'impact final reste borné par ce que l'identité relayée peut réellement faire.

  1. 01

    Identité ou machine légitime

  2. 02

    Authentification NTLM déclenchée ou détournée

    • Résolution de noms héritée
    • Coercition d'authentification
  3. 03

    Attaquant en position de relais

  4. 04

    Échange NTLM transmis à une autre cible

    • SMB
    • LDAP ou LDAPS
    • Endpoint HTTP d'inscription
  5. 05

    La cible accepte l'authentification sans protection suffisante contre le relay

  6. 06

    L'attaquant agit avec les droits de l'identité relayée

  7. 07

    Nouvelle étape possible dans le chemin d'attaque

Cette séquence n'a rien d'automatique : une coercition réussie sans cible exploitable ne mène nulle part, et une cible mal protégée n'est atteignable que si une authentification exploitable peut lui être présentée.

NTLM Relay ne donne aucun privilège supplémentaire par magie. Il permet d'utiliser ailleurs les privilèges que possède déjà l'identité relayée.

Le premier problème consiste à faire parler la victime

Un relais suppose une authentification à relayer. Deux familles de mécanismes très différentes permettent d'en obtenir une, et elles ne se corrigent pas de la même manière : l'une concerne la résolution de noms sur le réseau, l'autre concerne des interfaces Windows capables de déclencher une connexion sortante.

  • Résolution de noms héritée

    Lorsqu'un poste ne résout pas correctement une ressource par les mécanismes normaux, certains protocoles de résolution locale peuvent conduire à contacter une machine autre que celle attendue, y compris une machine contrôlée par un attaquant, qui reçoit alors une tentative d'authentification.

    • LLMNR ;
    • NBT-NS ;
    • mDNS lorsque le contexte réseau le rend pertinent.

    Ces mécanismes ne sont pas des vulnérabilités en eux-mêmes : ils deviennent un problème quand ils restent actifs sans besoin réel, sur des segments où une machine non maîtrisée peut répondre.

  • Coercition d'authentification

    Certaines interfaces Windows ont historiquement permis de pousser une machine à initier une authentification vers un système choisi par l'appelant. Les cas les plus documentés concernent les interfaces liées au chiffrement de fichiers et au service de spouleur d'impression, souvent désignées par les noms de recherche PetitPotam et PrinterBug.

    • MS-EFSRPC — PetitPotam ;
    • MS-RPRN — PrinterBug.

    La coercition ne constitue pas encore une compromission : elle fournit une authentification qu'il faut encore pouvoir relayer vers une cible exploitable, avec une identité dont les privilèges rendent l'opération intéressante.

Traiter uniquement le déclencheur revient donc à fermer une porte parmi d'autres. Une organisation qui bloque une interface de coercition précise sans traiter la capacité de ses services critiques à accepter une authentification relayée conserve la classe de chemins dans son environnement.

Il n'existe pas une protection universelle appelée « NTLM Relay »

Les protections contre le relay sont propres à chaque protocole : elles lient l'authentification à la session dans laquelle elle a été produite, ou exigent une signature que l'attaquant ne peut pas produire. Analyser un environnement revient donc à vérifier service par service ce qui est réellement exigé.

  • SMB

    SMB signing

    Un service SMB qui n'exige pas correctement la signature peut constituer une cible de relais selon le contexte, notamment lorsque des serveurs historiques conservent des réglages plus permissifs que les valeurs par défaut récentes.

  • LDAP

    LDAP signing

    Les binds insuffisamment protégés peuvent permettre certains scénarios de relais vers l'annuaire, avec un impact qui dépend des permissions de l'identité relayée sur les objets visés.

  • LDAPS

    LDAP channel binding

    Le chiffrement TLS seul ne protège pas contre tous les scénarios de relais : le channel binding lie l'authentification à la session TLS dans laquelle elle est présentée, ce qui casse la réutilisation de l'échange ailleurs.

  • HTTP / IIS / AD CS

    Extended Protection for Authentication et HTTPS

    Des endpoints d'inscription AD CS acceptant NTLM sans EPA constituent le scénario documenté ESC8, avec une conséquence particulière : la cible n'accorde pas seulement un accès, elle peut émettre un credential.

Le problème n'est pas seulement que NTLM existe. Le problème est qu'un service accepte une authentification relayée sans vérifier suffisamment le contexte dans lequel elle a été créée.

SMB Relay : les droits de l'identité déterminent l'impact

Lorsqu'une authentification NTLM peut être relayée vers un serveur SMB qui ne bloque pas ce scénario, l'attaquant agit avec les droits accordés à l'identité relayée sur cette cible précise. Il n'obtient pas un pouvoir générique sur le domaine, mais exactement le périmètre d'action de cette identité sur ce serveur.

Si l'identité relayée possède des privilèges d'administration locale sur la machine visée, l'impact peut aller jusqu'à des opérations d'administration à distance et ouvrir une nouvelle progression dans le chemin d'attaque. Si elle ne dispose que de droits limités, la même technique produit un résultat correspondant à ces droits.

C'est pourquoi la cartographie des comptes disposant de privilèges d'administration locale étendus sur un grand nombre de machines compte autant, dans l'analyse, que la configuration du protocole lui-même : elle détermine ce qu'un relais réussi rend possible.

Un relais SMB peut permettre des actions privilégiées lorsque l'identité relayée dispose elle-même de ces privilèges sur la cible atteinte.

LDAP transforme le relay en modification du graphe de droits

Active Directory ne sert pas uniquement à authentifier. LDAP permet également de lire et de modifier des objets, des attributs et des relations d'autorisation lorsque l'identité utilisée possède les permissions nécessaires sur les objets concernés.

Dans certains scénarios, un relais NTLM vers LDAP ou LDAPS peut donc servir à modifier le graphe de droits plutôt qu'à exécuter immédiatement une action visible : la conséquence n'est pas un accès ponctuel, mais une relation persistante inscrite dans l'annuaire. Les délégations sont l'exemple le plus parlant de cette catégorie, notamment la Resource-Based Constrained Delegation.

Selon l'identité relayée et les ACL présentes dans l'annuaire, un chemin peut permettre la création ou la modification d'une relation de délégation comme RBCD. Cette possibilité n'est pas une conséquence automatique d'un relais vers LDAP : elle dépend entièrement des permissions effectives de l'identité utilisée sur l'objet visé.

Un relais vers l'annuaire doit s'analyser avec la même grille qu'une délégation : ce n'est pas le protocole qui donne le pouvoir, ce sont les ACL que l'identité relayée porte déjà sur les objets.

ESC8 : quand la PKI accepte l'identité relayée

Active Directory Certificate Services peut exposer des services d'inscription via IIS, notamment le Certificate Authority Web Enrollment et le Certificate Enrollment Web Service. Ces interfaces répondent à des besoins légitimes d'inscription, mais elles sont accessibles par HTTP et acceptent des authentifications Windows.

Si ces endpoints acceptent NTLM sans les protections adaptées contre le relay, notamment HTTPS et Extended Protection for Authentication, Microsoft les considère comme exposés au scénario ESC8. La cible se distingue ici de toutes les autres : elle n'accorde pas un accès, elle peut émettre un credential utilisable ensuite de façon autonome.

La séquence documentée

  1. 01Contrôleur de domaine ou autre machine
  2. 02Authentification NTLM provoquée
  3. 03Relais vers l'endpoint AD CS
  4. 04AD CS authentifie le principal relayé
  5. 05Certificat émis pour ce principal selon les droits et modèles disponibles
  6. 06Le certificat devient un credential exploitable pour cette identité

Lorsque le principal relayé est un contrôleur de domaine

  1. 01Certificat du compte machine du contrôleur de domaine
  2. 02Authentification avec l'identité de ce compte
  3. 03Capacités critiques associées à ce compte
  4. 04Selon le chemin : accès aux secrets du domaine, par exemple via DCSync
  5. 05Tier 0
DCSync : l'abus des droits de réplication
Le certificat obtenu représente le principal réellement relayé, par exemple le compte machine d'un contrôleur de domaine. La compromission ultérieure des secrets du domaine est une étape possible, conditionnée par les capacités de ce compte, et non une conséquence automatique de l'émission.

ESC1 et ESC8 attaquent la même PKI par deux chemins différents

Les deux scénarios concernent Active Directory Certificate Services, mais ils ne portent ni sur le même objet, ni sur la même faiblesse, et ils ne se corrigent donc pas avec les mêmes mesures.

Présenter ces deux scénarios comme une même vulnérabilité conduit à corriger le mauvais objet : durcir des modèles ne protège pas un endpoint exposé, et protéger un endpoint ne corrige pas un modèle trop permissif.

Le relay doit être évalué dans un parc Windows réel, pas dans un lab de 2020

NTLM est désormais un protocole déprécié par Microsoft, mais il reste supporté dans Windows pour des raisons de compatibilité, et Kerberos demeure le mécanisme d'authentification privilégié dans un domaine Active Directory. Cette dépréciation ne signifie donc ni absence du protocole, ni absence de chemin.

Les versions récentes de Windows ont par ailleurs renforcé leurs valeurs par défaut, ce qui change la surface d'exposition d'un parc moderne par rapport aux analyses publiées il y a quelques années. Ce renforcement concerne les nouvelles installations et les configurations par défaut, pas l'état effectif d'un système d'information constitué par couches successives.

Ce qui a changé et ce qui reste à vérifier

  • Windows 11 24H2 a considérablement renforcé les exigences de signature SMB ;
  • Windows Server 2025 renforce également SMB et introduit de nouveaux mécanismes de blocage de NTLM pour SMB ;
  • les nouveaux déploiements Active Directory sous Windows Server 2025 exigent le LDAP signing par défaut ;
  • les environnements historiques, les systèmes non mis à niveau, les exceptions et les produits tiers restent à analyser un par un.

La version du système ne permet donc pas de conclure qu'un chemin est fermé : un parc récent peut conserver des exceptions documentées, des serveurs anciens ou des applications tierces qui rétablissent les conditions du relay. Seul l'audit de la configuration effective, côté clients comme côté serveurs, permet de le déterminer.

Détecter NTLM Relay demande de corréler plusieurs couches

Aucun événement isolé ne caractérise un relais : chaque signal pris séparément décrit une opération qui peut être parfaitement normale. La détection consiste donc à reconstruire une séquence cohérente entre l'usage du protocole, l'authentification observée sur la cible, le comportement réseau et le service spécifiquement visé.

  1. Niveau 1

    Observer l'usage de NTLM

    L'événement de validation de credentials sur le contrôleur de domaine documente les authentifications NTLM et permet de savoir quels comptes utilisent encore ce protocole, depuis quelles machines et à quelle fréquence. Il constitue la base de l'inventaire, pas une alerte.

    • quel compte utilise NTLM ;
    • depuis quelles machines ;
    • à quelle fréquence et dans quels créneaux.
    Event ID 4776
    Le contrôleur de domaine a tenté de valider les credentials d'un compte. Cet événement ne signifie pas « NTLM Relay ».
  2. Niveau 2

    Observer l'authentification sur la cible

    Sur le système visé, l'ouverture de session documente le type de connexion, le paquet d'authentification utilisé, la source réseau et l'identité. Une connexion réseau NTLM réussie peut être parfaitement normale : l'intérêt vient de sa corrélation avec une source, une cible et un comportement inattendus.

    • Logon Type ;
    • Authentication Package et NtLmSsp ;
    • adresse source ;
    • identité authentifiée.
    Event ID 4624
    Une session a été ouverte avec succès sur le système visé.
  3. Niveau 3

    Observer la coercition et le réseau

    La couche réseau apporte les signaux que les journaux d'authentification ne portent pas, dans la logique des détections associées à la technique MITRE correspondante : réponses anormales aux mécanismes de résolution hérités, trafic provenant d'un hôte non autorisé, authentifications SMB inhabituelles entre systèmes qui n'ont pas de raison de dialoguer, modification réactivant certains mécanismes de résolution, et création de services consécutive à une compromission.

  4. Niveau 4

    Observer la cible spécifique

    Chaque service visé apporte sa propre télémétrie. Côté annuaire, les événements de diagnostic identifient les clients qui ne respectent pas les exigences de signature ou de channel binding. Côté PKI, les événements Certification Services permettent de rapprocher une demande de certificat du contexte réseau dans lequel elle a été présentée, en s'appuyant aussi sur les journaux IIS.

    • LDAP : clients ne respectant pas le signing, événements 2886 à 2889 ;
    • LDAP channel binding : événements 3039 à 3041 lorsqu'ils sont disponibles ;
    • AD CS : corrélation avec les journaux IIS et le contexte de la requête.
    Event ID 4886
    Certificate Services a reçu une demande de certificat.
    Event ID 4887
    Certificate Services a approuvé une demande et émis un certificat.
Une demande de certificat, une authentification NTLM ou une connexion SMB ne constituent pas isolément une preuve de relay. La détection doit reconstruire la séquence : qui s'est authentifié, vers quoi, depuis où, et ce qui s'est produit ensuite.

La bonne stratégie consiste à supprimer plusieurs maillons

Un chemin de relay se compose d'un déclencheur, d'une cible et d'une identité. Chaque maillon retiré réduit la classe de chemins concernée, et la démarche progressive ci-dessous évite l'écueil d'une désactivation brutale qui casserait des usages métier encore dépendants du protocole.

  1. 01 — Cartographier NTLM

    Avant toute désactivation globale, inventorier les systèmes qui utilisent encore NTLM, identifier les dépendances héritées, distinguer les usages métier, les usages techniques et les exceptions historiques, puis préparer une migration vers Kerberos ou des mécanismes plus modernes.

  2. 02 — Réduire NTLM

    Privilégier Kerberos et restreindre NTLM une fois les dépendances identifiées. Sur les systèmes les plus privilégiés, notamment les contrôleurs de domaine, traiter en priorité les possibilités d'authentification NTLM sortante, qui alimentent directement les scénarios de coercition.

    Une désactivation aveugle sur l'ensemble du système d'information, sans phase d'audit ni traitement des exceptions, produit des ruptures de service sans garantir la fermeture des chemins.

  3. 03 — SMB

    Exiger la signature SMB là où la configuration ne le fait pas déjà, en vérifiant la configuration réelle des clients comme des serveurs, puis tirer parti des mécanismes récents de blocage de NTLM sur SMB lorsque le contexte le permet.

  4. 04 — LDAP

    Exiger le LDAP signing après identification des clients incompatibles et traiter le channel binding pour LDAPS et les authentifications concernées, en exploitant les modes d'audit avant l'enforcement lorsque le parc l'impose.

  5. 05 — AD CS et IIS

    Pour les services d'inscription AD CS, imposer HTTPS, activer Extended Protection for Authentication en privilégiant le mode Required lorsqu'il est compatible, et réduire ou supprimer NTLM sur ces endpoints lorsque c'est possible.

    HTTPS seul ne traite pas ESC8 : c'est la combinaison du chiffrement et de l'Extended Protection for Authentication qui lie l'authentification à la session présentée.

  6. 06 — Résolution de noms et coercition

    Réduire les mécanismes de résolution hérités devenus inutiles et surveiller les authentifications sortantes des systèmes critiques, sans compter uniquement sur le blocage d'un outil de coercition précis.

Bloquer une interface de coercition connue ne traite qu'un déclencheur. Empêcher une identité Tier 0 d'émettre une authentification NTLM exploitable, et empêcher les services critiques d'accepter une authentification relayée, casse en revanche une classe entière de chemins, indépendamment de l'outil employé.

La vulnérabilité n'est pas NTLM seul : c'est la chaîne qui reste exploitable

Un inventaire de configuration peut montrer que NTLM est encore actif, que la signature SMB n'est pas imposée partout, que le LDAP signing reste incomplet, qu'un endpoint AD CS fonctionne sans EPA et qu'un contrôleur de domaine peut initier une authentification vers un périmètre insuffisamment maîtrisé. Pris individuellement, ces constats produisent une liste de findings que l'on traite selon la disponibilité des équipes.

Reliés entre eux, les mêmes constats décrivent un chemin praticable vers le Tier 0, et l'ordre des corrections cesse d'être arbitraire : certaines mesures ferment un point de configuration, d'autres retirent un maillon commun à de nombreux chemins. C'est cette différence d'effet que l'analyse doit rendre visible.

La question à laquelle l'audit doit répondre

Dans cet environnement, une authentification obtenue par contrainte peut-elle encore être présentée à un service qui l'accepte, et jusqu'où mène-t-elle ?

L'audit recherche donc

  • quelles identités peuvent être forcées à s'authentifier ;
  • vers quelles destinations ces authentifications peuvent partir ;
  • quels services acceptent encore une authentification relayée ;
  • quelles protections sont effectivement appliquées, côté clients et côté serveurs ;
  • ce que l'identité relayée peut réellement faire après authentification ;
  • quelles corrections cassent le plus grand nombre de chemins.
Évaluer la sécurité de mon Active DirectoryDécouvrir l'offre Sécurité des identités et Active Directory

Techniques liées

Les autres fiches de la collection. Elles ne constituent pas des étapes obligatoirement successives : chacune s'insère dans un chemin d'attaque selon ce que l'environnement autorise.

Sources techniques

Références de premier rang utilisées pour étayer cette fiche.

Poursuivre l'analyse

Les pages qui prolongent cette fiche, du chemin d'attaque jusqu'à la démarche d'audit.