La plupart des vols d’identifiants sur Windows ne sont pas du ressort de la magie. C’est de la plomberie. Les attaquants n’ont pas besoin de « hacks » hollywoodiens quand vos postes conservent tranquillement des secrets réutilisables dans des endroits conçus pour la commodité, pas pour des réseaux hostiles.
Le paramètre qui change l’équation pour les attaquants est Windows Defender Credential Guard. Ce n’est pas nouveau. Ce n’est pas exotique. C’est juste… rarement activé de manière cohérente. Et c’est pourquoi il réapparaît dans les rapports post-incident comme un détecteur de fumée manquant : on ne le remarque qu’après l’incendie.
Le paramètre : Credential Guard (et ce qu’il fait vraiment)
Credential Guard est la tentative de Microsoft pour empêcher Windows de devenir un buffet de secrets réutilisables. Plus précisément, il utilise Virtualization-Based Security (VBS) pour isoler les secrets afin que, même si un attaquant obtient les droits admin sur la machine, les « choses précieuses » soient plus difficiles à extraire et à rejouer.
Sans Credential Guard, le Local Security Authority Subsystem Service (LSASS) est à la fois le videur et le bar. Il authentifie les utilisateurs et conserve aussi du matériel d’identification en mémoire de processus. Si un acteur malveillant peut dumper la mémoire de LSASS (ou la coercer via des drivers signés, des privilèges de débogage ou des manipulations de jetons), il peut souvent récolter :
- Hashes NTLM (carburant pour Pass-the-Hash)
- Tickets Kerberos Ticket Granting (carburant pour Pass-the-Ticket)
- Identifiants de domaine mis en cache (carburant pour cassage hors ligne)
- Parfois même des secrets en clair, selon la configuration et les composants d’authentification hérités
Avec Credential Guard, les éléments sensibles sont déplacés dans un environnement protégé (isolated user mode) soutenu par l’hyperviseur. LSASS peut toujours demander des opérations d’authentification, mais il n’a pas la garde des joyaux de la couronne d’une manière facile à racler.
Credential Guard est-il parfait ? Non. Rien ne l’est. C’est un contrôle qui augmente le coût pour l’attaquant et réduit le rayon d’impact. En sécurité opérationnelle, c’est tout le travail.
Ce que Credential Guard ne fait pas
- Il ne corrige pas les mots de passe faibles, les comptes sur-permissionnés, ni le fait d’avoir des « Domain Admin partout ».
- Il n’empêche pas le phishing de capturer des identifiants avant qu’ils n’atteignent votre machine.
- Il n’empêche pas un attaquant connecté d’agir en tant que cet utilisateur.
- Il ne rend pas l’authentification héritée magiquement sûre ; il la casse souvent (ce qui est une fonctionnalité, pas un bug).
Pourquoi personne ne l’active (et pourquoi ce n’est pas une bonne excuse)
Credential Guard est ignoré pour trois raisons : la peur, l’inertie et la « compatibilité ». La plupart des organisations ont au moins une application métier poussiéreuse, un client VPN fournisseur ancien, ou un plug-in d’authentification « spécial » qui n’a pas été mis à jour depuis l’époque où l’on débattait encore de l’adoption du Wi‑Fi.
Alors les équipes font ce qu’elles font sous pression de livraison : elles évitent les changements qui pourraient occasionner des tickets. Elles laissent la surface d’exposition des identifiants large parce que « ça a toujours marché comme ça ».
Pendant ce temps, les attaquants automatisent le vol d’identifiants. Ils n’ont pas besoin de votre planning helpdesk. Ils opèrent à la vitesse machine.
Voici la vérité inconfortable : la compatibilité est un problème résoluble ; le vol d’identifiants à grande échelle est un problème qui peut couler une entreprise. Votre objectif est d’identifier le petit nombre de postes et de workflows qui ne peuvent vraiment pas fonctionner avec Credential Guard, de les isoler, et d’arrêter de prétendre que l’ensemble de l’entreprise doit rester vulnérable pour leur bien.
Blague #1 : Si votre stratégie de sécurité repose sur « personne n’obtiendra jamais les droits admin locaux », j’ai un pont à vous vendre — paiement accepté en hashes NTLM.
Ce que vous empêchez réellement : LSASS, hashes, tickets et rejouage
Credential Guard cible un segment de chaîne d’attaque très spécifique et très courant : le rejouage d’identifiants après compromission et le mouvement latéral. Le schéma ressemble à ça :
- Accès initial (phishing, exploit navigateur, identifiants VPN volés, RDP exposé, macro malveillante — choisissez votre poison).
- Escalade locale de privilèges ou vol de jeton pour obtenir une intégrité élevée.
- Dump des identifiants depuis LSASS (ou coercition du matériel d’authentification) et réutilisation.
- Déplacement latéral vers des serveurs de fichiers, RDP sur des postes, attaque d’AD, récupération d’autres identifiants, escalade vers la domination du domaine.
Credential Guard rend l’étape 3 matériellement plus difficile en isolant les secrets, en limitant ce que LSASS expose, et en réduisant la valeur des outils « dump and go ».
Il vaut la peine de souligner les éléments qui reviennent souvent dans les incidents :
Pass-the-Hash (PtH)
Les hashes NTLM sont réutilisables dans trop d’endroits. Si vous pouvez récolter un hash pour un compte privilégié, vous pouvez souvent vous authentifier sans jamais connaître le mot de passe. Credential Guard réduit la disponibilité de ces hashes dans LSASS.
Pass-the-Ticket (PtT)
Les tickets Kerberos peuvent être rejoués. Si les attaquants peuvent extraire du matériel de ticket, ils peuvent usurper des utilisateurs et des services. Credential Guard réduit l’exposition des secrets liés à la délivrance de tickets.
WDigest et fournisseurs d’identifiants hérités
Windows a conservé des comportements d’authentification hérités pour la compatibilité. Certains de ces comportements reviennent à « stocker des secrets d’une manière pratique pour les attaquants ». Vous voulez les désactiver.
Exposition des identifiants via RDP
RDP n’est pas intrinsèquement malveillant. Mais laisser des utilisateurs à haut privilège se connecter en RDP sur des postes peu fiables, c’est donner des identifiants admin au premier échantillon de malware qui a de la chance. Credential Guard aide, mais Remote Credential Guard et une conception sensée des postes administratifs aussi.
Faits et historique qui expliquent le bazar d’aujourd’hui
Les contrôles de sécurité prennent plus de sens quand on comprend pourquoi les mauvais paramètres par défaut existent. Voici quelques points concrets — contexte historique, pas nostalgie :
- LSASS est une cible de grande valeur depuis des décennies parce que c’est là que se déroule l’authentification Windows et où le matériel d’identification s’accumule pendant l’usage normal.
- « Pass-the-Hash » est devenu médiatisé à la fin des années 2000, et il est resté pertinent parce que NTLM perdurait dans les entreprises comme une imprimante non patchée : toujours là, silencieusement critique.
- WDigest a été conçu pour la compatibilité avec d’anciens schémas d’authentification ; le problème est que compatibilité rime parfois avec « manipulation de texte en clair plus simple ». Les versions modernes de Windows ont resserré les valeurs par défaut, mais les mises à niveau et la dérive de stratégie maintiennent le risque vivant.
- Credential Guard est arrivé à l’ère Windows 10 Enterprise / Windows Server 2016, lié à VBS et à l’isolation par hyperviseur — sécurité intégrée à la plateforme plutôt qu’ajoutée.
- La virtualisation est devenue la frontière de sécurité parce que la frontière classique de l’OS a échoué face aux drivers noyau, aux droits admin et au scraping mémoire ; l’hyperviseur est plus difficile à manipuler qu’un processus en espace utilisateur.
- Les outils d’attaque se sont professionnalisés : ce qui était une compétence de niche est devenu des frameworks en un clic qui extraient les identifiants rapidement et discrètement.
- « Protéger LSASS » (RunAsPPL) précède une adoption généralisée de Credential Guard ; beaucoup d’organisations ont activé PPL sans finir le travail, laissant d’autres matériaux d’identification accessibles.
- Les recommandations modernes de Microsoft supposent de plus en plus « assumer la compromission », en se concentrant sur la minimisation de l’exposition des identifiants plutôt que de prétendre que les endpoints ne sont jamais compromis.
Mode d’emploi pour un diagnostic rapide
Quand vous suspectez une exposition au vol d’identifiants — ou que vous préparez un déploiement et voulez savoir ce qui va casser — ne vous éparpillez pas. Commencez par une boucle serrée : vérifiez les prérequis de la plateforme, vérifiez que le contrôle fonctionne réellement, puis identifiez les dépendances héritées.
1) Vérifier d’abord : Credential Guard est-il réellement activé ?
- Recherchez l’état de VBS et l’état d’exécution de Credential Guard.
- Si c’est « configuré » mais pas « en cours », vous avez un problème de plateforme/prérequis (firmware, virtualisation, stratégie, conflits de drivers).
2) Vérifier ensuite : fuyez-vous encore des identifiants via des paramètres hérités ?
- WDigest, usage NTLM, connexions mises en cache et paramètres de délégation « pratiques ».
- Si vous autorisez encore NTLM partout, Credential Guard aide mais vous laissez une porte dérobée ouverte.
3) Vérifier troisième point : les admins se connectent-ils aux mauvais endroits ?
- Les comptes privilégiés sur des postes utilisateurs sont un incident qui attend une invitation au calendrier.
- Corrigez les workflows : postes administratifs dédiés (PAWs/SAWs), Remote Credential Guard et séparation claire des rôles.
4) Vérifier quatrième point : bloquez-vous les techniques courantes de dump ?
- LSASS PPL, règles Attack Surface Reduction (ASR), contrôle des drivers et protection anti-sabotage de l’EDR.
- Si vous ne pouvez pas empêcher le chargement d’un driver vulnérable signé, votre histoire d’isolation est moins solide qu’elle n’en a l’air.
Tâches pratiques : 12+ vérifications avec commandes, sorties, décisions
Ce sont des tâches « à exécuter sur une machine ». Chacune inclut une commande réaliste, ce que signifie la sortie et quelle décision prendre ensuite. Exécutez-les dans une session PowerShell élevée sauf indication contraire. L’invite dans les blocs est figée par conception.
Task 1: Check whether Credential Guard is running (WMI)
cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning"
1
2
Ce que cela signifie : Le tableau numérique liste les services de sécurité actuellement en cours sous Device Guard/VBS. Couramment, 1 indique Credential Guard et 2 indique Hypervisor-protected Code Integrity (HVCI), bien que les mappages exacts puissent varier selon la build.
Décision : Si vous ne voyez pas les valeurs attendues, Credential Guard n’est pas en cours. Passez à la vérification des prérequis et des stratégies (Tâches 2–4).
Task 2: Check whether VBS is enabled (WMI)
cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, RequiredSecurityProperties, AvailableSecurityProperties | Format-List"
VirtualizationBasedSecurityStatus : 2
RequiredSecurityProperties : {1}
AvailableSecurityProperties : {0, 1, 2, 3}
Ce que cela signifie : VirtualizationBasedSecurityStatus typiquement : 0=off, 1=configuré mais pas en cours, 2=en cours. Les propriétés Required/Available indiquent si le hardware/firmware prend en charge le modèle de sécurité.
Décision : Si le statut est 1, vous aurez probablement besoin d’un redémarrage, d’activer la virtualisation dans le firmware, ou de corriger des drivers. Si c’est 0, la stratégie n’est pas appliquée.
Task 3: Verify Hyper-V hypervisor is present (system info)
cr0x@server:~$ powershell -NoProfile -Command "systeminfo | Select-String -Pattern 'Hyper-V Requirements|A hypervisor has been detected|Virtualization' -Context 0,1"
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
Virtualization Enabled In Firmware: Yes
Second Level Address Translation: Yes
Data Execution Prevention Available: Yes
Ce que cela signifie : La virtualisation firmware et SLAT sont requises pour de nombreux scénarios VBS. Si « Virtualization Enabled In Firmware: No », vous êtes bloqué.
Décision : Si la virtualisation est désactivée, planifiez une modification du BIOS/UEFI et une fenêtre de maintenance. Si SLAT manque, ce matériel ne sera pas bon pour VBS.
Task 4: Confirm Credential Guard policy in registry
cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard' /v EnableVirtualizationBasedSecurity & reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v LsaCfgFlags"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
EnableVirtualizationBasedSecurity REG_DWORD 0x1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
LsaCfgFlags REG_DWORD 0x1
Ce que cela signifie : Ces valeurs reflètent couramment la configuration de VBS et de Credential Guard. LsaCfgFlags peut indiquer désactivé/activé avec ou sans verrou UEFI selon les choix de l’organisation.
Décision : Si la stratégie est définie mais que WMI dit « pas en cours », dépannez les prérequis (drivers, état de l’hyperviseur, Secure Boot, redémarrage nécessaire).
Task 5: Check if LSASS is running as a Protected Process Light (PPL)
cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Name lsass | Select-Object Name,Id,Path | Format-List"
Name : lsass
Id : 628
Path : C:\Windows\System32\lsass.exe
Ce que cela signifie : PowerShell n’affiche pas directement PPL. Cette tâche confirme le chemin du processus et la sanity avant de vérifier le registre et les événements à l’étape suivante.
Décision : Si lsass n’est pas au chemin attendu, traitez cela comme suspect et enquêtez immédiatement.
Task 6: Verify “RunAsPPL” setting for LSASS
cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v RunAsPPL"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
RunAsPPL REG_DWORD 0x1
Ce que cela signifie : RunAsPPL=1 active LSASS en tant que Protected Process Light, ce qui bloque de nombreuses techniques de dump en espace utilisateur à moins que l’attaquant n’ait des astuces noyau.
Décision : Si c’est 0 ou absent, activez-le dans votre baseline. Credential Guard et PPL sont complémentaires ; ne choisissez pas l’un et pensez le travail fait.
Task 7: Check WDigest usage (plaintext exposure risk)
cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' /v UseLogonCredential"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
UseLogonCredential REG_DWORD 0x0
Ce que cela signifie : 0 signifie généralement que WDigest ne met pas en cache les identifiants d’une manière qui expose du texte clair. 1 est un drapeau rouge vif sauf si vous avez un besoin hérité très spécifique.
Décision : Si c’est 1, corrigez via la stratégie et auditez quelles applis l’exigent. Si quelqu’un « en a besoin », faites-le prouver et isolez ce système.
Task 8: Identify NTLM usage on the endpoint (local events)
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 30 | Where-Object {$_.Properties[10].Value -like 'NTLM*'} | Select-Object -First 5 | ForEach-Object { $_.Properties[5].Value + ' ' + $_.Properties[10].Value }"
jdoe NTLMv2
svc_backup NTLMv2
jdoe NTLMv2
Ce que cela signifie : Des connexions récentes utilisant NTLM apparaissent. Le parsing des événements varie ; l’objectif est de trouver si NTLM est encore actif dans les workflows.
Décision : Si NTLM est courant pour des comptes admin ou l’accès aux serveurs, vous avez un accélérateur de mouvement latéral. Planifiez des restrictions NTLM et migrez les services vers Kerberos quand possible.
Task 9: Check cached logon count (offline credential cache exposure)
cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' /v CachedLogonsCount"
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
CachedLogonsCount REG_SZ 10
Ce que cela signifie : Windows met en cache un certain nombre de connexions de domaine précédentes pour une utilisation hors ligne. Plus le nombre est élevé, plus il y a de matériel mis en cache intéressant à attaquer sur des portables volés.
Décision : Réduisez-le quand le business le permet (surtout pour les utilisateurs privilégiés), et associez-le à BitLocker et des contrôles forts sur les appareils. Ne cassez pas les road warriors sans avertissement ; pilotez d’abord.
Task 10: Verify Remote Credential Guard readiness (RDP client / server capability)
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name SecurityLayer,UserAuthentication | Format-List"
SecurityLayer : 2
UserAuthentication : 1
Ce que cela signifie : Les paramètres indiquent la négociation de sécurité RDP et NLA. Ce n’est pas une vérification complète de Remote Credential Guard, mais c’est un signal rapide que vous n’êtes pas complètement à nu sur RDP.
Décision : Si NLA est désactivé, activez-le. Ensuite, concevez l’accès admin pour utiliser Remote Credential Guard ou des jump hosts durcis.
Task 11: Confirm Secure Boot state (often required for locked-down modes)
cr0x@server:~$ powershell -NoProfile -Command "Confirm-SecureBootUEFI"
True
Ce que cela signifie : Secure Boot est activé. Certains modes de déploiement de Credential Guard (surtout avec verrou UEFI) supposent Secure Boot pour augmenter la résistance aux manipulations.
Décision : Si false, décidez d’accepter un état « configuré mais plus facile à manipuler » ou planifiez l’activation de Secure Boot. Pour les postes privilégiés, planifiez-le.
Task 12: Check if you’re in a VM (and whether VBS is supported there)
cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_ComputerSystem | Select-Object Model,Manufacturer"
Model Manufacturer
----- ------------
Virtual Machine Microsoft Corporation
Ce que cela signifie : Cet hôte est virtualisé. Le support de VBS/Credential Guard dans les VM dépend de votre hyperviseur, de sa version et de ses fonctionnalités (virtualisation imbriquée, vTPM, etc.).
Décision : Si des serveurs critiques sont des VM, validez que l’hyperviseur supporte les fonctionnalités de sécurité que vous exigez. Ne « requérez VBS » puis ne déployez pas sur une plateforme incapable de l’exécuter.
Task 13: Spot potentially dangerous delegation settings on accounts (AD query from an admin host)
cr0x@server:~$ powershell -NoProfile -Command "Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation | Select-Object SamAccountName,TrustedForDelegation | Sort-Object SamAccountName | Select-Object -First 5"
SamAccountName TrustedForDelegation
------------- --------------------
svc_app01 True
svc_legacy02 True
Ce que cela signifie : Les comptes de confiance pour la délégation peuvent augmenter l’impact du vol d’identifiants et de l’abus de tickets.
Décision : Auditez pourquoi chacun existe. Préférez la délégation contrainte et des schémas d’authentification modernes. Si vous ne savez pas pourquoi il existe, voilà votre réponse.
Task 14: Confirm ASR rule state relevant to credential theft (Defender)
cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids | Select-Object -First 5"
D4F940AB-401B-4EFC-AADC-AD5F3C50688A
9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2
Ce que cela signifie : Des règles ASR sont configurées. Il vous faudra encore mapper les GUID aux intentions de règle dans votre standard, mais ceci indique si le poste est même dans le jeu.
Décision : Si ASR n’est pas utilisé, Credential Guard seul laisse d’autres voies de vol d’identifiants ouvertes (dump scripté, comportements de processus suspects). Planifiez ASR en mode audit, puis appliquez.
Task 15: Confirm crash dump settings (prevent “oops we wrote LSASS to disk” moments)
cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\CrashControl' /v CrashDumpEnabled & reg query 'HKLM\SYSTEM\CurrentControlSet\Control\CrashControl' /v DumpFile"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
CrashDumpEnabled REG_DWORD 0x2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
DumpFile REG_EXPAND_SZ %SystemRoot%\MEMORY.DMP
Ce que cela signifie : Les dumps noyau/mémoire peuvent contenir du matériel sensible selon le contexte de crash et les outils. Ce n’est pas « Credential Guard désactivé » grave, mais c’est un risque de gestion de données.
Décision : Assurez-vous que les dumps sont protégés (ACL, chiffrement au repos, accès limité), et que votre processus d’incident traite les dumps comme hautement sensibles.
Trois mini-récits d’entreprises tirés du réel
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
Une entreprise de taille moyenne disposait d’un EDR solide et d’un cycle de patch fier. Leur hypothèse était simple : « Si Defender et l’EDR sont installés partout, le dump de credentials sera détecté. » Ils traitaient le vol d’identifiants comme un problème de détection, pas d’exposition.
Une campagne de phishing a atterri sur un poste de la finance. Le malware initial n’a rien fait de fancy. Il a attendu un token admin local (quelqu’un de l’IT a pris la main à distance pour « réparer Outlook »), puis a utilisé ce privilège pour tenter d’accéder à LSASS. L’EDR a bloqué une technique de dump connue. Tout le monde a soufflé. Ticket clos.
Deux jours plus tard, un serveur de fichiers montrait des accès étranges. Puis un contrôleur de domaine. L’attaquant n’a pas eu besoin de dumper LSASS de la façon « bruyante ». Il a utilisé des chemins alternatifs : usurpation de token, matériel mis en cache récolté, et rejouage d’identifiants via la plomberie Windows intégrée. Ils n’étaient pas plus rapides que l’équipe bleue. Ils étaient juste plus patients.
Le postmortem fut douloureux parce que les contrôles « étaient là », mais les secrets restaient accessibles. Credential Guard n’avait pas été activé parce que « nous avons entendu que ça casse certains VPN ». C’était vrai pour une poignée de postes, pas pour 18 000.
La correction n’a pas été héroïque. Ils ont déployé Credential Guard d’abord aux utilisateurs standard, puis à l’IT, puis à une couche soigneusement conçue de postes d’administration. Le plus grand changement fut culturel : les comptes admin ont cessé de se connecter sur n’importe quel poste. Le mouvement préféré de l’attaquant — attraper un hash privilégié sur un poste — a cessé d’être fiable.
Mini-récit 2 : L’optimisation qui a foiré
Une société globale était obsédée par la performance. Ils ont optimisé les temps de boot et l’accès à distance à grande échelle. Une partie de cette optimisation incluait un cache d’identifiants généreux (« les utilisateurs voyagent »), l’autorisation large de NTLM (« shares hérités »), et garder quelques politiques de commodité activées parce qu’elles réduisaient les tickets du helpdesk.
Puis ils ont activé Credential Guard pour un groupe pilote de développeurs. Un petit ensemble de workflows distants a ralenti. Certains anciens handshakes d’authentification ont échoué. La conclusion bruyante fut : « Credential Guard provoque des problèmes. » La réalité discrète était : « Nous comptions sur des secours non sécurisés comme optimisations de performance. »
Au lieu de réparer la chaîne de dépendances, ils ont fait marche arrière. Six mois plus tard, un attaquant a atterri sur un poste dev, y a raclé ce qu’il pouvait, et a utilisé un mouvement latéral basé sur NTLM pour atteindre un serveur de build. De là, ils ont altéré des artefacts ; la réponse à incident est devenue un problème de chaîne d’approvisionnement logicielle — coûteux, lourd pour la réputation, lent à démêler.
Ensuite, l’« optimisation » a été rebaptisée pour ce qu’elle était : un instrument de dette technique avec intérêt composé. Ils ont réintroduit Credential Guard, mais cette fois avec remédiation : migration de services spécifiques vers Kerberos, resserrement du périmètre NTLM, et usage de jump hosts durcis pour les chemins admin. Les performances étaient correctes. Le recours non sécurisé avait été le véritable goulot d’étranglement — juste pas celui mesuré sur les tableaux de bord.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une organisation de santé appliquait une baseline stricte sur les postes. Ce n’était pas glamour. C’était un tas de GPO, VBS là où possible, Credential Guard appliqué sur la plupart des postes, et une règle stricte : les comptes privilégiés ne se connectent que depuis des postes d’accès privilégié. Ils gardaient aussi une petite liste d’exceptions pour les systèmes incapables de supporter VBS, et ceux-ci étaient isolés comme du matériel radioactif.
Ils ont quand même été atteints par du malware. Tout le monde l’est. La différence fut ce que le malware ne pouvait pas faire. Il a atterri sur un PC d’infirmière, a obtenu un accès utilisateur, et a tenté de se déplacer latéralement. Il a trouvé peu de choses à réutiliser. Les identifiants admin n’étaient pas présents. Le matériel d’identification était moins accessible. Les routes évidentes PtH et PtT étaient peu fiables.
L’attaquant a pivoté vers un comportement opportuniste de ransomware. Le rayon d’impact fut moche mais contenu : un sous-ensemble de postes et quelques partages de fichiers. Les contrôleurs de domaine sont restés propres. Les systèmes cliniques centraux sont restés en ligne. L’organisation a eu une mauvaise semaine au lieu d’un mois catastrophique.
La revue post-incident fut presque ennuyeuse : « La baseline a fonctionné comme prévu. » C’est le but. La fiabilité, ce n’est pas des feux d’artifice ; c’est l’absence de surprise.
Listes de vérification / plan étape par étape (déploiement qui ne fera pas exploser le helpdesk)
Credential Guard n’est pas une case à cocher. C’est un déploiement. Faites-le comme le ferait un SRE : par étapes, mesurable, réversible quand c’est approprié, et avec des boucles de rétroaction serrées.
Étape 1 : Inventairez et segmentez les postes (ne noyez pas l’océan)
- Modèle Tier 0/1/2 : contrôleurs de domaine et infrastructure d’identité ; paliers serveurs ; postes utilisateurs.
- Identifiez les postes qui doivent supporter l’auth héritée (systèmes fournisseurs, clients VPN anciens, drivers matériels spécialisés).
- Créez un « anneau d’exception » avec contrôles compensatoires (isolation réseau, connexions admin restreintes, politiques EDR renforcées).
Étape 2 : Activez les prérequis proprement
- Virtualisation firmware activée.
- Secure Boot activé quand c’est faisable (surtout pour les postes privilégiés).
- Hygiène des drivers : retirez ou mettez à jour les drivers noyau incompatibles.
Étape 3 : Pilotez par anneaux
- Anneau 0 : laptops de l’équipe sécurité IT et quelques power users volontaires.
- Anneau 1 : population d’utilisateurs standard.
- Anneau 2 : postes développeurs (souvent la pile d’auth la plus compliquée).
- Anneau 3 : postes d’accès privilégié et jump hosts.
Étape 4 : Associez aux contrôles ennuyeux qui font tenir le tout
- Activez LSASS PPL (RunAsPPL) quand supporté.
- Désactivez le cache en clair WDigest (vérifiez qu’il reste désactivé).
- Utilisez les règles Attack Surface Reduction (démarrez en audit, puis appliquez).
- Réduisez l’empreinte NTLM ; restreignez où il peut être utilisé.
- Séparez les identités admin et restreignez où les comptes privilégiés peuvent se connecter.
Étape 5 : Surveillez et appliquez
- Signalez les états « configuré mais pas en cours ».
- Suivez les appareils en exception et justifiez-les périodiquement.
- Alertes sur accès suspect à LSASS et au matériel d’identification.
Étape 6 : Documentez les modes de panne dont les utilisateurs se plaindront
- Anciens clients VPN qui tentent d’hooker des fournisseurs d’authentification.
- Plugins SSO hérités.
- Middleware pour cartes à puce ou outils de sécurité avec drivers obsolètes.
Blague #2 : La seule chose plus permanente qu’une exception temporaire est une exception temporaire qui « a juste besoin d’un trimestre de plus ».
Erreurs fréquentes : symptôme → cause racine → fix
1) « Credential Guard est activé par stratégie, mais il ne fonctionne pas. »
Symptôme : WMI montre le statut VBS « configuré » ou « off », et SecurityServicesRunning est vide.
Cause racine : Virtualisation firmware manquante, mismatch Secure Boot, drivers incompatibles, ou pas de redémarrage après activation.
Fix : Validez la virtualisation firmware (Tâche 3), Secure Boot (Tâche 11), et remédiez les conflits de drivers. Redémarrez. Si c’est en VM, confirmez le support hyperviseur (Tâche 12).
2) « Après activation, le VPN/SSO a cassé. »
Symptôme : Boucle de prompts d’authentification, SSO en échec, ou client qui ne se connecte plus.
Cause racine : Fournisseurs d’identifiants hérités, hooks d’auth, ou drivers non compatibles avec l’isolation VBS.
Fix : Mettez à jour le client, migrez vers une méthode d’auth supportée, ou isolez ce workflow vers des jump hosts durcis. Ne faites pas de rollback global — créez un anneau d’exception avec contrôles compensatoires.
3) « Le RDP sur les serveurs demande maintenant les identifiants différemment / l’automatisation a cassé. »
Symptôme : Scripts qui s’appuyaient sur des creds stockés échouent ; admins se plaignent de prompts supplémentaires.
Cause racine : Vous dépendiez de schémas de délégation d’identifiants risqués par conception.
Fix : Utilisez Remote Credential Guard quand approprié, migrez l’automatisation vers des identités gérées / service principals, et arrêtez d’embarquer des secrets réutilisables dans des scripts.
4) « L’EDR indique un accès LSASS bloqué ; des applis se plaignent au hasard. »
Symptôme : Un outil de sécurité bloque un processus lisant LSASS ; un « gestionnaire de mots de passe » ou un agent de monitoring signale un problème.
Cause racine : Un outil légitime (ou pas si légitime) tente un comportement d’accès aux credentials indiscernable d’un dump.
Fix : Retirez l’outil ou obtenez une version supportée par le vendor qui n’exige pas de scraper LSASS. Traitez « besoin de lire LSASS » comme un défaut de conception, pas une exigence.
5) « Nous avons activé Credential Guard, mais les attaquants ont quand même bougé latéralement. »
Symptôme : Le mouvement latéral a quand même eu lieu via SMB/RDP/WinRM.
Cause racine : Credential Guard réduit certains chemins de vol d’identifiants ; il ne corrige pas la mauvaise hygiène admin, les privilèges excessifs, la prolifération NTLM ou le phishing d’identifiants.
Fix : Appliquez le modèle de poste admin dédié, restreignez NTLM, réduisez l’appartenance à local admin, et durcissez la gestion à distance. Assumez la compromission d’un endpoint et concevez pour la contention.
6) « Le helpdesk l’a désactivé sur quelques machines pour résoudre un ticket — et a oublié. »
Symptôme : Dérive : certains endpoints ne fonctionnent plus avec VBS/Credential Guard.
Cause racine : Pas de boucle d’application/rapport ; les exceptions ne sont pas suivies comme dette opérationnelle.
Fix : Supervisez l’état d’exécution (Tâches 1–2) centralement, appliquez la stratégie, et exigez des exceptions limitées dans le temps avec revue.
Une citation à garder sur votre mur
Idée paraphrasée — Werner Vogels : on conçoit des systèmes en supposant que des choses vont échouer, et on les rend résilients par conception, pas par souhait.
Ce qu’il faut éviter : la version « théâtre de sécurité » de ce contrôle
Credential Guard est souvent déployé d’une manière qui est belle dans une présentation mais inefficace en pratique :
- Activé sur un sous-ensemble d’endpoints sans mesure de l’« état d’exécution ».
- Les admins continuent de se connecter partout, si bien que des identifiants privilégiés atterrissent encore sur des postes peu sûrs.
- NTLM reste partout, et les exceptions se multiplient en silence.
- Pas de plan pour les applis héritées, si bien que les équipes font un rollback au premier bruit.
Ne faites pas ça. Si vous allez prendre la chaleur politique et opérationnelle de resserrer l’authentification, vous devriez en retirer le bénéfice réel en sécurité.
Comment Credential Guard change les maths de l’attaquant (pratiquement)
En réponse à incident, vous vous demandez sans cesse : « S’ils avaient les droits admin sur un poste, auraient-ils pu prendre le domaine ? » Credential Guard rend cette question moins terrifiante parce qu’il réduit la probabilité qu’un seul endpoint compromis devienne une fontaine d’identifiants.
Mais ça ne marche que si vous le traitez comme partie d’une stratégie de contention d’identité :
- Réduire la présence des identifiants : Ne connectez pas les comptes privilégiés sur des appareils non fiables.
- Réduire la réutilisation des identifiants : Moins de mots de passe locaux partagés, moins de comptes de service avec des droits larges.
- Réduire l’auth héritée : Réduire le périmètre NTLM, supprimer les anciens providers.
- Réduire l’extraction : Credential Guard + LSASS PPL + EDR/ASR + contrôle des drivers.
C’est la vision SRE de la sécurité : contrôlez le rayon d’impact, supprimez les points uniques de défaillance catastrophique, et mesurez vos contrôles en tant que systèmes en fonctionnement, pas en intentions.
FAQ
1) Credential Guard est-ce la même chose que « protection de LSASS » ?
Non. La protection de LSASS (RunAsPPL) rend plus difficile la lecture de LSASS par des processus. Credential Guard utilise VBS pour isoler les secrets afin qu’ils ne soient pas simplement présents dans la mémoire de LSASS. Utilisez les deux quand vous pouvez.
2) Credential Guard arrêtera-t-il Mimikatz ?
Il peut réduire significativement ce que les outils courants d’extraction de credentials peuvent extraire de LSASS sur des systèmes correctement configurés. Il n’arrêtera pas toutes les techniques post-exploitation, et il n’arrêtera pas le phishing. Il change ce qui est disponible à voler.
3) Pourquoi entend-on « ça casse des choses » ?
Parce que certains logiciels dépendent de comportements hérités des fournisseurs d’identifiants ou de drivers noyau qui ne se comportent pas bien avec l’isolation VBS. C’est un problème de qualité logicielle que vous pouvez généralement corriger par des mises à jour, des changements de configuration ou une refonte des workflows.
4) Ai-je besoin de Windows Enterprise ?
Credential Guard est généralement destiné aux éditions Enterprise/Education et aux environnements gérés. En pratique, ce que vous pouvez activer dépend de l’édition OS, de la build et de votre approche de gestion. Validez sur votre parc avant de promettre quoi que ce soit.
5) Puis-je l’activer sur des serveurs ?
Oui, dans de nombreux scénarios, mais traitez les serveurs comme de l’infrastructure de production : testez la compatibilité des drivers, des outils de sécurité et des workflows de gestion à distance. Certains serveurs (surtout anciens ou spécialisés) peuvent nécessiter des exceptions isolées.
6) Si j’utilise des cartes à puce ou Windows Hello for Business, en ai-je encore besoin ?
Oui. Une authentification utilisateur plus forte aide, mais Credential Guard protège le matériel dérivé des identifiants et réduit les opportunités de rejouage sur des endpoints compromis.
7) Comment prouver aux auditeurs que c’est réellement activé ?
Ne prouvez pas que « la stratégie est définie ». Prouvez que « ça fonctionne ». Utilisez les signaux WMI (Tâches 1–2) collectés centralement et signalez la dérive. Les auditeurs aiment les preuves ; les attaquants aiment la dérive.
8) Quelle est la plus grande raison pour laquelle cet investissement échoue ?
Le comportement des admins. Si les comptes privilégiés continuent de se connecter sur des postes utilisateurs, vous pouvez toujours perdre le domaine par d’autres chemins. Credential Guard réduit une grande avenue ; il n’excuse pas une mauvaise hygiène d’identité.
9) Dois-je désactiver NTLM après avoir activé Credential Guard ?
Pas en mode big-bang. Mesurez d’abord l’usage NTLM, puis restreignez-le chirurgicalement. L’objectif est de réduire NTLM là où il est inutile et de le contenir là où il est inévitable.
10) Cela vaut-il la peine si j’ai déjà un EDR ?
Oui. L’EDR concerne la détection et la réponse. Credential Guard réduit l’exposition. Vous voulez les deux : moins de secrets disponibles à voler, et de meilleures chances d’attraper l’attaquant de toute façon.
Prochaines étapes réalisables cette semaine
Si vous voulez que cela soit réel — pas un PowerPoint de politique — faites ces étapes pratiques :
- Mesurez la réalité : Exécutez les Tâches 1–2 sur un échantillon représentatif. Comptez « en cours » vs « configuré » vs « off ».
- Trouvez vos bloqueurs : Pour les systèmes non en cours, collectez l’état de virtualisation firmware (Tâche 3) et Secure Boot (Tâche 11). Identifiez les conflits de drivers et les agents fournisseurs.
- Éliminez les expositions héritées évidentes : Assurez-vous que WDigest est désactivé (Tâche 7) et activez LSASS PPL quand supporté (Tâche 6).
- Corrigez les chemins de connexion admin : Arrêtez de connecter des utilisateurs privilégiés sur des bureaux aléatoires. Construisez un workflow de postes d’accès privilégié / jump host.
- Démarrez un registre d’exceptions : Chaque appareil qui ne peut pas exécuter Credential Guard va sur une liste avec propriétaire métier, justification, contrôles compensatoires et date de revue.
- Déployez par anneaux : Pilotez, mesurez les types de tickets, remédiez, étendez. Ne faites pas de surprise un vendredi soir.
Le vol d’identifiants est populaire parce que ça marche. Credential Guard est impopulaire parce qu’il change les valeurs par défaut. C’est justement pour cela que vous devez l’activer : c’est l’un des rares contrôles Windows qui réduit de manière significative la valeur d’un endpoint compromis.