Bloquer la coercition d'authentification sur les DC

La coercition d'authentification est l'étape qui transforme un compte de domaine peu privilégié en compromission du domaine, sans le moindre mot de passe. L'attaquant appelle une méthode RPC sur un contrôleur de domaine qui force le compte machine du DC à s'authentifier auprès d'un hôte de son choix. Cette authentification est ensuite relayée via NTLM vers l'inscription web AD CS (ESC8) ou LDAP, ou capturée sous forme de TGT Kerberos sur un hôte disposant de la délégation non contrainte. Le compte machine d'un DC peut effectuer un DCSync : la chaîne se termine donc avec tous les hachages du domaine.

Les déclencheurs les plus connus sont PrinterBug (MS-RPRN), PetitPotam (MS-EFSR), DFSCoerce (MS-DFSNM) et ShadowCoerce (MS-FSRVP). De nouvelles variantes apparaissent régulièrement, et Microsoft ne considère généralement pas la coercition authentifiée comme une vulnérabilité. Ce guide va plus loin que les notes sur la coercition de la base DC. Il couvre la mesure de l'exposition, la suppression des déclencheurs par les services et les filtres RPC, la neutralisation des authentifications contraintes et la vérification du résultat.

Pourquoi la coercition est un problème à deux faces

Toute chaîne de coercition comporte un déclencheur (une interface RPC du DC qui accepte un chemin UNC fourni par l'appelant) et une destination (une cible de relais ou un hôte de délégation qui accepte les informations d'identification du DC). Ne corriger qu'un côté revient à parier que personne ne trouvera le prochain déclencheur ou la prochaine destination. C'est en durcissant les deux que cette classe d'attaques devient anodine :

Le côté destination relève d'autres guides : signature LDAP et liaison de canal, signature SMB, EPA sur l'inscription web AD CS et suppression de la délégation non contrainte. La suite de ce guide traite du côté déclencheur et des contrôles propres aux DC qui relient les deux.

Mesurer : ce qui est exposé aujourd'hui

Commencez par confirmer quels services déclencheurs tournent réellement sur chaque DC. Le spouleur devrait déjà être désactivé si vous avez appliqué la base, mais vérifiez quand même. Le service File Server VSS Agent n'est présent que si le service de rôle FS-VSS-Agent est installé.

$dcs = (Get-ADDomainController -Filter *).HostName
Invoke-Command -ComputerName $dcs -ScriptBlock {
    [PSCustomObject]@{
        DC            = $env:COMPUTERNAME
        Spooler       = (Get-Service Spooler -ErrorAction SilentlyContinue).Status
        FssAgent      = (Get-Service -DisplayName 'File Server VSS Agent Service' -ErrorAction SilentlyContinue).Status
        DfsNamespace  = (Get-Service Dfs -ErrorAction SilentlyContinue).Status
        EfsService    = (Get-Service EFS -ErrorAction SilentlyContinue).Status
        VssAgentRole  = (Get-WindowsFeature FS-VSS-Agent).InstallState
        RpcFilters    = (netsh rpc filter show filter | Select-String 'filterKey').Count
    }
} | Format-Table -AutoSize

Notez qu'arrêter le service EFS ne corrige pas PetitPotam. L'interface MS-EFSR est aussi joignable via \pipe\lsarpc, servi par LSASS que le service EFS tourne ou non. C'est pourquoi le filtrage RPC est le contrôle recommandé pour EFSRPC.

Vérifiez ensuite les destinations. La coercition vise le DC, mais le relais aboutit ailleurs. Listez les hôtes qui transformeraient une authentification contrainte du DC en victoire :

# Ordinateurs (hors DC) approuvés pour la délégation non contrainte
Get-ADComputer -Filter { TrustedForDelegation -eq $true -and PrimaryGroupID -ne 516 } |
    Select-Object Name, DNSHostName

# Hôtes d'AC d'entreprise : vérifier chacun (et les serveurs CES/Web Enrollment) comme cibles de relais HTTP
Get-ADObject -SearchBase ("CN=Enrollment Services,CN=Public Key Services,CN=Services," +
    (Get-ADRootDSE).configurationNamingContext) -Filter * -Properties dNSHostName |
    Select-Object Name, dNSHostName

Auditer : voir les tentatives de coercition avant de bloquer

Avant d'ajouter des filtres bloquants, faites tourner les mêmes filtres en mode audit pendant une semaine. Le moteur de filtrage RPC de Windows écrit l'événement de sécurité 5712 (« A Remote Procedure Call (RPC) was attempted ») pour les filtres dont l'audit est activé, à condition que la sous-catégorie d'audit RPC Events soit active :

auditpol /set /subcategory:"RPC Events" /success:enable /failure:enable

Vous pouvez aussi observer l'accès aux canaux nommés sur le DC avec l'audit Detailed File Share (événement 5145) et un filtre sur les noms de cible relatifs efsrpc, lsarpc, spoolss, netdfs et FssagentRpc. Attention : lsarpc est utilisé en permanence par tous les membres du domaine. Servez-vous-en pour la corrélation, pas pour l'alerte.

Cherchez d'abord les signaux évidents. Tout appel EFSRPC vers un DC depuis un poste de travail est suspect, car aucun client légitime ne chiffre de fichiers sur un DC. Tout appel MS-DFSNM depuis un hôte qui n'est pas un PAW Tier 0 doit avoir un propriétaire identifié.

Appliquer : supprimer ou filtrer chaque déclencheur

Spouleur d'impression

Maintenez-le désactivé avec Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Print Spooler = Disabled dans une GPO liée à l'UO Domain Controllers. C'est le seul correctif complet contre PrinterBug. Le filtrage RPC de MS-RPRN n'est qu'une solution de repli pour les serveurs membres qui doivent conserver le spouleur.

File Server VSS Agent (ShadowCoerce)

Un DC ne doit pas héberger ce rôle. Supprimez-le :

Uninstall-WindowsFeature -Name FS-VSS-Agent -ComputerName DC01

Filtres RPC pour EFSRPC et DFSNM

Les filtres RPC sont des règles de la plateforme de filtrage Windows (WFP) appliquées à la couche RPC et indexées sur l'UUID d'interface. Bloquer par UUID arrête l'appel quel que soit le canal nommé ou le point de terminaison TCP par lequel il arrive. L'interface MS-EFSR est exposée sous deux UUID, c681d488-d850-11d0-8c52-00c04fd90f7e (via lsarpc) et df1941c5-fe89-4e79-bf10-463657acf44d (via efsrpc) : bloquez les deux. MS-DFSNM utilise 4fc742e0-4a10-11cf-8273-00aa004ae673. Pour DFSNM, une règle d'autorisation limitée à votre groupe Tier 0 est plus sûre qu'un blocage total, car les administrateurs gèrent encore les espaces de noms de domaine par cette interface.

Enregistrez la définition des filtres dans un fichier versionné, par exemple dc-rpc-filters.txt :

rpc
filter
add rule layer=um actiontype=block audit=enable
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter
add rule layer=um actiontype=block audit=enable
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
add rule layer=um actiontype=permit audit=enable
add condition field=if_uuid matchtype=equal data=4fc742e0-4a10-11cf-8273-00aa004ae673
add condition field=remote_user_token matchtype=equal data=D:(A;;CC;;;DA)
add filter
add rule layer=um actiontype=block audit=enable
add condition field=if_uuid matchtype=equal data=4fc742e0-4a10-11cf-8273-00aa004ae673
add filter
quit

Appliquez-le et vérifiez :

netsh -f C:\Tier0\dc-rpc-filters.txt
netsh rpc filter show filter

Remplacez DA dans le SDDL par le SID de votre groupe d'administrateurs Tier 0 dédié lorsque vous en avez un. Il n'existe pas de nœud de stratégie de groupe pour les filtres RPC : distribuez donc le fichier via votre gestion de configuration Tier 0 ou un script de démarrage des DC. Rendez le script idempotent : n'exécutez d'abord netsh rpc filter delete filter filterkey=all que si tous les filtres présents sur la machine sont les vôtres.

Supprimer le chemin réseau

La coercition exige que le DC puisse joindre l'écouteur de l'attaquant en SMB (445) ou en HTTP (80, ou n'importe quel port via le service WebClient). Un DC a rarement une raison légitime d'ouvrir des sessions SMB ou HTTP vers des postes de travail ou des sous-réseaux de serveurs utilisateurs. Le blocage de ces flux sortants est traité dans filtrage pare-feu des contrôleurs de domaine ; c'est l'un des contrôles anti-coercition les plus efficaces, car il couvre aussi les déclencheurs que personne n'a encore publiés.

Durcir les destinations

Considérez ces mesures comme des compléments obligatoires, pas comme des options :

• LDAP : exigez la signature et la liaison de canal sur chaque DC.
• SMB : exigez la signature côté serveurs et côté clients. C'est le comportement par défaut sur les builds récentes de Windows 11 et Windows Server 2025, mais vérifiez-le plutôt que de le supposer.
• AD CS : supprimez Web Enrollment s'il n'est pas utilisé. Sinon, imposez HTTPS avec Extended Protection for Authentication et désactivez NTLM sur ces sites IIS.
• Délégation : aucun ordinateur autre qu'un DC ne doit conserver la délégation non contrainte. Ajoutez les comptes Tier 0 à Protected Users et marquez-les comme sensibles afin que leurs TGT ne puissent pas être transférés.

Vérifier

Contrôlez la configuration depuis un PAW :

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $f = netsh rpc filter show filter | Out-String
    [PSCustomObject]@{
        DC          = $env:COMPUTERNAME
        Spooler     = (Get-Service Spooler).StartType
        EfsLsarpc   = $f -match 'c681d488-d850-11d0-8c52-00c04fd90f7e'
        EfsEfsrpc   = $f -match 'df1941c5-fe89-4e79-bf10-463657acf44d'
        DfsNm       = $f -match '4fc742e0-4a10-11cf-8273-00aa004ae673'
        VssAgent    = (Get-WindowsFeature FS-VSS-Agent).InstallState
    }
}

Testez ensuite le comportement. En laboratoire ou pendant une fenêtre approuvée, demandez à votre red team, ou dans le cadre d'un exercice purple team, de lancer les outils de coercition courants (par exemple Coercer ou les preuves de concept individuelles) contre un DC avec un compte utilisateur standard. Confirmez trois points : aucune authentification n'atteint l'écouteur, l'événement 5712 est généré pour l'interface bloquée, et votre SIEM lève une alerte. Testez aussi la règle d'autorisation DFSNM : ouvrez la console Gestion du système de fichiers distribués DFS depuis un PAW en tant qu'administrateur Tier 0 et confirmez que l'administration des espaces de noms fonctionne toujours.

Relancez la vérification après chaque mise à jour cumulative et après toute reconstruction de DC. Un DC fraîchement promu sans le fichier de filtres est la lacune la plus fréquente.

Ce que cela casse

• Les opérations EFS distantes sur les DC. Rien de légitime ne devrait chiffrer de fichiers sur un DC via le réseau. Les outils de sauvegarde ou de gestion de fichiers qui appellent EFSRPC sur des partages hébergés par des DC échoueront. Déplacez ces partages hors des DC.
• L'administration des espaces de noms DFS depuis des hôtes non administratifs. Avec le filtre DFSNM, seul le SID de la règle d'autorisation peut gérer les espaces de noms à distance. Les administrateurs d'espaces de noms délégués qui travaillent depuis des postes ordinaires perdent l'accès jusqu'à ce qu'ils passent sur un PAW ou rejoignent le groupe autorisé. Les références SYSVOL et NETLOGON ne sont pas affectées, car les clients n'utilisent pas l'interface d'administration.
• L'impression via un DC. Toute file d'attente encore publiée depuis un DC disparaît dès que le spouleur est désactivé.
• Les agents de supervision ou de sauvegarde qui collectent depuis les DC en SMB/HTTP dans le sens inverse. Le filtrage des flux sortants peut bloquer les agents qui attendent que le DC se connecte à eux. Recensez-les pendant la semaine d'audit.
• Les évolutions RPC futures. Les filtres indexés sur l'UUID sont précis. Si Microsoft déplace un jour une fonctionnalité vers une nouvelle interface, les filtres ne la couvriront pas : continuez donc à collecter les événements d'audit.

Pour aller plus loin : la base DC pour le reste de la configuration des contrôleurs de domaine, Stopper le NTLM relay : signature LDAP et SMB, LLMNR pour le côté cibles de relais, et l'entrée de glossaire NTLM relay pour comprendre pourquoi une authentification contrainte a autant de valeur.