NetSessionEnum, durcissement SAM distant, reconnaissance BloodHound, Active Directory : aveugler le graphe d’attaque

Qu'est-ce que le durcissement de NetSessionEnum, du SAM distant et de la reconnaissance BloodHound sur Active Directory ?

NetSessionEnum, le durcissement du SAM distant, la reconnaissance BloodHound, les graphes d'attaque Active Directory : ces quatre sujets se ramènent aux trois mêmes réglages, et aucun d'eux ne porte de numéro CVE — ce qui explique presque exactement pourquoi (presque) personne ne les durcit.

Les deux types d'arêtes les plus précieux de BloodHound, HasSession et AdminTo, ne reposent pas sur un exploit. Ils proviennent de deux appels RPC Windows ordinaires : NetSessionEnum (qui est actuellement connecté ici ?) et une requête SAMR contre la base SAM locale (qui est administrateur local ici ?). Le fait qu'un compte de domaine peu privilégié puisse les effectuer dépend entièrement de deux réglages par défaut qui ont changé à des moments différents — et qui laissent encore aujourd'hui une large ouverture. NetSessionEnum était ouvert aux Authenticated Users jusqu'à Windows 10 1703 et Windows Server 2016, et le SAM distant était sans restriction avant Windows 10 1607 et Windows Server 2016 ; sur les versions actuelles, les deux sont restreints sur les serveurs membres et les postes de travail, mais le SAM distant reste ouvert à Everyone sur chaque contrôleur de domaine, par conception documentée. Un attaquant disposant d'un seul point d'appui peu privilégié parcourt le parc en posant les deux questions partout où elles obtiennent encore une réponse, et SharpHound transforme les réponses en un graphe qui pointe directement vers Domain Admin.

Les trois réglages ci-dessous sont les leviers qui retirent ces deux questions du graphe : le descripteur de sécurité SrvsvcSessionInfo qui contrôle NetSessionEnum, la stratégie RestrictRemoteSam qui contrôle la requête SAM/SAMR, et la présence ou non de SMBv1 — le protocole dont l'époque précède les deux réglages de durcissement — encore installé quelque part dans le parc.

Comment ça fonctionne

L'énumération des sessions et des administrateurs locaux fait partie des faiblesses d'identité machine qui alimentent le graphe d'attaque de BloodHound — voir aussi la surface d'attaque des objets ordinateur Active Directory, plus large, pour le volet délégation et DCSync du même problème.

NetSessionEnum et l'arête HasSession

NetSessionEnum est une API héritée du service Server (\\host\srvsvc via le partage administratif IPC$) qui liste les sessions réseau actuellement connectées à une machine — en clair, « quels comptes sont connectés ou ont un lecteur mappé vers moi en ce moment ». SharpHound l'appelle lors de la méthode de collecte Session par défaut, résout les IP/noms d'hôte renvoyés vers des objets ordinateur, et trace une arête HasSession de cet ordinateur vers chaque compte trouvé. Une arête HasSession est une promesse d'opportunité, pas une garantie : si l'attaquant peut atteindre cette machine avec des droits admin (ou un autre chemin), les identifiants ou le jeton d'un utilisateur réellement connecté peuvent se trouver en mémoire, prêts à être volés.

Qui a le droit d'appeler NetSessionEnum est contrôlé par un descripteur de sécurité stocké dans la valeur de registre SrvsvcSessionInfo, sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\DefaultSecurity. Compass Security a testé cette ACL précise build par build et publié la matrice : Windows 10 1607 (14393) et 1703 (15063) ainsi que Windows Server 2016 (14393) accordent aux Authenticated Users le droit de l'appeler, tandis que Windows 10 1709 (16299) et versions ultérieures, Windows Server 2019 (17763) et Windows Server 2022 (20348) ne le font pas. Sur ces builds plus récents, le descripteur accorde ce droit à distance aux Administrateurs, Server Operators et Power Users, plus localement aux sessions de connexion Interactive, Service et Batch — ce qui correspond, presque exactement, à l'ACL que le script de durcissement NetCease a été écrit pour appliquer. Compass note également que les mises à jour cumulatives n'ont pas modifié ce comportement au sein d'une même version, et qu'il n'existe pas de documentation Microsoft publique claire sur ce changement — la seule façon de savoir quel comportement présente une machine donnée est de lire la valeur, pas de la déduire de la version d'OS sur l'inventaire.

L'accès SAM distant et l'arête AdminTo

La méthode de collecte LocalAdmin de SharpHound (également utilisée par les méthodes RDP, DCOM et PSRemote) énumère les groupes locaux d'une machine via le tube nommé SAMR (\\host\samr, également via IPC$) pour trouver qui est membre du groupe Administrateurs locaux — la source de l'arête AdminTo. Le protocole SAMRPC permet à un appelant peu privilégié d'énumérer les utilisateurs, les groupes et l'appartenance aux groupes depuis le SAM local et depuis Active Directory — exactement l'étape de reconnaissance que les attaquants utilisaient bien avant l'existence de BloodHound pour trouver où un compte privilégié dispose de droits d'administrateur local permanents.

Ceci est contrôlé par la stratégie Accès réseau : restreindre les clients autorisés à effectuer des appels distants sur SAM (valeur de registre RestrictRemoteSam, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RestrictRemoteSam, REG_SZ). La documentation de Microsoft elle-même est explicite sur le réglage par défaut ici, et ce défaut est volontairement inégal :

Cette ligne du milieu est la nuance qui compte : le discours « sécurisé par défaut depuis 2016 » ne s'applique qu'aux serveurs membres et aux postes de travail. Les contrôleurs de domaine — les machines dont un attaquant veut le plus les données d'administration locale — sont livrés avec des lectures SAMR ouvertes à Everyone, sur toutes les versions de Windows Server prises en charge, pour des raisons de compatibilité que Microsoft énonce explicitement, et non par omission.

Où se situe SMBv1

SMBv1 n'est pas le transport qui porte les appels NetSessionEnum ou SAMR — ces RPC circulent sur des tubes nommés via IPC$ quel que soit le dialecte SMB. Ce que SMBv1 révèle, c'est un historique. Microsoft ne l'installe plus par défaut depuis Windows 10 et Windows Server, version 1709, et Windows Server 2019 et versions ultérieures sont livrés sans lui après une installation propre. Une machine qui répond encore à SMBv1 tombe donc dans l'une de trois catégories, et la troisième est celle que la plupart des parcs oublient : elle précède la date de bascule, quelqu'un l'a réinstallé délibérément, ou elle a été mise à niveau sur place. Microsoft précise explicitement que les mises à niveau sur place ne suppriment pas automatiquement SMBv1, et que sur Windows 10 Enterprise, Education et Pro for Workstations, « un administrateur doit décider de désinstaller SMBv1 dans ces environnements gérés » — aucune suppression automatique à 15 jours ne s'y applique. SMBv1 ne prouve donc pas que la machine est ancienne ; il prouve qu'elle n'a jamais été rebasélinée. C'est la même condition sous laquelle survit un descripteur SrvsvcSessionInfo antérieur à 1709, ce qui en fait un raccourci d'inventaire utile — « aller lire à la main les ACL de session et SAM de cette machine » — plutôt qu'un primitif d'attaque distinct.

Cette surface de reconnaissance des sessions et des administrateurs locaux se situe à côté d'autres chemins de reconnaissance déjà couverts sur ce blog : la signature SMB laissée désactivée, qui permet le relais NTLM, les chaînes d'attaque par relais NTLM contre Active Directory de façon plus large, et l'accès LDAP anonyme via une valeur dsHeuristics permissive, qui couvre l'énumération côté annuaire. Cet article ne reprend rien de tout cela — il porte spécifiquement sur la surface d'énumération des sessions et des administrateurs locaux qui alimente HasSession et AdminTo.

La chaîne d'attaque

Étape 1 — Un point d'appui de domaine quelconque

L'attaquant n'a besoin de rien de plus qu'un seul identifiant de domaine valide (ou un jeton de session non surveillé) — aucun exploit, et aucun droit d'administrateur local sur les contrôleurs de domaine qu'il s'apprête à énumérer.

Étape 2 — Collecte SharpHound par défaut

# -c All exécute toutes les méthodes de collecte, Session et LocalAdmin incluses
.\SharpHound.exe -c All -d corp.local

Pour chaque machine active, SharpHound appelle NetSessionEnum via \\host\srvsvc pour les sessions et une requête de groupe local SAMR via \\host\samr pour les administrateurs locaux. Les deux appels ne réussissent ou n'échouent pas ensemble. La requête SAMR réussit contre chaque contrôleur de domaine quelle que soit la version de Windows, à cause du réglage par défaut vide mentionné plus haut ; l'appel de session réussit sur toute machine dont le descripteur SrvsvcSessionInfo est encore celui d'avant 1709, ou a été assoupli depuis. Un seul compte peu privilégié suffit pour les deux.

Étape 3 — BloodHound construit le chemin

BloodHound Community Edition corrèle les arêtes HasSession et AdminTo renvoyées avec l'appartenance aux groupes existante pour calculer un chemin le plus court tel que : compte peu privilégié compromis → possède une session sur l'hôte X → un compte Domain Admin est également connecté sur l'hôte X → l'attaquant prend le contrôle de l'hôte X → dump de LSASS ou vol du jeton du Domain Admin.

Étape 4 — Vol d'identifiants sur la machine cible

Si l'attaquant dispose également (ou peut obtenir) des droits d'administrateur local sur la machine porteuse de la session — souvent le cas, puisque l'énumération AdminTo issue du même balayage peu privilégié révèle déjà quelles machines ont une appartenance au groupe administrateurs locaux permissive — la session devient une opportunité de vol d'identifiants via l'accès LSASS ou l'usurpation de jeton.

Détection

Ni NetSessionEnum ni une lecture SAMR ne produisent par défaut un événement Windows dédié « quelqu'un m'a énuméré », et les deux reposent sur la même configuration de la stratégie d'audit avancée que la plupart des domaines laissent dans son état incomplet de sortie de boîte. Les événements suivants offrent la couverture la plus proche :

Ne construisez pas de détection volumétrique sur 16965 seul. Microsoft le limite : par défaut, l'événement n'est écrit que la première fois qu'un accès est refusé après le démarrage, et chaque refus ultérieur dans une fenêtre de 15 minutes est simplement compté et remonté en bloc par l'événement 16969 (« N appels distants à la base SAM ont été refusés durant la fenêtre de limitation des X dernières secondes »). La fenêtre est définie par RestrictRemoteSamEventThrottlingWindow (REG_DWORD, en secondes, sous HKLM\System\CurrentControlSet\Control\Lsa) ; réglez-la sur 0 pour désactiver la limitation et journaliser chaque refus. Le mode audit seul n'est pas limité, ce qui est une raison de plus de l'exécuter en premier.

Une chasse pratique : filtrez l'ID d'événement 5145 sur Share Name = \\*\IPC$ et Relative Target Name parmi srvsvc, samr, lsarpc, puis signalez tout compte source non contrôleur de domaine qui touche plus d'une poignée de machines de destination distinctes dans une courte fenêtre — un seul compte de poste de travail appelant srvsvc/samr contre des dizaines de machines en quelques minutes correspond au comportement de collecte par défaut de SharpHound, pas à une activité utilisateur normale. L'événement 5145 provient de la sous-catégorie Audit Detailed File Share, désactivée par défaut et à fort volume — délimitez-la donc délibérément.

Remédiation

1. Faites l'inventaire avant de restreindre. Activez RestrictRemoteSamAuditOnlyMode (REG_DWORD, valeur 1, sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa) et examinez l'événement 16968 pendant quelques jours pour identifier les appelants SAM distant légitimes avant de configurer la stratégie en production.
2. Configurez explicitement RestrictRemoteSam sur les contrôleurs de domaine. Le réglage par défaut y est « Everyone » pour la compatibilité — il ne devient pas sécurisé simplement parce que la machine tourne sous la dernière version de Windows Server. Définissez un SDDL qui n'autorise que les comptes et groupes ayant réellement besoin de lectures SAM distantes (SAMRi10, des mêmes chercheurs Microsoft que NetCease, crée un groupe dédié « Remote SAM Users » et écrit le SDDL pour vous plutôt que de modifier la chaîne à la main). Aucun redémarrage n'est requis : Microsoft précise que le réglage prend effet dès son enregistrement local ou son application par stratégie de groupe.
3. Durcissez NetSessionEnum par une modification de l'ACL SrvsvcSessionInfo — sur les builds qui en ont encore besoin. Le script NetCease retire Authenticated Users du descripteur de sécurité SrvsvcSessionInfo et ajoute les SID de connexion Interactive, Service et Batch, tout en laissant en place Administrateurs, Power Users et Server Operators. Sa propre documentation précise explicitement qu'il faut « redémarrer le service 'Server' pour que les changements prennent effet » (Restart-Service -Name LanmanServer -Force). Notez ce que cela signifie sur un parc moderne : Windows 10 1709+ et Windows Server 2019+ livrent déjà cette ACL, donc NetCease s'y approche d'un no-op — sa valeur se situe sur les machines antérieures à 1709 et sur Server 2016, ainsi que sur toute machine dont le descripteur a été assoupli après coup. Testez d'abord dans un groupe d'audit/pré-production — les mêmes outils d'administration qui cassent sous RestrictRemoteSam peuvent aussi casser ici.
4. Ne présumez pas que la version d'OS indique l'état actuel. Interrogez directement SrvsvcSessionInfo et RestrictRemoteSam au lieu de vous fier à « nous sommes sur Server 2019/2022 donc tout va bien » :

   Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name RestrictRemoteSam -ErrorAction SilentlyContinue
   

5. Confirmez que SMBv1 est réellement absent, pas seulement présumé absent.

   # Nécessite une élévation ; la désactivation déclenche un redémarrage sauf si -NoRestart est utilisé
   Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
   # Si State est Enabled :
   Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
   
   # Alternative non élevée de Microsoft, mieux adaptée pour balayer un parc :
   Get-SmbServerConfiguration | Format-List EnableSMB1Protocol
   

   Traitez toute machine qui répond encore à SMBv1 comme un signal à vérifier manuellement pour son état SrvsvcSessionInfo et RestrictRemoteSam — non pas parce que SMBv1 prouve que la machine est ancienne, mais parce qu'il prouve qu'elle n'a jamais été rebasélinée, ce qui est la même condition qui préserve un descripteur de session ou SAM obsolète. Ceci complète la liste plus large des priorités de durcissement d'Active Directory, qui indique où cela se situe par rapport aux autres correctifs.
6. Relancez SharpHound après durcissement et comparez le nombre d'arêtes. Une baisse des arêtes HasSession et AdminTo sur le même domaine, avec les mêmes méthodes de collecte, est la seule preuve que le changement a réellement réduit le graphe d'attaque, et pas seulement la liste de conformité.

Comment EtcSec détecte cela

L'audit Active Directory d'EtcSec couvre les trois réglages au niveau où ils sont gouvernés de façon centralisée : la stratégie de groupe. NET_SESSION_HARDENING_MISSING se déclenche lorsqu'aucune stratégie ne configure le durcissement de session SrvsvcSessionInfo — le réglage équivalent à NetCease est tout simplement absent de l'ensemble de stratégies du domaine. SAM_REMOTE_ACCESS_OPEN se déclenche lorsque RestrictRemoteSam est soit non défini, soit porteur d'un SDDL sans DACL, ce qui correspond à l'état laissant en place le réglage par défaut du contrôleur de domaine. SMB_V1_ENABLED se déclenche lorsque la stratégie laisse SMBv1 activé.

Considérez ces trois constats pour ce qu'ils sont : ils indiquent si le domaine possède une stratégie comblant ces failles, pas si chaque machine individuelle s'y conforme. Cette distinction est tout l'enjeu de cet article. Une base GPO propre laisse encore le travail par machine décrit ci-dessus — lire SrvsvcSessionInfo et RestrictRemoteSam sur les machines elles-mêmes, et relancer SharpHound pour comparer le nombre d'arêtes — car une mise à niveau sur place, une écriture de stratégie locale ou un script de durcissement tiers peuvent diverger de la stratégie sans la modifier.