Protéger LSASS : protection LSA et Credential Guard, ce qu'ils bloquent et ce qu'ils ne bloquent pas
Le processus LSASS conserve en mémoire les éléments d'authentification des utilisateurs connectés : hachages NT, tickets Kerberos, parfois davantage. Un attaquant administrateur local d'une machine cherche presque toujours à les extraire pour rebondir ailleurs. La protection LSA et Credential Guard répondent à cette menace de deux manières différentes et complémentaires.
Pourquoi LSASS est une cible
Pour permettre l'authentification unique vers les ressources du réseau, Windows garde dans LSASS des dérivés des identifiants de chaque session ouverte. Un administrateur du domaine qui se connecte à un serveur compromis y laisse ainsi des éléments réutilisables. L'extraction de ces éléments puis leur rejeu (pass-the-hash, pass-the-ticket) constituent le moteur principal du mouvement latéral dans les compromissions d'annuaire.
La protection LSA (RunAsPPL)
La protection LSA fait tourner LSASS en tant que processus protégé léger (PPL). Seuls des processus bénéficiant d'un niveau de protection équivalent peuvent alors lire sa mémoire ou y injecter du code, et seuls des modules signés selon les exigences de Microsoft peuvent y être chargés. Un outil exécuté avec des droits d'administrateur ne peut plus simplement ouvrir LSASS pour en lire le contenu.
Elle s'active par la valeur de registre RunAsPPL sous la clé LSA, ou par stratégie de groupe sur les versions récentes. Avec la valeur 1 sur une machine UEFI avec démarrage sécurisé, le réglage est verrouillé dans une variable UEFI et ne peut être désactivé par simple modification du registre. Les versions récentes de Windows 11 l'activent par défaut dans certaines conditions ; vérifiez la documentation Microsoft à jour pour votre version.
Limites. Un attaquant capable de charger un pilote noyau peut contourner la protection. Celle-ci ne protège pas non plus la base SAM locale ni les secrets LSA stockés dans le registre.
Credential Guard
Credential Guard va plus loin en s'appuyant sur la sécurité basée sur la virtualisation (VBS). Les secrets les plus sensibles, hachages NT et TGT Kerberos notamment, sont conservés dans un processus isolé, LSAIso, exécuté dans un environnement que le système d'exploitation lui-même ne peut pas lire. LSASS ne manipule plus que des références. Même avec un accès au noyau, l'attaquant ne peut pas extraire ces secrets.
Credential Guard est activé par défaut sur les éditions Entreprise et Éducation récentes de Windows 11 qui satisfont aux exigences matérielles, et Microsoft a étendu ce comportement à Windows Server 2025 dans certaines conditions. Les prérequis (processeur 64 bits, extensions de virtualisation, démarrage sécurisé, TPM recommandé) et les règles d'activation par défaut évoluent : vérifiez-les dans la documentation Microsoft actuelle.
| Credential Guard protège | Credential Guard ne protège pas |
|---|---|
| Hachages NT des sessions de domaine | Mots de passe capturés à la saisie (enregistreur de frappe) |
| TGT Kerberos | Comptes locaux et base SAM |
| Identifiants de domaine enregistrés dans le gestionnaire d'identifiants | Tickets de service déjà délivrés, utilisables pendant leur validité |
| Actions menées directement sur la machine compromise pendant la session |
Impacts de compatibilité
Credential Guard bloque des mécanismes anciens : NTLMv1, MS-CHAPv2 avec les identifiants de session (certains VPN et réseaux Wi-Fi en PEAP), la délégation Kerberos non contrainte et le chiffrement DES. La protection LSA peut empêcher le chargement de modules tiers non conformes (fournisseurs d'authentification, certains pilotes de cartes à puce ou agents de sécurité anciens).
Auditer avant d'appliquer. La protection LSA dispose d'un mode audit qui journalise dans le journal CodeIntegrity les modules qui auraient été bloqués. Laissez-le tourner sur un échantillon représentatif avant l'activation. Pour Credential Guard, testez en priorité les accès VPN et Wi-Fi.
Déploiement sur serveurs et postes
- Postes de travail. Activez les deux protections sur l'ensemble du parc éligible, par stratégie de groupe ou par Intune, après la phase d'audit.
- Serveurs membres. Activez la protection LSA largement ; Credential Guard sur les serveurs où des administrateurs ouvrent des sessions interactives, en vérifiant la compatibilité des applications.
- Contrôleurs de domaine. Credential Guard n'y apporte pas de bénéfice, car la base de l'annuaire contient de toute façon tous les secrets. La protection LSA y reste en revanche recommandée.
- Machines virtuelles. Credential Guard nécessite la virtualisation imbriquée et un hyperviseur compatible ; vérifiez la configuration de votre plateforme.
Aucune de ces protections ne remplace le cloisonnement : le meilleur moyen de ne pas se faire voler un identifiant d'administrateur du domaine reste de ne jamais l'utiliser sur une machine de niveau inférieur.
Ce qu'un audit vérifie
- l'état effectif de la protection LSA et de Credential Guard, et non la seule présence d'une GPO ;
- le verrouillage UEFI de la protection LSA sur les machines compatibles ;
- les dépendances à NTLMv1, MS-CHAPv2 ou à la délégation non contrainte ;
- la couverture des serveurs sur lesquels des comptes privilégiés ouvrent des sessions ;
- la désactivation de WDigest et de la mise en cache inutile d'identifiants.