Kerberos expliqué - Protocole, flows, attaques, hardening

Kerberos est le protocole d'authentification qui fait tenir Active Directory, et donc 95 % de l'authentification en entreprise. Conçu au MIT dans les années 80, adopté par Microsoft dans Windows 2000, il est omniprésent mais peu compris - et ses faiblesses sont la cause racine de la majorité des incidents AD des 15 dernières années (Kerberoasting, Golden Ticket, Pass-the-Ticket). Ce guide couvre Kerberos en profondeur : concepts (KDC, TGT, Service Ticket), flows détaillés (AS-REQ, TGS-REQ, AP-REQ), cryptographie utilisée, 10 attaques classiques avec leurs détections, et les hardening critiques 2026 (disable RC4, Protected Users, Authentication Policies, Kerberos Armoring).

1. Origine et contexte

1.1 Le MIT, Project Athena et Cerbère

Kerberos a été conçu au MIT dans le cadre du Project Athena (1983-1991), projet de recherche financé par IBM et DEC pour équiper les campus universitaires en environnement informatique distribué.

Le nom vient de Cerbère (Cerberus, Kerberos en grec), chien à trois têtes gardien des Enfers dans la mythologie grecque. Les trois têtes symbolisent les trois acteurs du protocole :

• Le client (utilisateur ou workload).
• Le service auquel il veut accéder.
• Le KDC (Key Distribution Center) qui les met en relation.

1.2 Versions

• Kerberos v4 : publié 1988, limité (clés DES).
• Kerberos v5 : publié 1993, standardisé RFC 4120 en 2005. Version actuelle, dominante.

1.3 Adoption majeure

• MIT Kerberos : implémentation référence, utilisée sur Linux, macOS, BSD.
• Heimdal : implémentation alternative (suédoise), origine libre.
• Microsoft Kerberos : implémentation intégrée à Windows 2000+ et fondement d'Active Directory. C'est le déploiement le plus massif au monde.

En 2026, Kerberos est dans tous les domaines Active Directory (~80 % des entreprises mondiales), activé par défaut, utilisé partout derrière l'authentification Windows, RDP, SSH Linux enterprise, NFS sécurisé, Apache SPNEGO.

2. Vocabulaire et acteurs

2.1 Les rôles

2.2 Les tickets

2.3 Les clés

3. Le flow Kerberos - 3 échanges

Kerberos structure l'authentification en 3 échanges :

1. AS-REQ / AS-REP : obtenir un TGT.
2. TGS-REQ / TGS-REP : échanger le TGT contre un Service Ticket.
3. AP-REQ / AP-REP : présenter le Service Ticket au service.

3.1 Étape 1 - AS-REQ et AS-REP

Le client veut se loguer (par exemple, Alice entre son mot de passe).

AS-REQ envoyé par le client au KDC :

• Principal : alice@EXAMPLE.COM.
• Target : krbtgt/EXAMPLE.COM@EXAMPLE.COM (demande un TGT).
• Timestamp chiffré avec la clé dérivée du password d'Alice (pre-authentication).
• Options (flags, durée demandée, etc.).

AS-REP retourné par le KDC :

• TGT : chiffré avec la krbtgt key (opaque pour Alice, seul le KDC peut le lire).
• TGS session key : chiffrée avec la clé long-term d'Alice (elle peut la déchiffrer avec son password).

Alice obtient ainsi :

• Un TGT qu'elle ne peut pas lire (juste présenter au KDC ultérieurement).
• Une TGS session key qu'elle peut utiliser pour chiffrer ses futures requêtes au TGS.

Note critique : la pre-authentication avec password-derived key prouve au KDC qu'Alice connaît son password, sans le transmettre.

3.2 Étape 2 - TGS-REQ et TGS-REP

Alice veut accéder à un service, par exemple cifs/fileserver.example.com (partage de fichiers).

TGS-REQ envoyé par Alice au KDC :

• Son TGT (réutilisé).
• Un Authenticator : timestamp chiffré avec la TGS session key (prouve qu'Alice détient la session key).
• Le SPN (Service Principal Name) cible : cifs/fileserver.example.com.

Le KDC :

• Déchiffre le TGT avec la krbtgt key, valide son intégrité et expiration.
• Déchiffre l'Authenticator avec la TGS session key du TGT, valide le timestamp.
• Vérifie que le SPN demandé existe.

TGS-REP retourné :

• Service Ticket : chiffré avec la clé long-term du service (opaque pour Alice).
• Service session key : chiffrée avec la TGS session key (Alice peut la déchiffrer).

3.3 Étape 3 - AP-REQ et AP-REP

Alice utilise son Service Ticket pour accéder au service.

AP-REQ envoyé par Alice au service :

• Le Service Ticket.
• Un Authenticator : timestamp chiffré avec la Service session key.

Le service :

• Déchiffre le Service Ticket avec sa propre clé long-term.
• Récupère la Service session key et les attributs du client.
• Déchiffre l'Authenticator, valide le timestamp (fenêtre +/- 5 min par défaut).
• Vérifie que le principal et les autorisations sont corrects.

AP-REP optionnel : le service peut répondre avec un timestamp chiffré pour prouver son identité (mutual authentication).

À ce stade, Alice et le service partagent une session key et peuvent communiquer chiffré.

3.4 Pourquoi cette architecture

Le design Kerberos vise plusieurs objectifs :

• Single sign-on : Alice entre son password une fois, les futures authentifications utilisent le TGT sans retaper.
• Pas de password transmis : même sur un réseau hostile, seul un timestamp chiffré avec la clé dérivée du password circule.
• Délégation : un service peut obtenir un ticket au nom d'Alice pour agir en son nom.
• Scale : le KDC n'a pas besoin de connaître les services directement, juste leurs clés long-term.

4. La cryptographie dans Kerberos

4.1 Algorithmes historiques et modernes

4.2 Pourquoi désactiver RC4

RC4-HMAC est encore supporté par défaut dans beaucoup de domaines AD pour compatibilité :

• Permet le Kerberoasting efficace : le password du service account peut être bruteforcé depuis un Service Ticket capturé avec RC4, bien plus rapidement que AES.
• Cassé cryptographiquement (biais connus depuis 2001).
• Microsoft recommande désactivation depuis Windows Server 2008 R2.

Désactivation :

• GPO : Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos. Décocher DES_CBC_CRC, DES_CBC_MD5, RC4_HMAC_MD5. Laisser AES128 et AES256.
• Clé registry msDS-SupportedEncryptionTypes sur les comptes pour forcer AES.

Important : vérifier compatibilité avant déploiement (vieux services peuvent exiger RC4).

4.3 String-to-key

Le password d'un utilisateur est transformé en clé cryptographique via string-to-key :

• RC4-HMAC : MD4(UTF-16LE(password)). Rapide → bruteforcé facile.
• AES256 : PBKDF2-SHA1 avec salt REALM + principal, 4096 iterations (default faible par standards 2026).

Les tickets modernes utilisent AES256, mais la clé RC4-HMAC co-existe souvent côté KDC → attaquant peut demander un ticket RC4 et le bruteforcer.

5. Kerberos dans Active Directory

5.1 KDC = Domain Controller

Chaque Domain Controller (DC) d'un domaine AD est aussi un KDC Kerberos. Les DC répliquent entre eux la base (ntds.dit) qui contient :

• Comptes utilisateurs avec hashes.
• Comptes ordinateurs.
• Comptes de service avec SPNs.
• La clé secrète krbtgt.

5.2 Le compte krbtgt - la clé du royaume

krbtgt est un compte spécial dans chaque domaine AD :

• Créé automatiquement à la création du domaine.
• Désactivé par défaut pour login humain.
• Son hash NTLM sert de clé pour chiffrer/déchiffrer les TGTs.
• Compromission = Golden Ticket possible = compromission totale du domaine.

5.3 SPN (Service Principal Name)

Identifiant unique d'un service dans le domaine. Format :

service-class/host-name[:port]/service-name

Exemples :

• cifs/fileserver.example.com : partage de fichiers.
• MSSQLSvc/sqlserver.example.com:1433 : serveur SQL.
• HTTP/iis.example.com : site IIS.
• ldap/dc1.example.com : LDAP sur un DC.

Chaque SPN est associé à un compte utilisateur ou ordinateur qui peut l'offrir.

5.4 UPN (User Principal Name)

Identifiant moderne pour les users : alice@example.com. Pas obligatoire mais recommandé (compatibilité cloud Entra ID).

5.5 Trusts entre domaines

Kerberos supporte la cross-realm authentication via des trusts entre domaines. Chaque trust a sa propre clé symétrique partagée entre les deux KDCs.

Attention : un trust compromis peut permettre l'escalade cross-domaine via Golden Ticket inter-forêt (EuPathetic, SID History).

6. Les 10 attaques Kerberos classiques

6.1 Kerberoasting - le plus fréquent

Principe : un utilisateur authentifié demande un Service Ticket pour un SPN. Le ticket est chiffré avec la clé long-term du service account. Si cette clé est faible (password court ou courant), l'attaquant bruteforce offline.

Impact : compromission du service account, souvent à privilèges élevés.

Particulièrement efficace avec RC4 (crack rapide) vs AES (plus lent).

Outils : Rubeus (kerberoast), Impacket (GetUserSPNs.py).

Mitigation :

• Service accounts avec passwords longs aléatoires (min 25 caractères).
• Group Managed Service Accounts (gMSA) : passwords gérés automatiquement par AD, rotés tous les 30j, 256 caractères.
• Désactiver RC4.
• Monitoring de demandes de ST en masse.

6.2 AS-REP Roasting

Principe : certains comptes utilisateurs ont le flag DONT_REQ_PREAUTH (pre-authentication désactivée). L'attaquant peut demander directement un AS-REP pour eux sans authentification préalable, et bruteforce hors ligne.

Impact : compromission du user si password faible.

Outils : Rubeus (asreproast), Impacket (GetNPUsers.py).

Mitigation : retirer le flag DONT_REQ_PREAUTH sur tous les users (rare qu'il soit justifié).

Requête PowerShell pour lister les comptes vulnérables :

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties *

6.3 Pass-the-Ticket

Principe : l'attaquant vole un ticket (TGT ou Service Ticket) depuis la mémoire LSASS d'une machine compromise, et le rejoue sur une autre machine.

Outils : Rubeus (ptt), Mimikatz (kerberos::ptt), Impacket.

Impact : usurpation du user cible sans connaître son password.

Mitigation :

• Credential Guard (Windows 10+) : isole LSASS des outils de dump.
• Protected Users group : tickets short-lived non rollés.
• Réduire la durée de vie des TGT.

6.4 Golden Ticket

Principe : l'attaquant avec le hash krbtgt peut forger un TGT arbitraire (n'importe quel user, n'importe quels groupes, durée 10 ans si souhaité).

Comment obtenir le hash krbtgt : DCSync (voir 6.7), dump NTDS.dit, compromission d'un DC.

Impact : persistence totale du domaine. Même si l'admin change tous les passwords, le Golden Ticket reste valide tant que le krbtgt n'est pas roté deux fois.

Outils : Mimikatz (kerberos::golden), Rubeus (golden).

Mitigation :

• Rotation du krbtgt deux fois (script Microsoft "New-KrbtgtKeys.ps1").
• Fréquence recommandée : tous les 6-12 mois, + rotation en post-incident.
• Rigoureuse protection des DCs (Tier 0 model).
• Detection Defender for Identity (alerte sur Golden Ticket improbable).

6.5 Silver Ticket

Principe : l'attaquant avec le hash NTLM d'un service account peut forger un Service Ticket pour ce service directement (sans passer par le KDC).

Impact : accès au service usurpé. Plus discret qu'un Golden Ticket (aucune interaction avec KDC).

Mitigation :

• Passwords forts pour service accounts (gMSA).
• Monitoring des connexions au service.
• Signature et validation du PAC (Privilege Attribute Certificate) - activée par défaut depuis Windows Server 2008.

6.6 Skeleton Key

Principe : malware installé sur un DC qui modifie LSASS pour accepter un "password universel" en plus du password réel de chaque user.

Outils : Mimikatz (misc::skeleton).

Impact : compromission silencieuse du domaine.

Mitigation :

• Protection des DCs (Tier 0).
• Credential Guard sur DCs (Windows Server 2019+).
• Monitoring LSASS anomalies (Defender for Identity).

6.7 DCSync

Principe : abuse de la réplication AD. Un compte avec les droits Replicating Directory Changes + Replicating Directory Changes All peut demander à un DC de répliquer le hash de n'importe quel compte (incluant krbtgt).

Impact : récupération du hash krbtgt → Golden Ticket → compromission totale.

Outils : Mimikatz (lsadump::dcsync), Impacket (secretsdump.py).

Mitigation :

• Least privilege sur les DROIT de réplication : seuls les DCs et SA exceptionnels devraient l'avoir.
• Defender for Identity : détecte DCSync via observation du trafic RPC MS-DRSR.
• Audit ACL sur la partition domaine.

6.8 Unconstrained Delegation

Principe : un compte avec TrustedForDelegation reçoit le TGT du user lors d'une connexion Kerberos. L'attaquant qui compromet la machine de ce compte récupère les TGTs des users qui s'y sont connectés.

Impact : credential theft massive.

Scénarios : forcer un admin à se connecter (printer exploitation - "The Printer Bug"), SPN injection.

Mitigation :

• Retirer Unconstrained Delegation sur tous les comptes sauf cas justifié (rare).
• Protected Users group pour les admins sensibles (immunise contre le forwarding de TGT).
• Account sensitive and cannot be delegated flag sur admins.

6.9 Constrained Delegation (S4U2Self + S4U2Proxy)

Principe : abuse du mécanisme "Service for User" qui permet à un service d'obtenir un ticket au nom d'un user sans son interaction. Si mal configuré ou combiné avec d'autres faiblesses, permet d'imposter n'importe quel user.

Outils : Rubeus (s4u).

Mitigation :

• Resource-Based Constrained Delegation (RBCD) configurée strictement.
• Protected Users pour admins.
• Monitoring PAC anomalies.

6.10 Resource-Based Constrained Delegation (RBCD) abuse

Principe : l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity permet à un compte d'agir au nom d'autres users vers une ressource. Si un attaquant peut écrire cet attribut sur une ressource, il peut ensuite l'abuser pour compromise.

Chaîne d'attaque classique : Relay NTLM → écriture RBCD sur machine → compromission.

Outils : Rubeus, Impacket (ntlmrelayx.py).

Mitigation :

• Restreindre les droits d'écriture sur msDS-AllowedToActOnBehalfOfOtherIdentity.
• Désactiver NTLM au maximum.
• Monitoring des modifications ACL AD critiques.

7. Hardening Kerberos 2026

7.1 Désactiver RC4 et DES

Via GPO appliqué à tous les comptes :

Network security: Configure encryption types allowed for Kerberos
  - AES128_HMAC_SHA1 : activé
  - AES256_HMAC_SHA1 : activé
  - Future encryption types : activé
  - RC4_HMAC_MD5 : désactivé
  - DES_CBC_CRC : désactivé
  - DES_CBC_MD5 : désactivé

Tester en preprod avant prod : certains services legacy peuvent casser.

7.2 Protected Users group

Groupe spécial Windows Server 2012 R2+ qui applique des restrictions fortes aux membres :

• Aucune NTLM authentication.
• Aucun cached credential.
• Aucun RC4 ou DES Kerberos.
• TGT réduit à 4 heures (vs 10 par défaut).
• Aucune Unconstrained Delegation.
• Aucune CredSSP delegation.

Membres recommandés : tous les comptes admin sensibles (Domain Admins, Enterprise Admins, etc.).

Attention : impact sur la compatibilité - tester avant déploiement large.

7.3 Authentication Policies and Silos

Windows Server 2012 R2+ permet de créer des policies qui restreignent où un user peut s'authentifier et quels services il peut utiliser.

Exemple : un compte Domain Admin ne peut se loguer QUE sur une PAW spécifique (Tier 0 workstation).

Configuration via :

• PowerShell : New-ADAuthenticationPolicy, New-ADAuthenticationPolicySilo.
• Associer user au silo, associer ressources (computers) au silo.

7.4 Kerberos Armoring (FAST)

FAST (Flexible Authentication Secure Tunneling) chiffre la pre-authentication Kerberos dans un tunnel armored (à partir du TGT de la machine). Mitigation contre :

• AS-REP Roasting.
• Certaines attaques offline sur timestamp pre-auth.

Activation :

• GPO Computer Configuration > Policies > Administrative Templates > System > Kerberos > Support client Kerberos armoring = Enabled.
• GPO KDC support for claims, compound authentication and Kerberos armoring = Always provide claims.

Prérequis : DFL Windows Server 2012+ et tous les DCs compatibles.

7.5 krbtgt rotation

Rotation automatique du password krbtgt à planifier :

• Fréquence recommandée : tous les 6-12 mois.
• Rotation en double obligatoire : le krbtgt conserve une version N-1 pour permettre aux tickets émis récemment de rester valides. Pour vraiment invalider les anciens Golden Tickets, roter 2 fois avec un délai > durée max d'un TGT (10h par défaut).
• Script Microsoft : New-KrbtgtKeys.ps1 publié sur GitHub.

7.6 Group Managed Service Accounts (gMSA)

Pour remplacer les service accounts avec password statique :

• Password géré automatiquement par AD, roté tous les 30 jours.
• Password aléatoire 240 caractères (immune au bruteforce).
• Récupéré par les machines autorisées via LDAP.
• Élimine Kerberoasting sur le compte.

Création :

New-ADServiceAccount -Name "gMSA_SQL" `
  -DNSHostName "gmsa-sql.example.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "SQLServers" `
  -Enabled $True

Recommandation 2026 : migrer tous les service accounts legacy vers gMSA.

7.7 Restriction des délégations

• Unconstrained Delegation : retirer sauf cas justifié. Audit périodique.
• Constrained Delegation : scope minimal des services autorisés.
• RBCD : contrôler les ACLs d'écriture.

Requête PowerShell pour lister les comptes Unconstrained Delegation :

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties *
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties *

7.8 Flags de comptes sensibles

• Account is sensitive and cannot be delegated : sur tous les comptes admin.
• Account does not require Kerberos preauthentication : désactiver partout sauf cas exceptionnel.

8. Détection des attaques Kerberos

8.1 Microsoft Defender for Identity

Anciennement Azure ATP, maintenant intégré à Microsoft 365 Defender. Analyse le trafic réseau vers les DCs pour détecter :

• Kerberoasting (demandes de ST en masse).
• AS-REP Roasting.
• Golden Ticket (certains patterns anormaux).
• Pass-the-Ticket (contexte de session anormal).
• DCSync (utilisation anormale de l'API MS-DRSR).
• Reconnaissance LDAP agressive.

Déploiement : agent sur chaque DC, envoi de télémétrie vers le cloud Microsoft.

Recommandation 2026 : incontournable pour environnement Microsoft 365 / Entra ID.

8.2 Sysmon sur DCs

Règles Sysmon (SwiftOnSecurity / Olaf Hartong templates) pour détecter :

• Dumps LSASS (Event ID 10 + Access Rules).
• Connexions anormales aux DCs (Event ID 3).
• Fichiers suspects créés (Event ID 11).

8.3 Windows Event Logs critiques

8.4 Règles Sigma publiques

Sigma project (github.com/SigmaHQ/sigma) contient des centaines de règles pour détection Kerberos et AD, convertibles vers SPL (Splunk), KQL (Sentinel), EQL (Elastic).

8.5 Outils tiers d'audit

• PingCastle (Vincent Le Toux) : audit AD complet avec score de maturité. Gratuit. Incontournable.
• Purple Knight (Semperis) : audit de misconfigurations AD, y compris Kerberos.
• Semperis DSP : Directory Services Protector, monitoring temps réel.
• ADRecon : PowerShell script open source pour audit AD.
• ADSecurity.org : site de référence avec articles détaillés (Sean Metcalf).

9. Kerberos hors Active Directory

9.1 Linux et MIT Kerberos

MIT Kerberos est disponible sur la majorité des distros Linux. Usages :

• Authentification SSH avec GSSAPI.
• NFSv4 avec sécurité Kerberos (sec=krb5p).
• PostgreSQL GSSAPI authentication.
• Apache mod_auth_gssapi pour SSO web.

9.2 macOS

Intégré depuis 10.4. Utilisable avec domaines AD ou MIT Kerberos.

9.3 Cross-realm

Possible entre un realm MIT et un realm Microsoft AD. Configuration plus manuelle mais opérationnelle.

9.4 Azure / Entra ID - l'ère hybride

Entra ID (ex-Azure AD) n'utilise pas Kerberos nativement. Elle utilise :

• OAuth 2.0 et OpenID Connect.
• SAML 2.0 pour apps fédérées.

Hybride : avec Entra Connect (ex-AADConnect), les comptes AD on-prem sont synchronisés vers Entra ID. Les users ont un TGT Kerberos on-prem ET un token OIDC cloud.

Azure AD Kerberos (2021+) : mode où Entra ID peut émettre des TGTs Kerberos pour ressources on-prem. Cas d'usage : accès fichiers on-prem depuis un device Azure AD joined.

10. Kerberos vs alternatives modernes

10.1 Les limites de Kerberos en 2026

• Clock-dependent : dérive horaire > 5 min casse l'auth.
• Synchronous KDC dependency : si les DCs tombent, auth impossible.
• Pas naturellement web : nécessite SPNEGO pour HTTP.
• Legacy crypto par défaut (RC4 reste activé pour compat dans beaucoup de domaines).
• Complexité : debugging difficile pour débutants.
• Conçu pour LAN : trusts cross-forest possibles mais complexes, scaling internet limité.

10.2 Comparaison avec OIDC

10.3 Avenir

Kerberos ne va pas disparaître : il sous-tend l'AD qui équipe encore 95 % des entreprises. Les initiatives actuelles :

• Modernisation : algos AES256-SHA256 (RFC 8009), Kerberos Armoring, Protected Users.
• Coexistence avec OIDC pour les ressources cloud (modèle hybride).
• Future roadmap Microsoft : plus d'intégration Entra ID, émission de tickets Kerberos depuis le cloud.

11. Outils - pentest et blue team

11.1 Pentest / Red team

11.2 Blue team / Audit

11.3 Purple team

Les exercices purple team combinent :

• Red team exécute des attaques (Kerberoasting, Pass-the-Ticket, etc.).
• Blue team cherche à détecter.
• Améliore les règles de détection et les hardening.

12. Checklist Kerberos hardening

Cryptographie

• RC4 désactivé dans les GPOs
• AES128 et AES256 activés
• DES désactivé (généralement déjà)
• Migration Windows Server 2022+ pour AES256-SHA256

Comptes

• Tous les admins dans Protected Users group
• Flag "Account is sensitive and cannot be delegated" sur admins
• Flag "DONT_REQ_PREAUTH" retiré sauf cas exceptionnel
• Service accounts migrés vers gMSA
• Passwords service accounts : 25 caractères minimum si gMSA non possible

Délégations

• Unconstrained Delegation retirée partout sauf justifié
• Constrained Delegation scoped minimum
• Audit périodique des délégations actives

krbtgt

• Rotation planifiée (6-12 mois)
• Rotation en double testée
• Rotation sur incident documentée

Infrastructure

• Kerberos Armoring (FAST) activé
• Authentication Policies et Silos pour admins
• NTLM désactivé au maximum
• NTP synchronisé sur tous les membres

Monitoring et détection

• Defender for Identity sur tous les DCs
• Sysmon sur DCs
• Event Log forwarding vers SIEM
• Sigma rules Kerberos déployées
• PingCastle audit trimestriel

Processus

• Red team Kerberos exercises annuels
• Procédure Golden Ticket response documentée
• Rotation krbtgt dans le runbook
• Formation ops équipe AD mise à jour

13. Verdict et posture Zeroday

Kerberos est techniquement mature (38 ans, v5 stabilisée depuis 1993) mais opérationnellement mal géré dans la majorité des entreprises en 2026. Le protocole lui-même est solide ; les problèmes viennent des defaults permissifs (RC4 activé, unconstrained delegation, mot de passe service accounts faibles) et du manque de rotation krbtgt.

Pour un administrateur AD : appliquer les 7 hardening du §7 élimine 80 % des vecteurs d'attaque Kerberos connus. Coût faible, impact massif.

Pour un blue teamer / SOC analyst : comprendre les flows Kerberos est la base pour détecter les attaques via Event Logs et Defender for Identity. Les patterns de Kerberoasting, Golden Ticket, Pass-the-Ticket sont identifiables avec les bons outils.

Pour un pentester : maîtriser Rubeus, Mimikatz et BloodHound, savoir enchaîner les techniques (Kerberoast → crack → reuse → privesc) est le cœur du métier sur cibles Windows enterprise.

Pour une organisation : un audit PingCastle + Purple Knight annuel donne une baseline objective. Les findings critiques sur Kerberos méritent un plan d'action prioritaire - ils conditionnent la résilience au ransomware et aux APT.

Pour approfondir : les prochains articles de la catégorie Active Directory & Windows détailleront chaque attaque (Kerberoasting, Golden Ticket, AD CS) et chaque brique de hardening (Tier Model, PAW, LAPS). Articles connexes : sécurité des comptes privilégiés pour le Tier Admin Model et PAM, PKI expliquée pour AD CS et certificats, MITRE ATT&CK expliqué pour le framework de détection, qu'est-ce qu'un spécialiste Active Directory Security pour le parcours métier.