NTLM Relay : attaque et contre-mesures

Le NTLM Relay est une attaque par relais ciblant le protocole d'authentification NTLM, natif des environnements Windows et Active Directory. Son principe est simple : un attaquant positionné en homme du milieu intercepte un échange d'authentification NTLM initié par une victime, puis relaie ce challenge-response vers un service tiers pour s'y authentifier à la place de la victime. Contrairement au Pass-the-Hash, l'attaquant ne capture pas le hash pour le rejouer plus tard : il exploite la session d'authentification en cours, en temps réel. NTLM fonctionne en trois messages — NEGOTIATE, CHALLENGE, AUTHENTICATE — et n'intègre pas de liaison cryptographique entre la session négociée et le canal de transport. Cette absence de channel binding rend le relais possible. L'attaque est particulièrement redoutable dans les environnements où SMB signing ou LDAP signing ne sont pas activés, ce qui reste fréquent par défaut sur les postes de travail Windows. Le relais peut cibler SMB, LDAP, HTTP, MSSQL ou même ADCS. L'impact va de l'exécution de code à distance jusqu'à la compromission complète du domaine via une délégation de droits ou une inscription de certificat frauduleuse.

La détection du NTLM Relay repose sur plusieurs sources de logs distinctes. Côté contrôleur de domaine, l'événement Windows 4624 (logon réussi) avec le type de logon 3 (réseau) et le champ 'Authentication Package' à 'NTLM' doit alerter, surtout si la source IP ne correspond pas à la machine habituellement associée au compte. L'événement 4625 indique des tentatives échouées. L'événement 4648 signale un logon explicite avec des credentials, souvent présent lors d'un relais vers LDAP. Sur les serveurs ciblés, les logs IIS ou les traces SMB peuvent révéler des authentifications anormales depuis des adresses IP inattendues. Le trafic réseau est également parlant : une capture Wireshark ou Zeek montrera des séquences NTLM à trois messages entre des hôtes qui ne communiquent pas habituellement. Les outils SIEM comme Elastic ou Splunk permettent de corréler les événements 4624 NTLM avec des listes d'IP autorisées. L'activation du log 'NetLogon' et l'analyse des traces LDAP sur le port 389 complètent la surveillance. Un pic d'authentifications NTLM vers LDAP depuis un même hôte en peu de secondes constitue un indicateur fort de relais en cours, à intégrer dans les règles de détection.

En Red Team, NTLM Relay s'orchestre classiquement avec deux outils complémentaires. Responder empoisonne les protocoles de résolution de noms broadcast (LLMNR, NBT-NS, mDNS) pour forcer les victimes à s'authentifier vers la machine de l'attaquant. ntlmrelayx, inclus dans Impacket, reçoit ces authentifications et les relaie vers des cibles choisies. La commande typique combine Responder en mode passif (--no-smb, --no-http) et ntlmrelayx avec une liste de cibles SMB sans signing. Avec l'option --delegate-access, ntlmrelayx peut configurer une délégation contrainte basée sur les ressources (RBCD), permettant l'usurpation ultérieure de comptes via S4U2Proxy. Le relais vers ADCS (PKI Active Directory) via l'interface HTTP de l'autorité de certification permet d'obtenir un certificat valide pour le compte relayé, technique connue sous le nom ESC8. Côté durcissement, les contre-mesures prioritaires sont : activer SMB signing sur tous les postes via GPO, activer LDAP signing et LDAP channel binding sur les contrôleurs de domaine, désactiver LLMNR et NBT-NS par GPO, et déployer EPA (Extended Protection for Authentication) sur IIS et ADCS. Ces mesures éliminent la majorité des vecteurs de relais sans impacter les usages courants.