Authentification inter-domaines : Kerberos referral et NTLM pass-through

Concept

Lorsqu’un utilisateur du Domaine A souhaite s’authentifier sur une ressource du Domaine B, Windows utilise l’un des deux protocoles d’authentification historiques :

Kerberos referral (recommandé / moderne) : le protocole Kerberos v5 étend son fonctionnement via les tickets d’aiguillage (Referral Tickets ou Cross-Realm TGTs). Le client interroge son propre KDC, qui lui renvoie un ticket referral pointant vers le KDC suivant dans l’arbre d’approbation, jusqu’au KDC hébergeant le SPN de la ressource cible.
NTLM pass-through (hérité / fallback) : si Kerberos échoue (absence de SPN, adresse IP utilisée au lieu du FQDN, pare-feu bloquant le port 88), le client utilise NTLM. NTLM ne supportant pas les referrals côté client, c’est le serveur de ressource qui contacte son contrôleur de domaine, lequel délègue la vérification de réponse au contrôleur de domaine de l’utilisateur via le service Netlogon (RPC sur port 445/135).

Pourquoi c’est important en DFIR

Comprendre la mécanique protocolaire détermine où chercher les preuves d’accès :

Dispersion des logs Kerberos : lors d’un referral Kerberos, des événements 4768 (TGT) apparaissent sur le DC du domaine de l’utilisateur, des événements 4769 (TGS de referral) apparaissent sur les DC intermédiaires et le DC cible, et l’événement 4624 apparaît sur la machine hébergeant la ressource.
Goulot d’étranglement et traçabilité NTLM pass-through : dans une authentification NTLM inter-domaine, le DC du domaine cible consigne l’Event ID 8004 (NTLM authentication to domain was forwarded to...) via NTLM Auditing, documentant précisément la route de validation Netlogon empruntée.
Faiblesses exploitables par les attaquants : l’authentification NTLM à travers une approbation expose le hash NTLM Netlogon et peut faire l’objet d’attaques par relais NTLM (NTLM Relay) vers d’autres serveurs du domaine de ressource ou de domaine tiers.

Comment ça fonctionne

1. La chaîne de Kerberos referrals

Imaginons user@child.corp.local accédant à fileserver.partner.local (relié par une Forest Trust entre corp.local et partner.local) :

[Client user@child]
   │ 1. TGS-REQ pour cifs/fileserver.partner.local
   ▼
[KDC child.corp.local] ──► Renvoie Referral TGT pour krbtgt/corp.local
   │
   │ 2. TGS-REQ pour cifs/fileserver.partner.local (avec Referral TGT)
   ▼
[KDC corp.local (Racine)] ──► Renvoie Referral TGT pour krbtgt/partner.local
   │
   │ 3. TGS-REQ pour cifs/fileserver.partner.local (avec Referral TGT inter-forêt)
   ▼
[KDC partner.local] ──► Renvoie TGS final pour cifs/fileserver.partner.local
   │
   │ 4. AP-REQ (Présente TGS final)
   ▼
[fileserver.partner.local] ──► Valide le ticket et accorde l'accès

2. Le mécanisme NTLM pass-through

[Client user@child]
   │ 1. Connexion SMB vers IP \10.0.1.50
   │ 2. Négociation NTLM & Challenge
   ▼
[Serveur de Fichiers (partner.local)]
   │ 3. Envoie Challenge/Response via Netlogon Secure Channel
   ▼
[DC partner.local]
   │ 4. Détecte que le domaine est child.corp.local
   │    Relaye la requête via RPC Netlogon inter-DC
   ▼
[DC child.corp.local]
   │ 5. Valide la réponse contre la base SAM/NTDS locale
   │ 6. Renvoie STATUS_SUCCESS au DC partner.local
   ▼
[DC partner.local] ──► Renvoie STATUS_SUCCESS au Serveur de Fichiers

Ce qui est possible

Reconstituer le chemin d’un attaquant via les événements 4769 : en corrélant le champ ServiceName (krbtgt/NOM_DE_DOMAINE) sur les DC successifs, l’enquêteur peut cartographier avec exactitude chaque saut inter-domaine franchi par l’adversaire.
Forcer le fallback NTLM : un attaquant peut volontairement forcer l’usage de NTLM en ciblant les ressources distantes par leur adresse IP plutôt que par leur nom DNS pour contourner les protections Kerberos (ex: FAST / Armoring) ou pour capturer/relayer des challenges Netlogon.
Auditer précisément le trafic NTLM inter-domaines : l’activation des stratégies de restriction NTLM (Network security: Restrict NTLM: Audit NTLM authentication in this domain) génère des événements très riches (8001 à 8004).

Ce qui n’est pas possible

Obtenir un referral Kerberos si le routage des suffixes DNS échoue : si le KDC source ne parvient pas à associer le SPN demandé à un suffixe de nom approuvé (Name Suffix Routing), il renvoie KDC_ERR_S_PRINCIPAL_UNKNOWN et le client bascule en NTLM ou échoue.
Utiliser Kerberos referral sans visibilité réseau sur tous les DC : le client doit obligatoirement être en mesure d’échanger avec les KDCs de chaque domaine le long de la chaîne de confiance.
Masquer le domaine d’origine dans le PAC Kerberos : le Privilege Attribute Certificate (PAC) contient obligatoirement le SID d’origine de l’utilisateur, même après plusieurs sauts de referrals.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« L’utilisateur n’a pas accès au DC distant, donc Kerberos ne peut pas fonctionner. »	Dans Kerberos Referral, le client doit impérativement contacter le KDC du domaine cible pour obtenir le TGS final. S’il n’a pas d’accès réseau au DC distant, Kerberos échoue et tente NTLM.
« Les événements 4769 avec ServiceName=krbtgt sont des attaques Golden Ticket. »	Non. C’est le fonctionnement légitime et standard de Kerberos Referral : un TGS pour `krbtgt/DOMAINE_DISTANT` est un ticket de renvoi inter-domaine ordinaire.
« NTLM Pass-Through fonctionne sans communication directe entre les DC. »	NTLM Pass-Through impose une liaison RPC Netlogon directe entre le DC du domaine cible et le DC du domaine de comptes.

Exemple concret d’investigation

Un incident de ransomware frappe un serveur applicatif dans subsidiary.corp. L’analyste DFIR inspecte les journaux :

Sur le serveur applicatif : Event ID 4624, LogonProcessName: NtLmSsp, Workstation Name: KALI-PENTEST, TargetUserName: admin_svc, TargetDomainName: PARENT_CORP.
Sur le DC de subsidiary.corp : Event ID 8004 (NTLM Auditing), montrant que l’authentification de admin_svc a été relayée via Netlogon vers le DC DC01.parent_corp.local.
Sur le DC DC01.parent_corp.local : Event ID 4624 (Logon Type 3) émis par le DC de la filiale.
Conclusion : l’attaquant a exploité une connexion NTLM avec un compte du domaine parent pour s’authentifier sur le domaine enfant, laissant une chaîne d’événements Netlogon Pass-Through parfaitement corrélée.

Artefacts et traces forensiques

Journaux de sécurité DC — Kerberos referral :
- Event ID 4768 : demande de TGT initial dans le domaine d’origine.
- Event ID 4769 : demande de TGS avec ServiceName: krbtgt/<NOM_DOMAINE_DISTANT> (Ticket Referral).
- Ticket options : présence du flag 0x40810010 ou 0x40800000 indiquant un referral.
Journaux de sécurité DC — NTLM pass-through :
- Event ID 8004 (Microsoft-Windows-NTLM/operational) : audit du routage NTLM (The domain controller forwarded the authentication request for the user...).
Journaux de sécurité du serveur cible :
- Event ID 4624 : logon Type 3 avec indication du protocole (Kerberos vs NtLmSsp) et des informations du domaine source.

Méthodes d’investigation

Tracer la séquence complète de referrals Kerberos : Interroger les événements 4769 sur l’ensemble des DC des domaines intermédiaires en filtrant sur l’adresse IP cliente et le compte utilisateur.
Activer OU collecter les logs NTLM operational : Analyser le journal Microsoft-Windows-NTLM/Operational pour isoler les requêtes relayées par le canal Netlogon.
Inspecter le cache de tickets Kerberos sur l’hôte source : Exécuter klist sur le poste suspect pour examiner les tickets krbtgt/ distants en mémoire.

Outils d’investigation

Klist (Windows natif) :
Fenêtre de terminal
```
klist
klist purge
```

Kansa / log parser PowerShell :

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4769} |
  Where-Object { $_.Properties[0].Value -like 'krbtgt/*' } |
  Select-Object TimeCreated, @{N='TargetUser';E={$_.Properties[4].Value}}, @{N='Service';E={$_.Properties[0].Value}}, @{N='IPAddress';E={$_.Properties[6].Value}}

Wireshark / network miner : Analyse des paquets Kerberos TGS-REQ (port 88) contenant le champ PA-DATA: PA-PAC-REQUEST et les referrals.

Points clés à retenir

Kerberos Referral est une navigation étape par étape effectuée par le client.
NTLM Pass-Through est un relais d’authentification pris en charge par les contrôleurs de domaine via Netlogon.
Les TGS pour krbtgt/<DOMAINE> dans l’Event 4769 sont la signature normale des referrals inter-domaines.
Le ciblage par adresse IP force le protocole NTLM au détriment de Kerberos.