NTLM vs Kerberos : différences fondamentales en investigation

Concept

Dans un domaine Active Directory moderne, deux protocoles d’authentification cohabitent :

Kerberos V5 (protocole par défaut et privilégié) : repose sur la cryptographie à clés secrètes symétriques et un tiers de confiance central (le Key Distribution Center - KDC, hébergé sur chaque contrôleur de domaine). L’utilisateur ne transmet jamais son mot de passe ni son hash au serveur de ressources.
NTLM (NT LAN manager - protocole hérité) : repose sur un échange de défi-réponse en trois étapes (Negotiate, Challenge, Authenticate). Le client prouve sa connaissance du mot de passe en chiffrant un défi aléatoire avec son hash NTLM.

Pourquoi c’est important en DFIR

Identifier si une action a été exécutée via NTLM ou Kerberos conditionne l’ensemble de l’enquête :

Localisation des traces : une authentification Kerberos laisse des traces immédiates et détaillées sur le KDC (Events 4768 et 4769 indiquant le nom du compte, l’adresse IP et le SPN du service). Une authentification NTLM vers une ressource locale (ou un compte local) ne laisse aucune trace sur les DC.
Vulnérabilité aux attaques :
- NTLM est vulnérable aux attaques par relais (NTLM Relay) et au vol de hash pour réutilisation directe (Pass-the-Hash).
- Kerberos est immunisé contre le Pass-the-Hash simple (il exige le calcul d’un TGT chiffré AES/RC4), mais il est vulnérable aux attaques par vol de tickets (Pass-the-Ticket, Golden/Silver Ticket) et aux attaques hors-ligne (Kerberoasting, AS-REP Roasting).
Détection des anomalies de protocole : lorsqu’un attaquant utilise des outils de pentest comme CrackMapExec/NetExec ou Impacket par adresse IP, Windows désactive Kerberos et bascule automatiquement en NTLM. Ce basculement est un indicateur de compromission majeur.

Comment ça fonctionne

Matrice comparative des protocoles en DFIR

Critère d’investigation	Kerberos v5	NTLMv2
Autorité centrale	KDC (port 88 TCP/UDP)	Aucun (décentralisé ou Netlogon RPC)
Preuve d’identité	Tickets chiffrés (TGT, TGS avec PAC)	Réponse chiffrée au Challenge (HMAC-MD5)
Traces sur le DC lors d’un logon	Event 4768 (TGT) + Event 4769 (TGS)	Event 4776 (Netlogon validation)
Traces sur la machine cible	Event 4624 (`LogonProcessName: Kerberos`)	Event 4624 (`LogonProcessName: NtLmSsp`)
Niveau de chiffrement	AES-256 (0x12), AES-128 (0x11), RC4 (0x17)	DES / HMAC-MD5 / RC4
Support de la délégation	Oui (Unconstrained, Constrained, RBCD)	Non (sauf transition via Kerberos S4U)
Sensibilité au ciblage par IP	Échec systématique (Kerberos exige un SPN FQDN)	Fonctionnement transparent

Ce qui est possible

Identifier le protocole exact utilisé lors de chaque connexion : le champ AuthenticationPackageName / LogonProcessName de l’Event ID 4624 indique Kerberos ou NtLmSsp.
Déterminer le type de chiffrement d’un ticket Kerberos : L’Event ID 4769 consigne le champ TicketEncryptionType (0x12 = AES-256, 0x17 = RC4 / Arcfour, souvent révélateur de tickets forgés par Mimikatz ou de Kerberoasting).
Identifier la station de travail d’origine en NTLM : L’Event ID 4624 pour un logon NTLM fournit le champ Workstation Name transmis par le client.

Ce qui n’est pas possible

Obtenir un ticket Kerberos en ciblant une machine par son adresse IP : Kerberos requiert impérativement la résolution d’un Service Principal Name (SPN) associé à un compte dans l’annuaire. Une commande comme dir \\192.168.1.10\c$ bascule inévitablement en NTLM.
Relayer un ticket Kerberos comme on relaye une authentification NTLM : les tickets Kerberos sont liés cryptographiquement à une clé de session et à un service cible spécifique ; ils ne peuvent pas être rejoués arbitrairement sur un autre service sans délégation.
Trouver des traces d’event 4768/4769 pour une authentification NTLM : si l’attaquant a utilisé NTLM, les journaux Kerberos du DC restent totalement vierges de cette transaction.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« Nous avons vu un Event 4624 sur le serveur de fichiers, donc le compte a été vérifié par le DC. »	Si le `LogonProcessName` est `NtLmSsp` et que le compte est un compte local de la machine, le DC n’a jamais été contacté.
« Le Pass-the-Hash fonctionne avec Kerberos. »	Non. Le Pass-the-Hash au sens strict injecte un hash NT dans NTLM. Pour Kerberos, on parle d’Overpass-the-Hash / Pass-the-Key (conversion du hash en TGT).
« La présence de l’Event 4776 prouve que l’utilisateur a réussi à se connecter au serveur. »	L’Event 4776 prouve seulement que le contrôleur de domaine a validé les identifiants NTLM. L’autorisation d’accès sur le serveur cible peut avoir été refusée par la DACL.

Exemple concret d’investigation

Dans une campagne d’espionnage, l’analyste DFIR examine deux connexions simultanées vers le serveur comptable SRV-FINANCE :

Première connexion :
- Event 4624 : TargetUserName: admin_local, LogonProcessName: NtLmSsp, Workstation Name: LAPTOP-DEV.
- DC logs : aucun événement 4768, 4769 ni 4776.
- Diagnostic : pass-the-Hash NTLM utilisant un compte administrateur local sans passer par le DC.
Deuxième connexion :
- Event 4624 : TargetUserName: DA_Bob, LogonProcessName: Kerberos, Workstation Name: -.
- DC logs : event 4768 émis à 02h14, suivi d’un Event 4769 pour cifs/SRV-FINANCE.corp.local avec TicketEncryptionType: 0x17 (RC4).
- Diagnostic : mouvement latéral Kerberos suspect (l’usage de RC4 dans un environnement moderne pointe vers un ticket forgé ou une négociation dégradée volontaire).

Artefacts et traces forensiques

Événements sur les contrôleurs de domaine :
- Event ID 4768 (Kerberos TGT request) : audit de l’authentification initiale. Indique le type de pré-authentification (PreAuthType: 2 = mot de passe standard, PreAuthType: 0 = AS-REP Roasting).
- Event ID 4769 (Kerberos TGS request) : audit de l’accès à un service (nom du SPN dans ServiceName, adresse IP client, type de chiffrement).
- Event ID 4776 (credential validation via netlogon) : validation d’un hash NTLM par le DC (PackageName: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0).
Événements sur les serveurs et postes cibles :
- Event ID 4624 (successful logon) : examiner LogonType (Type 3 = Réseau), AuthenticationPackageName, LogonProcessName (Kerberos vs NtLmSsp), ElevatedToken.
- Event ID 4625 (failed logon) : examiner Status et SubStatus (ex: 0xC000006A = mauvais mot de passe NTLM, 0xC00002F5 = pré-authentification Kerberos échouée).

Méthodes d’investigation

Identifier le protocole dans l’event 4624 : Extraire les valeurs de LogonProcessName pour scinder les investigations en flux Kerberos et flux NTLM.
Pour les sessions Kerberos, remonter aux KDCs : Rechercher dans les événements 4769 du DC la demande de ticket correspondant à l’horodatage et à l’IP source de l’Event 4624.
Pour les sessions NTLM, pister le canal netlogon : Vérifier si le DC a enregistré un Event 4776 avec le même utilisateur et la même heure pour confirmer s’il s’agit d’un compte de domaine ou d’un compte local.

Outils d’investigation

PowerShell / Get-WinEvent :

# Extraire les connexions NTLM réseau
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} |
  Where-Object { $_.Properties[8].Value -eq 'NtLmSsp' -and $_.Properties[7].Value -eq 3 } |
  Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}}, @{N='Workstation';E={$_.Properties[11].Value}}, @{N='IP';E={$_.Properties[18].Value}}

Klist :
Fenêtre de terminal
```
klist sessions
klist tickets
```

Points clés à retenir

Kerberos s’appuie sur le KDC (Events 4768, 4769) ; NTLM s’appuie sur Netlogon (Event 4776) ou la SAM locale.
Le ciblage par adresse IP force systématiquement le basculement en NTLM.
Le Pass-the-Hash classique n’est possible qu’en NTLM.
Les tickets Kerberos chiffrés en RC4 (0x17) doivent immédiatement être considérés comme suspects dans un parc sous Windows Server 2016+.