CVE-2026-69676 Kerberos : exécution de code à distance et correctifs

Qu'est-ce que CVE-2026-69676, l'exécution de code à distance dans Kerberos ?

CVE-2026-69676 Kerberos : exécution de code à distance, touche Windows Kerberos et justifie une vérification rapide des correctifs. Microsoft la classe comme critique : un attaquant authentifié disposant d'un accès de faible niveau à un serveur affecté peut soumettre une requête spécialement conçue qui exécute du code sur ce serveur, sans interaction de l'utilisateur. L'avis ne présente pas l'accès administrateur comme un prérequis.

Le CVRF MSRC de septembre 2026, lu au format JSON le 3 octobre 2026, consigne ces valeurs exactes pour cette CVE :

La révision de l'avis individuel est 1.0, datée du 8 septembre 2026. Il s'agit d'une mise à jour de sécurité de septembre examinée en octobre. La CVE était absente du catalogue CISA Known Exploited Vulnerabilities le 3 octobre 2026, dans la version récupérée du catalogue 2026.10.02. Cette observation et l'évaluation de l'exploitation par Microsoft constituent des éléments distincts ; aucun ne permet d'établir qu'une exploitation n'a pas pu se produire ailleurs.

Fonctionnement : capture et rejeu avec de faibles privilèges

Microsoft identifie un contournement de l'authentification impliquant la capture et le rejeu. Sa description situe l'exécution de code résultante sur le réseau, tandis que la FAQ précise que l'attaquant est authentifié et dispose d'un accès de faible niveau au serveur affecté. Sur le plan opérationnel, on ne peut donc pas différer l'application du correctif au seul motif que les comptes ordinaires n'ont pas de droits administrateur.

Le CVRF public n'explique ni quel message est capturé, ni comment il est rejoué, ni le chemin de traitement vulnérable exact. Il ne précise pas non plus l'identité sous laquelle le code résultant s'exécute. Décrire une séquence de paquets détaillée, une commande d'exploitation ou une compromission automatique du domaine dépasserait ces éléments.

La chaîne d'attaque confirmée par l'avis

1. L'attaquant dispose d'un accès authentifié de faible niveau à un serveur affecté.
2. L'attaquant envoie une requête spécialement conçue sur le réseau.
3. Du code s'exécute sur ce serveur sans qu'un utilisateur ait à intervenir.

Ce sont les limites documentées du scénario, pas une preuve de concept. Le prérequis de faibles privilèges rend les identités ordinaires compromises pertinentes pour la priorisation, mais l'avis ne dit pas que chaque compte de domaine peut exploiter chaque serveur.

Détection : collecter le contexte Kerberos, puis enquêter

La documentation des événements de Microsoft fournit une visibilité Kerberos utile sur les contrôleurs de domaine. Ces événements peuvent étayer une investigation, mais aucun n'est documenté ici comme une signature fiable d'exploitation de CVE-2026-69676.

Activez et collectez de manière centralisée les sous-catégories d'audit Kerberos Authentication Service et Kerberos Service Ticket Operations. Validez la couverture des réussites et des échecs lorsqu'elle s'applique. Le guide publié de supervision Active Directory explique pourquoi la stratégie d'audit, la transmission, la préservation des champs et les références d'activité normale doivent fonctionner ensemble pour qu'une requête SIEM apporte une couverture utile.

Point de départ KQL pour le triage

Cette requête rédigée par un analyste utilise la table SecurityEvent documentée et ses colonnes typées. Dans cette table, EventData est une chaîne de caractères ; la requête n'y accède donc pas comme à un objet dynamique. Elle regroupe l'activité pour examen ; la fenêtre de 24 heures et les intervalles de 15 minutes sont des choix d'investigation, pas des seuils d'exploitation.

SecurityEvent
| where TimeGenerated > ago(24h)
| where Channel == "Security"
| where EventSourceName == "Microsoft-Windows-Security-Auditing"
| where EventID in (4768, 4769, 4771)
| extend Account = TargetUserName,
         ClientIP = IpAddress,
         Service = ServiceName
| summarize Events = count(), Services = make_set(Service, 20)
    by bin(TimeGenerated, 15m), Computer, EventID, Account, ClientIP, Status
| order by Events desc

Confirmez que votre connecteur collecte ces identifiants d'événement dans SecurityEvent et renseigne TargetUserName, IpAddress, ServiceName et Status pour chaque type d'événement. Comparez des lignes d'exemple avec le XML de l'événement original ; les champs manquants imposent de revoir le parseur avant que les résultats regroupés soient utiles. N'interprétez pas des valeurs manquantes ou un résultat vide comme la preuve qu'aucune exploitation n'a eu lieu. Cette requête n'a pas été exécutée sur la télémétrie de clients.

Comparez les combinaisons inhabituelles de compte, client et service ainsi que les pics d'activité aux activités normales, aux fenêtres de changement et aux éléments des terminaux sur le serveur affecté. Les événements de tickets du contrôleur de domaine ne constituent pas un relevé complet de ce qui s'exécute sur un serveur membre. Préservez la télémétrie de l'hôte lorsqu'une activité suspecte coïncide avec un actif non corrigé.

Le guide distinct du repli Kerberos vers RC4 explique comment distinguer les éléments relatifs au chiffrement des tickets de la configuration des comptes et corriger les dépendances AES en toute sécurité. L'activité RC4 fournit du contexte ; le passage à AES n'est pas établi comme un correctif de cette CVE.

Remédiation : vérifier la bonne mise à jour pour chaque produit

1. Associer chaque actif à son produit CVRF

Lisez les entrées de produit affecté et de remédiation correspondant à la version Windows et au type d'installation de l'actif. L'entrée inclut des clients Windows ainsi que des produits serveur ; une revue AD ne doit donc pas supposer que seuls les contrôleurs de domaine comptent.

Pour Windows Server 2025, le CVRF associe ProductID 12436, et Server Core ProductID 12437, à KB5122871, avec FixedBuild 10.0.26100.33438 et RestartRequired Yes. La page de mise à jour Microsoft Support confirme la publication du 8 septembre et le build du système d'exploitation 26100.33438. Utilisez cet exemple propre à une version, et non comme une KB à appliquer à chaque version de Windows. La même page Support documente une régression Remote Desktop Services après la mise à jour de septembre et indique qu'elle est résolue dans les mises à jour publiées à partir du 14 septembre 2026. Examinez les problèmes connus actuels et les mises à jour applicables qui la remplacent avant le déploiement.

2. Recueillir les preuves d'installation

Sur un actif Windows Server 2025, adaptez la recherche par identifiant documentée de Get-HotFix à la KB confirmée ci-dessus :

Get-HotFix -Id KB5122871

Pour obtenir des éléments de version supplémentaires, cette commande est citée directement depuis la documentation Get-ComputerInfo :

Get-ComputerInfo -Property "*version"

Ces commandes sont des exemples issus de la documentation, pas des mesures de vos serveurs. Get-HotFix interroge Win32_QuickFixEngineering ; conservez également les relevés de maintenance et les éléments complets du build du système d'exploitation. Si la KB d'origine est absente, vérifiez si une mise à jour cumulative installée la remplace et inclut le correctif. Ne déclarez pas un actif vulnérable ou corrigé à partir de la seule absence de résultat d'une recherche de KB.

3. Installer, redémarrer et vérifier à nouveau

Déployez la mise à jour de sécurité applicable, ou une mise à jour qui la remplace dont la couverture est vérifiée, via votre processus de maintenance pris en charge. Effectuez le redémarrage requis, consignez le build en cours d'exécution et validez les applications dépendantes de Kerberos. Suivez les exceptions avec un responsable et une date de remédiation. Tant qu'une exception subsiste, restreignez les accès inutiles au serveur affecté et surveillez les activités suspectes ; ces mesures ne remplacent pas le correctif.

Comment EtcSec détecte ce problème

Aucun contrôle EtcSec direct pour CVE-2026-69676 n'a été vérifié pour cet article. N'utilisez pas un résultat de posture etc-collector seul comme preuve de l'état des correctifs ou d'une exploitation.

Utilisez les preuves de correctif et le processus d'investigation Kerberos ci-dessus pour évaluer ce problème. Consignez séparément les constats de posture, les preuves de mises à jour installées et les observations d'incident. Un audit de configuration sans anomalie ne peut pas, à lui seul, établir que ce défaut de code Windows a été corrigé.