Durcir le canal sécurisé Netlogon après ZeroLogon

Chaque ordinateur joint au domaine et chaque approbation maintiennent un canal sécurisé vers un contrôleur de domaine via le protocole Netlogon Remote Protocol (MS-NRPC). Il transporte l'authentification NTLM pass-through, les changements de mot de passe des comptes machine et la validation des approbations. ZeroLogon (CVE-2020-1472) a montré à quel point un canal sécurisé faible peut être dangereux. Une faille dans la négociation AES-CFB8 permettait à un attaquant non authentifié présent sur le réseau de vider le mot de passe du compte machine d'un DC et de prendre le contrôle du domaine en quelques secondes.

Le correctif n'est plus une nouveauté, mais le durcissement qui l'accompagne est souvent inachevé. Des GPO de liste d'autorisation créées lors du déploiement de 2020 accordent encore des exceptions. L'exigence complémentaire de scellement issue de CVE-2022-38023 n'a jamais été vérifiée, et quelques NAS ou anciens hôtes Samba journalisent discrètement des refus tous les jours. Ce guide va au-delà de la vérification en une ligne de la base DC. Il montre comment mesurer ce qui utilise encore un Netlogon faible, imposer chaque couche et le prouver.

Les couches du durcissement

Le durcissement de Netlogon est arrivé par étapes. Chaque étape a son propre contrôle et ses propres événements :

Signification des événements ZeroLogon :

• 5827 : le DC a refusé une connexion Netlogon vulnérable provenant d'un compte machine.
• 5828 : le DC a refusé une connexion Netlogon vulnérable provenant d'un compte d'approbation.
• 5829 : le DC a autorisé une connexion machine vulnérable. Vous ne le voyez qu'avant la phase d'application ; sur un DC à jour aujourd'hui, cela signifie donc qu'un problème existe.
• 5830 : le DC a autorisé une connexion machine vulnérable à cause de la GPO de liste d'autorisation.
• 5831 : le DC a autorisé une connexion d'approbation vulnérable à cause de la GPO de liste d'autorisation.

Les événements 5838 et 5839 signifient qu'un compte machine ou un compte d'approbation a utilisé la signature RPC alors que le scellement était attendu. Sur un DC entièrement à jour et après la date d'application, ces clients sont refusés, pas simplement signalés.

Mesurer : collecter les événements de chaque DC

Récupérez un mois d'événements Netlogon de chaque DC en une seule passe. Si vous transférez les journaux Système vers un SIEM, exécutez-y la requête équivalente. L'objectif est de savoir quels appareils et quelles approbations sont encore à la limite.

$ids = 5827,5828,5829,5830,5831,5838,5839
$since = (Get-Date).AddDays(-30)

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'System'; ProviderName = 'NETLOGON'; Id = $ids; StartTime = $since
    } -ErrorAction SilentlyContinue
} | Select-Object MachineName, Id, TimeCreated,
    @{ n = 'Detail'; e = { ($_.Message -split "`n" | Select-String 'Machine|Account|Domain|OS' ) -join ' | ' } } |
    Sort-Object Id, TimeCreated |
    Export-Csv C:\Reports\netlogon-events.csv -NoTypeInformation

Chaque événement enregistre le nom de la machine ou de l'approbation, son domaine et, lorsqu'elle est connue, la version de l'OS. Les découvertes typiques : baies de stockage, imprimantes et scanners qui s'authentifient auprès du domaine, anciennes versions de Samba et systèmes Linux embarqués joints avec des outils obsolètes.

Vérifiez ensuite si quelqu'un a un jour renseigné la liste d'autorisation. Il s'agit d'un descripteur de sécurité stocké dans une GPO : lisez-le donc dans la stratégie résultante de chaque DC :

Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    $p = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
    Get-ItemProperty $p | Select-Object PSComputerName,
        FullSecureChannelProtection, RequireSeal, VulnerableChannelAllowList,
        RequireSignOrSeal, SealSecureChannel, SignSecureChannel, RequireStrongKey
}

VulnerableChannelAllowList est la valeur de registre derrière la GPO. Si elle a un contenu, décodez le SDDL (ConvertFrom-SddlString) pour voir quels comptes ou groupes sont exemptés.

Auditer : traiter chaque appareil avant de resserrer

Parcourez le CSV appareil par appareil :

1. Identifiez le propriétaire de chaque compte machine présent dans les événements 5827, 5829, 5830 et 5838. Utilisez Get-ADComputer <name> -Properties operatingSystem, whenChanged, ManagedBy, Description.
2. Mettez à jour ou remplacez. Un firmware constructeur ou une version actuelle de Samba corrige presque tous ces cas. Samba exige le schannel sécurisé par défaut depuis des années, mais d'anciennes builds d'appliances peuvent figer une version plus ancienne.
3. Vérifiez les approbations pour les événements 5828, 5831 et 5839. Il s'agit d'approbations externes ou de forêt dont l'autre côté a des DC non corrigés, souvent un partenaire ou un domaine acquis. Les DC de ce domaine doivent être mis à jour. Il n'existe aucun contournement local sûr.
4. Supprimez les comptes morts. Une part étonnante des comptes machine refusés appartient à des appareils qui n'existent plus. Désactivez-les, puis supprimez-les conformément à votre processus de gestion des objets obsolètes.

Maintenez la collecte après ce premier passage. De nouveaux appareils sont joints, les partenaires reconstruisent leurs DC et des appliances sont restaurées à partir d'anciennes images. Un rapport mensuel de tout événement Netlogon dans la plage 5827-5839, envoyé à l'équipe responsable des jonctions au domaine, détecte ces cas bien avant qu'un changement d'application ne les transforme en panne.

Appliquer

Vider la liste d'autorisation des connexions vulnérables

Ouvrez la GPO qui la définit (généralement la Default Domain Controllers Policy ou une GPO de l'époque ZeroLogon) et accédez à :

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: Allow vulnerable Netlogon secure channel connections

Définissez-la sur Not Defined une fois que tous les appareils listés ont été corrigés. Si un appareil critique pour l'activité ne peut vraiment pas encore être corrigé, conservez un seul groupe dédié dans le descripteur, documentez le propriétaire et la date de fin, et alertez sur chaque événement 5830. Ne l'accordez jamais à un groupe large comme Domain Computers.

Confirmer l'application du scellement

Sur les builds Windows Server actuelles et prises en charge, le calendrier de Microsoft pour CVE-2022-38023 a déjà rendu le scellement obligatoire : depuis les mises à jour de juillet 2023, RequireSeal ne peut plus être défini à 0 (désactivé) ni à 1 (compatibilité), si bien que sur un DC à jour la valeur ne change plus le comportement. La définir à 2 est sans effet néfaste et ne fait de différence que sur un DC resté à un niveau de mises à jour compris entre novembre 2022 et juin 2023. Définissez tout de même la valeur explicitement, afin qu'un DC restauré à partir d'une ancienne sauvegarde ou un DC rarement mis à jour apparaisse dans le rapport de dérive :

$p = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
Set-ItemProperty -Path $p -Name RequireSeal -Value 2 -Type DWord
Set-ItemProperty -Path $p -Name FullSecureChannelProtection -Value 1 -Type DWord

Déployez ces valeurs sous forme d'éléments de registre des préférences de stratégie de groupe dans une GPO réservée aux DC, et non à la main, afin qu'elles soient réappliquées à chaque actualisation.

Verrouiller les options classiques du canal sécurisé

Ces options de sécurité existent depuis Windows 2000 et doivent être activées sur chaque membre du domaine et chaque DC. Les bases de sécurité Microsoft en définissent déjà la plupart :

• Domain member: Digitally encrypt or sign secure channel data (always) = Enabled
• Domain member: Digitally encrypt secure channel data (when possible) = Enabled
• Domain member: Digitally sign secure channel data (when possible) = Enabled
• Domain member: Require strong (Windows 2000 or later) session key = Enabled
• Domain member: Disable machine account password changes = Disabled
• Domain member: Maximum machine account password age = 30 jours
• Domain controller: Refuse machine account password changes = Disabled

La rotation régulière du mot de passe machine limite la durée pendant laquelle un secret machine volé reste utile. Arrêtez tout processus de création d'images ou de VDI qui désactive la rotation pour « garder l'approbation stable ». Corrigez plutôt l'image.

Vérifier

Commencez par vérifier que le canal sécurisé fonctionne toujours depuis un échantillon de membres, dont au moins un par famille d'OS :

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:corp.example.com

Relancez ensuite la collecte d'événements et confirmez qu'il n'y a aucun événement 5829, 5830 ou 5831 et que les événements 5827, 5828, 5838 et 5839 ne citent que des appareils dont vous avez déjà décidé le retrait. Relancez la requête de registre et confirmez que VulnerableChannelAllowList est absente sur chaque DC.

Enfin, ajoutez des détections qui surveillent les régressions et l'exploitation :

• Tout événement 5829, 5830 ou 5831 est une régression de configuration. Ouvrez un ticket.
• Une rafale d'événements 5827 depuis une source unique peut signaler un scan à la recherche de Netlogon faible.
• L'événement 4742 (compte d'ordinateur modifié) portant sur le propre compte d'un contrôleur de domaine, avec ANONYMOUS LOGON comme sujet et un changement de mot de passe, est l'artefact classique d'une exploitation de ZeroLogon. Il ne devrait jamais se produire légitimement. Alertez dessus avec une sévérité élevée. Les ID d'événements à transférer sont listés dans la référence des ID d'événements AD.

Ce que cela casse

• Les appareils non Windows dotés d'anciennes piles Netlogon. NAS, imprimantes multifonctions, anciens serveurs de fichiers Samba et certains agents Linux de jonction au domaine ne parviennent plus à s'authentifier ni à changer leur mot de passe machine une fois refusés. Les utilisateurs voient des erreurs « la relation d'approbation a échoué » ou des erreurs d'ouverture de session NTLM sur ces appareils.
• Les approbations avec des domaines non corrigés. Une approbation de forêt ou externe dont les DC distants ne savent pas sceller est refusée. L'authentification à travers cette approbation échoue jusqu'à ce que le partenaire applique les correctifs.
• Les images VDI et de laboratoire figées. Les images qui ont désactivé le changement de mot de passe machine se désynchronisent et perdent leur canal sécurisé dès que la rotation reprend. Reconstruisez-les avec la rotation activée, ou utilisez la gestion des mots de passe machine prise en charge par votre éditeur VDI.
• Les DC restaurés. Un DC restauré à partir d'une sauvegarde antérieure à votre base de mises à jour revient sans application tant qu'il n'est pas corrigé. Incluez ces valeurs dans les vérifications de votre plan de restauration de forêt.

Pour aller plus loin : la base DC pour la configuration environnante, bloquer la coercition d'authentification pour l'autre classe d'attaques RPC visant les DC, et restreindre NTLM pour réduire ce qui dépend encore du pass-through Netlogon.