Attaque IDOR et NTLM Relay, comprendre ces deux vulnérabilités critiques

Deux vulnérabilités, deux mondes différents

L'IDOR et le NTLM Relay figurent parmi les vulnérabilités les plus couramment identifiées lors des missions de test d'intrusion, mais elles touchent des couches très différentes du système d'information, l'IDOR est une faille de logique applicative côté web, tandis que le NTLM Relay exploite un protocole d'authentification Windows au niveau infrastructure.

Qu'est-ce qu'une attaque IDOR ?

L'IDOR (Insecure Direct Object Reference) est une vulnérabilité qui survient lorsqu'une application web expose une référence directe à un objet interne (identifiant de fichier, de commande, de compte utilisateur) sans vérifier correctement que l'utilisateur authentifié a réellement le droit d'accéder à cette ressource précise.

Cette vulnérabilité fait partie de la catégorie A01, Broken Access Control du classement OWASP Top 10, régulièrement en première position des vulnérabilités les plus critiques identifiées sur les applications web.

Comment détecter et corriger l'IDOR

• Détection en pentest test systématique de modification des identifiants dans les requêtes (paramètres URL, body JSON, headers) en comparant les réponses entre deux comptes utilisateurs distincts
• Correction implémentation systématique de contrôles d'autorisation côté serveur, vérifiant que l'objet demandé appartient bien à l'utilisateur authentifié, à chaque requête
• Bonne pratique privilégier des identifiants non séquentiels et imprévisibles (UUID plutôt qu'identifiants incrémentaux) en complément des contrôles d'autorisation, sans s'y substituer

Qu'est-ce qu'une attaque NTLM Relay ?

Le NTLM Relay exploite le protocole d'authentification NTLM utilisé dans les environnements Active Directory. Plutôt que de tenter de casser un mot de passe, l'attaquant intercepte une tentative d'authentification NTLM légitime et la relaie vers un autre service, se faisant ainsi passer pour l'utilisateur sans jamais connaître son mot de passe.

Concrètement, un attaquant positionné sur le réseau peut forcer une machine victime à s'authentifier vers lui (via des techniques de coercition comme PetitPotam ou PrinterBug), puis relayer cette authentification vers un autre serveur du domaine, obtenant ainsi un accès avec les privilèges de la victime, potentiellement jusqu'à la compromission complète du contrôleur de domaine.

Pourquoi le NTLM Relay reste critique en 2026

Malgré son ancienneté, le protocole NTLM reste largement présent dans les environnements Active Directory pour des raisons de compatibilité historique. Tant que NTLM n'est pas désactivé ou strictement encadré, le risque de relay persiste, y compris sur des infrastructures par ailleurs bien sécurisées.

Mesures défensives contre le NTLM Relay

• Activer la signature SMB sur l'ensemble des serveurs pour empêcher le relais des sessions SMB
• Désactiver NTLM au profit de Kerberos partout où c'est techniquement possible
• Activer l'Extended Protection for Authentication (EPA) sur les services critiques (ADCS, LDAP)
• Surveiller les événements d'authentification suspects via le SIEM, notamment les authentifications NTLM provenant de comptes machine vers des destinations inhabituelles
• Segmenter le réseau pour limiter la portée d'un relay réussi