Dans la grande majorité des tests d'intrusion internes, les auditeurs n'ont pas besoin de trouver une vulnérabilité zero-day. Ils trouvent un contrôleur de domaine configuré avec les paramètres par défaut, et cela suffit. L'Active Directory reste l'épine dorsale de l'infrastructure de presque toutes les organisations d'une certaine taille, au Maroc comme partout ailleurs. C'est précisément pour ça qu'il est ciblé en priorité.
Cet article revient sur les mauvaises configurations les plus répandues d'un Domain Controller, celles que l'on retrouve systématiquement, et qui transforment un composant critique en point d'entrée évident pour un attaquant positionné sur le réseau local.
LLMNR et NBT-NS : des protocoles qui trahissent vos utilisateurs
Le LLMNR (Link-Local Multicast Name Resolution) et NBT-NS sont des mécanismes de résolution de noms activés par défaut sur Windows. Quand un poste ne parvient pas à résoudre un nom de machine via DNS, il diffuse une requête en broadcast sur le segment réseau. N'importe quel hôte peut alors répondre en se faisant passer pour la ressource demandée.
C'est exactement ce qu'exploite un outil comme Responder : il écoute ces requêtes et répond à la place de la cible légitime, récupérant au passage les hachages NTLMv2 des utilisateurs qui tentent de s'authentifier. Ces hachages peuvent ensuite être craqués hors ligne ou relayés directement pour obtenir un accès sans jamais avoir besoin du mot de passe en clair.
La correction est simple et sans impact fonctionnel dans la quasi-totalité des environnements : désactiver LLMNR via une GPO et bloquer NBT-NS au niveau des interfaces réseau. Ce n'est pas une mesure de durcissement avancée, c'est une hygiène de base.
SMB Signing et versions du protocole : deux erreurs souvent liées
Le protocole SMB est omniprésent dans un environnement Active Directory. Il sert aux partages de fichiers, aux connexions aux contrôleurs de domaine, aux GPO, à la réplication. C'est aussi l'un des vecteurs de latéralisation les plus utilisés.
La signature SMB désactivée
Sans SMB signing, un attaquant positionné entre deux hôtes peut réaliser une attaque de type NTLM relay. Concrètement, il intercepte une authentification légitime et la rejoue vers une autre machine pour obtenir un accès. Dans un scénario classique, coupler Responder en mode analyse avec ntlmrelayx suffit à compromettre des partages, voire des machines entières, sans aucune interaction utilisateur supplémentaire.
La signature SMB doit être rendue obligatoire (required) sur tous les contrôleurs de domaine, et idéalement sur l'ensemble du parc. Les serveurs Windows le supportent nativement. Le seul point d'attention concerne certains équipements tiers ou anciens NAS qui ne l'implémentent pas correctement.
SMBv1 encore présent dans l'environnement
SMBv1 est un protocole qui ne devrait plus exister dans aucun réseau en production. Il est non seulement dépourvu de chiffrement et de signature robuste, mais c'est aussi celui qu'exploitait EternalBlue, la vulnérabilité à l'origine des épidémies de ransomware de la fin des années 2010. Pourtant, on le retrouve encore régulièrement activé, souvent parce qu'un ancien équipement ou une application legacy en dépend encore.
La désactivation de SMBv1 se fait via PowerShell ou GPO. Si une application l'exige absolument, c'est le signe qu'un projet de remplacement ou d'isolation doit être priorisé.
Les comptes et délégations mal configurés dans l'Active Directory
Un Domain Controller expose aussi tous les objets de l'annuaire. Plusieurs configurations par défaut ou héritées créent des vecteurs d'escalade de privilèges directs.
Kerberoasting et comptes de service sans précaution
Les comptes de service enregistrés avec un SPN (Service Principal Name) peuvent être ciblés par une attaque dite de Kerberoasting : n'importe quel utilisateur authentifié peut demander un ticket Kerberos pour ces comptes, ticket chiffré avec le hash du mot de passe du compte. Si ce mot de passe est faible, il sera craqué hors ligne en quelques minutes.
L'utilisation de Managed Service Accounts (gMSA) résout ce problème : les mots de passe sont générés automatiquement, longs, rotatifs, et ne peuvent pas être demandés par un utilisateur standard.
Délégation sans contrainte (Unconstrained Delegation)
Quand un compte ou une machine est configuré avec la délégation sans contrainte, il peut demander un ticket Kerberos au nom de n'importe quel utilisateur qui s'y connecte, y compris un administrateur de domaine. Un attaquant ayant compromis ce système peut alors extraire ces tickets et les utiliser pour se déplacer latéralement, potentiellement jusqu'au DC lui-même.
Autres vecteurs souvent négligés
Au-delà des protocoles réseau, plusieurs paramètres moins visibles augmentent significativement la surface d'attaque d'un environnement Active Directory.
- Le canal sécurisé Netlogon (vulnérabilité Zerologon, CVE-2020-1472) reste non patché dans certains environnements qui n'ont pas appliqué les mises à jour de sécurité régulièrement.
- Les ACLs permissives sur les objets AD : des utilisateurs ordinaires qui ont des droits de modification sur des groupes privilégiés, des GPO, ou même sur le DC lui-même, sans que personne ne s'en soit rendu compte.
- Le protocole NTLMv1 encore accepté par certains DC, alors que NTLMv2 doit être imposé et que Kerberos doit être privilégié partout où c'est possible.
- Les comptes administrateurs locaux avec le même mot de passe sur toutes les machines, rendant chaque compromission latérale triviale en l'absence de LAPS.
Comment aborder le durcissement du Domain Controller
Le durcissement d'un Active Directory n'est pas un projet ponctuel. C'est un processus continu, qui commence par un audit de l'état réel de la configuration, pas de ce qu'elle devrait être selon la documentation d'installation.
Des outils comme BloodHound permettent de cartographier les chemins d'attaque dans un annuaire existant, et de prioriser les corrections selon leur impact réel. Microsoft publie également des guides de durcissement (notamment via le benchmark CIS for Windows Server) qui constituent un bon point de départ structuré.
Pour les équipes SOC, la détection de ces attaques passe par la surveillance des événements Kerberos (4769, 4771), des connexions SMB anormales, et des résolutions LLMNR sur le réseau. Un SIEM correctement alimenté par les logs du DC peut détecter ces comportements avant qu'ils ne se transforment en compromission complète.
Questions fréquentes
Pourquoi LLMNR est-il dangereux dans un environnement Active Directory ?
LLMNR permet à n'importe quel hôte sur le réseau local de répondre à une requête de résolution de nom. Un attaquant peut intercepter ces requêtes et récupérer des hachages NTLM des utilisateurs, qu'il peut ensuite craquer ou relayer pour accéder à d'autres ressources du réseau sans connaître le mot de passe en clair.
Quelle est la différence entre SMB signing désactivé et SMBv1 ?
Ce sont deux problèmes distincts. L'absence de SMB signing expose au NTLM relay, une attaque où l'authentification d'un utilisateur légitime est détournée vers une autre cible. SMBv1, lui, est une version obsolète du protocole qui manque de chiffrement moderne et a été exploitée par des vulnérabilités critiques comme EternalBlue. Les deux doivent être corrigés, mais ils ne concernent pas les mêmes risques.
Est-ce qu'un contrôleur de domaine à jour est suffisant pour être protégé ?
Les mises à jour corrigent des vulnérabilités connues, mais elles ne changent pas les mauvaises configurations. Un DC entièrement patché avec LLMNR activé, SMB signing désactivé et des comptes mal délégués reste fortement exposé. La mise à jour est nécessaire, mais pas suffisante sans un audit de configuration rigoureux.
Comment détecter une attaque Kerberoasting sur un Domain Controller ?
Les attaques Kerberoasting génèrent des événements 4769 dans les logs de sécurité Windows, avec un type de chiffrement RC4 (0x17). Un volume inhabituellement élevé de ces demandes, ou des demandes provenant d'un compte qui ne devrait pas en faire, sont des signaux à surveiller dans un SIEM ou via un outil de détection dédié.