Triage DFIR : « ce compte existe-t-il, d'où vient-il, où a-t-il le droit d'aller ? »

Concept

Lorsqu’une alerte EDR ou SIEM signale une activité suspecte associée à un nom de compte (ex: CORP\svc_deploy, DESKTOP-89A\admin, ou S-1-5-21-98765-1105), l’analyste DFIR doit neutraliser les hypothèses trompeuses en exécutant une procédure de qualification d’identité en trois dimensions :

L’existence et la nature : le compte est-il un compte d’utilisateur humain, un compte de machine ($), un compte de service géré (gMSA), un compte local machine, ou un compte fantôme généré par un ticket forgé ?
La provenance et la chaîne de confiance : l’authentification a-t-elle été validée par la SAM locale, le DC local, un DC d’une autre forêt via une relation de confiance, ou n’a-t-elle jamais fait l’objet de validation (Silver Ticket) ?
Le périmètre effectif : les droits exercés correspondent-ils aux autorisations normales du compte ou révèlent-ils une élévation de privilèges ou une persistance ?

Pourquoi c’est important en DFIR

Cette méthodologie évite les erreurs de diagnostic les plus destructrices en crise :

Ne pas confondre compte local et compte de domaine : bannir un compte Administrator au niveau du domaine ne stoppe pas un attaquant qui utilise le compte .\Administrator local sur des dizaines de serveurs.
Détecter les comptes fantômes (ghost principals) : si un compte apparaît dans l’Event ID 4624 mais qu’il est introuvable dans l’Active Directory (Get-ADUser renvoie une erreur), l’analyste fait face à un Golden Ticket ou à une machine désynchronisée.
Isoler le domaine source compromis : si le compte provient d’une filiale reliée par une approbation, isoler le compte dans le domaine local de ressources ne suffit pas ; il faut couper ou filtrer la relation d’approbation à la frontière.

Comment ça fonctionne

La matrice de qualification de l’identité en DFIR

Nom de compte extrait des logs : "TargetDomainName\TargetUserName"
                                  │
      ┌───────────────────────────┴───────────────────────────┐
      ▼                                                       ▼
TargetDomainName == ComputerName           TargetDomainName == AD Domain
      │                                                       │
      ▼                                                       ▼
[ COMPTE LOCAL ]                                       [ COMPTE DE DOMAINE ]
- Base : SAM locale (%SystemRoot%\System32\config\SAM) - Base : ntds.dit sur les DC
- SID : Préfixe Machine (S-1-5-21-M-RID)               - SID : Préfixe Domaine (S-1-5-21-D-RID)
- Logs DC : AUCUNE trace sur les DC                    - Logs DC : Events 4768 / 4769 / 4776
- Rebond réseau : Pass-the-Hash local possible         - Rebond réseau : Kerberos / NTLM

Les 3 étapes systématiques de qualification

Validation de l’existence :
- Interroger le DC local : Get-ADUser -Identity <TargetUserName>.
- Si introuvable : interroger le Catalogue Global (-Server <GC>:3268) pour vérifier si le compte réside dans un autre domaine de la forêt.
- Si toujours introuvable : vérifier la SAM locale de la machine cible (Get-LocalUser).
- Si introuvable nulle part : suspecter immédiatement un Golden Ticket forgé avec un faux nom d’utilisateur.
Identification de l’origine :
- Examiner l’Event 4624 sur la machine cible : vérifier LogonProcessName (Kerberos vs NtLmSsp).
- Si Kerberos : vérifier sur les DC quel KDC a émis l’Event 4768 (TGT) ou l’Event 4769 (TGS).
- Si NTLM : vérifier sur le DC local l’Event 4776 et l’Event 8004 pour déterminer quel DC distant a validé le mot de passe via Netlogon.
Cartographie des droits légitimes :
- Extraire les groupes réels du compte : Get-ADPrincipalGroupMembership <Account>.
- Comparer avec les SIDs figurant dans le jeton d’accès lors de la connexion (Event 4627 - Group Membership Information).
- Tout SID présent dans le jeton mais absent de l’annuaire révèle une injection de droits (sIDHistory ou falsification de PAC).

Ce qui est possible

Confirmer instantanément si une identité est locale OU de domaine : en comparant le SID de l’utilisateur avec le SID de la machine hôte.
Déceler un golden ticket dès le triage : si un compte s’authentifie en Kerberos sans aucun événement 4768 sur les KDC, ou si le nom d’utilisateur n’existe pas dans la base LDAP.
Identifier la machine physique d’origine : le champ IpAddress et WorkstationName dans l’Event 4624 documentent la provenance réseau initiale.

Ce qui n’est pas possible

Garantir l’identité réelle d’un utilisateur sous NTLM si le réseau n’impose pas la signature SMB : un attaquant en position d’homme du milieu (MitM) peut relayer une session NTLM sans connaître les identifiants de la victime.
Retrouver dans les logs du DC les actions locales d’un compte local : la SAM locale est totalement autonome ; ses ouvertures de session ne remontent jamais aux DC.
Déterminer les autorisations NTFS d’un utilisateur depuis le contrôleur de domaine : les permissions NTFS sont hébergées sur les disques des serveurs de fichiers ; le DC ne connaît que les appartenances aux groupes.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« L’utilisateur s’appelle DOMAIN\Admin, donc c’est un compte du domaine. »	Vérifiez le champ `TargetDomainName` et `TargetUserSid`. Si le domaine affiché est en réalité le nom d’hôte de la machine, c’est un compte local.
« Si le compte existe dans l’AD, c’est forcément l’utilisateur légitime qui s’est connecté. »	Cela prouve seulement que ses identifiants (mot de passe, hash ou ticket) ont été présentés avec succès.
« Ce compte n’a aucun droit dans l’AD, donc il ne peut rien faire. »	Un utilisateur standard du domaine peut avoir été ajouté dans le groupe local `Administrators` de serveurs spécifiques sans posséder aucun droit dans l’AD.

Exemple concret d’investigation

Alerte SOC : un compte nommé sql_admin a exécuté vssadmin delete shadows sur le serveur de bases de données DB01. L’analyste DFIR applique la méthode en 3 questions :

Existe-t-il ?
- Get-ADUser sql_admin $\rightarrow$ Erreur : Cannot find an object with identity: 'sql_admin'.
- Connexion sur DB01 : Get-LocalUser sql_admin $\rightarrow$ Présent, créé il y a 3 ans par un prestataire.
- SID : S-1-5-21-44332211-1004 (Préfixe correspondant au SID de la machine DB01).
D’où vient-il ?
- Event 4624 sur DB01 : LogonType: 3, LogonProcessName: NtLmSsp, Workstation Name: LAPTOP-PRESTA, IpAddress: 192.168.20.45.
- Conclusion : authentification SAM locale via SMB en provenance d’un PC portable du réseau interne.
Où a-t-il le droit d’aller ?
- sql_admin est membre d’Administrators sur DB01. Il n’a aucun droit sur l’AD ni sur les autres serveurs.
Action corrective immédiate : isoler 192.168.20.45, bloquer le compte local sur DB01. L’Active Directory n’a pas besoin d’une réinitialisation de krbtgt.

Artefacts et traces forensiques

Sur la machine cible :
- Event ID 4624 : TargetDomainName, TargetUserName, TargetUserSid, LogonProcessName, IpAddress.
- Event ID 4627 (group membership information) : liste complète des SIDs injectés dans le jeton d’accès lors du logon.
- Event ID 4672 (special privileges assigned) : liste des privilèges OS accordés.
Sur les contrôleurs de domaine :
- Event ID 4768 : demande de TGT (présente si compte de domaine sous Kerberos).
- Event ID 4776 : validation NTLM (présente si compte de domaine sous NTLM).

Méthodes d’investigation

Comparer TargetDomainName et ComputerName : Déterminer immédiatement si l’authentification est locale (SAM) ou centralisée (Domaine).
Valider le préfixe du SID : Comparer les sous-autorités du SID (S-1-5-21-...) avec le SID du domaine obtenu via (Get-ADDomain).DomainSID.
Corréler l’event 4624 avec les KDC de la forêt : Vérifier si le DC a émis un ticket pour cette session ou si l’Event 4624 est orphelin de trace KDC.

Outils d’investigation

PowerShell natif :

# Extraire le SID du domaine pour comparaison
$DomainSID = (Get-ADDomain).DomainSID.Value

# Comparer avec un SID suspect
$SuspectSID = "S-1-5-21-987654321-1001"
if ($SuspectSID -like "$DomainSID*") { "Compte du Domaine" } else { "Compte Local ou Externe" }

PsGetsid (sysinternals) :
Fenêtre de terminal
```
psgetsid TARGET-HOST
```

Points clés à retenir

Ne jamais se fier uniquement au nom d’utilisateur : seul le SID identifie l’autorité émettrice avec certitude.
Si TargetDomainName == ComputerName, l’authentification est locale et le DC n’a aucune visibilité.
Une authentification Kerberos réussie sans Event 4768 sur les DC indique un ticket forgé (Golden/Silver Ticket).
Les droits d’un compte sur une machine dépendent de la DACL locale et de ses groupes dans le jeton (Event 4627).