Credential Guard : protection des secrets LSASS

Credential Guard est une fonctionnalité de sécurité Windows, introduite avec Windows 10 et Server 2016, qui protège les secrets LSASS en les isolant dans un environnement d'exécution sécurisé. Cette protection repose sur la Virtualization-Based Security (VBS), qui exploite l'hyperviseur Hyper-V pour créer un Isolated User Mode (IUM). Dans cet espace mémoire séparé, les condensats NTLM, les tickets Kerberos et les secrets LSA ne sont plus accessibles depuis le système d'exploitation principal. Même un processus s'exécutant avec les privilèges SYSTEM ne peut pas lire directement ces données. Le processus LsaIso.exe, qui s'exécute dans l'enclave protégée, prend en charge les opérations cryptographiques sensibles. Cette architecture empêche les outils classiques d'extraction de credentials, comme Mimikatz avec la commande sekurlsa::logonpasswords, d'accéder aux condensats en mémoire. Credential Guard est particulièrement pertinent en cybersécurité car il neutralise une grande partie des attaques de type Pass-the-Hash et Pass-the-Ticket, souvent utilisées en phase de mouvement latéral lors d'intrusions sur des environnements Active Directory.

Côté Blue Team, la détection de l'état et de l'intégrité de Credential Guard passe par plusieurs sources. L'événement Windows 4688 (création de processus) permet de surveiller l'apparition de LsaIso.exe au démarrage du système, sa présence confirme l'activation de l'isolation. Le journal System enregistre des événements liés à la VBS lors du démarrage. La clé de registre HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard contient la valeur Enabled, vérifiable via des politiques de conformité dans des outils comme Microsoft Defender for Endpoint ou SCCM. En cas de tentative de contournement, surveiller les accès directs à LSASS via l'événement 4656 (demande d'accès à un objet) et l'Event ID 10 de Sysmon (ProcessAccess sur lsass.exe) reste essentiel. Une tentative d'injection dans lsass.exe génère des alertes dans Microsoft Defender, identifiables par la règle 'Credential Dumping'. Les équipes SOC doivent également surveiller les tentatives de désactivation de la VBS via des modifications du registre sur DeviceGuard, signalées par l'événement 4657. Les anomalies d'authentification Kerberos, comme des demandes de tickets depuis des comptes inhabituels, indiquent un contournement potentiel.

Côté Red Team, Credential Guard ne protège pas contre toutes les techniques d'extraction de credentials. Les mots de passe en clair restent accessibles via le fournisseur WDigest si la clé UseLogonCredential est forcée à 1, bien que cela nécessite une reconnexion de l'utilisateur. Les tickets Kerberos générés après l'activation restent protégés, mais les secrets des comptes de service gérés (MSA) et les condensats stockés en cache (DCC2) peuvent subsister dans la ruche SAM ou SECURITY, accessibles via secretsdump d'Impacket. Mimikatz en mode DPAPI ou via lsadump::cache permet d'exploiter ces résidus. Sur des systèmes mal configurés, Credential Guard peut être désactivé en modifiant les GPO ou la valeur de registre Enabled sous DeviceGuard, nécessitant toutefois un redémarrage. Les techniques d'abus de Kerberoasting et d'AS-REP Roasting ne sont pas bloquées par Credential Guard. Côté durcissement, les équipes doivent activer Credential Guard via GPO (Computer Configuration > Administrative Templates > System > Device Guard), exiger le niveau 'Enabled with UEFI lock' pour empêcher toute désactivation sans accès physique, et combiner cette protection avec Protected Users Security Group et la désactivation de WDigest via la GPO réseau.