Cas limites, pièges et faux amis en environnement AD réel

Concept

Les cas limites (Edge Cases) et faux amis (False Friends) désignent les anomalies techniques, comportements de rétrocompatibilité ou artefacts trompeurs susceptibles d’induire en erreur un enquêteur DFIR et de mener à des conclusions erronées.

Dans un annuaire d’entreprise ayant traversé 10 à 20 ans d’existence et de migrations successives, ces pièges se concentrent autour de 5 domaines :

L’illusion du renommage : modifier sAMAccountName ou UserPrincipalName ne modifie jamais le SID de l’objet.
Le décalage d’horloge (clock skew) : par défaut, Kerberos tolère jusqu’à 5 minutes d’écart d’horloge, perturbant la corrélation chronologique fine.
Les comptes machines et l’authentification réseau : les comptes se terminant par $ (COMPUTER$) exécutent des connexions réseau légitimes massives (Event 4624 Type 3) souvent confondues avec des mouvements latéraux.
La persistance de sessions en cache : des tickets ou secrets NTLM restent en mémoire LSASS des heures après la déconnexion effective de l’utilisateur.
Les conflits de réplication (CNF mangling) : la création d’objets homonymes simultanés génère des objets corrompus (CN=User\0ACNF:GUID).

Pourquoi c’est important en DFIR

Identifier ces pièges permet d’éviter les deux écueils majeurs de la réponse à incident :

Le faux positif conduisant à l’arrêt injustifié de la production : confondre une tâche de maintenance SCCM/MECM exécutée sous SYSTEM avec un déploiement de ransomware via SMB.
Le faux négatif laissant subsister l’attaquant : croire qu’un compte a été neutralisé parce qu’il a été renommé ou désactivé, alors que des tickets Kerberos actifs restent valables en mémoire jusqu’à leur expiration.
La contamination des indices chronologiques : interpréter des timestamps d’événements sans corriger la dérive temporelle du serveur source, faussant l’ordre de causalité des actions de l’attaquant.

Comment ça fonctionne

Revue détaillée des 5 pièges majeurs

1. Le renommage de compte malveillant

L’attaquant renomme le compte CORP\compromised_user en CORP\Exchange_Health_Check.
Dans les journaux de sécurité, les événements 4624 afficheront désormais le nouveau nom innocent.
Réalité forensique : le SID (TargetUserSid) reste strictement inchangé. Seule la recherche par SID permet d’établir la continuité de l’activité.

2. L’authentification anonyme et les comptes machine ($)

Les machines du domaine contactent en permanence les DC et les serveurs de fichiers en SMB sous leur identité machine HOSTNAME$ pour vérifier les GPO ou le temps NTP.
Ces connexions génèrent des centaines d’Event IDs 4624 (Logon Type 3) sous NT AUTHORITY\ANONYMOUS LOGON ou DOMAIN\MACHINE$. Elles ne doivent pas être confondues avec des mouvements latéraux humains.

3. Le cache LSASS persistant (orphaned credential trap)

Lorsqu’un administrateur ferme sa session RDP, Windows ferme la session interactive (Event 4634/4647).
Cependant, le processus lsass.exe conserve souvent en mémoire les clés Kerberos et hashs NTLM jusqu’au redémarrage de la machine ou écrasement de la mémoire vive. Un attaquant qui dumpe LSASS 8 heures plus tard peut récupérer ces identifiants bien que l’administrateur soit déconnecté.

4. Le champ `Workstation Name` forgé sous NTLM

Dans un échange NTLM (Event 4624), le champ Workstation Name est une chaîne de caractères envoyée en clair par le client.
L’attaquant peut y inscrire n’importe quelle valeur arbitraire (ex: DC01, BACKUP, SRV-CLEAN). Seule l’adresse IP (IpAddress) transmise par la couche TCP/IP est fiable.

5. La tolérance de dérive Kerberos (Kerberos clock skew)

Kerberos autorise jusqu’à 300 secondes (5 minutes) de dérive par défaut (MaxTolerance).
Les timestamps dans les tickets chiffrés et les journaux des DC peuvent être décalés par rapport aux logs de l’EDR ou du pare-feu, rendant la corrélation seconde par seconde trompeuse sans normalisation NTP.

Ce qui est possible

Retrouver le nom historique d’un compte via son SID : même si un compte a été renommé 10 fois, son SID initial est immuable.
Repérer les faux noms de stations de travail en NTLM : en comparant le champ Workstation Name avec la résolution DNS inverse de IpAddress.
Dater la création réelle d’un objet via l’annuaire : l’attribut whenCreated de l’objet Active Directory résiste aux modifications de date système locales.

Ce qui n’est pas possible

Se fier à Account Name dans l’event 4624 pour identifier une machine d’origine : le client NTLM contrôle entièrement cette chaîne.
Affirmer qu’un utilisateur était physiquement devant son poste au vu d’un event 4624 type 3 : le Type 3 est une connexion réseau (SMB, RPC) qui n’implique aucune présence physique ou interactive de l’utilisateur.
Éliminer instantanément un ticket Kerberos volé en désactivant le compte dans l’AD : les serveurs de ressources continuent d’accepter le TGS tant qu’il n’est pas expiré (jusqu’à 10 heures), car ils ne contactent pas le DC pour vérifier le statut du compte à chaque requête.

Confusions fréquentes en DFIR

Faux Ami / Piège	Erreur d’interprétation classique	Réalité forensique vérifiable
Event 4624 avec `ANONYMOUS LOGON`	« Un attaquant non authentifié s’est connecté au serveur. »	Comportement standard lors de la phase de négociation SMB initiale ou requêtes IPC/DNS légitimes.
SID se terminant par -500 sur un serveur membre	« Le compte administrateur du domaine a été utilisé. »	Si le préfixe du SID correspond à la machine locale, c’est l’administrateur local, pas le Domain Admin.
Présence d’un compte dans `SYSVOL\Policies`	« L’attaquant a modifié la GPO. »	Vérifier si l’outil de gestion GPMC n’a pas simplement fait une mise à jour d’horodatage automatique lors d’une simple ouverture de console.

Exemple concret d’investigation

Dans une enquête sur une exfiltration de données :

Les analystes découvrent que le compte CORP\support_temp a ouvert une session SMB sur le serveur financier à 22h10 UTC.
Le gestionnaire de parc affirme : « C’est impossible, ce compte a été renommé en support_old et désactivé le matin même à 09h00 ! »
L’analyste DFIR inspecte l’Event 4624 sur le serveur financier :
- TargetUserName: support_temp
- TargetUserSid: S-1-5-21-9988-1420
- LogonProcessName: Kerberos
L’analyste inspecte les KDCs :
- À 08h45 (avant la désactivation), l’attaquant avait demandé un TGT de 10 heures pour support_temp.
- À 22h10, l’attaquant a présenté ce ticket en mémoire. Le serveur financier a validé le TGS sans interroger l’AD.
Résultat : le renommage et la désactivation dans l’AD n’ont pas révoqué le ticket en cours de validité dans la mémoire de l’attaquant.

Artefacts et traces forensiques

Journaux de sécurité Windows :
- Event ID 4738 (a user account was modified) : consigne les modifications de sAMAccountName, UserPrincipalName et l’état d’activation du compte.
- Event ID 4781 (the name of an account was changed) : trace explicite du renommage d’un compte avec ancien et nouveau nom.
Métadonnées de réplication Active Directory :
- repadmin /showobjmeta <DC> <DN_de_l'objet> : horodatage exact de la dernière modification de chaque attribut individuel (sAMAccountName, unicodePwd, userAccountControl).
Artefacts d’horloge :
- Event ID 1 (Microsoft-Windows-time-service) : changement ou dérive d’horloge du système.

Méthodes d’investigation

Pister les identités par leur SID binaire : Ne jamais exécuter de requêtes de filtrage basées uniquement sur le nom d’utilisateur textuel.
Vérifier les événements 4781 de renommage : Rechercher tout événement 4781 sur les DC pour faire correspondre d’anciens noms d’utilisateurs avec leurs nouveaux libellés.
Valider la synchronisation NTP lors de la collecte : Noter le décalage temporel (Time Delta) de chaque hôte investigué par rapport à la source de temps de référence.

Outils d’investigation

Repadmin (Windows natif) :

repadmin /showobjmeta DC01 "CN=VictimUser,CN=Users,DC=corp,DC=local"

PowerShell AD module :

# Rechercher un compte par son SID immuable
Get-ADObject -Filter "objectSid -eq 'S-1-5-21-9988-1420'" -IncludeDeletedObjects

Points clés à retenir

Le SID ne ment jamais : le nom d’utilisateur peut changer, être forgé ou masqué, mais le SID lie l’activité à l’objet réel.
La désactivation d’un compte ne révoque pas les tickets Kerberos actifs en mémoire.
Le champ Workstation Name en NTLM est contrôlé par l’attaquant et ne doit pas servir de preuve de localisation.
Toujours vérifier le décalage d’horloge avant de construire une chronologie d’incident.