Tout au long de l'histoire d'Active Directory, les cybercriminels n'ont cessé de trouver de nouveaux moyens d'exploiter les failles du protocole d'authentification Kerberos. Afin de réduire les risques liés au « kerberoasting », Microsoft va abandonner le chiffrement RC4 à compter d'avril 2026. Si vous n'avez pas encore identifié les applications de votre environnement susceptibles d'être affectées par ce changement, il est temps de placer cette tâche en tête de votre liste de priorités. Cet article explique la procédure à suivre et vous indique les ressources qui peuvent vous aider.
Pourquoi Microsoft abandonne-t-il le cryptage RC4 ?
Les tactiques, techniques et procédures (TTP) qui exploitent Kerberos peuvent être classées en trois catégories :
- Les attaques de type « roasting », telles que AS-REQ Roasting et Kerberoasting
- Abus de délégation, notamment la délégation Kerberos sans restriction et la délégation restreinte basée sur les ressources
- Abus liés aux tickets, notamment les tickets « Golden », « Silver », « Diamond », « Sapphire », « Bronze », « Pass-the-Ticket », etc.
Le « kerberoasting » est devenu l'une des techniques d'attaque les plus courantes. Ces dernières années, Microsoft a mis en place des mesures de défense contre les attaques de type « kerberoasting », et de nombreux articles ont été publiés sur ce sujet et sur les moyens de s'en prémunir. Nous n'aborderons pas en détail les mécanismes de cette attaque dans cet article, mais voici, en gros, comment elle fonctionne :
- Un attaquant demande un ticket de service pour un nom d'entité de service (SPN) valide.
- Le centre de distribution de clés Kerberos (KDC) émet le ticket de service en utilisant le chiffrement RC4, un algorithme moins sûr que l'AES-SHA1 (et donc plus facile à pirater).
- L'attaquant met ce ticket hors ligne et utilise une attaque par force brute pour récupérer le mot de passe du compte.
- L'attaquant utilise le compte compromis pour se déplacer latéralement et obtenir des privilèges supplémentaires.
En raison de l'exploitation courante de RC4 dans le cadre d'attaques de type « Kerberoasting », Microsoft a annoncé la dépréciation de ce mode de chiffrement, avec un suivi à partir de janvier 2026, une mise en application avec retour manuel en avril 2026 et une mise en application complète en juillet 2026.
Cependant, de nombreuses entreprises continuent de s'appuyer sur des applications internes ou tierces qui ne prennent pas en charge les types de chiffrement plus sécurisés, tels que l'AES-128 et l'AES-256. Si votre organisation fait partie de ce groupe, vous devrez identifier ces comptes d'application et configurer l'AES pour chacun d'entre eux.
Quelles applications utilisent RC4 ?
Alors, comment savoir quelles applications utilisent RC4 comme type de chiffrement Kerberos ?
Vous devrez surveiller le service d'authentification Kerberos et les opérations de ticket de service Kerberos afin de capturer les ID d'événement 4768 (événements du service d'authentification) et 4769 (opérations de ticket de service) dans le journal des événements de sécurité. (Microsoft a introduit les ID d'événement supplémentaires 201 à 209, également appelés « renforcement KDC », avec les correctifs de janvier 2026 dans le journal des événements système afin de soutenir davantage l'effort de mise hors service du RC4. Cependant, les événements 4768 et 4769 peuvent être considérés comme les événements « principaux », c'est pourquoi cet article se concentre sur le suivi de ces deux événements.)
Examinons ces événements.
ID d'événement 4768
La figure 1 présente un exemple de message généré par l'ID d'événement 4768.
Un ticket d'authentification Kerberos (TGT) a été demandé.
Informations sur le compte :
Nom du compte : jdoe
Nom du domaine fourni : CHILD
ID utilisateur : S-1-5-21-1873250772-3107742394-1596888999-1114
Types de chiffrement pris en charge par MSDS : 0x27 (DES, RC4, AES-Sk)
Clés disponibles : AES-SHA1, RC4
Informations sur le service :
Nom du service : krbtgt
ID du service : S-1-5-21-1873250772-3107742394-1596888999-502
Types de chiffrement pris en charge par MSDS : 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Clés disponibles : AES-SHA1, RC4
Informations sur le contrôleur de domaine :
Types de chiffrement pris en charge par MSDS : 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Clés disponibles : AES-SHA1, RC4
Informations réseau :
Adresse du client : ::ffff:10.1.1.250
Port du client : 53904
Types de connexion annoncés :
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
DES-CBC-MD5
Informations supplémentaires :
Options de ticket : 0x40810010
Code de résultat : 0x0
Type de chiffrement du ticket : 0x12
Type de chiffrement de session : 0x12
Type de pré-authentification : 2
Type de chiffrement de pré-authentification : 0x12
--Le reste a été supprimé par souci de concision.--
Figure 1. Exemple de message généré par l'ID d'événement 4768
Cet exemple contient plusieurs ensembles d'informations pertinentes.
Informations sur le compte
- Nom du compte. L'entité qui demande le Ticket Granting Ticket (TGT)
- Nom du domaine fourni. Le domaine dans lequel réside l'identité
- Identifiant utilisateur. Le nom descriptif (ou SID) de l'identité
- MSDS-SupportedEncryptionTypes. Les types de chiffrement que le compte peut utiliser
Informations sur le service
- Nom du service. L'entité de service demandée (dans ce cas, krbtgt)
- ID du service. Le nom descriptif (ou SID) de l'entité de service demandée
- MSDS-SupportedEncryptionTypes. Les types de chiffrement que le compte de service peut utiliser
Informations sur le contrôleur de domaine (DC)
- MSDS-SupportedEncryptionTypes. Les types de chiffrement pris en charge par le contrôleur de domaine
Informations complémentaires
- Options de ticket. 0x40810010 (transférable, renouvelable, canonique, renouvelable-ok), comme illustré à la figure 2.
- Type de chiffrement du ticket : 0x12 (AES256), comme le montre la figure 3.
- Type de chiffrement de session. 0x12 (AES256), comme le montre la figure 3.
- Type de chiffrement de pré-authentification : 0x12 (AES256), comme le montre la figure 4.
ID d'événement 4769
La figure 5 présente un exemple de message généré par l'ID d'événement 4769.
A Kerberos service ticket was requested.
Account Information:
Account Name: jdoe@CHILD.CONTOSO.COM
Account Domain: CHILD.CONTOSO.COM
Logon GUID: {5f752786-c7b3-fb33-0ce8-a54adeea22c3}
MSDS-SupportedEncryptionTypes: N/A
Available Keys: N/A
Service Information:
Service Name: CHILDMEMBER$
Service ID: S-1-5-21-1873250772-3107742394-1596888999-1105
MSDS-SupportedEncryptionTypes: 0x1C (RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Network Information:
Client Address: ::ffff:10.1.1.250
Client Port: 53905
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x12
Session Encryption Type: 0x12
Failure Code: 0x0
Transited Services: -
--Remainder snipped brevity--
Figure 5. Exemple de message généré par l'ID d'événement 4769
Cet exemple contient plusieurs ensembles d'informations pertinentes.
Informations sur le service
- Nom du service. Le SPN de la demande de ticket de service (dans ce cas, pour host/childmember.child.contoso.com), comme illustré à la figure 6.
sname-string : 2 éléments
SNameString : host
SNameString : childmember.child.contoso.com
Figure 6. Extrait d'une trace Wireshark montrant le SPN de la requête de ticket de service
- ID de service. Le nom descriptif (ou SID) de l'entité de sécurité qui a enregistré le SPN
- MSDS-SupportedEncryptionTypes. Les types de chiffrement que le compte de service peut utiliser
Informations sur DC
- MSDS-SupportedEncryptionTypes. Les types de chiffrement pris en charge par le contrôleur de domaine
Informations complémentaires
- Options de billets. 0x40810000
- Type de chiffrement du ticket. 0x12 (AES256)
- Type de chiffrement de session. 0x12 (AES256)
Lorsque l'on utilise RC4 pour le chiffrement, les résultats diffèrent légèrement de ceux des exemples précédents. La figure 7 présente la sortie de l'ID d'événement 4769 pour un ordinateur client qui utilise uniquement le chiffrement RC4.
A Kerberos service ticket was requested.
Account Information:
Account Name: jdoe@CHILD.CONTOSO.COM
Account Domain: CHILD.CONTOSO.COM
Logon GUID: {df8a66a8-8c1d-061e-b216-f935b45eb88a}
MSDS-SupportedEncryptionTypes: N/A
Available Keys: N/A
Service Information:
Service Name: CHILDMEMBER$
Service ID: CHILD\CHILDMEMBER$
MSDS-SupportedEncryptionTypes: 0x4 (RC4)
Available Keys: AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Network Information:
Client Address: ::ffff:10.1.1.250
Client Port: 51299
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x17
Session Encryption Type: 0x17
Failure Code: 0x0
Transited Services: -
--Remainder snipped for brevity--
Figure 7. Message généré pour l'ID d'événement 4769 sur un ordinateur client utilisant uniquement le protocole RC4
Les passages en gras mettent en évidence les principales différences entre cet exemple et les précédents. Examinons-les en détail.
Informations sur le service
- Nom du service : CHILDMEMBER$ (comme dans l'exemple précédent)
- ID du service. Le nom descriptif (ou SID) de l'entité de service faisant l'objet de la requête
- Types de chiffrement pris en charge par MSDS. 0x4 (RC4)
Informations complémentaires
- Options de billet. 0x40810000 (comme dans l'exemple précédent)
- Type de chiffrement du ticket. 0x17 (RC4-HMAC)
- Type de chiffrement de session. 0x17 (RC4-HMAC)
Comment vérifier si des applications utilisant RC4 sont présentes dans votre environnement
Comme le montre l'exemple précédent concernant RC4, pour détecter le chiffrement RC4 dans votre environnement, vous devez parcourir les journaux d'événements (de préférence les journaux SIEM) afin d'identifier les requêtes (AS-REQ) et les réponses (AS-REP) du service d'authentification, ainsi que les requêtes (TGS-REQ) et les réponses (TGS-REP) du service d'octroi de tickets, pour lesquelles les types de chiffrement de ticket et de session sont 0x17.
Pour vous aider dans cette tâche, nous avons créé des exemples de requêtes pour Microsoft Sentinel et Splunk. Vous pouvez utiliser ces exemples comme modèles pour auditer votre propre environnement.
Selon la manière dont vous avez configuré le transfert d'événements pour Sentinel, vous devrez interroger soit DeviceEvents, soit WindowsEvent. Par exemple, si vous utilisez le transfert d'événements Windows pour collecter les journaux d'événements et les transférer vers Sentinel, vous devrez interroger WindowsEvent et rechercher uniquement les occurrences des ID d'événement 4768 et 4769 qui correspondent à 0x17 dans le champ « Type de chiffrement du ticket » ou « Type de chiffrement de session ».
Vous pouvez utiliser la requête suivante pour effectuer une recherche dans Sentinel. Cette requête a été étendue afin d'inclure d'autres colonnes de données.
WindowsEvent
| où EventID est dans ('4768', '4769')
| où TimeGenerated est compris entre (ago(60d) .. now())
| définir EventDataJson = parse_json(EventData)
| définir TargetUserName = EventDataJson.TargetUserName
| définir TargetDomainName = EventDataJson.TargetDomainName
| extend IpAddress = EventDataJson.IpAddress
| extend ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys
| extend ServiceName = EventDataJson.ServiceName
| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
| extend TicketEncryption = EventDataJson.TicketEncryptionType
| extend TicketOptions = EventDataJson.TicketOptions
| where SessionKeyEncryption == '0x17' or
TicketEncryption == '0x17'
| project TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson
Voici un bref aperçu de la requête :
WindowsEvent
Comment la requête est stockée dans cette implémentation de Sentinel (il peut s'agir de DeviceEvents dans votre environnement, comme décrit précédemment)
| where EventID in ('4768', '4769')
Recherches des identifiants d'événement 4768 et 4769
| where TimeGenerated between (ago(60d) .. now())
Remonte à 60 jours (vous pouvez définir la durée de votre choix)
| extend EventDataJson = parse_json(EventData)
Mise en forme de la colonne EventData au format JSON et analyse du JSON en vue de son utilisation dans le reste de la requête
| extend TargetUserName = EventDataJson.TargetUserName
Indique l'identité qui demande le ticket
| extend TargetDomainName = EventDataJson.TargetDomainName
Indique le domaine auquel appartient l'identité à l'origine de la requête
| extend IpAddress = EventDataJson.IpAddress
Affiche l'adresse IP du client, si celle-ci est indiquée dans l'événement
| extend ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys
Indique les clés de chiffrement disponibles pour le service
| extend ServiceName = EventDataJson.ServiceName
Indique le nom de service (SPN) pour lequel la demande de ticket est effectuée
| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
Spécifie le type de chiffrement de la clé de session que le client (demandeur) utilisera pour interagir avec le détenteur du ticket
| extend TicketEncryption = EventDataJson.TicketEncryptionType
Spécifie le type de chiffrement du TGT ou du ticket de service
| extend TicketOptions = EventDataJson.TicketOptions
Fournit des informations supplémentaires sur les types de tickets concernés par la demande, ce qui peut s'avérer utile pour identifier certains types de tickets, tels que les tickets de transfert, de délégation, de redirection, de procuration, etc.
| where SessionKeyEncryption == '0x17' or
TicketEncryption == '0x17'
Recherche soit un chiffrement de clé de session, soit un chiffrement de ticket utilisant l'algorithme RC4-HMAC (0x17)
| project TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson
Indique les champs à afficher dans les résultats
La figure 8 présente un exemple des résultats de cette requête.
Pour Splunk, cette même requête se présenterait comme suit :
index="wineventlog" LogName="Security" EventCode IN ("4768", "4769") earliest=-60d@d latest=now
| search Session_Encryption_Type="0x17" or Ticket_Encryption_Type="0x17"
| table _time EventCode Account_Name Account_Domain Client_Address service_name Ticket_Encryption_Type Session_Encryption_Type Ticket_Options, _raw
Avant d'utiliser ces requêtes dans votre environnement, assurez-vous que l'audit des tickets de service est activé. Si cette fonctionnalité n'est pas activée, les contrôleurs de domaine ne généreront pas les événements correspondants (ID d'événement 4768 et 4769, ainsi que les ID d'événement 201 à 209, qui concernent le renforcement de la sécurité du KDC).
La meilleure façon d'activer l'audit des tickets de service consiste soit à mettre à jour une stratégie de groupe existante, soit à en ajouter une qui soit attribuée à l'unité d'organisation (OU) de votre contrôleur de domaine (DC). Vous devez effectuer cette opération pour chaque domaine de votre forêt AD. Le chemin d'accès aux paramètres concernés est le suivant : Configuration de l'ordinateur > Paramètres Windows > Paramètres de sécurité > Configuration avancée de la stratégie d'audit > Stratégies d'audit > Connexion au compte. Activez les sous-catégories Auditer le service d'authentification Kerberos et Auditer les opérations de ticket de service Kerberos pour les succès et les échecs ( Figure 9).
Si vous n'avez jamais configuré de stratégie d'audit avancée dans vos domaines, veillez également à activer la stratégie « Audit : forcer les paramètres de la sous-catégorie de stratégie d'audit (Windows Vista ou version ultérieure) pour remplacer les paramètres de la catégorie de stratégie d'audit » dans Configuration de l'ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité. Cette stratégie est généralement définie dans la même stratégie de groupe que l'audit des tickets de service.
Remarque : si vous ne constatez aucun événement de ticket de service 4769 dans les journaux d'événements de sécurité de vos contrôleurs de domaine, vous ne verrez pas non plus d'avertissements relatifs au renforcement de la sécurité du KDC (201–209) dans le journal Système.
Conseil de validation : forcez temporairement un périphérique à ne prendre en charge que le protocole RC4, puis demandez un ticket de service à partir d'un compte dont le paramètre `msDS-SupportedEncryptionTypes` ne contient aucune valeur. Si l'audit est correctement configuré, vous devriez voir s'afficher les avertissements correspondants. Pour plus d'informations, consultez l'article Microsoft Learn intitulé «Détecter et corriger l'utilisation du protocole RC4 dans Kerberos ».
Une fois que vous avez vérifié que l'audit Kerberos fonctionne correctement, le vrai travail commence : analyser les événements reçus et prendre les mesures correctives nécessaires pour les comptes ou les systèmes concernés.
La principale difficulté liée à la suppression du RC4 provient des anciens comptes de service dont les mots de passe n'ont pas été modifiés depuis de nombreuses années. Étant donné que le RC4 dans Active Directory est lié au hachage NT, tout compte dont le mot de passe n'a jamais été réinitialisé après l'introduction de l'AES (c'est-à-dire après la sortie de Windows Server 2008 et de Windows Vista) pourrait encore disposer uniquement de clés compatibles avec le RC4.
La seule solution consiste à réinitialiser deux fois le mot de passe du compte de service, ce qui oblige Active Directory à générer les clés AES nécessaires. Cependant, vous devrez également savoir où ce compte de service est utilisé dans votre environnement ; par exemple, pour démarrer le service concerné sur un serveur membre spécifique ou pour exécuter une tâche planifiée.
Si vous constatez des avertissements relatifs au renforcement de la sécurité du KDC (événements 201 à 209 dans le journal système) à côté des événements 4768 ou 4769, cet article publié sur LinkedIn par Jerry Devore de Microsoft offre un excellent aperçu de la manière de corriger les comptes et les systèmes concernés, où msds-SET = msDS-SupportedEncryptionTypes (tableau 1).
| Paire d'événements | Ce que cela signifie | Cause principale | Solution rapide |
|---|---|---|---|
| 201/203 | Client RC4 uniquement + msds-SET vide | Appareil hérité ou keytab | Activer l'AES sur le client OU définir msds-SET sur 28 |
| 202/204 | Le compte ne dispose pas de clé AES + msds-SET vide | Ancien mot de passe | Réinitialiser le mot de passe du compte (deux fois) |
| 205 | Types d'encodage pris en charge par défaut actuellement utilisés | Remplacement du registre présent | Supprimer la dérogation si possible |
| 206/208 | Client RC4 uniquement + msds-SET AES uniquement | Incompatibilité entre clients | Ajouter RC4 à msds-SET (valeur 28) |
| 207/209 | Le compte ne dispose pas de clé AES + AES msds-SET | Le mot de passe n'a pas été réinitialisé | Réinitialiser le mot de passe du compte (deux fois) |
En résumé, pour les administrateurs informatiques
- Vérifiez dès maintenant si certains comptes et appareils sont encore liés à RC4.
- Mettez à jour les comptes de service pour les rendre compatibles avec l'AES avant la mise en œuvre complète de cette norme ou l'abandon du RC4.
- Supprimer ou mettre à niveau les systèmes existants qui ne prennent pas en charge l'AES.
- Utilisez les journaux d'événements de manière proactive pour détecter les appareils défaillants avant qu'ils ne tombent en panne — ce qui arrivera inévitablement après l'application des mises à jour de juillet 2026.
Vous avez besoin d'aide ?
La dépréciation de RC4 constitue une avancée positive dans la lutte contre le « kerberoasting », mais elle nécessite une réaction rapide. Si vous avez des questions à ce sujet ou si vous avez besoin d'aide pour faire évoluer les comptes de vos applications, nous sommes là pour vous aider.
