Bloquer le NTLM sortant du Tier 0 contre la coercition et le relais : les attaques stoppées au niveau de la GPO

Ce que « NTLM sortant » signifie pour un contrôleur de domaine

Ce guide explique comment bloquer le NTLM sortant du Tier 0 contre la coercition et le relais : les chaînes d'attaque telles que PetitPotam et les techniques qui ont suivi dépendent entièrement de l'existence de cette authentification sortante — refusez-la, et il ne leur reste plus rien à relayer. Les contrôleurs de domaine authentifient en Kerberos la quasi-totalité de ce qu'ils font entre eux et vers les autres services intégrés à Active Directory, mais NTLM subsiste en dessous comme solution de repli, et par défaut tout système Windows accepte volontiers de s'authentifier en sortie via NTLM auprès de n'importe quel serveur qui le lui demande.

L'ANSSI, l'agence nationale française de cybersécurité, documente directement ce schéma dans son guide d'administration sécurisée d'Active Directory. L'authentification NTLMv2 est une ouverture de session réseau — distincte des ouvertures de session interactives qui laissent en mémoire des empreintes réutilisables — et sa réponse au défi peut être interceptée en vol puis relayée vers une seconde cible sans que l'attaquant n'apprenne jamais le secret sous-jacent : il emprunte les droits d'accès de la victime au lieu de lui voler son mot de passe (ANSSI-PA-099, §4.15.2). Lorsque le système soumis à la coercition est un contrôleur de domaine, les droits d'accès ainsi relayés sont ceux du Tier 0.

Comment les attaques par coercition et relais abusent du NTLM sortant

Le membre le mieux documenté de cette famille est PetitPotam. L'avis du CERT/CC consacré à la technique explique qu'elle détourne le protocole distant du système de fichiers chiffré (EFSRPC) : un appel à EfsRpcOpenFileRaw amène le système cible à « utiliser NTLM pour s'authentifier auprès de l'hôte spécifié dans le chemin », et un attaquant peut faire pointer ce chemin vers une infrastructure qu'il contrôle — déclenchant une tentative d'authentification NTLM depuis le compte machine du contrôleur de domaine lui-même, sans aucune information d'identification pour amorcer la chaîne (CERT/CC VU#405600).

Cette authentification NTLM capturée n'est dangereuse que parce qu'elle est acceptée ailleurs. Le CERT/CC détaille en trois étapes la chaîne complète contre les services de certificats Active Directory (AD CS) :

Étape 1 — Coercition

L'attaquant appelle EfsRpcOpenFileRaw (ou une méthode RPC équivalente au même comportement déclencheur d'authentification) contre le contrôleur de domaine, en le faisant pointer vers une infrastructure qu'il contrôle. Le compte machine du DC ouvre une authentification NTLM sortante — il s'agit d'une ouverture de session réseau, précise le guide de l'ANSSI, et non du type interactif qui laisse des empreintes réutilisables en mémoire.

Étape 2 — Relais

L'attaquant capture la réponse au défi NTLMv2 — l'empreinte « Net-NTLMv2 » — et la relaie immédiatement, sans la modifier, vers le point de terminaison HTTP d'inscription web d'AD CS avant qu'elle n'expire.

Étape 3 — Conversion

AD CS délivre un certificat pour le compte machine du contrôleur de domaine. Le CERT/CC note que ce certificat « peut être utilisé pour obtenir un ticket d'octroi de tickets (TGT) », ce qui suffit à compromettre l'intégralité du domaine — sans qu'il ait jamais fallu casser le moindre mot de passe ni la moindre empreinte.

Chaque étape de cette chaîne dépend de la réussite de l'étape 1 : il faut que le contrôleur de domaine accepte d'émettre une authentification NTLM vers l'extérieur. Supprimez cela, et les étapes 2 et 3 n'ont plus rien sur quoi travailler.

Le correctif de Microsoft, suivi sous la référence CVE-2021-36942 (« Windows LSA Spoofing Vulnerability »), n'a fermé que la version non authentifiée de l'appel EfsRpcOpenFileRaw. Il n'a pas fermé le schéma sous-jacent — un système Tier 0 peut toujours être poussé vers une authentification NTLM sortante par d'autres interfaces RPC au comportement identique, raison pour laquelle les préconisations de remédiation de Microsoft pour cette famille d'attaques vont au-delà d'un simple correctif. L'article KB5005413 recommande d'activer la protection étendue de l'authentification sur les points de terminaison AD CS et, comme option plus forte au niveau du protocole, de « désactiver l'authentification NTLM sur votre contrôleur de domaine Windows » purement et simplement (Microsoft KB5005413). Cette seconde option est précisément ce que la recommandation R73 de l'ANSSI traduit en un unique paramètre de stratégie de groupe.

Bloquer le NTLM sortant du Tier 0 contre la coercition et le relais (ANSSI R73)

La recommandation R73 de l'ANSSI est directe : « les authentifications NTLM sortantes de tous les systèmes du Tier 0 doivent être bloquées », au moyen d'un unique paramètre de stratégie de groupe. Le chemin de la GPO, repris du guide, est le suivant :

Computer Configuration\Windows Settings\Security Settings\Local Policies\
Security Options\Network Security: Restrict NTLM: Outgoing NTLM traffic
to remote servers → Deny all

La documentation de référence de Microsoft pour ce paramètre confirme les trois mêmes états — Allow all (aucune restriction), Audit all (journalise chaque tentative NTLM sortante sans la bloquer) et Deny all (l'appareil « ne peut authentifier aucune identité auprès d'un serveur distant au moyen de l'authentification NTLM ») — et précise que le paramètre est Not Configured par défaut sur tout contrôleur de domaine et tout serveur membre (Microsoft Learn — Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers). Laissé non configuré, il offre à la famille coercition-et-relais exactement le chemin sortant dont elle a besoin.

L'ANSSI est explicite : Audit all ne suffit pas pour R73 — la recommandation prescrit le blocage, pas la journalisation. Le mode audit est l'étape préalable au déploiement : laissez-le tourner assez longtemps pour confirmer qu'aucun trafic NTLM sortant légitime ne provient du Tier 0 (il ne devrait normalement pas y en avoir, puisque les flux de DC à DC et de DC vers les services AD prennent nativement en charge Kerberos), puis basculez sur Deny all. Le guide ajoute une réserve opérationnelle à prendre au sérieux : bloquer le NTLM sortant suppose que les systèmes du Tier 0 joignent les autres services AD par FQDN plutôt que par adresse IP brute, car Kerberos dépend de la résolution de noms pour sélectionner le bon ticket de service — une mauvaise configuration que la phase d'audit fera apparaître avant qu'elle ne provoque une interruption de service.

Le contrôle complémentaire : restreindre ce que le Tier 0 émet vers le bas (ANSSI R82/R83)

Bloquer le NTLM sortant referme le volet « authentification réseau » de l'exposition du Tier 0. La position de référence de l'ANSSI est que les postes d'administration du Tier 0 ne devraient avoir aucune connectivité descendante au départ — physiquement dédiés, avec un trafic sortant autorisé uniquement vers les ressources du Tier 0 (R80). R82 et R83 s'appliquent spécifiquement lorsqu'une organisation adopte à la place la seconde architecture alternative de l'ANSSI : la mutualisation de l'accès distant du Tier 0 vers des environnements de moindre confiance, comme repli transitoire en attendant une ségrégation complète. Dans ce modèle, R82 restreint les méthodes de connexion à distance autorisées au départ du Tier 0 vers les zones de moindre confiance — RPC/MMC, PowerShell WinRM avec son authentification réseau Kerberos-ou-NTLM par défaut, ou RDP natif soit en mode RestrictedAdmin, soit avec un compte cantonné au tier de destination. R83 va plus loin : le compte utilisé pour une session interactive sur cette destination de moindre confiance doit appartenir à la zone de confiance de cette destination, jamais à une identité Tier 0 ou Tier 1, afin qu'un système de tier inférieur compromis ne se retrouve jamais à détenir des secrets Tier 0 réutilisables. Pour le déroulé complet des restrictions d'ouverture de session par tier, voir Stratégies d'authentification et silos Active Directory pour le Tier 0.

Détecter le NTLM sortant avant et après le blocage

Ces deux Event ID sont confirmés directement dans l'ANSSI-PA-099 §4.15.2.1, et la documentation de référence de Microsoft pour ce paramètre de stratégie pointe vers le même chemin de journal opérationnel. Deux points méritent une surveillance une fois le blocage en place :

• Toute salve d'Event ID 4001 après le déploiement mérite investigation — soit une dépendance légitime a été manquée pendant la phase d'audit, soit quelque chose tente activement de provoquer une authentification sortante et se fait arrêter.
• Les Event ID 8001 pendant la phase d'audit constituent votre cartographie des dépendances. Chaque couple source/destination qu'ils listent est à traiter — corrigez-le, exemptez-le ou migrez-le vers Kerberos — avant de basculer sur Deny all.

La couverture de détection connexe — les défenses contre le relais LDAP et SMB, qui importent, que le NTLM sortant soit bloqué ou non — est traitée dans La liaison de canal LDAP sur les contrôleurs de domaine et La signature SMB et le relais NTLM.

Remediation

1. Confirmez d'abord le périmètre du Tier 0. R73 ne fonctionne que si votre UO Tier 0 contient effectivement tous les contrôleurs de domaine et tous les serveurs sensibles du Tier 0 — recoupez avec votre modèle d'administration par tiers avant de lier la moindre GPO.
2. Déployez Audit all via une GPO liée à l'UO Tier 0. Laissez-la tourner assez longtemps pour couvrir votre cycle de correctifs, vos travaux de sauvegarde et toute tâche d'administration mensuelle ou trimestrielle — les fenêtres d'audit trop courtes manquent les dépendances récurrentes.
3. Passez en revue les entrées Event ID 8001 et résolvez chacune des entrées légitimes : basculez la source vers Kerberos (généralement une correction DNS/SPN), ajoutez-la à la liste d'exceptions de serveurs NTLM si elle ne peut réellement pas quitter NTLM, ou retirez la dépendance.
4. Basculez la même GPO sur Deny all. Surveillez l'Event ID 4001 dans les jours qui suivent — tout élément inattendu est soit une dépendance manquée, soit une tentative de coercition active.
5. Étendez à R74+ une fois le Tier 0 assaini : liez une GPO équivalente à la racine du domaine pour le reste de l'environnement, avec des exceptions filtrées par WMI là où NTLM ne peut pas encore être réellement supprimé.
6. Ajoutez R82/R83 pour les administrateurs Tier 0 qui doivent se connecter vers le bas — restreignez la méthode de connexion à distance et exigez un compte du tier de destination, conformément à la section précédente, afin que ce contrôle et le blocage au niveau réseau couvrent les deux sens du risque.
7. Combinez avec le durcissement côté relais. Le blocage du NTLM sortant supprime la source des authentifications relayées depuis le Tier 0, mais tout système du SI qui accepte encore des cibles de relais NTLM non signées ou non protégées (LDAP sans liaison de canal, SMB sans signature, inscription web AD CS sans protection étendue) reste exploitable contre des victimes hors Tier 0. Traitez cette GPO comme une couche, pas comme la défense entière.

Comment EtcSec détecte ce problème

L'audit Active Directory d'EtcSec recherche exactement cette lacune de configuration. ANSSI_R73_NTLM_OUTBOUND_TIER0 signale l'absence de tout paramètre de GPO positionnant RestrictSendingNTLMTraffic sur Deny all à l'échelle des systèmes du Tier 0 — le mode audit seul est correctement considéré comme ne satisfaisant pas le contrôle. ANSSI_R74_NTLM_OUTBOUND_DOMAIN suit séparément l'extension de cette même stratégie de blocage à une GPO liée à la racine du domaine. ANSSI_R82_R83_ADMIN_ARCHITECTURE signale les systèmes du Tier 0 dépourvus des garde-fous d'architecture d'administration exigés par R82 et R83, et NTLM_RELAY_OPPORTUNITY signale l'exposition au relais plus large dans l'environnement dès lors que NTLM reste joignable sans les protections compensatoires décrites ci-dessus.