Les comptes locaux sur des machines jointes à un domaine

Concept

Lorsqu’un serveur ou un poste de travail Windows rejoint un domaine Active Directory :

La base SAM locale reste Active : située dans %SystemRoot%\System32\config\SAM, elle continue de gérer les comptes locaux de la machine (.\Administrator, .\Guest, comptes de techniciens locaux).
Deux espaces d’authentification coexistent :
- Local : validé par le LSA contre la SAM locale (HOSTNAME\user).
- Domaine : validé par Kerberos ou Netlogon contre les contrôleurs de domaine (DOMAIN\user).
L’imbrication par défaut : lors de la jonction au domaine, Windows ajoute automatiquement le groupe du domaine Domain Admins dans le groupe local Administrators de la machine, créant le pont d’administration.

Pourquoi c’est important en DFIR

L’utilisation de comptes locaux sur des machines de domaine est l’un des vecteurs majeurs de propagation des attaquants :

Mouvement latéral sans contrôleur de domaine (Pass-the-Hash local) : si les machines du parc ont été déployées avec une image clonée (Golden Image) possédant le même mot de passe d’administrateur local, un attaquant qui extrait le hash NTLM local sur une machine peut rebondir en SMB sur toutes les autres machines du parc, sans jamais générer le moindre événement d’authentification sur les DC !
LAPS (local administrator password solution) : LAPS élimine ce risque en générant un mot de passe aléatoire unique par machine, stocké dans un attribut chiffré de l’annuaire Active Directory (msLAPS-Password ou hérité ms-Mcs-AdmPwd). En DFIR, vérifier le déploiement et la lecture de ces attributs est crucial.
Échappement à la surveillance centralisée : une connexion effectuée avec un compte local (Logon Type 3 ou 10) n’est enregistrée que dans le journal de sécurité local de la machine cible. Le SIEM ne recevra rien si les logs des postes ne sont pas collectés.

Comment ça fonctionne

Résolution de l’autorité d’authentification

Tentative de connexion : "Administrator"
                     │
         La chaîne contient-elle un domaine ?
                    / \
                   /   \
           OUI    /     \   NON
                 /       \
                ▼         ▼
    "DOMAIN\Administrator"    ".\Administrator" OU Machine isolée
                │                         │
                ▼                         ▼
   Validé par KDC / NTDS      Validé par LSA / SAM locale
   SID: S-1-5-21-DOM-500      SID: S-1-5-21-MACHINE-500

La protection LocalAccountTokenFilterPolicy :
- Par défaut sous Windows Vista/7/10/11 et Windows Server, les comptes locaux non-RID 500 connectés via le réseau (SMB/WMI/WinRM) subissent le filtrage UAC et perdent leurs droits administrateur (jeton filtré à Medium Integrity).
- Seul le compte administrateur local intégré (RID 500) conserve ses pleins privilèges réseau, sauf si la clé de registre LocalAccountTokenFilterPolicy = 1 a été explicitement activée par les administrateurs.

Ce qui est possible

Rebondir d’un poste à un autre avec un compte local : si le mot de passe du compte local RID 500 est identique sur plusieurs machines, l’attaquant peut pivoter via SMB (psexec, wmiexec, smbexec) sur tout le réseau sans toucher aux DC.
Accéder à une machine de domaine même en cas de panne totale du réseau OU des DC : les comptes locaux permettent la reprise d’activité d’urgence car ils ne dépendent d’aucun service réseau.
Auditer les lectures de mots de passe LAPS : la consultation des attributs LAPS dans l’Active Directory génère l’Event ID 4662 sur les DC, révélant qui a lu les mots de passe des administrateurs locaux.

Ce qui n’est pas possible

Accéder aux ressources du domaine avec un compte local : un compte local ne peut s’authentifier que sur sa propre machine. Il n’a aucune existence dans Active Directory et ne peut pas accéder aux partages d’autres serveurs qui exigent une identité de domaine (sauf si une autre machine possède exactement le même nom d’utilisateur et le même mot de passe local).
Consulter les journaux d’authentification locale sur les contrôleurs de domaine : une connexion utilisant .\Administrator ne produit aucun événement 4624 ou 4768 sur les DC.
Synchroniser automatiquement le mot de passe local avec le domaine : modifier le mot de passe d’un compte de domaine n’affecte en rien les comptes locaux.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« L’attaquant s’est connecté en Administrateur, donc le domaine est compromis. »	Vérifiez le SID : si le SID commence par le SID de la machine locale, c’est l’administrateur local. Le domaine n’est pas compromis.
« Nous collectons tous les logs des DC, donc nous voyons toutes les attaques Pass-the-Hash. »	Faux. Le Pass-the-Hash utilisant des comptes locaux ne transite jamais par les DC. Il est invisible sans collecte des logs des machines cibles.
« Désactiver le compte Administrateur local empêche tout mouvement latéral local. »	Si `LocalAccountTokenFilterPolicy = 1` est configuré, n’importe quel compte local membre d’`Administrators` permet le mouvement latéral.

Exemple concret d’investigation

Lors d’une réponse à incident dans une PME :

Les DC ne montrent aucune activité anormale. Pourtant, 40 postes de travail ont été chiffrés par un ransomware.
L’analyse du poste initialement infecté révèle un dump LSASS extrayant le hash NTLM du compte local Administrator (S-1-5-21-209384-500).
Ce hash est identique sur les 40 postes en raison d’une image de déploiement commune sans LAPS.
L’attaquant a exécuté un script PowerShell utilisant wmiexec pour pousser le ransomware sur les 40 adresses IP en passant le hash local.
Constat DFIR : l’attaque s’est déroulée intégralement sous le radar des contrôleurs de domaine grâce aux comptes locaux.

Artefacts et traces forensiques

Journaux de sécurité locaux de la machine cible :
- Event ID 4624 (logon type 3) : TargetDomainName égal au nom d’hôte de la machine locale (indiquant une authentification SAM locale), TargetUserSid commençant par le SID de la machine.
- Event ID 4672 : privilèges spéciaux attribués à .\Administrator.
Active Directory LAPS auditing (sur les DC) :
- Event ID 4662 : lecture de l’attribut msLAPS-Password ou ms-Mcs-AdmPwd sur l’objet ordinateur.
Registre Windows :
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy (si = 1, UAC réseau désactivé pour tous les comptes locaux).

Méthodes d’investigation

Distinguer compte local et compte domaine dans les logs : Comparer TargetDomainName avec le nom de la machine locale vs le nom NetBIOS du domaine Active Directory.
Vérifier l’état de déploiement de LAPS : Exécuter Get-ADComputer -Filter * -Properties msLAPS-Password, ms-Mcs-AdmPwd pour vérifier si les machines bénéficient de mots de passe uniques.
Identifier les machines présentant des comptes locaux réutilisés : Rechercher les occurrences d’authentifications Type 3 réussies provenant de la même adresse IP source avec un compte local sur plusieurs hôtes distincts.

Outils d’investigation

PowerShell AD / LAPS :

# Vérifier l'état LAPS Windows Server 2022+
Get-ADComputer -Identity "SRV01" -Properties msLAPS-PasswordExpirationTime

Kansa / Velociraptor : Recherche des événements 4624 avec TargetDomainName == ComputerName sur l’ensemble du parc d’endpoints.

Points clés à retenir

La SAM locale reste active et indépendante sur les machines jointes à un domaine.
L’authentification locale ne transite jamais par les contrôleurs de domaine.
La réutilisation de mots de passe locaux permet des mouvements latéraux massifs sans alerte sur les DC.
LAPS est la seule contremesure architecturale efficace contre ce vecteur.