Netlogon RCE critique : patcher Windows Server en urgence

Une vulnérabilité critique Netlogon est désormais exploitée activement contre des serveurs Windows non patchés, transformant chaque contrôleur de domaine non corrigé en porte d’entrée vers Active Directory. Pour les PME-ETI qui font tourner un AD on-premise ou hybride, l’exploitation in-the-wild change l’équation : il ne s’agit plus d’évaluer un risque théorique, mais de patcher avant la prochaine vague de chiffrement. Ce tutoriel détaille les étapes concrètes pour neutraliser la faille Netlogon, valider l’application du correctif et durcir le service contre les attaques de relais et de prise de contrôle.

Pourquoi cette vulnérabilité Netlogon est critique pour les PME-ETI

Le service Netlogon est le mécanisme qui permet à un poste joint au domaine de s’authentifier auprès du contrôleur de domaine et d’établir un canal sécurisé. Quand cette brique est cassée, l’attaquant n’a plus besoin de phishing ni d’identifiant valide : il parle directement à l’AD comme s’il en faisait partie. Microsoft a publié un correctif lors du dernier Patch Tuesday, mais BleepingComputer et SecurityWeek confirment cette semaine que l’exploitation a commencé en environnement réel.

Concrètement, le risque pour une PME-ETI se résume à trois scénarios :

• Élévation de privilèges vers Domain Admin en quelques minutes après un accès réseau interne.
• Pivot vers les sauvegardes sauvegardées dans le même AD, ce qui annule la dernière ligne de défense face à un ransomware.
• Persistance silencieuse via la création de comptes machines ou la modification de descripteurs de sécurité difficile à détecter sans audit AD avancé.

Étape 1 — Identifier vos contrôleurs de domaine exposés

Avant de déployer le patch, dressez la cartographie exacte. Sur n’importe quel poste membre du domaine, lancez en PowerShell :

Get-ADDomainController -Filter * | Select-Object Name,IPv4Address,OperatingSystem,OperatingSystemVersion

Repérez tous les contrôleurs qui tournent sous Windows Server 2019, 2022 ou 2025. Si vous voyez encore du Windows Server 2016 ou plus ancien, la priorité change : ces versions cumulent souvent plusieurs CVE Netlogon non corrigées et doivent être traitées avant tout.

Étape 2 — Appliquer le correctif Netlogon dans l’ordre

Le patch Microsoft est cumulatif. L’ordre d’application limite le risque de désynchronisation entre contrôleurs :

1. Patchez d’abord un DC secondaire et observez 2 heures de réplication AD sans erreur (repadmin /replsummary).
2. Patchez ensuite les autres DC un par un, jamais en parallèle.
3. Terminez par le PDC Emulator, car c’est lui qui synchronise l’heure et les politiques.
4. Redémarrez chaque DC après installation — un service Netlogon non redémarré reste vulnérable.

Validation rapide après reboot :

Get-HotFix | Where-Object { $_.InstalledOn -gt (Get-Date).AddDays(-7) }
Get-WinEvent -LogName System -MaxEvents 50 | Where-Object { $_.ProviderName -eq "Netlogon" }

Étape 3 — Activer le mode enforcement sécurisé du canal Netlogon

Microsoft expose une clé de registre qui force l’utilisation de canaux sécurisés et bloque les négociations dégradées. C’est elle qui transforme le correctif en barrière réelle :

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" /v FullSecureChannelProtection /t REG_DWORD /d 1 /f

Après application, surveillez le journal système pendant 48 heures pour les événements 5827, 5828, 5829. Tout équipement legacy (NAS, imprimantes, contrôleurs industriels) qui parle encore en RPC non sécurisé apparaîtra ici. Ne désactivez surtout pas la protection — corrigez la source.

Étape 4 — Détecter une exploitation passée ou en cours

Si votre SIEM remonte vers Wazuh, Splunk, Sentinel ou ELK, créez immédiatement les règles suivantes :

• Connexions Netlogon depuis un compte machine vers plusieurs DC en moins de 5 minutes (signature classique de relais).
• Réinitialisation du mot de passe du compte machine d’un DC depuis une source non-DC (event ID 4742 + filtrage).
• Création soudaine d’objets ordinateur par un utilisateur non administrateur (event ID 4741).
• Erreurs NTLM en burst — souvent la queue d’un brute-force préparant le canal Netlogon.

Pour aller plus loin, lancez un BloodHound à jour : si un compte machine peut atteindre Domain Admin via un chemin court, vous avez déjà un problème indépendant du patch — corrigez-le aussi.

Étape 5 — Réduire la surface d’attaque autour d’Active Directory

Le patch ferme cette fenêtre, mais d’autres s’ouvrent en permanence. Quatre actions valent leur poids en heures de SOC :

• Isoler les contrôleurs de domaine sur un VLAN dédié, accessible uniquement par les serveurs membres légitimes.
• Imposer SMB signing et désactiver SMBv1 sur tout le périmètre AD.
• Faire tourner les mots de passe des comptes machines (KRBTGT inclus) une fois par trimestre, et toujours après une suspicion d’incident.
• Auditer les délégations Kerberos et révoquer toute délégation non contrainte.

Pour les PME-ETI qui n’ont pas d’équipe sécurité interne, ces étapes peuvent être intégrées dans une checklist trimestrielle. C’est ce que l’on recommande dans notre guide cybersécurité PME-ETI, et c’est ce que l’on déploie chez nos clients via le module Agentic SOC ucyber.ai.

Conclusion : le patch Netlogon est urgent, le durcissement est permanent

Appliquer le correctif Microsoft cette semaine n’est pas une option : c’est le minimum vital. Mais la véritable résilience repose sur le triptyque patch + enforcement + détection. Une PME-ETI qui patche ses DC mais laisse FullSecureChannelProtection à 0 reste exposée à la première variante du Netlogon RCE qui sortira. À l’inverse, une équipe qui applique les 5 étapes de ce tutoriel transforme un incident potentiellement catastrophique en simple non-événement.

Sources :

• BleepingComputer — Critical Windows Netlogon RCE flaw now exploited in attacks
• SecurityWeek — Critical Windows Netlogon Vulnerability in Attackers’ Crosshairs