Coercition d'authentification et relais NTLM : comprendre le risque et le réduire
Parmi les faiblesses que nous constatons le plus souvent lors des audits Active Directory, la famille « coercition plus relais NTLM » reste l'une des plus préoccupantes. Elle ne repose pas sur une faille unique, mais sur l'enchaînement de comportements hérités et de configurations par défaut. C'est aussi pour cela qu'elle se traite par plusieurs mesures complémentaires, et non par un seul correctif.
Le principe, sans entrer dans le détail offensif
Le risque combine deux idées. D'une part, plusieurs services Windows légitimes acceptent qu'on leur indique un chemin réseau et tentent alors de s'y connecter en s'authentifiant avec l'identité de la machine. Cette coercition d'authentification permet de faire parler un serveur, y compris un contrôleur de domaine, sans le compromettre. Certaines variantes ont reçu des surnoms connus, comme le « bug de l'imprimante » lié au service d'impression ou PetitPotam lié au service de chiffrement de fichiers.
D'autre part, une authentification NTLM n'est pas liée au service auquel elle était destinée. Si elle est interceptée et retransmise vers un autre service qui l'accepte, elle y est honorée au nom de la machine d'origine. C'est le relais. L'attaquant n'apprend pas le mot de passe : il agit sous l'identité de la victime le temps de la session. La conjonction des deux permet de transformer une identité de machine, parfois très privilégiée, en accès à un service sensible.
Pourquoi cela reste efficace
NTLM ne vérifie pas, par défaut, que le service qui reçoit l'authentification est bien celui pour lequel elle a été produite. Beaucoup de services acceptent encore NTLM, et certains n'exigent ni signature ni liaison de canal, ce qui autorise la retransmission. Enfin, l'identité d'un compte ordinateur, notamment celle d'un contrôleur de domaine, est intrinsèquement privilégiée. Aucun de ces éléments n'est une vulnérabilité au sens strict ; c'est leur accumulation qui crée le risque.
Deux cibles de relais à surveiller. Les destinations qui rendent ce risque critique sont généralement l'inscription web d'une autorité de certification AD CS, qui peut délivrer un certificat réutilisable au nom de la victime, et le service LDAP des contrôleurs de domaine, dont l'accès privilégié peut servir à modifier des objets sensibles. Ce sont les deux à verrouiller en priorité.
Réduire la surface de coercition
On ne peut pas supprimer toutes les fonctions susceptibles de provoquer une authentification, mais on peut en limiter l'exposition :
- Arrêter les services inutiles sur les contrôleurs de domaine, à commencer par le spouleur d'impression, qui n'y a pas sa place ;
- Appliquer les correctifs qui ont neutralisé les variantes accessibles sans authentification ;
- Filtrer le trafic RPC entre les segments non administratifs et les contrôleurs de domaine, afin que les interfaces concernées ne soient pas joignables depuis un poste utilisateur ordinaire ;
- Segmenter le réseau pour que les machines de niveau 0 ne soient atteignables que depuis des zones d'administration maîtrisées.
Empêcher le relais d'aboutir
La mesure de fond est de réduire la place de NTLM, mais tant qu'il subsiste, plusieurs protections rendent le relais inopérant :
- Protection étendue de l'authentification (EPA) sur les services web qui s'appuient sur l'authentification intégrée, dont l'inscription web d'AD CS : elle lie l'authentification au canal TLS et empêche sa réutilisation ailleurs.
- Désactiver ou retirer l'inscription web NTLM d'AD CS lorsqu'elle n'est pas nécessaire, et plus largement exiger HTTPS et une authentification qui ne se relaie pas sur les points d'inscription.
- Liaison de canal et signature LDAP sur les contrôleurs de domaine : une authentification relayée sur un canal différent de celui d'origine est alors rejetée.
- Signature SMB exigée, qui empêche le relais de ce protocole.
- Placer les comptes sensibles dans Protected Users, qui interdit l'usage de NTLM pour ces comptes.
Ces mesures se recoupent volontairement. Une seule d'entre elles laissée de côté suffit souvent à rouvrir un chemin ; c'est l'ensemble qui ferme la chaîne.
Surveiller ce qui ne peut pas être supprimé
Certaines fonctions resteront exposées. Il faut donc aussi détecter : connexions LDAP qui ne respectent pas la liaison de canal (en mode audit avant de forcer), demandes de certificats incohérentes avec l'usage habituel d'un compte ordinateur, authentifications NTLM de comptes ordinateurs vers des serveurs inattendus. Ces signaux, rassemblés dans la supervision, permettent de repérer une tentative avant qu'elle n'aboutisse.
Ce qu'un audit vérifie
- Les services exposés sur les contrôleurs de domaine, en particulier le spouleur d'impression.
- L'état des correctifs couvrant les variantes de coercition sans authentification.
- La présence d'EPA sur les services web d'authentification intégrée et sur l'inscription web d'AD CS.
- L'exigence de liaison de canal et de signature LDAP sur les contrôleurs de domaine.
- Les filtres RPC et la segmentation réseau autour des machines de niveau 0.
- La réduction globale de NTLM et la présence des comptes sensibles dans Protected Users.