Credential Guard et protection LSA : protéger LSASS

LSASS (Local Security Authority Subsystem Service) détient les secrets qui font fonctionner l'authentification unique : empreintes NTLM, tickets et clés Kerberos, et parfois davantage. Tout processus capable de lire la mémoire de LSASS peut récolter ces secrets et les réutiliser ailleurs. L'extraction d'identifiants depuis LSASS apparaît dans une très grande partie des intrusions menées par un attaquant aux commandes, c'est pourquoi Windows intègre désormais deux défenses dédiées :

• La protection LSA (RunAsPPL) exécute LSASS en processus protégé léger. Seul du code signé avec le niveau de protection adéquat peut l'ouvrir pour lire sa mémoire ou y injecter du code, même si l'attaquant est administrateur local.
• Credential Guard s'appuie sur la sécurité basée sur la virtualisation (VBS) pour déplacer les empreintes NTLM, les clés de session des TGT Kerberos et les identifiants de domaine stockés dans un processus isolé, LsaIso.exe, qui s'exécute dans un niveau de confiance virtuel distinct. LSASS communique avec lui par RPC et ne détient jamais lui-même les secrets bruts.

Ces deux mécanismes sont complémentaires et doivent être activés ensemble.

Prérequis

Ce qui casse

Les deux fonctionnalités retirent des capacités, par conception. Anticipez :

• Les plug-ins LSA et pilotes tiers non signés pour les processus protégés : middleware de cartes à puce, certains filtres de mots de passe, produits de sécurité anciens. La protection LSA dispose d'un mode audit pour cela : utilisez-le.
• Avec Credential Guard : l'authentification unique NTLMv1, MS-CHAPv2 et Digest ne fonctionne plus avec les identifiants enregistrés, la délégation Kerberos non contrainte et le chiffrement DES sont bloqués, et CredSSP ne peut plus déléguer les identifiants enregistrés ou par défaut. Les profils Wi-Fi et VPN qui utilisent MS-CHAPv2 (PEAP-MSCHAPv2) afficheront une invite ou échoueront s'ils s'appuient sur les identifiants Windows enregistrés. Basculez-les d'abord vers une authentification par certificat (EAP-TLS).

Étape 1 : auditer la protection LSA avant de l'imposer

Passez LSASS en mode audit sur un groupe pilote (Windows 11 22H2 et ultérieur audite déjà par défaut). Chaque module qui ne pourrait pas se charger sous protection est journalisé, sans rien bloquer :

Key:   HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe
Value: AuditLevel  (REG_DWORD) = 8

Redémarrez et examinez Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational :

• Événement 3065 : LSASS a tenté de charger un pilote ou un module qui ne satisfait pas aux exigences de sécurité des sections partagées.
• Événement 3066 : LSASS a tenté de charger un module qui ne satisfait pas aux exigences de niveau de signature Microsoft ; il serait donc bloqué une fois la protection activée.

Contactez l'éditeur de chaque module listé. La plupart des produits actuels de sécurité et d'authentification livrent des composants LSA correctement signés.

Étape 2 : activer la protection LSA

Stratégie de groupe (ADMX de Windows 11 22H2 et ultérieur, et de Server 2025) : Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process, réglé sur Enabled with UEFI Lock ou Enabled without UEFI Lock.

La valeur de registre équivalente, qui fonctionne aussi sur les builds plus anciennes :

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: RunAsPPL  (REG_DWORD)
       1 = enabled with a UEFI variable (cannot be turned off by registry alone)
       2 = enabled without UEFI lock (Windows 11 22H2 and later)

Le verrou UEFI est plus robuste, car un attaquant disposant de droits d'administration ne peut pas simplement modifier le registre et redémarrer. Cela signifie aussi qu'une désactivation ultérieure exige un outil de désactivation documenté et une présence physique : utilisez-le une fois la compatibilité confirmée.

Vérifiez après redémarrage dans le journal System : l'événement 12 de la source Wininit indique LSASS.exe was started as a protected process with level: 4.

Étape 3 : activer Credential Guard

Stratégie de groupe : Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security :

Équivalents registre, pour un déploiement par script ou hors domaine :

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
  EnableVirtualizationBasedSecurity   REG_DWORD 1
  RequirePlatformSecurityFeatures     REG_DWORD 1  (Secure Boot)  or 3 (Secure Boot + DMA)

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
  LsaCfgFlags                         REG_DWORD 1  (with UEFI lock) or 2 (without lock)

Dans Intune, utilisez Endpoint security > Account protection ou un profil de catalogue de paramètres pour Credential Guard.

Étape 4 : vérifier

Sur l'appareil, msinfo32 affiche Virtualization-based security: Running et liste Credential Guard sous Virtualization-based security Services Running. Depuis PowerShell :

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
$dg.VirtualizationBasedSecurityStatus   # 2 = en cours d'exécution
$dg.SecurityServicesRunning             # contient 1 = Credential Guard, 2 = HVCI (intégrité de la mémoire)

Microsoft ne recommande pas de chercher LsaIso.exe dans le Gestionnaire des tâches ; consultez plutôt, dans le journal System, l'événement 13 de WinInit (Credential Guard (LsaIso.exe) was started and will protect LSA credentials). Collectez ces valeurs sur tout le parc via votre outil de gestion ou un script de conformité, car les mises à jour de micrologiciel, les réinitialisations du BIOS et les remplacements de matériel peuvent désactiver VBS sans bruit.

Étape 5 : désactiver les reliquats hérités

Credential Guard et PPL protègent ce que détient LSASS. Réduisez d'abord ce qu'il détient :

Activez aussi la règle ASR Block credential stealing from the Windows local security authority subsystem (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2), qui ajoute une barrière supplémentaire sur les appareils où Credential Guard ne peut pas fonctionner. Voir le guide des règles ASR.

La détection reste indispensable

Aucune des deux fonctionnalités ne protège les identifiants saisis sur une machine compromise (un enregistreur de frappe les voit toujours), les empreintes des comptes locaux dans la SAM, ni la base NTDS.dit des contrôleurs de domaine. Continuez à détecter :

• L'accès à lsass.exe par un processus avec des droits de lecture mémoire (Sysmon Event 10, ou votre EDR).
• Les modifications de RunAsPPL, LsaCfgFlags et UseLogonCredential (audit du registre ou Sysmon Event 13).
• La création de fichiers de vidage de LSASS (Sysmon Event 11 pour des *.dmp écrits par des processus inhabituels).

Liste de contrôle

• Protection LSA auditée (événements 3065/3066), puis imposée avec verrou UEFI
• L'événement 12 confirme le niveau de processus protégé sur chaque hôte
• VBS et Credential Guard actifs sur tous les clients et serveurs membres éligibles
• Wi-Fi/VPN sortis de MS-CHAPv2 avant le déploiement de Credential Guard
• WDigest désactivé et surveillé ; ouvertures de session en cache réduites
• Règle ASR LSASS en mode blocage
• Rapport de parc sur SecurityServicesRunning, revérifié après les mises à jour de micrologiciel

Ces deux paramètres transforment la technique de post-exploitation la plus fiable sous Windows en technique peu fiable. Combinés au modèle en tiers, ils laissent tout simplement moins de choses à voler, et moins d'endroits où les voler.