Tickets Kerberos après désactivation du compte : durée et confinement

Tickets Kerberos après désactivation du compte : pourquoi les sessions persistent

La durée des tickets Kerberos après désactivation du compte est importante, car changer l'état d'un compte n'annule pas automatiquement les tickets déjà émis pour lui. Microsoft indique que des tickets de service valides émis avant la désactivation peuvent encore permettre un accès. L'intervenant doit donc réunir des preuves concernant le compte, les tickets et les ressources qui les acceptent, au lieu de considérer la désactivation comme la preuve d'un confinement terminé. Microsoft Learn : durée du ticket utilisateur

Il existe une deuxième limite : une connexion authentifiée peut survivre au ticket qui l'a établie. Microsoft explique que les tickets de service authentifient les nouvelles connexions ; leur expiration n'interrompt pas les opérations en cours sur une connexion déjà authentifiée. Attendre l'heure de fin du ticket ne suffit donc pas à prouver que l'accès a cessé. Microsoft Learn : durée du ticket de service

Dans une investigation de réponse à incident, distinguez trois questions. L'identité peut-elle obtenir un autre ticket ? Un ticket déjà détenu peut-il authentifier une autre connexion ? Une connexion précédemment authentifiée fonctionne-t-elle encore ? Ces questions d'investigation découlent des limites documentées ; ce ne sont pas trois étapes suivies par chaque incident. Séparez-les dans le dossier d'incident pour que les preuves relatives à l'une ne permettent pas de clôturer les autres par erreur.

Ce guide traite des tickets légitimes déjà émis, y compris du problème de confinement lorsque ces éléments ont été volés. Pour la menace distincte des TGT falsifiés à partir d'un secret krbtgt compromis, consultez l'attaque Golden Ticket et son prérequis krbtgt. Pour distinguer la falsification d'un ticket de service de la réutilisation d'un ticket volé, consultez la comparaison Silver Ticket et Pass-the-Ticket et la comparaison Pass-the-Hash, Overpass-the-Hash et Pass-the-Ticket. Leurs scénarios d'attaque sont distincts des décisions de durée et de confinement présentées ici.

Les trois horloges : TGT, ticket de service et connexion établie

Le ticket d'octroi de tickets, ou TGT, sert à obtenir d'autres tickets Kerberos. Le ticket de service est présenté à un service particulier. La connexion établie possède ensuite sa propre durée de vie, que la stratégie des tickets de service ne définit pas. Distinguez les deux horloges des tickets de celle de la connexion ; la fenêtre de renouvellement impose une limite supplémentaire aux TGT renouvelables. Microsoft Learn : durée du ticket de service, RFC 4120 §2.3

Les valeurs suivantes sont les valeurs par défaut documentées par Microsoft, et non des mesures de votre domaine. Les clés et les unités sont définies dans MS-GPSB §2.2.2, Kerberos Policy.

Convertissez les heures et les minutes avant de comparer les valeurs. MS-GPSB désigne MaxTicketAge comme la limite supérieure associée à MaxServiceAge ; la page Learn sur les tickets de service contient une coquille comparant le paramètre à lui-même, qui ne doit pas devenir une règle opérationnelle. Le décalage de cinq minutes est une tolérance, et non un délai de confinement garanti. MS-GPSB, Microsoft Learn : tolérance de synchronisation des horloges

Sept jours de renouvellement ne signifient pas que chaque TGT reste continuellement valide pendant sept jours. Un ticket renouvelable a une expiration individuelle et une limite finale de renouvellement. Réduire cette fenêtre a aussi des conséquences sur la disponibilité pour les utilisateurs qui ne peuvent pas joindre fréquemment un contrôleur de domaine. Microsoft Learn : renouvellement du ticket utilisateur, RFC 4120 §2.3

Les contrôles du compte limitent les nouveaux tickets sans annuler automatiquement ceux déjà émis

Windows contrôle les comptes lors des demandes de tickets. MS-KILE §5.1.3 impose aux KDC du domaine du compte de contrôler celui-ci lorsque le TGT présenté a plus de 20 minutes. MS-KILE §3.3.5.7.1 précise les conditions : la validation de la stratégie du compte doit être activée et le KDC doit appartenir au domaine du compte de l'utilisateur. Un KDC d'un autre domaine ne peut pas effectuer ce contrôle. Dans ces conditions, un compte désactivé est rejeté avec KDC_ERR_CLIENT_REVOKED.

Il s'agit du traitement des demandes, et non d'un minuteur qui déconnecte chaque session à la vingtième minute. Ce contrôle limite l'émission ultérieure de TGS et ne rappelle pas un ticket de service déjà obtenu. Les demandes de TGT font également l'objet de contrôles documentés de la stratégie du compte, notamment le rejet des comptes désactivés lorsque l'option de validation est activée. MS-KILE §3.3.5.6.3

Le protocole décrit aussi un mécanisme de révocation. RFC 4120 §3.3.3.1 définit une hot-list contrôlée par le service d'octroi de tickets, empêchant les tickets annulés d'obtenir des tickets supplémentaires. La spécification distingue ce mécanisme des tickets ordinaires déjà obtenus, qui restent valides jusqu'à leur expiration habituelle. Elle n'établit pas de commande d'administration Windows universelle pour révoquer globalement les tickets d'un utilisateur. RFC 4120 §3.3.3.1

Changer le mot de passe de l'utilisateur ne remplace pas automatiquement les clés de session et les tickets déjà détenus. Cette déduction cryptographique découle de l'échange TGS : le TGT est traité avec la clé du service d'octroi de tickets, et la réponse utilise une clé de session plutôt que le secret à long terme du client. Cela ne garantit pas que toute authentification future réussira après une réinitialisation. RFC 4120 §§3.3.2–3.3.3

Le retrait d'un groupe présente une autre limite. Les SID des groupes globaux et universels entrent dans le PAC lors de l'émission initiale du TGT et sont copiés dans les TGT renouvelés. Le renouvellement seul ne garantit donc pas l'actualisation des appartenances. Les groupes locaux du domaine de la ressource sont ajoutés lors de l'émission du ticket de service ; ne généralisez pas en affirmant que tous les groupes sont figés au premier TGT. MS-PAC §4.1.2.1, MS-KILE §3.3.5.7.3

Détection

1. Construire une chronologie à partir des journaux du compte, du KDC et de la destination

Utilisez les événements Windows documentés ci-dessous comme éléments de preuve. La stratégie de corrélation est une recommandation analytique fondée sur leurs champs et les limites du protocole décrites plus haut ; aucun résultat de laboratoire ni résultat de détection en production n'est revendiqué.

L'événement 4768 ne couvre pas tous les échecs de TGT : Microsoft indique que les codes de résultat 0x10 et 0x18 génèrent plutôt l'événement 4771. Incluez ces échecs de préauthentification lors de l'examen des demandes infructueuses. Microsoft Learn : couverture de 4768

Ancrez l'incident sur la cible de 4725, et non sur l'administrateur qui l'a désactivée. Associez cette identité aux noms normalisés dans les événements Kerberos : 4769 ne fournit pas le même champ SID de l'utilisateur cible que 4725. Conservez l'événement brut et la décision de correspondance. Utilisez l'hôte de destination et son identifiant d'ouverture de session pour apparier 4624 et 4634 ; Microsoft précise que ces identifiants ne sont uniques qu'entre deux redémarrages d'un même ordinateur. Définition des champs de 4725, définition des champs de 4769, limites de corrélation de 4634

Priorisez les demandes de tickets réussies ou les nouvelles ouvertures de session sur les destinations après la désactivation, les hôtes sources inattendus et l'activité persistante sur des connexions connues. Examinez le KDC du domaine du compte, le paramètre de validation, l'âge du TGT et la chronologie de l'incident avant d'interpréter une demande TGS ultérieure réussie. Ces pistes d'investigation découlent de KILE ; elles ne prouvent pas automatiquement un vol de ticket. Des événements manquants créent un manque de visibilité ; ils ne démontrent pas qu'une connexion s'est terminée. Corroborez la chronologie avec l'inventaire actuel des connexions du propriétaire de la ressource et la piste d'audit de l'application.

2. Mesurer la stratégie sur les contrôleurs de domaine concernés

Les exemples suivants sont adaptés de la documentation : ces commandes n'ont pas été exécutées dans un environnement AD. Utilisez un contexte autorisé, les outils et modules requis ainsi qu'un répertoire de rapports existant et accessible en écriture. L'exemple local gpresult cible le DC sur lequel il est exécuté. Lisez les paramètres Kerberos Policy du rapport avec le contexte des GPO appliquées. Microsoft Learn : gpresult

gpresult /scope computer /h C:\Temp\Kerberos-RSoP.html

Examinez les paramètres de la Default Domain Policy avec le rapport suivant. Son GUID bien connu est aussi la clé de recherche du helper du collecteur à helpers/gpo_policy.go:11. Un rapport pour une seule GPO ne démontre pas à lui seul la stratégie effective sur tous les DC. Microsoft Learn : Get-GPOReport

Get-GPOReport -Guid 31B2F340-016D-11D2-945F-00C04FB984F9 -ReportType XML

Examinez les autres GPO, y compris leurs liens et filtres, avec un rapport séparé. Sélectionnez le domaine et le serveur réels à l'aide des paramètres documentés lorsque le contexte actuel ne convient pas. Get-GPOReport

Get-GPOReport -All -ReportType XML

Get-ADDefaultDomainPasswordPolicy ne lit pas la stratégie Kerberos. Sa sortie est l'objet de stratégie de mot de passe par défaut du domaine ; ne l'utilisez pas pour affirmer que MaxTicketAge ou MaxRenewAge ont été vérifiés. Microsoft Learn : Get-ADDefaultDomainPasswordPolicy

3. Examiner les tickets réellement détenus sur les hôtes du périmètre

Les exemples séparés suivants proviennent de Microsoft Learn : klist. Lisez le cache de la session actuelle :

klist

Examinez son TGT, notamment son heure de fin et sa limite de renouvellement :

klist tgt

Énumérez les sessions d'ouverture de session locales avant de supposer que le cache de l'utilisateur actuel couvre l'hôte :

klist sessions

Sélectionnez une session avec -li, qui indique la partie basse de son LUID ; utilisez aussi -lh si la partie haute est non nulle. 0x3e7 est l'exemple documenté par Microsoft :

klist -li 0x3e7

Consignez l'hôte, la session, l'heure de collecte et les horaires des tickets. Ces observations couvrent le cache sélectionné, pas les copies de tickets sur un autre système. Conservez ce périmètre dans le dossier de réponse.

Remédiation (Remediation)

1. Réduire les durées excessives avant un incident

Les recommandations de Microsoft pour les tickets utilisateur proposent 4–10 heures, des demandes plus fréquentes augmentant la charge du KDC. Testez la valeur retenue avec les processus légitimes. Configurez les paramètres Kerberos du domaine sous Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy. Microsoft Learn : durée du ticket utilisateur

Pour une préparation ciblée autour des comptes privilégiés, examinez les stratégies d'authentification et silos pour des TGT Tier 0 plus courts et des restrictions sur les appareils. Séparez cette décision de déploiement du nettoyage d'urgence des caches.

Réduire une durée dans une GPO ne purge pas rétroactivement les tickets. Cette déduction découle des périodes de validité portées par les tickets et des opérations de cache local documentées plus haut. Appliquez la modification et vérifiez les nouveaux tickets émis ; conservez séparément les preuves relatives aux tickets existants. RFC 4120, klist

2. Confiner l'identité et les ressources pendant l'incident

Désactivez et réinitialisez l'identité affectée selon les besoins pour les authentifications futures, puis isolez les hôtes compromis et inventoriez les connexions impliquant cette identité. L'isolement et la fermeture côté ressource sont des recommandations opérationnelles déduites de la persistance documentée des connexions authentifiées, et non une procédure universelle de récupération Microsoft. Attribuez un responsable à chaque hôte et service affecté, et consignez le chemin d'accès couvert par chaque action. MS-KILE : contrôles du compte pour le TGT, Microsoft Learn : durée du ticket de service

Sur un hôte que vous contrôlez, purgez les tickets de la session actuelle avec cette commande documentée :

klist purge

Pour une session sélectionnée, l'exemple de Microsoft constitue une opération séparée :

klist purge -li 0x3e7

Sans sélecteur LUID, la purge s'applique à la session actuellement ouverte. Elle n'atteint pas les autres caches ni les tickets copiés ailleurs. Fermez les connexions concernées et organisez une nouvelle authentification dans le cadre de la réponse. La purge seule ne prouve pas que toutes les connexions applicatives ont été fermées. klist, limite des connexions liée au ticket de service

L'opérateur responsable peut choisir de redémarrer un hôte ou un service pour fermer les contextes locaux lorsque les sessions individuelles ne peuvent pas être contrôlées. Considérez cela comme une décision opérationnelle locale, et non comme une révocation à l'échelle du domaine ou une preuve d'éradication. Aucune commande universelle de redémarrage n'est prescrite ici.

3. Réserver la récupération krbtgt à une compromission de ce secret

La désactivation d'un utilisateur ordinaire ne justifie pas deux rotations de krbtgt. Si ce secret est compromis, suivez la planification de récupération du domaine. La procédure Microsoft de récupération de forêt exige deux réinitialisations, car l'historique conserve deux mots de passe. Attendez 10 heures entre les réinitialisations avec les valeurs par défaut ; si les durées maximales ont été modifiées, l'attente minimale doit être supérieure à la durée configurée. Vérifiez la réplication et le périmètre des DC avant de planifier la seconde opération. La procédure citée s'applique aux DC accessibles en écriture, et non aux comptes krbtgt_number des RODC. Microsoft Learn : réinitialiser le mot de passe krbtgt

N'en déduisez pas que ces réinitialisations détruisent tous les tickets de service émis ou toutes les connexions existantes. Leurs clés de service et leurs contextes établis constituent des limites distinctes. Validez séparément les nouvelles tentatives d'accès, les caches locaux et les connexions précédemment ouvertes ; consignez les résultats réels lorsque l'équipe de réponse effectue ces contrôles. RFC 4120 §3.3, Microsoft Learn : durée du ticket de service

Comment EtcSec détecte ce problème

L'etc-collector d'EtcSec identifie les durées configurées excessives au moyen de trois identifiants de détecteurs réels. Les affirmations suivantes proviennent de l'inspection statique de leurs implémentations Detect(), et non d'un audit du domaine d'un client. Les chemins ci-dessous sont relatifs à public/internal/audit/detectors/ad/ dans les sources du collecteur.

Les comparaisons sont strictes : 10 heures et 7 jours ne déclenchent pas ces constats. Le contrôle agrégé recoupe les deux contrôles spécialisés ; il s'agit de deux contrôles de durée et d'un contrôle agrégé, et non de trois capacités de confinement indépendantes. Ils ne détectent pas le vol de tickets, ne ferment pas les sessions et n'implémentent pas la révocation des tickets utilisateur.

Les entrées principales sont les paramètres Kerberos extraits du fichier SYSVOL GptTmpl.inf, à public/internal/providers/smb/gptmpl_parser.go:221–227. Le helper public/internal/audit/helpers/gpo_policy.go:42–54 privilégie la Default Domain Policy, puis une autre GPO disponible avec des paramètres Kerberos. Il ne calcule pas la priorité RSoP complète. Comparez le constat avec la stratégie effective du DC concerné et les tickets observés avant de déclarer la remédiation terminée.

Les détecteurs spécialisés sélectionnent les valeurs positives et contiennent des solutions de repli DomainInfo. MaxTicketAge=0, malgré sa signification documentée par Microsoft d'absence d'expiration, n'est pas signalé par la comparaison de durée. Des entrées manquantes ou nulles peuvent également laisser Count=0. Le contrôle agrégé renvoie immédiatement Count=0 lorsque DomainInfo est nil, même si des données de stratégie SYSVOL sont présentes (weak-kerberos-policy.go:25–33). Ses détails dépendent de IncludeDetails. Aucune de ces trois comparaisons ne contrôle la durée des tickets de service, le décalage d'horloge ou l'indicateur de validation du compte.

Le dossier final de réponse doit associer les durées configurées aux preuves des caches de tickets, aux résultats des demandes KDC et aux contrôles des connexions côté ressource. Ce sont les éléments nécessaires pour distinguer une stratégie corrigée d'un accès qui a réellement cessé.