ANAVEM
Languageen
Windows security monitoring dashboard displaying Kerberos authentication events in Event Viewer
Event ID 4769InformationMicrosoft-Windows-Security-AuditingWindows

ID d'événement Windows 4769 – Microsoft-Windows-Security-Auditing : Demande de ticket de service Kerberos

L'ID d'événement 4769 enregistre lorsqu'un ticket de service Kerberos est demandé à un contrôleur de domaine. Cet événement d'audit de sécurité suit les tentatives d'authentification aux services et ressources réseau.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 mars 202612 min de lecture 0
Event ID 4769Microsoft-Windows-Security-Auditing 5 méthodes 12 min
Référence événement

Signification de cet événement

L'ID d'événement 4769 représente un composant fondamental de la journalisation de la sécurité des domaines Windows. Lorsqu'un utilisateur ou un service tente d'accéder à une ressource réseau protégée par l'authentification Kerberos, le client doit demander un ticket de service au contrôleur de domaine. Cette demande génère l'événement 4769, offrant aux administrateurs une visibilité détaillée sur l'activité d'authentification à travers le domaine.

L'événement contient des informations détaillées, y compris le nom du compte effectuant la demande, le nom principal du service (SPN) auquel on accède, l'adresse IP du client, les détails du protocole d'authentification et le code de résultat. Les événements de succès (Code de Résultat 0x0) indiquent un flux d'authentification normal, tandis que les codes d'échec révèlent des problèmes de sécurité potentiels ou des erreurs de configuration.

Dans les environnements Windows modernes exécutant les versions 2025 et ultérieures, Microsoft a amélioré la structure de l'événement pour inclure un contexte supplémentaire pour les scénarios hybrides cloud et une meilleure corrélation avec les événements d'authentification Azure AD. L'événement s'intègre avec Windows Defender for Identity et Microsoft Sentinel pour la détection avancée des menaces, en faisant un pilier des stratégies de surveillance de la sécurité d'entreprise.

Comprendre les modèles 4769 aide à identifier les comptes compromis, détecter les tentatives de mouvement latéral et valider l'utilisation des comptes de service. La fréquence et le contenu de l'événement le rendent à la fois précieux pour l'analyse de sécurité et difficile à gérer sans outils de filtrage et d'analyse appropriés.

S'applique à

Windows 10Windows 11Windows Server 2019/2022/2025
Analyse

Causes possibles

  • Utilisateur accédant aux partages de fichiers réseau ou aux lecteurs mappés
  • Applications se connectant à SQL Server, Exchange ou à d'autres services compatibles Kerberos
  • Comptes de service s'authentifiant aux systèmes backend
  • Applications web utilisant l'authentification Windows intégrée
  • Remote PowerShell ou connexions WinRM
  • Tâches planifiées s'exécutant sous des comptes de domaine
  • Tentatives d'authentification échouées en raison de mots de passe expirés ou de comptes verrouillés
  • Désynchronisation de l'horloge entre le client et le contrôleur de domaine dépassant la tolérance
  • Mauvaise configuration du Service Principal Name (SPN)
  • Attaques potentielles de sécurité comme Kerberoasting ou credential stuffing
Méthodes de résolution

Étapes de dépannage

01

Examiner les détails de l'événement dans le Visualiseur d'événements

Commencez par examiner les détails spécifiques de l'événement 4769 pour comprendre le contexte d'authentification.

  1. Ouvrez Observateur d'événementsJournaux WindowsSécurité
  2. Filtrez pour l'ID d'événement 4769 en utilisant Filtrer le journal actuel
  3. Double-cliquez sur un événement 4769 récent pour voir les détails
  4. Champs clés à examiner :
    • Nom du compte : Utilisateur ou compte de service effectuant la demande
    • Nom du service : Service cible étant accédé
    • Adresse client : IP source de la demande d'authentification
    • Code d'échec : 0x0 pour succès, d'autres codes indiquent des échecs spécifiques
    • Options de ticket : Indicateurs Kerberos et types de chiffrement
  5. Notez l'horodatage et la fréquence des événements du même compte

Utilisez cette commande PowerShell pour extraire rapidement les événements 4769 récents :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 50 | Select-Object TimeCreated, Id, @{Name='Account';Expression={$_.Properties[0].Value}}, @{Name='ServiceName';Expression={$_.Properties[1].Value}}
02

Analyser les modèles d'authentification avec PowerShell

Utilisez PowerShell pour identifier des modèles d'authentification inhabituels ou des problèmes de sécurité potentiels.

  1. Extraire et analyser les événements 4769 pour une activité suspecte :
# Obtenir les demandes de ticket de service Kerberos échouées
$FailedAuth = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 1000 | Where-Object {$_.Properties[8].Value -ne '0x0'}

# Regrouper par compte pour identifier les comptes avec des taux d'échec élevés
$FailedAuth | Group-Object {$_.Properties[0].Value} | Sort-Object Count -Descending | Select-Object Name, Count

# Vérifier les modèles d'accès aux services inhabituels
$ServiceTickets = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 500
$ServiceTickets | Group-Object {$_.Properties[1].Value} | Sort-Object Count -Descending | Select-Object Name, Count
  1. Recherchez ces modèles suspects :
    • Volumes élevés de demandes échouées provenant de comptes uniques
    • Accès aux services inhabituel en dehors des heures de bureau normales
    • Demandes de tickets de service pour des services sensibles provenant de comptes inattendus
    • Tentatives d'authentification en rafale indiquant des attaques automatisées
  2. Faire une référence croisée avec l'ID d'événement 4768 (demandes TGT) pour un flux d'authentification complet
03

Configurer les politiques d'audit avancées

Optimisez les paramètres d'audit Kerberos pour capturer les événements pertinents tout en gérant le volume des journaux.

  1. Ouvrez Group Policy Management Console et accédez à l'OU du contrôleur de domaine
  2. Modifiez la stratégie par défaut des contrôleurs de domaine
  3. Accédez à Configuration de l'ordinateurStratégiesParamètres WindowsParamètres de sécuritéConfiguration avancée de la stratégie d'audit
  4. Configurez Audit des opérations de ticket de service Kerberos:
    • Succès : Activer pour le suivi normal de l'authentification
    • Échec : Activer pour la surveillance de la sécurité
  5. Utilisez PowerShell pour configurer les paramètres d'audit par programmation :
# Activer l'audit des tickets de service Kerberos
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable

# Vérifier les paramètres d'audit actuels
auditpol /get /subcategory:"Kerberos Service Ticket Operations"
  1. Envisagez d'activer Audit du service d'authentification Kerberos pour une surveillance complète de Kerberos
  2. Appliquez la stratégie et exécutez gpupdate /force sur les contrôleurs de domaine
Astuce pro : Dans les environnements à fort volume, envisagez de filtrer les événements 4769 au niveau de la collecte pour vous concentrer uniquement sur les échecs et l'accès aux services sensibles.
04

Enquêter sur les problèmes de nom principal de service

Résoudre les échecs d'authentification liés aux SPN qui génèrent des événements d'erreur 4769.

  1. Identifier les échecs liés aux SPN en vérifiant les codes d'échec dans les événements 4769
  2. Codes d'échec SPN courants:
    • 0x7: KDC_ERR_S_PRINCIPAL_UNKNOWN (SPN non trouvé)
    • 0x25: KDC_ERR_INTEGRITY (échec de chiffrement/intégrité)
  3. Utiliser setspn pour diagnostiquer les problèmes de SPN:
# Lister tous les SPN pour un compte de service
setspn -L DOMAIN\ServiceAccount

# Vérifier les SPN en double dans le domaine
setspn -X

# Trouver les SPN enregistrés pour un service spécifique
setspn -Q HTTP/webserver.domain.com
  1. Résoudre les problèmes de SPN:
    • Enregistrer les SPN manquants: setspn -A HTTP/server.domain.com DOMAIN\ServiceAccount
    • Supprimer les SPN en double: setspn -D HTTP/server.domain.com DOMAIN\WrongAccount
  2. Vérifier la résolution des SPN en utilisant:
# Tester l'authentification Kerberos pour un service spécifique
klist get HTTP/webserver.domain.com

# Vider le cache des tickets Kerberos si nécessaire
klist purge
Avertissement: Des modifications incorrectes des SPN peuvent casser l'authentification du service. Testez toujours les modifications des SPN dans un environnement non-production d'abord.
05

Mettre en œuvre la surveillance et l'alerte de sécurité

Configurez la surveillance automatisée pour 4769 événements afin de détecter les menaces de sécurité et les problèmes d'authentification.

  1. Créez des vues personnalisées dans l'Observateur d'événements pour la surveillance de la sécurité :
  2. Dans l'Observateur d'événements, cliquez avec le bouton droit sur Vues personnaliséesCréer une vue personnalisée
  3. Configurez les critères de filtrage :
    • Journaux d'événements : Sécurité
    • ID d'événements : 4769
    • Mots-clés : Échec d'audit (pour les échecs d'authentification)
  4. Utilisez PowerShell pour créer des scripts de surveillance automatisée :
# Surveiller les tentatives de Kerberoasting (demandes de chiffrement RC4)
$KerberoastingEvents = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 100 | Where-Object {
    $_.Properties[7].Value -match '0x17' # Chiffrement RC4-HMAC
}

# Alerte sur les authentifications à haut volume depuis une source unique
$RecentEvents = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddHours(-1)}
$HighVolumeIPs = $RecentEvents | Group-Object {$_.Properties[6].Value} | Where-Object {$_.Count -gt 100}

if ($HighVolumeIPs) {
    Write-Warning "Demandes Kerberos à haut volume détectées depuis : $($HighVolumeIPs.Name -join ', ')"
}
  1. Configurez le transfert d'événements Windows (WEF) pour centraliser les événements 4769 :
  2. Sur le serveur collecteur, activez WinRM : winrm quickconfig
  3. Créez un abonnement pour les événements 4769 des contrôleurs de domaine
  4. Intégrez avec des solutions SIEM comme Microsoft Sentinel ou Splunk pour des analyses avancées
Astuce pro : Concentrez la surveillance sur les événements 4769 échoués et les événements réussis avec chiffrement RC4, car ils indiquent souvent des préoccupations de sécurité dans les environnements modernes.

Aperçu

L'ID d'événement 4769 se déclenche chaque fois qu'un client demande un ticket de service Kerberos (TGS) à un contrôleur de domaine. Cet événement fait partie de l'audit de sécurité Windows et apparaît dans le journal de sécurité lorsque l'authentification Kerberos se produit pour accéder à des ressources réseau telles que des partages de fichiers, des serveurs SQL ou des applications web.

L'événement capture des détails d'authentification critiques, y compris le compte utilisateur demandeur, le service cible, l'adresse IP du client et le résultat de l'authentification. Les contrôleurs de domaine génèrent cet événement lors de la deuxième phase de l'authentification Kerberos, après l'obtention initiale du TGT (Ticket Granting Ticket).

Cet événement est essentiel pour la surveillance de la sécurité, l'audit de conformité et le dépannage des problèmes d'authentification. Des volumes élevés d'événements 4769 sont normaux dans les environnements Active Directory, mais des modèles spécifiques peuvent indiquer des préoccupations de sécurité telles que des attaques par bourrage d'identifiants, une mauvaise utilisation des comptes de service ou des échecs d'authentification nécessitant une enquête.

Questions Fréquentes

Que signifie l'ID d'événement 4769 et quand se produit-il ?+
L'ID d'événement 4769 indique qu'un ticket de service Kerberos (TGS) a été demandé à un contrôleur de domaine. Cela se produit lors de la deuxième phase de l'authentification Kerberos lorsqu'un client doit accéder à un service réseau spécifique après avoir déjà obtenu un Ticket Granting Ticket (TGT). L'événement se déclenche pour les demandes de ticket de service réussies et échouées, fournissant des informations détaillées sur le compte demandeur, le service cible, l'adresse IP du client et le résultat de l'authentification. Cela fait partie intégrante de l'authentification de domaine et apparaîtra fréquemment dans les environnements Active Directory.
Comment puis-je distinguer entre les événements 4769 normaux et les menaces de sécurité potentielles ?+
Concentrez-vous sur plusieurs indicateurs clés pour identifier une activité suspecte 4769 : tentatives d'authentification échouées (codes d'échec non nuls), surtout lorsqu'elles sont regroupées à partir de comptes ou d'adresses IP uniques ; requêtes utilisant un chiffrement faible comme RC4-HMAC pouvant indiquer des attaques de Kerberoasting ; modèles d'accès aux services inhabituels en dehors des heures de bureau normales ; requêtes à haut volume et à tir rapide suggérant des attaques automatisées ; et demandes de tickets de service pour des services sensibles à partir de comptes utilisateurs inattendus. Les événements normaux 4769 montrent des codes de succès (0x0), utilisent un chiffrement moderne (AES) et suivent des modèles prévisibles basés sur les horaires de travail des utilisateurs et les modèles d'accès aux applications.
Quels sont les codes d'échec les plus courants dans l'ID d'événement 4769 et que signifient-ils ?+
Les codes d'erreur 4769 les plus courants incluent : 0x6 (KDC_ERR_C_PRINCIPAL_UNKNOWN) indiquant que le compte client n'existe pas ou est désactivé ; 0x7 (KDC_ERR_S_PRINCIPAL_UNKNOWN) signifiant que le nom principal de service (SPN) demandé n'est pas enregistré ; 0x18 (KDC_ERR_CLIENT_REVOKED) montrant que le compte client est désactivé ou verrouillé ; 0x20 (KDC_ERR_TKT_EXPIRED) indiquant que le TGT a expiré ; et 0x25 (KDC_ERR_INTEGRITY) suggérant des échecs de chiffrement ou de vérification d'intégrité. Comprendre ces codes aide à diagnostiquer rapidement si les échecs d'authentification sont dus à des problèmes de compte, des erreurs de configuration de service, ou des attaques de sécurité potentielles.
Comment puis-je réduire le volume de 4769 événements dans des environnements à fort trafic ?+
Pour gérer le volume d'événements 4769, implémentez un audit sélectif en configurant la stratégie de groupe pour auditer uniquement les échecs pour les services de routine tout en maintenant l'audit des réussites pour les services sensibles. Utilisez les abonnements au journal des événements pour transférer uniquement les événements critiques 4769 vers des collecteurs centraux. Configurez les politiques de rétention des journaux pour équilibrer les exigences de conformité avec les contraintes de stockage. Envisagez de filtrer au niveau du SIEM pour vous concentrer sur les événements pertinents pour la sécurité comme les échecs d'authentification, l'utilisation du chiffrement RC4 et l'accès aux services de grande valeur. Vous pouvez également exclure les comptes de service de routine de l'audit si leurs schémas d'authentification sont bien compris et surveillés par d'autres moyens.
L'ID d'événement 4769 peut-il aider à détecter les attaques Kerberoasting ?+
Oui, l'ID d'événement 4769 est crucial pour détecter les attaques Kerberoasting. Recherchez les demandes de tickets de service qui spécifient le chiffrement RC4-HMAC (option de ticket 0x17) au lieu du chiffrement AES par défaut, car les attaquants demandent souvent des tickets RC4 parce qu'ils sont plus faciles à craquer hors ligne. Surveillez les modèles inhabituels tels que les demandes pour des comptes de service qui ne sont généralement pas accessibles par l'utilisateur demandeur, des volumes élevés de demandes de tickets de service sur de courtes périodes, et des demandes pour des SPN associés à des comptes de service à privilèges élevés. Combinez l'analyse 4769 avec 4768 (demandes de TGT) pour identifier les comptes qui obtiennent des TGT et demandent ensuite immédiatement plusieurs tickets de service, ce qui est caractéristique des phases de reconnaissance et d'attaque de Kerberoasting.
Documentation

Références (2)

Emanuel DE ALMEIDA
Écrit par

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Événements Windows associés

Windows security monitoring dashboard displaying audit events and privilege tracking logs
Event 6276
Microsoft-Windows-Security-Auditing
Windows EventInformation

ID d'événement Windows 6276 – Microsoft-Windows-Security-Auditing : Privilèges spéciaux attribués à une nouvelle connexion

L'ID d'événement 6276 enregistre lorsque des privilèges spéciaux sont attribués à un compte utilisateur lors de la connexion, indiquant que des droits d'accès élevés ont été accordés pour la session.

18 mars9 min
Windows security monitoring dashboard displaying privilege assignment events in a professional SOC environment
Event 6274
Microsoft-Windows-Security-Auditing
Windows EventInformation

ID d'événement Windows 6274 – Microsoft-Windows-Security-Auditing : Privilèges spéciaux attribués à une nouvelle connexion

L'ID d'événement 6274 enregistre lorsque des privilèges spéciaux sont attribués à une nouvelle session de connexion utilisateur, indiquant que des droits d'accès élevés ont été accordés pour des opérations sensibles à la sécurité.

18 mars9 min
Network Policy Server monitoring dashboard showing authentication events and security logs
Event 6273
Microsoft-Windows-Security-Auditing
Windows EventInformation

ID d'événement Windows 6273 – Microsoft-Windows-Security-Auditing : Accès accordé par le serveur de stratégie réseau

L'ID d'événement 6273 indique que le serveur de politique réseau (NPS) a accordé l'accès au réseau à un utilisateur ou un appareil après une authentification et une autorisation réussies via les protocoles RADIUS.

18 mars9 min
Network operations center displaying Windows NPS authentication monitoring dashboards and security event logs
Event 6272
Microsoft-Windows-Security-Auditing
Windows EventInformation

ID d'événement Windows 6272 – Microsoft-Windows-Security-Auditing : Serveur de stratégie réseau a accordé l'accès

L'ID d'événement 6272 indique que le serveur de politique réseau (NPS) a accordé l'accès au réseau à un utilisateur ou un appareil après une authentification et une autorisation réussies via les protocoles RADIUS.

18 mars12 min

Discussion

Partagez vos réflexions et analyses

Vous devez être connecté pour commenter.

Chargement des commentaires...