Une vulnérabilité critique affectant le service Netlogon de Windows est désormais signalée comme exploitée en conditions réelles, ce qui change immédiatement la priorité de traitement pour les équipes en charge d’Active Directory. Relayée par BleepingComputer à partir des informations de Microsoft, cette faille permet une exécution de code à distance sur des systèmes Windows exposant le service concerné, avec un risque particulièrement élevé lorsqu’un contrôleur de domaine est touché. Dans un environnement AD, l’exploitation d’un bug dans Netlogon ne se limite pas à la compromission d’un seul hôte : elle peut ouvrir la voie à l’élévation de privilèges, au mouvement latéral, à la prise de contrôle du domaine et, in fine, au déploiement de rançongiciels à l’échelle de l’entreprise.

La vulnérabilité suivie ici est CVE-2025-33073, une faille d’exécution de code à distance dans Windows Netlogon, à laquelle Microsoft a attribué un score CVSS 8.1. Le point déterminant n’est plus seulement sa sévérité théorique, mais le fait que l’éditeur indique désormais une exploitation active. En pratique, cela signifie qu’un niveau de risque auparavant gérable dans une fenêtre de maintenance standard doit basculer vers un traitement prioritaire, en particulier pour les serveurs jouant un rôle d’authentification, les contrôleurs de domaine, les serveurs membres sensibles et les segments réseau où des flux RPC internes sont largement autorisés.

La source primaire à retenir reste l’avis de sécurité officiel de Microsoft pour CVE-2025-33073, complété par la couverture de BleepingComputer sur l’exploitation en cours. Pour les organisations françaises, cette alerte doit être rapprochée des recommandations habituelles du CERT-FR sur la réduction de la surface d’exposition des services d’administration Windows et sur la surveillance renforcée des actifs d’infrastructure. Les environnements hébergés chez OVHcloud, Scaleway ou o2switch ne sont pas épargnés dès lors qu’ils embarquent des serveurs Windows intégrés à un domaine ou reliés par VPN/MPLS à un SI central : le risque dépend de l’exposition réseau réelle du service, pas du lieu d’hébergement.

L’enjeu opérationnel est simple : identifier d’abord les serveurs critiques, vérifier les versions et niveaux de correctifs, déployer les mises à jour Microsoft sans attendre la prochaine vague de patching mensuelle, puis mettre en place des mesures transitoires de confinement si un correctif immédiat n’est pas possible. La présence d’une exploitation active doit aussi déclencher une recherche d’indices de compromission sur les contrôleurs de domaine et les serveurs d’administration, car un patch tardif posé après intrusion ne répare pas un domaine déjà altéré.

Versions affectées

CVE-2025-33073 concerne le composant Windows Netlogon sur des éditions Windows prises en charge par Microsoft au moment de la publication du correctif. Comme souvent sur les vulnérabilités du noyau des services d’infrastructure Windows, Microsoft ne raisonne pas en “version applicative” autonome du service, mais en builds de systèmes d’exploitation et en packages de sécurité cumulés. Les versions vulnérables sont donc, de manière pratique, les systèmes Windows supportés qui n’ont pas installé les mises à jour de sécurité corrigeant CVE-2025-33073.

Les familles de produits à vérifier en priorité sont les suivantes :

  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2022
  • Windows Server 2025, le cas échéant
  • Windows 10 sur postes ou serveurs techniques encore présents dans des rôles d’administration
  • Windows 11 lorsque des usages d’administration ou des flux RPC internes existent

Sur le terrain, les systèmes les plus critiques à inventorier en premier ne sont pas tous les hôtes Windows, mais ceux qui combinent rôle d’infrastructure et accessibilité réseau :

  • les contrôleurs de domaine Active Directory ;
  • les serveurs AD DS, AD CS et bastions d’administration ;
  • les serveurs membres hébergeant des applications sensibles avec droits élevés dans le domaine ;
  • les serveurs accessibles depuis plusieurs VLAN, zones d’administration ou réseaux de filiales ;
  • les systèmes joignables depuis des segments utilisateurs pouvant servir de point d’appui à un attaquant après compromission initiale.

En termes de remédiation, la distinction utile est la suivante :

  • Versions vulnérables : systèmes Windows supportés sans le correctif de sécurité Microsoft traitant CVE-2025-33073.
  • Versions corrigées : systèmes Windows supportés après installation de la mise à jour cumulative de sécurité publiée par Microsoft pour CVE-2025-33073.

Pour vérifier rapidement si un correctif a été appliqué, les équipes Windows peuvent s’appuyer sur PowerShell :

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20

Cette commande permet de lister les derniers correctifs installés. Pour un contrôle plus précis en environnement industrialisé, il est préférable de croiser :

  • la build système remontée par winver ou Get-ComputerInfo ;
  • les KB déployées via WSUS, Microsoft Configuration Manager ou Intune ;
  • la matrice officielle Microsoft dans l’advisory de CVE-2025-33073.

Exemple de vérification PowerShell plus détaillée :

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer, OsBuildNumber

Et pour interroger un ensemble de serveurs :

Invoke-Command -ComputerName DC01,DC02,SRV-APP01 -ScriptBlock { Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 }

Dans les grandes infrastructures, l’ordre de priorité conseillé est :

  • niveau 1 : tous les contrôleurs de domaine ;
  • niveau 2 : serveurs d’administration, PKI, ADFS, serveurs d’identité et de fédération ;
  • niveau 3 : serveurs applicatifs membres du domaine avec forte connectivité latérale ;
  • niveau 4 : postes d’administration et jump servers.

Si des contrôleurs de domaine sont hébergés chez un prestataire ou dans un cloud privé opéré, il faut également vérifier les fenêtres de maintenance imposées par l’hébergeur et exiger la confirmation du niveau de patch. Dans les contextes hybrides avec réplication AD entre sites on-premise et clouds privés, un seul DC vulnérable suffit à remettre en cause l’ensemble du périmètre de confiance.

Vecteur d'attaque

Netlogon est un composant central de l’écosystème Windows, utilisé pour les opérations d’authentification et de communication sécurisée entre machines membres du domaine et contrôleurs de domaine. Une faille RCE dans ce service est particulièrement sensible parce qu’elle se situe au cœur des mécanismes de confiance du domaine. L’attaquant n’a pas nécessairement besoin d’un accès interactif préalable sur le serveur ciblé : selon le scénario exact, l’exploitation peut être déclenchée à distance via des échanges réseau vers le service vulnérable, ce qui en fait un excellent levier pour une progression rapide après une compromission initiale modeste.

Le changement majeur vient de l’état “exploité”. Tant qu’une faille critique n’est qu’un risque théorique, certaines organisations arbitrent en fonction de la disponibilité des correctifs, des contraintes de production et de la sensibilité métier. Lorsqu’une exploitation active est confirmée, cet arbitrage devient beaucoup plus défavorable au report. En clair : l’existence d’attaques réelles signifie qu’un outillage offensif circule déjà, qu’il soit privé, semi-public ou intégré à des chaînes opératoires de groupes criminels.

Sur un plan technique, l’exploitation d’une vulnérabilité dans Netlogon peut déboucher sur plusieurs conséquences :

  • exécution de code dans le contexte du service ou avec des privilèges élevés ;
  • compromission d’un serveur membre connecté au domaine ;
  • si la cible est un DC, compromission directe du contrôleur de domaine ;
  • accès à des secrets en mémoire, tickets ou artefacts d’authentification ;
  • mouvement latéral vers d’autres systèmes Windows via SMB, WMI, WinRM, PsExec ou tâches planifiées ;
  • élévation vers une compromission complète du domaine.

Le scénario d’attaque le plus préoccupant pour une équipe AD est le suivant :

  • un poste utilisateur ou un serveur périphérique est compromis par phishing, vol d’identifiants VPN ou exploitation d’un autre service ;
  • l’attaquant cartographie le réseau interne et identifie les DC via LDAP, DNS ou simple résolution des enregistrements de service ;
  • il cible ensuite un serveur Windows vulnérable exposant Netlogon, idéalement un DC ;
  • la RCE lui permet d’exécuter du code avec des privilèges élevés ;
  • il implante une porte dérobée, extrait des secrets, modifie des GPO, crée des comptes, déploie des outils de rebond ;
  • la compromission devient persistante et difficile à éradiquer sans procédure de reconstruction du domaine.

Ce type de séquence n’a rien d’exceptionnel. L’histoire récente de la sécurité Windows montre qu’une faiblesse sur les protocoles d’authentification ou de confiance du domaine est régulièrement exploitée pour transformer une compromission locale en incident majeur. Les comparaisons naturelles sont :

  • Zerologon (CVE-2020-1472) : vulnérabilité critique de Netlogon permettant une élévation vers le contrôle du domaine ;
  • NoPac (CVE-2021-42278 et CVE-2021-42287) : abus de mécanismes AD pour obtenir des privilèges élevés ;
  • diverses failles RPC et LSASS ayant permis de contourner les frontières de confiance internes.

La différence avec une simple faille de service applicatif est donc structurelle : ici, l’actif visé participe à la racine de confiance du SI Windows. Quand un contrôleur de domaine tombe, l’incident n’est plus celui d’un serveur, mais celui de l’annuaire, des politiques de sécurité, des secrets machine et, souvent, de toute la chaîne d’administration.

Un autre point opérationnel important concerne l’exposition “interne”. Beaucoup d’organisations classent encore les vulnérabilités selon qu’elles sont exploitables depuis Internet. Pour Netlogon, cette lecture est insuffisante. Les attaques modernes passent très souvent par une première intrusion sur un point d’entrée banal, puis exploitent les services internes pour gagner en privilèges. Une faille non exposée publiquement mais accessible depuis un poste utilisateur compromis reste une priorité élevée.

Les équipes doivent donc vérifier en premier :

  • les flux réseau autorisés vers les DC ;
  • la présence de segments utilisateurs capables de joindre les ports RPC nécessaires ;
  • les règles inter-VLAN trop permissives ;
  • les accès d’administration depuis des postes standards ;
  • les serveurs de rebond non durcis.

Dans certains environnements, la télémétrie réseau montrera des connexions vers des ports liés à RPC et aux services d’authentification Windows depuis des machines qui n’ont aucune raison métier de parler directement à un DC. Ce type d’anomalie doit être traité comme un signal faible de reconnaissance ou de tentative d’exploitation.

Exemple de contrôle local de l’état du service :

Get-Service -Name Netlogon

Exemple de vérification des connexions réseau sur un serveur :

Get-NetTCPConnection | Where-Object { $_.State -eq "Established" } | Sort-Object RemoteAddress

Exemple de journalisation à surveiller dans les journaux Windows :

  • System
  • Security
  • Microsoft-Windows-ActiveDirectory_DomainService
  • Microsoft-Windows-SMBServer/Audit
  • Microsoft-Windows-Windows Defender/Operational

Un attaquant ayant obtenu l’exécution de code cherchera généralement à enchaîner très vite avec des commandes de découverte :

whoami /all
nltest /dclist:mondomaine.local
nltest /domain_trusts
net group "Domain Admins" /domain
dsquery server -o rdn

Ces commandes ne constituent pas à elles seules une preuve d’exploitation, mais leur apparition sur un serveur où elles ne sont pas attendues, surtout en corrélation avec des connexions réseau anormales, doit déclencher une investigation.

Impact

L’impact métier et technique dépend du rôle du serveur vulnérable, mais il est maximal sur un contrôleur de domaine. Dans ce cas, l’exploitation peut aboutir à :

  • la prise de contrôle de comptes à privilèges ;
  • la modification des GPO pour déployer scripts, services ou logiciels malveillants ;
  • la création de comptes persistants ou de délégations cachées ;
  • l’accès aux secrets d’authentification du domaine ;
  • la désactivation ou l’affaiblissement des mécanismes de sécurité ;
  • la préparation d’un chiffrement massif de serveurs et postes.

Sur un serveur membre, l’impact peut sembler plus limité, mais reste sérieux. Un attaquant peut s’en servir pour :

  • rebondir vers des serveurs plus sensibles ;
  • capturer des identifiants d’administration ;
  • abuser de comptes de service ;
  • déployer des implants ;
  • préparer une élévation ultérieure vers le domaine.

Le score CVSS 8.1 traduit une sévérité élevée, mais en environnement AD critique, le risque opérationnel réel peut être perçu comme encore supérieur si le serveur vulnérable est un DC exposé à un grand nombre de segments internes. C’est une illustration classique des limites du CVSS : le score ne reflète pas toujours la centralité métier de l’actif compromis.

Les conséquences indirectes sont également importantes :

  • arrêt de la chaîne d’authentification et indisponibilité d’applications dépendantes de l’AD ;
  • perte de confiance dans l’annuaire nécessitant une reconstruction partielle ou totale ;
  • rotation d’urgence des secrets, comptes de service, mots de passe administrateurs ;
  • mobilisation longue des équipes SOC, infra, IAM, sauvegarde et production ;
  • coûts de remédiation élevés et risque réglementaire en cas de fuite de données.

Comment patcher

La remédiation prioritaire consiste à appliquer les mises à jour de sécurité Microsoft corrigeant CVE-2025-33073. La source de vérité est l’advisory officiel Microsoft associé à la CVE, qui référence les KB et packages cumulatifs selon la version de Windows concernée. Il faut viser l’installation du dernier cumulative update disponible pour chaque système affecté, et non une sélection partielle de correctifs anciens.

Pour un serveur autonome ou un test ponctuel, la méthode la plus simple reste l’interface graphique :

  • ouvrir Settings puis Windows Update ;
  • lancer Check for updates ;
  • installer toutes les mises à jour de sécurité applicables ;
  • redémarrer si requis ;
  • vérifier la présence du correctif et la build finale.

En ligne de commande, sur les environnements modernes :

UsoClient StartScan
UsoClient StartDownload
UsoClient StartInstall

Dans les environnements administrés, le déploiement doit passer par les outils habituels :

  • WSUS
  • Microsoft Configuration Manager
  • Intune
  • ou orchestration PowerShell contrôlée

Exemple de recherche et installation via module PSWindowsUpdate si son usage est autorisé dans l’organisation :

Install-Module PSWindowsUpdate
Get-WindowsUpdate
Install-WindowsUpdate -AcceptAll -AutoReboot

Pour vérifier la présence d’une KB spécifique une fois l’advisory Microsoft consulté :

Get-HotFix -Id KBXXXXXXX

Dans les environnements de production AD, l’ordre de patching recommandé est généralement :

  • patcher un DC secondaire de test ou de moindre criticité ;
  • valider réplication, authentification et services dépendants ;
  • patcher l’ensemble des autres DC ;
  • terminer par les serveurs membres critiques et bastions ;
  • vérifier la santé AD après redémarrage.

Contrôles post-correctif à réaliser :

  • dcdiag /v
  • repadmin /replsummary
  • repadmin /showrepl
  • test d’ouverture de session utilisateur ;
  • test des applications dépendantes de l’AD ;
  • revue des journaux System et Directory Service.

Exemple :

dcdiag /v
repadmin /replsummary

Si des serveurs sont hébergés chez un prestataire ou un infogérant, il faut exiger :

  • la confirmation écrite du déploiement du correctif ;
  • la liste des hôtes concernés ;
  • l’horaire exact d’application ;
  • les résultats de vérification fonctionnelle ;
  • les éventuels serveurs exclus et la justification de risque.

Dans les environnements critiques où la haute disponibilité est sensible, il ne faut pas confondre prudence et immobilisme. Le risque de redémarrage d’un DC est généralement inférieur au risque de laisser en production une RCE activement exploitée. Si une fenêtre de maintenance est nécessaire, elle doit être avancée, pas repoussée au cycle mensuel suivant.

Détection

Lorsqu’une faille est déjà exploitée dans la nature, la réponse ne peut pas se limiter au patching. Il faut aussi rechercher si une exploitation a déjà eu lieu. La détection doit combiner journaux Windows, télémétrie EDR, flux réseau, événements AD et recherche de comportements post-exploitation.

Serveurs à inspecter en premier

  • tous les contrôleurs de domaine ;
  • serveurs d’administration et jump servers ;
  • serveurs exposés à plusieurs segments réseau ;
  • hôtes ayant récemment reçu des connexions depuis des postes utilisateurs ;
  • machines où des outils d’administration à distance sont présents.

Indicateurs de compromission à rechercher

Les IoC spécifiques évoluent souvent rapidement et ne sont pas toujours publiés au début d’une campagne. En revanche, plusieurs indicateurs comportementaux sont utiles :

  • création inattendue de services Windows ;
  • exécution de cmd.exe, powershell.exe ou rundll32.exe par un processus lié à un service système ;
  • apparition de tâches planifiées non autorisées ;
  • création de comptes administrateurs locaux ou domaine ;
  • modification de groupes sensibles comme Domain Admins ;
  • activité réseau anormale entre un serveur compromis et plusieurs hôtes internes ;
  • dump mémoire, accès à LSASS ou usage d’outils de credential access ;
  • déploiement d’outils comme PsExec, scripts PowerShell encodés, binaires temporaires dans C:\Windows\Temp ou C:\ProgramData.

Chemins et emplacements à examiner :

  • C:\Windows\Temp\
  • C:\ProgramData\
  • C:\Users\Public\
  • C:\Windows\System32\Tasks\
  • clés Run et RunOnce du registre

Exemples de commandes de triage :

Get-ScheduledTask | Where-Object { $_.TaskPath -notlike "\Microsoft*" }
Get-Service | Where-Object { $_.StartType -eq "Automatic" }
Get-LocalGroupMember -Group "Administrators"
wevtutil qe Security /f:text /c:200

Événements Windows utiles à corréler :

  • 4624 : ouverture de session réussie ;
  • 4625 : échec d’ouverture de session ;
  • 4672 : privilèges spéciaux attribués ;
  • 4688 : création de processus ;
  • 4697 : installation d’un service ;
  • 4720 : création d’un compte ;
  • 4728 et 4732 : ajout à un groupe privilégié ;
  • 4742 : modification d’un compte machine ;
  • 7045 dans System : création d’un service.

Une attention particulière doit être portée aux événements 4688 montrant des chaînes telles que :

  • powershell.exe -enc
  • cmd.exe /c
  • rundll32.exe
  • reg add
  • net user
  • net group "Domain Admins"
  • nltest

Sur le plan réseau, il faut rechercher :

  • des connexions inhabituelles vers les DC depuis des postes utilisateurs ;
  • des scans internes ciblant plusieurs serveurs Windows ;
  • des séquences de connexion rapprochées suivies d’activités SMB ou WinRM ;
  • des communications entre segments habituellement peu liés.

Exemple de collecte PowerShell locale :

Get-WinEvent -LogName Security -MaxEvents 500 | Where-Object { $_.Id -in 4624,4672,4688,4697,4720,4728,4732,4742 }

Si un doute sérieux existe sur un DC, les mesures immédiates sont :

  • isoler le serveur du réseau si la continuité le permet ;
  • préserver les journaux et la mémoire si une investigation forensique est prévue ;
  • réinitialiser les comptes à privilèges potentiellement exposés ;
  • vérifier les ajouts de comptes, GPO, délégations et tâches planifiées ;
  • contrôler l’intégrité de la réplication AD ;
  • engager un plan de réponse à incident orienté compromission du domaine.

Mitigation

Si le patch ne peut pas être appliqué immédiatement, il faut réduire la surface d’attaque sans attendre. Aucune mesure compensatoire ne remplace le correctif, mais plusieurs actions peuvent compliquer l’exploitation ou limiter le rayon d’impact.

  • Segmenter l’accès aux DC : limiter les flux réseau aux seuls serveurs et postes d’administration autorisés.
  • Restreindre les accès RPC internes : revoir les ACL réseau entre VLAN utilisateurs et serveurs d’infrastructure.
  • Interdire l’administration depuis les postes bureautiques : utiliser des bastions dédiés.
  • Réduire les privilèges : retirer les comptes inutiles des groupes sensibles.
  • Durcir la supervision : activer une collecte renforcée des événements de sécurité et de création de processus.
  • Activer ou renforcer l’EDR sur les DC et serveurs critiques.

Exemple de logique réseau à faire valider par les équipes infra :

  • seuls les sous-réseaux d’administration peuvent joindre les DC sur les ports nécessaires ;
  • les VLAN utilisateurs ne doivent pas initier librement des connexions vers les contrôleurs de domaine ;
  • les serveurs applicatifs ne communiquent qu’avec les DC strictement requis.

Sur les bastions, il est utile de vérifier :

  • l’activation de Credential Guard si applicable ;
  • la séparation des comptes d’administration ;
  • la désactivation des usages Internet et messagerie ;
  • la journalisation PowerShell avancée ;
  • la rotation des secrets administratifs.

Les organisations disposant de plusieurs sites ou filiales doivent aussi vérifier que les DC secondaires, souvent moins surveillés, ne deviennent pas le maillon faible. C’est un point fréquent dans les infrastructures distribuées, y compris lorsque certains serveurs sont externalisés chez des prestataires français ou hébergés dans des environnements cloud privés.

Source originale : avis de sécurité Microsoft sur CVE-2025-33073, complété par le signalement de BleepingComputer indiquant une exploitation active de la faille Windows Netlogon. Ces deux sources doivent être suivies pour les mises à jour de statut, la disponibilité d’éventuels IoC additionnels et les précisions sur les produits touchés.

Pour les équipes Windows et AD francophones, le message opérationnel est clair : une RCE critique sur Netlogon exploitée en conditions réelles doit être traitée comme un risque de compromission de domaine, pas comme une simple mise à jour de routine. Commencer par les contrôleurs de domaine, les bastions et les serveurs d’identité, vérifier les journaux avant et après patch, puis resserrer les flux internes tant que tout le parc n’est pas corrigé. Pour renforcer durablement le durcissement de l’infrastructure Windows et les pratiques de réduction de surface d’attaque, un détour par la catégorie /categorie/pratiques est pertinent.

Rubrique CVE
Partager
Retour aux actualités