Event ID 4769 : lire l'événement et détecter le Kerberoasting

L'event ID 4769 (« A Kerberos service ticket was requested ») est l'événement de sécurité qu'un contrôleur de domaine Windows écrit chaque fois que son centre de distribution de clés, le KDC, reçoit une demande de ticket de service Kerberos. Il indique qui demande l'accès, à quel compte de service, depuis quelle adresse IP, avec quel algorithme de chiffrement et avec quel résultat. C'est la trace de référence pour repérer le Kerberoasting, une technique qui consiste à demander des tickets de service afin de casser hors ligne le mot de passe des comptes qui les protègent. En 2026, sa lecture a changé : Microsoft a enrichi l'événement de nouveaux champs en 2025, puis a retiré le RC4 comme chiffrement implicite des contrôleurs de domaine entre avril et juillet 2026. Ce guide détaille les champs utiles, la grille de lecture des codes, des requêtes SIEM prêtes à adapter et un playbook de triage. Il prolonge notre dossier de référence sur le Kerberoasting, de l'attaque à la défense.

Qu'est-ce que l'event ID 4769 dans Active Directory ?

Dans un domaine Active Directory, l'authentification Kerberos se déroule en trois échanges. Le client obtient d'abord un ticket d'authentification initial, le TGT (Ticket Granting Ticket), auprès du KDC. Il échange ensuite ce TGT contre un ticket de service propre à la ressource visée. Il présente enfin ce ticket au serveur qui héberge le service. Chaque étape laisse une trace différente, et l'événement 4769 correspond exactement à la deuxième.

Le ticket de service dans l'échange Kerberos

Lorsqu'un utilisateur ouvre un partage réseau, se connecte à une base SQL Server ou accède à un intranet en authentification intégrée, son poste envoie au KDC une requête TGS-REQ. Celle-ci contient le TGT et le SPN (Service Principal Name), l'identifiant unique de l'instance de service visée. Le KDC retrouve le compte qui porte ce SPN, puis renvoie un ticket chiffré avec une clé dérivée du mot de passe de ce compte.

Le TGT initial est tracé par l'événement 4768 sur le contrôleur de domaine, et l'ouverture de session sur le serveur cible par l'événement 4624 sur ce serveur. Entre les deux, le 4769 est le seul moment où le contrôleur de domaine voit passer la demande d'accès à un service précis. C'est ce qui en fait une source de détection irremplaçable : le cassage d'un ticket se déroule ensuite hors ligne, sans aucune trace sur le réseau de l'entreprise.

Où l'événement 4769 est-il journalisé ?

D'après la documentation Microsoft de l'événement 4769, celui-ci est généré uniquement sur les contrôleurs de domaine, jamais sur le poste client ni sur le serveur cible. Chaque contrôleur ne trace que les demandes qu'il a lui-même traitées. Pour obtenir une vision complète d'un domaine, il faut donc collecter le journal Sécurité de tous les contrôleurs, y compris ceux des sites distants et les contrôleurs en lecture seule.

Le même identifiant couvre les succès et les échecs. Un succès porte un code d'échec 0x0 ; un échec affiche un code différent et un type de chiffrement 0xFFFFFFFF. La sous-catégorie d'audit concernée liste aussi l'événement 4770, émis lors du renouvellement d'un ticket de service, et l'événement 4773 pour les demandes en échec. Pour la détection du Kerberoasting, c'est toutefois le 4769 en succès qui concentre l'essentiel de la valeur.

Activer et collecter l'audit des tickets de service Kerberos

L'événement 4769 dépend de la sous-catégorie Audit Kerberos Service Ticket Operations, nommée « Auditer les opérations de ticket du service Kerberos » dans une console en français. Elle appartient à la catégorie Connexion de compte. Microsoft recommande d'y activer à la fois les succès et les échecs sur les contrôleurs de domaine, et précise que cette sous-catégorie n'a d'intérêt que sur eux : sur un serveur membre ou un poste de travail, elle ne produit rien d'utile.

La méthode la plus robuste consiste à la configurer dans une stratégie de groupe (GPO) liée à l'unité d'organisation Domain Controllers : Configuration ordinateur, Stratégies, Paramètres Windows, Paramètres de sécurité, Configuration avancée de la stratégie d'audit, Stratégies d'audit, Connexion de compte. Activez aussi l'option de sécurité qui force les paramètres de sous-catégorie à remplacer ceux des catégories héritées, faute de quoi une ancienne stratégie d'audit simple peut écraser votre réglage.

:: Vérifier l'état de la sous-catégorie, par son GUID pour éviter les écarts de langue
auditpol /get /subcategory:{0CCE9240-69AE-11D9-BED3-505054503030}

:: Activer succès et échec en local (le réglage durable doit venir de la GPO)
auditpol /set /subcategory:{0CCE9240-69AE-11D9-BED3-505054503030} /success:enable /failure:enable

:: Contrôler la stratégie effectivement appliquée sur le contrôleur
auditpol /get /category:*

Dimensionner la collecte des événements 4769

Microsoft qualifie le volume de la sous-catégorie d'audit des tickets de service de très élevé sur les KDC (Key Distribution Center), puisque chaque accès à un partage, à une base ou à une application authentifiée génère un événement. Avant d'activer la collecte, augmentez la taille du journal Sécurité des contrôleurs pour couvrir plusieurs jours d'activité, puis acheminez les événements vers un collecteur par Windows Event Forwarding ou par l'agent de votre SIEM (Security Information and Event Management). Un déploiement Wazuh comme SIEM/XDR ou une pile équivalente fera l'affaire.

Anatomie de l'événement 4769 : les champs qui comptent

Qu'on le désigne comme event ID 4769, « 4769 event id » ou événement de sécurité 4769, l'enregistrement se présente sous deux formes : le texte affiché dans l'Observateur d'événements et la structure XML exploitée par les SIEM. Les noms diffèrent parfois, ce qui explique bien des requêtes qui ne renvoient rien. Le tableau ci-dessous fait la correspondance entre les deux et indique, pour chaque champ, l'usage qu'en fait un analyste de SOC (Security Operations Center).

Deux pièges reviennent souvent. Le champ Account Name ressemble à un UPN (User Principal Name) mais n'est pas l'attribut UserPrincipalName : c'est un nom normalisé, construit à partir du SamAccountName et du nom de domaine. Le champ Service Name, lui, contient en cas de succès le nom du compte qui détient le SPN, par exemple svc_sql, et non le SPN complet. Une règle qui cherche « MSSQLSvc/ » dans ce champ manquera donc la plupart des tickets réussis.

Les champs ajoutés depuis janvier 2025

Microsoft indique que Windows Server 2016 et les versions ultérieures affichent une version enrichie de l'événement après la mise à jour cumulative de sécurité du 14 janvier 2025. Cette version ajoute, pour le compte demandeur, le service et le contrôleur, les valeurs de msDS-SupportedEncryptionTypes et la liste des clés disponibles, ainsi que les types de chiffrement annoncés par le client, le chiffrement de la clé de session et des empreintes des tickets de requête et de réponse.

Ces champs servent surtout à diagnostiquer les dépendances au RC4. Un compte dont les clés disponibles ne contiennent que RC4 n'a jamais reçu de clés AES, en général parce que son mot de passe n'a pas été changé depuis l'introduction d'AES dans le domaine ; une réinitialisation les génère. Attention à la lecture : jusqu'à Windows Server 2022, la valeur affichée pour msDS-SupportedEncryptionTypes inclut toujours DES et RC4 par compatibilité, alors que Windows Server 2025 n'affiche que AES et plus fort.

Les empreintes Request Ticket Hash et Response Ticket Hash ouvrent une piste de corrélation entre le TGT présenté au contrôleur et le ticket de service renvoyé. Leur exploitation en détection reste récente et peu documentée : validez leur comportement dans votre environnement avant d'en faire une règle de production.

Ticket Encryption Type : lire le chiffrement du ticket

Le champ Ticket Encryption Type indique l'algorithme avec lequel le contrôleur de domaine a chiffré le ticket de service délivré. C'est le champ le plus consulté de l'événement 4769, car il permet de trier en quelques secondes un événement isolé, avant même de lancer une requête de corrélation. Les valeurs ci-dessous proviennent de la documentation de Microsoft.

• 0x1 et 0x3 (DES-CBC-CRC et DES-CBC-MD5) : désactivés par défaut depuis Windows 7 et Windows Server 2008 R2 ; leur présence est une anomalie de configuration grave.
• 0x11 et 0x12 (AES128 et AES256 avec HMAC-SHA1) : valeurs attendues dans un domaine moderne, prises en charge depuis Windows Vista et Windows Server 2008.
• 0x17 et 0x18 (RC4-HMAC et RC4-HMAC-EXP) : suites par défaut des systèmes antérieurs à Windows Server 2008, aujourd'hui considérées comme faibles.
• 0xFFFFFFFF : valeur affichée dans les événements d'échec, lorsqu'aucun ticket n'a été émis.

La recommandation de Microsoft est simple : à partir de Windows Vista et Windows Server 2008, toute valeur autre que 0x11 et 0x12 mérite une surveillance. Dans un domaine récent et correctement configuré, la très grande majorité des tickets de service doit donc être en AES256. Chaque exception doit pouvoir être expliquée par un équipement, une application ou une configuration connus.

Codes d'échec et options du ticket

Le champ Failure Code, nommé Status dans le XML, donne le résultat de la demande de ticket de service, tandis que Ticket Options décrit les drapeaux Kerberos demandés par le client. Ensemble, ils permettent de distinguer un incident d'exploitation, comme une horloge décalée ou un chiffrement non pris en charge, d'un comportement qui mérite une investigation de sécurité.

Les codes d'échec les plus parlants

• 0x7 (KDC_ERR_S_PRINCIPAL_UNKNOWN) : SPN introuvable dans l'annuaire, signe d'un SPN obsolète ou d'une tentative d'énumération.
• 0xD (KDC_ERR_BADOPTION) : option refusée, par exemple une délégation vers un SPN absent de la liste autorisée.
• 0xE (KDC_ERR_ETYPE_NOTSUPP) : type de chiffrement non pris en charge, fréquent après la désactivation du RC4.
• 0x12 (KDC_ERR_CLIENT_REVOKED) : compte demandeur désactivé, expiré ou verrouillé.
• 0x20 (KRB_AP_ERR_TKT_EXPIRED) : ticket expiré, renouvelé automatiquement, sans intérêt de sécurité.
• 0x25 (KRB_AP_ERR_SKEW) : écart d'horloge trop important entre le client et le contrôleur.

Certains échecs ne sont journalisés que si la valeur de registre KdcExtraLogLevel du KDC contient les bons drapeaux : 0x01 pour les erreurs de SPN inconnu, 0x10 pour les erreurs de type de chiffrement et d'options invalides. Sans ces drapeaux, une partie des tentatives d'énumération et des incompatibilités de chiffrement reste invisible. Testez l'impact sur le volume avant de généraliser ce réglage à tous les contrôleurs.

Ticket Options

Le champ Ticket Options est un masque de drapeaux Kerberos exprimé en hexadécimal. Les valeurs les plus courantes citées par Microsoft sont 0x40810000 (transférable, renouvelable, canonicalisation), 0x40810010, qui ajoute l'option « renewable-ok », et 0x60810010, qui signale en plus un ticket issu d'un TGT transféré. Plutôt que de chercher une valeur magique, établissez la distribution habituelle par source et examinez les combinaisons rares.

Détecter le Kerberoasting avec l'event ID 4769

La fiche MITRE ATT&CK T1558.003 décrit le Kerberoasting ainsi : un adversaire qui dispose d'un TGT valide demande des tickets de service pour n'importe quel SPN, puis tente de casser hors ligne la partie chiffrée avec la clé du compte de service. Sa stratégie de détection DET0157 s'appuie explicitement sur l'événement 4769 : chiffrement RC4, nombre inhabituel de tickets en peu de temps, comptes de service sollicités hors de leur usage normal.

La difficulté tient au fait que la demande est parfaitement légitime du point de vue du protocole. N'importe quel utilisateur authentifié a le droit de demander un ticket pour n'importe quel service du domaine. Aucune règle ne peut donc bloquer l'action elle-même : le SOC doit reconnaître un comportement anormal au milieu de millions de demandes normales, en combinant plusieurs signaux complémentaires plutôt qu'en se fiant à un seul critère.

Signal 1 : un ticket RC4 pour un compte utilisateur

Le premier signal combine quatre conditions : identifiant 4769, code d'échec 0x0, type de chiffrement 0x17 ou 0x18, et nom de service qui ne se termine pas par $ et n'est pas krbtgt, ce dernier correspondant aux renouvellements de TGT. Les comptes machines sont exclus parce que leur mot de passe, long et aléatoire, est changé automatiquement : casser leur ticket n'a guère d'intérêt. Un ticket RC4 émis pour un compte de service utilisateur reste l'indicateur le plus direct du Kerberoasting.

Ce signal est d'autant plus fort que le domaine a été durci. Dans un parc où les comptes de service disposent de clés AES et où le RC4 n'est plus le chiffrement implicite, une demande qui obtient malgré tout un ticket RC4 révèle soit une dépendance héritée connue, soit un outil qui force volontairement un chiffrement plus facile à casser. Dans les deux cas, l'occurrence mérite une explication écrite.

Signal 2 : une rafale de services distincts

Le second signal est volumétrique et ne dépend pas du chiffrement. Les outils de Kerberoasting énumèrent les comptes porteurs d'un SPN puis demandent un ticket pour chacun, en quelques secondes. Compter le nombre de noms de service distincts demandés par un même compte, depuis une même adresse, sur une fenêtre de cinq à quinze minutes, fait ressortir ce comportement. Le seuil se calibre sur la ligne de base observée.

Ce signal est indispensable parce que le RC4 n'est pas une condition de l'attaque. La fiche MITRE mentionne un groupe criminel, Wizard Spider, ayant employé des outils de Kerberoasting pour récupérer des empreintes AES. Un ticket AES reste cassable si le mot de passe du compte de service est faible ; il est seulement plus coûteux à attaquer. Une détection limitée au seul RC4 laisse donc un angle mort.

Compte leurre et signaux de contexte

Les deux signaux fondés sur le chiffrement et sur le volume gagnent à être complétés par des indicateurs à très faible bruit. Le compte leurre en est le meilleur exemple ; les critères de contexte, eux, servent surtout à enrichir et à prioriser une alerte déjà levée sur un événement 4769.

Signal 3 : le compte leurre

Le troisième signal offre le meilleur rapport entre fiabilité et effort. Il consiste à créer un compte de service leurre, doté d'un SPN (Service Principal Name) crédible, d'un mot de passe très long et d'aucun droit réel, qu'aucune application n'utilise. Comme personne n'a de raison légitime de demander un ticket pour ce service, tout événement 4769 qui vise le compte leurre est une alerte quasi certaine, à traiter en priorité.

Les signaux de contexte

Les recommandations de surveillance de Microsoft ajoutent des critères contextuels utiles pour enrichir une alerte : adresse cliente hors des plages internes, demandes locales au contrôleur (::1) par un compte qui ne devrait pas s'y connecter, port client inférieur à 1024, activité en dehors des heures ouvrées, comptes inactifs ou désactivés qui réapparaissent. Isolés, ces critères produisent du bruit ; combinés à l'un des trois signaux, ils accélèrent fortement le triage.

Requêtes prêtes à adapter : KQL, SPL et Sigma

Les exemples suivants traduisent les signaux décrits dans ce guide dans trois langages courants. Les noms de champs dépendent de votre connecteur : la table SecurityEvent de Microsoft Sentinel reprend les noms XML, tandis que les add-ons Splunk et les intégrations Elastic les renomment souvent. Les seuils indiqués sont des points de départ, à ajuster après plusieurs semaines d'observation de votre propre domaine.

Microsoft Sentinel (KQL)

// Tickets RC4 réussis pour des comptes de service non machine, agrégés par demandeur
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4769 and Status == "0x0"
| where TicketEncryptionType in ("0x17", "0x18")
| where ServiceName !endswith "$" and ServiceName !~ "krbtgt"
| extend SourceIP = replace_string(IpAddress, "::ffff:", "")
| summarize Tickets = count(), ServicesDistincts = dcount(ServiceName),
            Services = make_set(ServiceName, 50),
            Debut = min(TimeGenerated), Fin = max(TimeGenerated)
            by TargetUserName, SourceIP, Computer
| order by ServicesDistincts desc

// Rafale de services distincts, quel que soit le chiffrement
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4769 and Status == "0x0"
| where ServiceName !endswith "$" and ServiceName !~ "krbtgt"
| summarize ServicesDistincts = dcount(ServiceName)
            by TargetUserName, IpAddress, bin(TimeGenerated, 10m)
| where ServicesDistincts >= 10

Splunk (SPL)

index=wineventlog EventCode=4769 Ticket_Encryption_Type IN ("0x17","0x18") Failure_Code="0x0"
| where NOT match(Service_Name, "\$$") AND lower(Service_Name)!="krbtgt"
| bin _time span=10m
| stats count AS tickets dc(Service_Name) AS services_distincts values(Service_Name) AS services
        by _time, Account_Name, Client_Address
| sort - services_distincts

Règle Sigma portable

Pour éviter de maintenir une règle par outil, la même logique peut s'écrire au format Sigma puis se convertir vers la plupart des SIEM. Notre guide d'écriture des règles Sigma détaille la syntaxe, les modificateurs et la conversion. La règle ci-dessous couvre le premier signal ; le signal volumétrique relève plutôt d'une corrélation propre à chaque moteur.

title: Ticket de service Kerberos RC4 pour un compte non machine
status: experimental
description: Événement 4769 réussi avec chiffrement RC4 visant un compte de service utilisateur
tags:
  - attack.credential-access
  - attack.t1558.003
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    Status: '0x0'
    TicketEncryptionType:
      - '0x17'
      - '0x18'
  filter_machine:
    ServiceName|endswith: '$'
  filter_krbtgt:
    ServiceName: 'krbtgt'
  condition: selection and not 1 of filter_*
falsepositives:
  - Équipements ou applications hérités documentés ne prenant pas en charge AES
level: medium

Ces requêtes complètent un socle plus large de règles d'identité, d'administration et de mouvement latéral. Pour les replacer dans un catalogue cohérent, consultez notre sélection de cas d'usage SIEM et règles de détection essentielles. Si votre SOC s'appuie sur une pile ouverte, le guide Elastic SIEM pour la détection open source montre comment ingérer le journal Sécurité des contrôleurs et y exécuter ce type de corrélation.

Réduire les faux positifs sans perdre le signal

Un ticket RC4 n'est pas toujours malveillant. Les sources légitimes les plus fréquentes sont les comptes de service dont le mot de passe n'a pas changé depuis l'introduction d'AES, les comptes explicitement configurés pour accepter le RC4, les relations d'approbation anciennes et les équipements non Windows. Microsoft cite les fichiers keytab exportés uniquement avec des clés RC4, utilisés par des NAS ou des applications Linux, comme le cas de rupture le plus courant.

La bonne pratique consiste à gérer les exceptions par couple service et source, jamais par compte demandeur. Exclure un utilisateur entier de la règle revient à offrir une couverture parfaite à quiconque usurpe ce compte. Chaque exception doit avoir un propriétaire, une justification et une date de revue, idéalement versionnées avec la règle elle-même, afin de pouvoir retirer l'exclusion dès que l'équipement concerné est remplacé.

Le signal volumétrique a ses propres faux positifs : scanners de vulnérabilités, outils de supervision, serveurs de sauvegarde ou d'administration qui se connectent à de nombreux services en peu de temps. Une ligne de base de trente jours permet d'identifier ces sources et de leur appliquer un seuil dédié plutôt qu'une exclusion totale. Un scanner compromis reste en effet un excellent point de départ pour un attaquant.

Enfin, la corrélation réduit l'incertitude. Le champ Logon GUID d'un 4769 permet, selon Microsoft, de retrouver sur le serveur cible les événements 4624, 4648 ou 4964 associés. À l'inverse, un ticket de service qui n'est suivi d'aucune ouverture de session sur la cible correspond au profil d'un ticket demandé pour être exporté plutôt qu'utilisé. Cette corrélation suppose de collecter aussi les journaux des serveurs concernés.

Fin du RC4 en 2026 : le calendrier de CVE-2026-20833

Le 13 janvier 2026, Microsoft a publié des protections pour CVE-2026-20833, une vulnérabilité de divulgation d'informations : un attaquant peut obtenir des tickets de service chiffrés avec des algorithmes faibles comme le RC4, puis mener une attaque hors ligne pour retrouver le mot de passe du compte de service. Le guide de déploiement KB5073381 en décrit le calendrier en trois phases.

1. Janvier 2026, phase d'audit : les contrôleurs de domaine mis à jour écrivent dans le journal Système neuf événements d'audit KDCSVC, numérotés de 201 à 209, et prennent en charge la valeur de registre RC4DefaultDisablementPhase.
2. 14 avril 2026, application avec retour arrière manuel : la valeur par défaut de DefaultDomainSupportedEncTypes passe à AES-SHA1 seul (0x18) pour les comptes sans msDS-SupportedEncryptionTypes explicite.
3. Juillet 2026, application définitive : la valeur RC4DefaultDisablementPhase n'est plus lue, le mode audit disparaît et seul le mode d'application subsiste.

Le durcissement ne supprime pas le RC4 partout. Microsoft précise que les configurations explicites restent honorées : un compte dont l'attribut msDS-SupportedEncryptionTypes inclut RC4, ou un contrôleur dont la valeur DefaultDomainSupportedEncTypes a été définie manuellement, continuera d'émettre des tickets RC4. Dans ce second cas, l'événement KDCSVC 205 est journalisé à chaque démarrage du service KDC pour signaler la configuration jugée non sûre.

Ce que la fin du RC4 change pour le SOC

Pour un centre opérationnel de sécurité (SOC), la conséquence est nette : sur un domaine à jour en novembre 2026, un ticket 0x17 émis sans configuration RC4 explicite, ni sur le compte ni sur le contrôleur, n'a plus d'explication normale. Il signale un contrôleur non mis à jour ou une configuration modifiée à identifier. Surveillez aussi les événements KDCSVC 205 et toute modification de l'attribut msDS-SupportedEncryptionTypes, qu'un attaquant disposant de droits d'écriture pourrait employer pour rendre un compte plus facile à attaquer.

À l'inverse, les échecs 0xE deviennent plus nombreux là où subsistent des dépendances au RC4. Ils traduisent en général un problème d'exploitation, pas une attaque, et doivent être orientés vers l'équipe d'infrastructure plutôt que traités comme incidents de sécurité. Notez enfin que, selon Microsoft, les contrôleurs de domaine sous Windows Server 2025 n'émettent plus de TGT chiffrés en RC4.

Durcir les comptes de service pour fiabiliser le signal

La détection n'a de sens que si le risque résiduel est maîtrisé. La fiche MITRE recommande trois mesures : chiffrement AES plutôt que RC4, mots de passe de 25 caractères ou plus pour les comptes de service, idéalement gérés par des comptes de service administrés de groupe (gMSA), et limitation stricte de leurs privilèges. Un ticket cassable n'a de valeur pour un attaquant que si le mot de passe est faible et le compte puissant.

L'ANSSI va dans le même sens. Son recueil de points de contrôle Active Directory classe les comptes privilégiés dotés d'un SPN parmi les problèmes de niveau 1, le plus critique, et vérifie aux niveaux 2 et 3 le chiffrement Kerberos faible des comptes utilisateurs ainsi que les algorithmes acceptés par les comptes de service. Ces contrôles sont repris par le service ADS de l'agence pour les opérateurs régulés et la sphère publique.

1. Inventorier les comptes utilisateurs porteurs d'un SPN, avec leurs privilèges, la date du dernier changement de mot de passe et leurs types de chiffrement.
2. Retirer tout SPN des comptes membres de groupes privilégiés, ou retirer ces privilèges au compte de service.
3. Imposer AES en positionnant msDS-SupportedEncryptionTypes à 24 (0x18), puis réinitialiser le mot de passe pour générer les clés AES.
4. Migrer vers des gMSA chaque fois que l'application le permet, afin de confier la rotation du mot de passe à l'annuaire.
5. Vérifier l'usage résiduel du RC4 avec les scripts List-AccountKeys.ps1 et Get-KerbEncryptionUsage.ps1 publiés par Microsoft.

Import-Module ActiveDirectory
Get-ADUser -Filter "servicePrincipalName -like '*'" -Properties servicePrincipalName,
    msDS-SupportedEncryptionTypes, PasswordLastSet, adminCount, Enabled |
  Select-Object SamAccountName, Enabled, adminCount, PasswordLastSet,
    @{Name = 'EncTypes'; Expression = { $_.'msDS-SupportedEncryptionTypes' }},
    @{Name = 'SPN'; Expression = { $_.servicePrincipalName -join ' ; ' }} |
  Sort-Object PasswordLastSet |
  Export-Csv -Path .\comptes-spn.csv -NoTypeInformation -Encoding UTF8

La page Microsoft Detect and remediate RC4 usage in Kerberos explique comment exploiter les deux scripts, publiés en open source dans le dépôt Kerberos-Crypto, et comment interpréter les cas où l'attribut n'est pas défini. Pour la partie offensive et le détail des contre-mesures, notre guide complet du Kerberoasting en 2026 couvre l'attaque, la détection et la défense de bout en bout.

Déployer le cas d'usage dans un SOC en six étapes

Un cas d'usage fondé sur l'event ID 4769 ne se résume pas à une requête copiée dans un SIEM. La méthode suivante, menée sur plusieurs semaines, évite les deux échecs classiques : la règle silencieuse parce que les journaux manquent, et la règle abandonnée parce qu'elle sonne trop souvent.

1. Cartographier les contrôleurs de domaine et vérifier pour chacun que la sous-catégorie d'audit est active et que le journal remonte au SIEM.
2. Inventorier les comptes porteurs d'un SPN et documenter les dépendances RC4 connues, avec un propriétaire pour chacune.
3. Observer trente jours de 4769 pour établir la distribution des chiffrements, des volumes par source et des comptes les plus sollicités.
4. Déployer les trois signaux, RC4, rafale et compte leurre, avec des sévérités distinctes et des exceptions versionnées.
5. Tester chaque règle en laboratoire par une simulation autorisée, puis à chaque modification de la règle.
6. Documenter le playbook de triage et mesurer le taux de vrais positifs pour ajuster les seuils.

Les étapes quatre et cinq gagnent à être industrialisées. Stocker les règles et leurs exceptions dans un dépôt Git, les tester automatiquement sur des journaux de référence et les déployer par pipeline évite les régressions silencieuses. Cette approche est détaillée dans notre article consacré à la détection en tant que code et aux pipelines CI/CD pour SIEM.

Retour terrain : Cas typique rencontré en mission — l'analyse des demandes de tickets de service révèle plusieurs comptes de service encore servis avec un chiffrement obsolète, faute d'AES activé, dont un compte privilégié au mot de passe ancien. Elle fait aussi ressortir une rafale de demandes visant tous les comptes à SPN, restée sans alerte des semaines durant : les journaux étaient collectés, mais aucune règle ne les exploitait. Durcissement retenu : migration vers des gMSA, AES imposé sur les comptes restants et compte leurre surveillé.

Investiguer une alerte 4769 : le playbook de triage

Lorsqu'une alerte se déclenche, la première question porte sur le périmètre : quel compte a demandé les tickets, depuis quelle machine, pour quels comptes de service, et sur quelle durée. Élargissez immédiatement la recherche à tous les contrôleurs de domaine et à une fenêtre de plusieurs jours, car une énumération peut avoir été étalée dans le temps pour rester sous les seuils de détection.

La deuxième étape consiste à évaluer l'exposition. Pour chaque compte de service ciblé, relevez ses privilèges réels, l'âge et la longueur probable de son mot de passe et les types de chiffrement acceptés. Un compte membre d'un groupe d'administration avec un mot de passe ancien constitue l'urgence absolue ; un gMSA ciblé présente un risque bien plus faible, puisque son mot de passe aléatoire et long résiste au cassage hors ligne.

La troisième étape remonte vers la source. Sur la machine identifiée par l'adresse cliente, la télémétrie de l'EDR (Endpoint Detection and Response) permet de rechercher le processus à l'origine du trafic Kerberos, les requêtes LDAP d'énumération des SPN qui précèdent souvent les demandes, et l'ouverture de session du compte demandeur. Une activité depuis un poste utilisateur sans lien avec l'administration renforce nettement la suspicion.

Si le doute persiste, traitez le cas comme une compromission de compte. Remplacez par une valeur longue et aléatoire le mot de passe des comptes de service ciblés, en commençant par les plus privilégiés, puis désactivez ou réinitialisez le compte demandeur et isolez la machine source. Les leçons tirées de l'incident alimentent ensuite l'inventaire des comptes porteurs d'un SPN et le réglage des seuils.

À lire aussi : valider la détection avec Atomic Red Team ; réduire le MTTD sur le Kerberoasting.

Questions fréquentes

Conclusion

L'event ID 4769 est l'un des rares points où le Kerberoasting devient visible avant que le mot de passe d'un compte de service ne soit cassé. Bien exploité, il fournit trois détections complémentaires : le ticket RC4 inattendu, la rafale de services distincts et l'accès au compte leurre. La fin du RC4 implicite, appliquée par les mises à jour Windows de 2026, renforce la valeur du premier signal, sans dispenser des deux autres.

La détection ne remplace pas le durcissement. Des comptes de service sans privilèges excessifs, protégés par AES et par des mots de passe longs ou gérés en gMSA, rendent le ticket intercepté sans valeur pour l'attaquant. Pour une vision complète de la menace, de ses variantes et des contre-mesures, reportez-vous à notre guide de référence Kerberoasting : attaque et défense.