Chaque deuxième mardi du mois, l’équipe qui gère l’Active Directory reçoit la même liste à trier, et celle de septembre 2026 est la plus longue jamais publiée par Microsoft: selon les décomptes, entre 964 (Tenable, CCB belge) et 974 CVE (Splashtop), dont deux failles déjà exploitées.
Dans ce volume, une ligne attire l’œil de quiconque administre un domaine: CVE-2026-69676, « Windows Kerberos Remote Code Execution Vulnerability ». Nous allons voir ce que l’avis dit réellement, à quel endroit du protocole il nous oriente, et ce qu’un administrateur AD peut vérifier dès maintenant. Deux mois après la publication, le détail technique n’a toujours pas été rendu public par Microsoft. Nous nous en tiendrons donc à ce qui est écrit.
Que dit l’avis?
La fiche de référence est celle du MSRC, publiée le 8 septembre 2026. Les éléments repris par les analyses du mois (Tenable, CrowdStrike, Rapid7) concordent:
- Composant: Windows Kerberos,
- Impact: exécution de code à distance,
- Score CVSS v3.1: 8.8, ce qui correspond à « High » sur l’échelle CVSS. Microsoft la classe pourtant « Critical » avec sa propre grille de sévérité,
- Évaluation d’exploitabilité: « Exploitation More Likely »,
- Faiblesse: CWE-294, contournement d’authentification par capture et rejeu (« capture-replay »).
La description officielle tient en une phrase: un contournement d’authentification par capture et rejeu dans Windows Kerberos permet à un attaquant autorisé d’exécuter du code via le réseau.
Le mot « autorisé » est le prérequis le plus important de l’avis. Automox et Action1 le reformulent de la même manière: il faut un attaquant déjà authentifié, avec des privilèges faibles, qui envoie une requête forgée vers un serveur vulnérable. Le score 8.8 est cohérent avec cette lecture: attaque réseau, faible complexité, privilèges faibles, pas d’interaction de l’utilisateur, impact total sur confidentialité, intégrité et disponibilité. Un simple compte du domaine suffit donc, ce qui dans la plupart des SI veut dire n’importe quel poste compromis par hameçonnage.
Sur l’exploitation, CVE-2026-69676 ne fait pas partie des deux failles exploitées du mois (CVE-2026-81963 et CVE-2026-85880). À l’heure où j’écris ces lignes, je n’ai trouvé aucune preuve de concept publiée par une source fiable. Attention: le champ « Publicly disclosed » de la fiche MSRC fait foi, et il peut évoluer avec les révisions de l’avis.
Elle n’arrive pas seule. Le même mois corrige d’autres failles dans la chaîne d’authentification: une faille dans le Key Distribution Center (CVE-2026-69712), deux élévations de privilèges Kerberos (CVE-2026-69685 et CVE-2026-69822, 7.8), deux dénis de service Kerberos (CVE-2026-69744 et CVE-2026-69760, 7.5) et une RCE critique dans Netlogon (CVE-2026-72982). CrowdStrike parle d’un risque élevé ce mois-ci pour les composants de la plateforme d’identité. Automox précise que Microsoft ne relie pas la faille Kerberos à la RCE du serveur DNS publiée le même mois.
Où se situe la faille dans le flux Kerberos?
Le KDC dispose de sa propre CVE ce mois-ci, alors que celle-ci vise le composant « Windows Kerberos ». Les synthèses parlent d’un serveur affecté qui reçoit la requête. Ce composant est le package de sécurité Kerberos présent sur toutes les machines Windows, qu’elles jouent le rôle de client ou de service. Un contrôleur de domaine héberge lui-même des services Kerberos (LDAP, CIFS, RPC…), il est donc concerné aussi.
Le terme « capture-replay » nous oriente vers les mécanismes anti-rejeu du protocole. Comme nous l’avions vu en lisant un ticket de service avec klist et Wireshark, le ticket seul ne prouve rien. Ce qui prouve que le client détient la clé de session, c’est l’authenticator joint au KRB_AP_REQ. Il est chiffré avec cette clé de session et contient le nom du client, un horodatage (ctime, cusec) et en option une sous-clé et un numéro de séquence.
La RFC 4120, section 3.2.3 décrit la défense côté service: refuser un authenticator dont l’horodatage sort de la tolérance d’horloge (5 minutes par défaut dans AD, erreur KRB_AP_ERR_SKEW, code 37) et garder un cache de rejeu des authenticators déjà vus dans cette fenêtre (erreur KRB_AP_ERR_REPEAT, code 34). Une protection équivalente existe sur les messages KRB_SAFE et KRB_PRIV, et sur les messages chiffrés par les numéros de séquence.
Attention: rien dans l’avis ne dit que c’est l’authenticator du KRB_AP_REQ qui est en cause. La catégorie CWE-294 rend cette zone la plus probable, mais le rejeu peut aussi viser une autre structure du protocole ou une extension propre à Windows. Tant que Microsoft ou le chercheur n’ont rien publié, toute description plus détaillée de l’attaque serait de la spéculation.
Ce que nous savons suffit pour l’exploitation au quotidien: le côté vulnérable est celui qui reçoit et valide, donc chaque serveur qui accepte de l’authentification Kerberos, contrôleurs de domaine compris.
Ce qu’il faut vérifier
La première vérification est la plus simple: la mise à jour cumulative de septembre 2026 (ou une plus récente, puisqu’elles sont cumulatives) doit être installée sur l’ensemble du parc Windows, en commençant par les contrôleurs de domaine et les serveurs exposés à de nombreux comptes. Splashtop recommande de traiter les DC et les systèmes d’identité juste après les deux failles exploitées. Les numéros de KB et de build corrigés par version se trouvent dans le tableau de la fiche MSRC. Je ne les recopie pas ici: c’est cette source qu’il faut comparer à votre parc.
Pour relever le build de tous les contrôleurs de domaine d’un coup:
Get-ADDomainController -Filter * | ForEach-Object {
Invoke-Command -ComputerName $_.HostName -ScriptBlock {
$v = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"{0} {1} {2}.{3}" -f $env:COMPUTERNAME, $v.ProductName, $v.CurrentBuild, $v.UBR
}
}La valeur UBR (Update Build Revision) est celle qu’il faut comparer au tableau MSRC: un CurrentBuild identique ne garantit rien. Un Get-HotFix trié sur InstalledOn complète la lecture sur une machine isolée.
Attention aux systèmes hors support. Rapid7 classe plusieurs CVE Kerberos du mois dans le périmètre ESU (Extended Security Updates). Un Windows Server 2012 R2 sans licence ESU ne recevra pas les correctifs. Il faut alors l’isoler ou le retirer.
Côté journaux, nous ne connaissons pas la signature de l’attaque. Nous pouvons tout de même nous assurer que les traces liées au rejeu sont collectées. Windows enregistre l’événement 4649 (« A replay attack was detected ») dans le journal Sécurité, à condition que la sous-catégorie d’audit correspondante soit active:
auditpol /get /subcategory:"Other Logon/Logoff Events"
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4649} -MaxEvents 50 |
Select-Object TimeCreated, MachineName, MessageAttention: sur un système installé en français, le nom de la sous-catégorie est traduit (« Autres événements d’ouverture/fermeture de session »). Le plus sûr est de passer par son GUID ou par une GPO d’audit avancé.
Pour les erreurs Kerberos elles-mêmes, la clé LogLevel (DWORD à 1) sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters fait remonter les erreurs dans le journal Système. C’est bavard, à réserver à quelques serveurs et à une durée limitée. Une rafale de KRB_AP_ERR_REPEAT ou de KRB_AP_ERR_SKEW sur un même serveur n’est pas une preuve d’exploitation: un décalage d’horloge ou un client mal écrit en produisent aussi. C’est une anomalie à expliquer, et le même travail permet de repérer les applications qui retombent en NTLM sans que personne ne s’en aperçoive.
Reste le prérequis de l’avis: un compte authentifié suffit. Une machine du domaine qui n’a pas reçu le correctif peut donc être attaquée depuis n’importe quel poste compromis, et le tableau MSRC comparé aux valeurs UBR remontées ci dessus est le seul contrôle qui permet de l’exclure.
Rémi Vernier
Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.