Pourquoi RC4 devient un risque opérationnel en 2026

RC4 n’est plus seulement un algorithme vieillissant à retirer un jour. Les mises à jour Windows publiées depuis le 13 janvier 2026 ont introduit les protections liées à CVE-2026-20833, une vulnérabilité permettant de demander des tickets de service avec un chiffrement faible afin de tenter de récupérer hors ligne le mot de passe d’un compte de service.

Depuis le 14 avril 2026, les contrôleurs de domaine mis à jour utilisent par défaut AES-SHA1, soit AES128_HMAC_SHA1 et AES256_HMAC_SHA1, lorsqu’aucune configuration explicite n’est définie. Les mises à jour de juillet 2026 ont ensuite activé la phase d’application et retiré le mécanisme temporaire de retour arrière RC4DefaultDisablementPhase. Un environnement qui dépend encore implicitement de RC4 peut donc subir des échecs d’authentification après la mise à jour de ses contrôleurs de domaine.

Comprendre ce que le KDC choisit réellement

Le type de chiffrement d’un ticket dépend des clés disponibles pour le compte cible, des types annoncés par le client, de l’attribut Active Directory msDS-SupportedEncryptionTypes et des valeurs par défaut du KDC. Une valeur vide ne signifie pas toujours que le compte est prêt pour AES : le KDC doit aussi disposer de clés AES dérivées du mot de passe du compte.

RC4 correspond au bit 0x4. AES128 correspond à 0x8 et AES256 à 0x10. Une configuration AES128 et AES256 utilise donc la valeur 0x18, soit 24 en décimal. La valeur 0x1C, soit 28, conserve RC4 en plus des deux variantes AES et ne constitue qu’une transition temporaire.

Valeur	Types permis	Usage recommandé
0x4 / 4	RC4 seulement	À éliminer
0x18 / 24	AES128 + AES256	Cible recommandée
0x1C / 28	RC4 + AES128 + AES256	Compatibilité temporaire documentée
Non défini	Valeur par défaut du KDC	À analyser avant de conclure

Étape 1 — Mettre à jour et centraliser les journaux

Tous les contrôleurs de domaine doivent recevoir les mises à jour Windows applicables. Sur Windows Server 2019 et les versions ultérieures, les événements de sécurité 4768 et 4769 exposent les types de chiffrement utilisés pour les tickets TGT et TGS. Windows Server 2016 reçoit ces champs avec les mises à jour cumulatives prises en charge depuis janvier 2025.

Centralisez ces événements dans Microsoft Sentinel, Wazuh, un SIEM ou Windows Event Forwarding. Un échantillon de quelques jours peut manquer des tâches mensuelles, des traitements de paie, des sauvegardes ou des applications rarement utilisées; conservez idéalement plusieurs semaines de données représentatives.

4768 : demande d’un ticket d’authentification TGT.
4769 : demande d’un ticket de service TGS.
Ticket Encryption Type 0x17 : RC4-HMAC.
Ticket Encryption Type 0x11 : AES128-CTS-HMAC-SHA1-96.
Ticket Encryption Type 0x12 : AES256-CTS-HMAC-SHA1-96.

Étape 2 — Surveiller les nouveaux événements Kdcsvc

Les mises à jour 2026 ajoutent neuf événements Kdcsvc, de 201 à 209, dans le journal Système des contrôleurs de domaine. Ils identifient notamment un client qui annonce seulement RC4, un compte de service dépourvu de clés AES ou une valeur DefaultDomainSupportedEncTypes qui permet explicitement un chiffrement non sécurisé.

Les événements 201 et 202 étaient des avertissements pendant la phase d’audit. En mode d’application, les scénarios correspondants produisent notamment les événements 203 et 204 lorsque le KDC bloque le chiffrement. L’événement 205 indique une configuration explicite non sécurisée du chiffrement par défaut du domaine.

Rechercher les événements Kdcsvc récents sur un contrôleur de domaine

$start = (Get-Date).AddDays(-30)
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
    Id           = 201,202,203,204,205,206,207,208,209
    StartTime    = $start
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

Étape 3 — Utiliser les scripts d’audit Microsoft

Microsoft publie les scripts List-AccountKeys.ps1 et Get-KerbEncryptionUsage.ps1 dans le dépôt Kerberos-Crypto. Le premier inventorie les clés disponibles pour les comptes observés dans les événements; le second synthétise les types de chiffrement réellement utilisés.

Exécutez-les depuis un poste d’administration protégé avec le module ActiveDirectory. Analysez séparément le ticket et la clé de session : une application peut recevoir un ticket AES tout en révélant une dépendance RC4 ailleurs dans le flux.

Afficher uniquement l’utilisation de RC4

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Étape 4 — Inventorier les comptes avec SPN

Les comptes utilisateurs possédant un SPN sont des cibles importantes, car ils représentent souvent des services historiques avec des mots de passe anciens ou gérés manuellement. Un compte créé avant la prise en charge AES, dont le mot de passe n’a jamais été renouvelé depuis, peut ne pas disposer des clés AES nécessaires.

Le rapport suivant sert de point de départ. Une valeur vide doit être corrélée avec les événements et les clés disponibles; elle ne doit pas être remplacée massivement sans validation.

Inventaire des comptes de service utilisateurs

Get-ADUser -LDAPFilter '(&(objectCategory=person)(servicePrincipalName=*))' `
  -Properties ServicePrincipalName,msDS-SupportedEncryptionTypes,PasswordLastSet |
  Select-Object SamAccountName,PasswordLastSet,`
    @{Name='EncryptionTypes';Expression={$_.'msDS-SupportedEncryptionTypes'}},`
    ServicePrincipalName |
  Sort-Object PasswordLastSet

Inventaire des comptes ordinateurs sans configuration explicite

Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes,OperatingSystem |
  Where-Object { $null -eq $_.'msDS-SupportedEncryptionTypes' } |
  Select-Object Name,OperatingSystem,DistinguishedName

Étape 5 — Générer des clés AES avant de modifier les bits

Déclarer qu’un compte accepte AES ne crée pas ses clés. Pour un compte de service utilisateur ancien, planifiez d’abord une rotation du mot de passe avec le propriétaire de l’application. Redémarrez ensuite le service ou actualisez ses identifiants enregistrés. Les gMSA simplifient cette étape grâce à la rotation automatique du secret lorsque l’application les prend en charge.

Une fois les clés AES présentes et l’application validée, l’attribut peut être fixé à 24 pour AES128 et AES256. Cette modification doit rester ciblée et documentée; ne lancez pas une réécriture globale de l’annuaire.

Vérifier puis configurer un compte de service validé

$account = Get-ADUser 'svc-application' -Properties msDS-SupportedEncryptionTypes,PasswordLastSet
$account | Select-Object SamAccountName,PasswordLastSet,msDS-SupportedEncryptionTypes

# Après rotation du mot de passe et validation applicative
Set-ADUser 'svc-application' -Replace @{'msDS-SupportedEncryptionTypes' = 24}

Étape 6 — Déployer AES avec une GPO pilote

Dans Group Policy Management, créez une GPO pilote et ouvrez Configuration ordinateur, Stratégies, Paramètres Windows, Paramètres de sécurité, Stratégies locales, Options de sécurité. Configurez Network security: Configure encryption types allowed for Kerberos avec AES128_HMAC_SHA1 et AES256_HMAC_SHA1.

Appliquez d’abord la GPO à des postes, serveurs et comptes de service représentatifs. Redémarrez les appareils ciblés, car Windows met à jour msDS-SupportedEncryptionTypes au démarrage. Surveillez ensuite les événements Kerberos et les incidents applicatifs avant d’élargir l’anneau.

Anneau 0 : postes TI et laboratoire.
Anneau 1 : serveurs applicatifs non critiques et clients pilotes.
Anneau 2 : applications métier, fichiers, sauvegardes et tâches planifiées.
Anneau 3 : services critiques après validation des propriétaires.

Tester les services qui cassent le plus souvent

L’absence d’événements Kdcsvc ne garantit pas la compatibilité de tous les équipements non Windows. Testez explicitement les NAS, appliances, applications Java, équipements réseau, tâches planifiées, sauvegardes, relations d’approbation, clusters et services qui utilisent des comptes avec SPN.

FSLogix avec des profils sur stockage SMB et Azure Files avec authentification AD DS méritent une attention particulière. Microsoft indique que des objets ou comptes dont les types de chiffrement sont RC4 seulement ou non définis peuvent perdre l’accès après le durcissement. Les partages Azure Files plus anciens doivent être validés et, lorsque nécessaire, reconfigurés pour AES-256.

Ouverture et fermeture d’une session FSLogix complète.
Accès SMB avec le nom DNS réellement utilisé en production.
WinRM, WMI et PowerShell Remoting.
Démarrage de services et tâches avec comptes dédiés.
Restauration de sauvegarde et accès aux dépôts.
Authentification des appliances Linux, NAS et systèmes médicaux ou industriels.

Diagnostiquer un échec après le retrait de RC4

Une erreur 0x80090342 ou KDC_ERR_ETYPE_NOTSUPP indique qu’aucun type de chiffrement compatible n’a pu être négocié. Demandez directement un ticket pour le SPN concerné avec klist, puis corrélez l’heure, le client et le service avec l’événement 4769 sur le contrôleur de domaine.

Demander un ticket pour le service à tester

klist purge
klist get HOST/serveur.contoso.com
klist tickets

Vérifier la configuration de l’objet cible

$name = 'SERVEUR'
Get-ADObject -Filter "Name -eq '$name' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')" `
  -Properties msDS-SupportedEncryptionTypes |
  Format-List DistinguishedName,Name,ObjectClass,msDS-SupportedEncryptionTypes

Gérer une exception RC4 sans annuler tout le durcissement

Depuis les mises à jour de juillet 2026, RC4DefaultDisablementPhase n’est plus un mécanisme de retour arrière durable. Si un service indispensable ne peut pas encore utiliser AES, Microsoft recommande d’activer RC4 explicitement dans le masque msDS-SupportedEncryptionTypes uniquement sur le compte de service concerné.

Cette exception doit avoir un propriétaire, une justification, une date d’expiration et un plan de remplacement. Utiliser une valeur globale autorisant RC4 sur tous les comptes recrée une surface de Kerberoasting et masque les dépendances restantes.

Décision	Portée	Risque
AES 0x18	Compte ou appareil validé	Cible sécurisée
Transition 0x1C	Service précis et temporaire	RC4 reste exploitable
RC4 autorisé globalement	Domaine ou large GPO	À éviter

Plan de changement recommandé

Inventorier les contrôleurs de domaine et confirmer leur niveau de mise à jour.
Centraliser les événements 4768, 4769 et Kdcsvc 201 à 209.
Mesurer RC4 pendant un cycle métier représentatif.
Associer chaque dépendance à une application et à un propriétaire.
Faire tourner les mots de passe des comptes dépourvus de clés AES.
Valider AES dans un anneau pilote, puis par groupes d’applications.
Conserver des exceptions RC4 ciblées, temporaires et révisées.
Surveiller KDC_ERR_ETYPE_NOTSUPP, les incidents SMB et les échecs WinRM après chaque vague.

Conclusion et références

Le passage de RC4 à AES est à la fois un projet de sécurité et de continuité opérationnelle. La bonne séquence n’est pas de cocher AES partout en une journée : il faut observer les tickets réellement émis, générer les clés manquantes, corriger les applications et restreindre progressivement les algorithmes permis.

En août 2026, l’enjeu n’est plus de préparer un changement lointain. Les contrôleurs de domaine à jour se trouvent dans la phase d’application prévue par Microsoft. Les dépendances restantes doivent être identifiées et traitées avant qu’une prochaine maintenance ne transforme une faiblesse silencieuse en panne visible.

À propos de l’auteur

Marc-Antoine Lambert

Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.

Discuter de votre environnement →