KomuraSoft LLC
Nous contacter
Menu

Les profondeurs de la virtualisation Windows (partie 2) — Une mémoire invisible même au noyau : comment fonctionnent VBS, HVCI et Credential Guard

· · Windows, Virtualisation, Sécurité, VBS, HVCI, Credential Guard

Il fut un temps où les privilèges administrateur étaient le « but » pour un attaquant sous Windows. Chargez un pilote noyau en tant qu’administrateur, videz la mémoire du processus LSASS, et vous avez les hachages de mots de passe et les tickets Kerberos. De là, il ne reste qu’à marcher vers une autre machine avec les hachages volés.

Sous Windows 11 actuel avec Credential Guard en cours d’exécution — l’état par défaut à partir de 22H2 sur les appareils qui remplissent les exigences de licence telles qu’Enterprise et Education, plus les exigences matérielles — ce mode opératoire ne fonctionne plus. Un attaquant qui a pleinement pris le noyau peut chercher la mémoire autant qu’il veut, et les hachages réels des informations d’identification de domaine protégées ne se trouvent pas « à l’intérieur de cet OS ». S’il ne tourne pas, l’ancien danger demeure, donc lisez ceci ensemble avec les méthodes de confirmation plus loin dans l’article.

Alors où sont-ils ? La réponse est « un autre monde, créé à l’intérieur du même PC ». Comme nous l’avons vu dans la partie 1, le Windows hôte s’exécute dans la partition racine au-dessus de l’hyperviseur (« Où s’exécute réellement votre Windows ? »). Cet article continue de là et suit une ligne de frontière de plus que l’hyperviseur trace à l’intérieur de la même partition.

La question à laquelle la partie 2 répond n’est qu’une.

Où Windows place-t-il les secrets que ni un administrateur ni le noyau ne peuvent lire ?

Le public visé est constitué des développeurs et des opérateurs qui ont vu des mots tels qu’Isolation du noyau, Intégrité de la mémoire et Credential Guard sur un écran de paramètres ou dans un cas de dépannage, et veulent comprendre la chose réelle depuis le mécanisme. Les prérequis sont Windows 10/11 x64 ou Windows Server actuel (comme dans la partie 1, la discussion des anneaux et de SLAT suppose x64 ; Arm64 utilise un mécanisme différent tel que les niveaux d’exception). Le bagage requis est constitué des concepts de partitions et de SLAT couverts dans la partie 1. La difficulté est intermédiaire. Le but est une explication de la structure, pas un mode d’emploi pour configurer les fonctionnalités de sécurité.

1. La conclusion, d’abord

Windows a ajouté un axe de privilège appelé VTL (Virtual Trust Level) et a mis les secrets dans VTL1. La mémoire de VTL1 ne peut pas être lue depuis le noyau ordinaire qui s’exécute dans VTL0. Ce qui garde la frontière n’est pas le noyau lui-même, mais l’hyperviseur qui détient les tables de traduction SLAT.

C’est le squelette de la sécurité basée sur la virtualisation (VBS). VBS utilise l’hyperviseur pour créer un environnement isolé et y loge des fonctionnalités de sécurité. Elle est conçue en partant du principe que l’environnement isolé reste protégé même si le noyau est compromis.1

Les deux mondes que VBS créeVTL0 et VTL1 se tiennent à l'intérieur de la même partition ; VTL0 détient le noyau ordinaire et les applications, VTL1 détient le Secure Kernel et les fonctionnalités de sécurité isolées, et l'hyperviseur garde la frontièreVTL1（le monde isolé）VTL0（le monde ordinaire）Ne peut pas lireFonctionnalités de sécurité isoléesSecure KernelApplications（anneau 3）Noyau NT et pilotes（anneau 0）Hyperviseur（applique la frontière via SLAT）

Figure 1 : il y a deux mondes à l’intérieur d’un seul Windows, et le noyau VTL0 ne peut pas accéder à la mémoire VTL1.

Le point important est que ce n’est pas « dresser une autre machine virtuelle ». VTL0 et VTL1 sont à l’intérieur de la même partition, à l’intérieur du même Windows. Nous regarderons tour à tour comment cette scission est réalisée.

2. Les limites du modèle d’anneaux — le gardien et le gardé se tiennent à la même hauteur

La sécurité Windows traditionnelle a été construite sur l’échelle des anneaux (niveaux de privilège). Le mode utilisateur (anneau 3) est gardé par le mode noyau (anneau 0). Alors qui garde l’anneau 0 — personne ne le peut. L’anneau 0 est le privilège le plus élevé.

Cette structure a deux faiblesses structurelles.

  • Le noyau n’est pas un monolithe. À l’anneau 0, non seulement Windows lui-même mais un grand nombre de pilotes tiers s’exécutent. Si l’un d’eux a une vulnérabilité, un attaquant obtient l’exécution de code à l’anneau 0.
  • Depuis l’anneau 0, tout est visible. Quelque défense qu’un processus en mode utilisateur tel que LSASS se donne, sa mémoire est libre à lire pour un attaquant qui a pris le noyau. Attributs de protection et tables des pages sont gérés par le noyau lui-même.
Le chemin de vol d'identifiants dans le modèle d'anneaux traditionnelUn attaquant qui prend l'anneau 0 via un pilote vulnérable peut lire la mémoire du processus LSASS avec l'autorité pleine du noyau et obtenir des hachages de mots de passeExploite un pilote vulnérableCode de l'attaquantPrend le contrôle de l'anneau 0Peut lire toute la mémoire physiqueObtient les hachages depuis LSASSAbusé pour un mouvement latéral

Figure 2 : parce que le gardien (le noyau) et le gardé (les secrets) se tiennent à la même hauteur, la faiblesse fondamentale est que si l’anneau 0 tombe, tout tombe.

Ce qu’il faut, alors, c’est « un endroit plus haut que l’anneau 0 ». Cet endroit est déjà apparu dans la partie 1. L’hyperviseur s’exécute à un privilège plus élevé que le noyau et monopolise tôt le contrôle des permissions d’accès mémoire du processeur (SLAT). Une région isolée que l’hyperviseur garde est protégée même contre un accès depuis le logiciel OS en anneau 0 (mode superviseur).2

3. VSM et VTL — ajouter un axe de privilège de plus

3.1. Virtual Trust Levels (VTL)

La famille de fonctionnalités de l’hyperviseur qui fournissent cette isolation s’appelle VSM (Virtual Secure Mode). VSM est le fondement de Device Guard, Credential Guard, d’un TPM virtuel, et analogues.2

Le concept central de VSM est le VTL (Virtual Trust Level). Les points clés sont les suivants.2

  • Les VTL sont hiérarchiques, et plus le numéro est élevé, plus le privilège est élevé. VTL0 est le plus bas ; VTL1 est plus privilégié que VTL0.
  • Architecturale, jusqu’à 16 niveaux sont définis, mais ce qui est actuellement implémenté, ce sont deux : VTL0 et VTL1.
  • Chaque VTL a des protections d’accès mémoire indépendantes. Ces protections sont gérées par l’hyperviseur contre l’espace d’adresses physiques de la partition, donc le logiciel système à l’intérieur de la partition ne peut pas les changer.
  • Un processeur virtuel a un état de registres et une machinerie d’interruptions séparés par VTL, et un VTL inférieur ne peut pas jeter un œil à l’état d’un VTL supérieur.
Trois indépendances qui composent l'isolation VTLLes protections d'accès mémoire, l'état des registres du processeur virtuel et la machinerie d'interruptions sont indépendants par VTL, et un VTL inférieur ne peut toucher aucun d'eux dans un VTL supérieurCe qui est indépendant par VTLProtections d'accès mémoireÉtat des registres du VPMachinerie d'interruptionsUn VTL inférieur ne peut toucher un supérieur

Figure 3 : faire non seulement de la mémoire mais aussi de l’état du processeur et des interruptions un monde séparé est le trio qui ne laisse aucun judas.

Si les anneaux (0 et 3) sont l’axe qui sépare « OS et applications », les VTL sont un second axe qui sépare « le monde ordinaire et le monde isolé ». Les deux axes sont orthogonaux, et à l’intérieur de VTL1 il y a aussi un mode noyau et un mode utilisateur.

Quatre régions créées par les deux axes des anneaux et des VTLL'axe des anneaux sépare le mode noyau et le mode utilisateur, l'axe des VTL sépare le monde ordinaire et le monde isolé, et la combinaison produit quatre régions : applications ordinaires, noyau NT, trustlets IUM et Secure KernelVTL1（monde isolé）VTL0（monde ordinaire）Anneau 3 : IUM（trustlets）Anneau 0 : Secure KernelAnneau 3 : applications ordinairesAnneau 0 : noyau NT et pilotes

Figure 4 : il y a désormais deux axes de privilège, et « est-ce le noyau ? » et « est-ce le monde isolé ? » sont devenus des questions séparées.

3.2. La substance de la frontière est SLAT

Dans la partie 1, nous avons dit que les tables de traduction de second niveau qui font correspondre une adresse physique d’invité (GPA) à la RAM réelle (SPA) — SLAT — sont détenues par l’hyperviseur. VSM utilise exactement cette propriété. L’isolation VTL est créée en utilisant l’hyperviseur Hyper-V et SLAT.3

Lorsque VTL1 déclare « cette mémoire ne doit pas être montrée à VTL0 », l’hyperviseur retire la permission d’accès à cette page des tables de traduction de VTL0. Dès lors, même si le noyau VTL0 essaie de toucher cette adresse, il est refusé au stade de la traduction d’adresses du processeur. Il est inutile que le noyau réécrive ses propres tables des pages autant qu’il veut. Les tables des pages (GVA→GPA) peuvent appartenir au noyau, mais la traduction au-delà (GPA→SPA) et la permission d’accès finale appartiennent à l’hyperviseur.

Le flux par lequel l'accès de VTL0 à la mémoire VTL1 est refuséLorsque le noyau VTL0 essaie de lire la mémoire VTL1, il peut passer sa propre table des pages mais est refusé par la protection d'accès SLAT, et le contrôle se transfère à l'hyperviseurNon autoriséAutoriséLe noyau VTL0 essaie de lire une page VTL1Passe la table des pages du noyauSLAT autorise-t-il l'accès ?L'hyperviseur intervient et refuseAccès mémoire ordinaireProtégé à une couche que le noyau ne peut changer

Figure 5 : la barrière siège hors du noyau, et les protections SLAT ne peuvent pas être changées par le logiciel à l’intérieur de la partition.

Dans la partie 1 de la série mémoire, nous avons écrit que « les VAD, les PTE et les attributs de protection décident si l’accès est autorisé ». Dans un environnement VBS, vous pouvez l’organiser ainsi : après que tous ceux-là ont été passés, un point de contrôle SLAT attend encore.

3.3. Le Secure Kernel et IUM

Ce qui s’exécute à l’intérieur de VTL1 n’est pas le noyau NT ordinaire mais un petit noyau appelé Secure Kernel. Le mode utilisateur dans VTL1 s’appelle IUM (Isolated User Mode), et les programmes qui s’y exécutent s’appellent trustlets (processus de confiance).3

Un trustlet ne peut pas tout faire comme un processus ordinaire. La plupart des appels système sont marshallés vers le noyau NT côté VTL0 et le travail y est demandé.3 VTL1 n’est pas un « monde supérieur qui peut tout faire » ; il est construit volontairement petit, comme un coffre qui détient des secrets. Moins vous pouvez apporter de code dans le coffre, plus la surface d’attaque est petite.

Le flux des appels système d'un trustletUn trustlet dans VTL1 ne traite pas la plupart des appels système lui-même ; il les marshalle vers le noyau NT VTL0 et ne reçoit que le résultat, ce qui garde VTL1 petitDans la plupart des casTrustlet（IUM dans VTL1）Un appel système est nécessaireRequête marshallée vers le noyau NT VTL0Seul le résultat revientVTL1 reste petit, réduisant la surface

Figure 6 : le coffre n’a pas d’installations propres ; il sous-traite les corvées et continue de ne garder que les secrets.

4. HVCI — vérifier l’intégrité du code noyau dans le coffre

4.1. Ce qui est vérifié

La première fonctionnalité représentative qui s’assoit sur VBS est l’intégrité de la mémoire — HVCI (intégrité du code protégée par l’hyperviseur). Windows a un mécanisme d’intégrité du code qui inspecte les pilotes et binaires en mode noyau avant qu’ils ne démarrent et ne charge pas ceux qui ne sont pas signés ou auxquels on ne fait pas confiance. HVCI exécute cette vérification à l’intérieur de l’environnement isolé de VBS.1

La raison de déplacer la logique de vérification elle-même dans VTL1 est exactement la faiblesse de la section 2. Si le code de vérification siège à l’intérieur du noyau VTL0, un attaquant qui a pris le noyau peut remplacer la vérification. S’il est dans VTL1, la main qui remplacerait ne peut pas l’atteindre.

La différence selon l'endroit où vit le code de vérificationSi le code de vérification siège à l'intérieur du noyau VTL0 il peut être désactivé en prenant le noyau, mais s'il est dans VTL1 même un attaquant qui a pris le noyau ne peut pas l'atteindre et la vérification est protégéeDans le noyau VTL0（classique）Environnement isolé VTL1（HVCI）Attaquant qui a pris le noyauOù vit la vérification d'intégrité ?La logique de vérification peut être remplacéeLe remplacement est hors de portéeDu code non signé peut tourner dans le noyauLa vérification continue après compromission

Figure 7 : ne mettez pas le point de contrôle à l’intérieur du côté qui pourrait être franchi — ce déplacement de la logique de vérification est l’essence d’HVCI.

4.2. Les règles pour les pages exécutables

L’effet d’HVCI ne se limite pas à « l’inspection au démarrage ». Il contraint aussi l’allocation de mémoire noyau.4

  • Une page noyau ne devient exécutable qu’après avoir passé la vérification d’intégrité du code.
  • Une page exécutable ne devient pas inscriptible (le soi-disant W^X).

Lorsque ces deux-là sont en place, même si une vulnérabilité telle qu’un débordement de tampon vous laisse réécrire la mémoire noyau, vous ne pouvez pas mettre le contenu réécrit en exécution. Une page exécutable ne peut pas être réécrite, et une page qui peut être réécrite ne peut pas être exécutée.4 Le soutien final de la permission d’exécution est le droit d’exécution côté SLAT, que le noyau VTL0 ne peut pas manipuler.

Jusqu'à ce qu'une page noyau devienne exécutable dans un environnement HVCIUne requête de chargement de pilote reçoit une vérification d'intégrité du code dans l'environnement isolé de VBS ; si elle passe elle est autorisée comme page exécutable non inscriptible, et si elle échoue elle est bloquée et enregistrée dans le journal CodeIntegrityRéussiteÉchecRequête de charger et d'exécuter du code noyauVérification d'intégrité dans l'environnement isoléExécutable（écritures interdites）Le chargement est bloquéJournal CodeIntegrity（3087）Les pages inscriptibles restent non exécutables

Figure 8 : la vérification de la règle qui ne laisse pas coexister exécution et écriture se fait côté VTL1, et le noyau VTL0 ne peut pas la renverser.

Suivre ceci du point de vue d’un attaquant rend clair comment la règle prend effet.

Le flux par lequel l'injection de code échoue dans un environnement HVCIMême si une vulnérabilité vous laisse réécrire la mémoire noyau, une page que vous avez pu écrire n'est pas exécutable, et une page exécutable ne peut pas être réécrite pour commencer, donc le code injecté ne peut pas être mis en exécutionUne page inscriptibleUne page exécutableTenter de falsifier la mémoire noyauQuelle page est la cible ?L'écriture réussitL'écriture elle-même est impossibleMais cette page n'est pas exécutableLe code injecté ne peut pas s'exécuter

Figure 9 : le sens de ne pas croiser pages inscriptibles et pages exécutables, c’est que quelle que soit l’entrée que vous prenez, vous butez sur une impasse.

4.3. Le prix en compatibilité des pilotes

Cette règle entre en collision avec les pilotes de conception plus ancienne. Ceux qui réécrivent leur propre code à l’exécution, n’ont pas de signature, ou exigent une mémoire à la fois exécutable et inscriptible — de tels pilotes ne peuvent pas être chargés dans un environnement HVCI. Le fait du blocage peut être confirmé dans l’Observateur d’événements sous Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (l’identifiant d’événement 3087 est représentatif).5

« Après avoir activé l’intégrité de la mémoire, un périphérique a cessé de fonctionner » — dans de nombreux cas, c’est la véritable identité du problème. La réponse appropriée est de mettre à jour vers un pilote compatible HVCI ; désactiver l’intégrité de la mémoire doit être pensé comme un dernier recours qui abandonne la protection en bloc. Si vous êtes impliqué dans cette vérification du point de vue du développement de pilotes, voir aussi l’article sur les pilotes filtres (« Pilotes minifiltres Windows »).

Isoler le cas où un périphérique cesse de fonctionner sous l'intégrité de la mémoireIdentifier le pilote bloqué dans le journal CodeIntegrity Operational ; la réponse appropriée est de mettre à jour vers une version compatible HVCI, demander au fournisseur s'il n'en existe pas, et traiter la désactivation comme un dernier recours que l'on ne rend pas permanentOuiNonUn périphérique s'arrête après activationIdentifier le pilote dans le journal CodeIntegrityY a-t-il un pilote compatible HVCI ?Mettre à jour et résoudre en gardant HVCIDemander une version compatible au fournisseurLa désactivation est un dernier recours, pas un réglage permanent

Figure 10 : la première chose à regarder n’est pas l’écran de paramètres mais le journal, et l’identifiant d’événement 3087 sait qui a bloqué le chargement.

5. Credential Guard — les hachages sont à l’intérieur de LSAIso

5.1. LSASS et LSAIso

La seconde fonctionnalité représentative qui s’assoit sur VBS est la réponse au mystère d’ouverture : Credential Guard.

Windows traditionnel conservait les hachages NTLM et les tickets Kerberos dans la mémoire du processus LSA (lsass.exe). Lorsque Credential Guard est activé, le stockage des secrets protégés parmi ceux-ci — les hachages NTLM des informations d’identification de domaine et les TGT Kerberos (Ticket Granting Tickets) — se déplace vers LSAIso.exe, un trustlet qui s’exécute en IUM dans VTL1.6

  • lsass.exe (VTL0) continue de s’exécuter comme le guichet du traitement d’authentification, comme auparavant.
  • Les secrets réels sont détenus par LSAIso.exe (VTL1) et ne peuvent pas être accédés depuis VTL0.
  • Les deux communiquent via RPC (Remote Procedure Call).
  • LSAIso n’héberge aucun pilote de périphérique, et ne loge que le minimum de binaires signés. Les signatures sont vérifiées avec un certificat auquel VBS fait confiance.6
Où siègent les informations d'identification lorsque Credential Guard est activélsass dans VTL0 communique avec LSAIso dans VTL1 via RPC comme guichet d'authentification ; les hachages et TGT réels des informations d'identification de domaine protégées sont détenus par LSAIso, donc un attaquant qui obtient des privilèges administrateur dans VTL0 et vide lsass n'obtient toujours pas la substance protégéeVTL1VTL0RPCVidage mémoireNe peut pas atteindreLSAIso.exe（coffre des secrets）lsass.exe（guichet d'authentification）Attaquant（privilèges administrateur）

Figure 11 : parce que le guichet et le coffre ont été séparés, vider lsass ne livre plus les hachages réels des informations d’identification de domaine protégées.

À partir de Windows 11 version 22H2, sur les appareils qui remplissent les exigences de licence (Enterprise E3/E5, Education A3/A5) et les exigences matérielles, VBS et Credential Guard sont activés par défaut. Sur des éditions telles que Pro, Credential Guard n’est pas activé automatiquement (il y a des exceptions, telles que lorsqu’une machine qui était activée sous une licence admissible est ensuite rétrogradée).7 « Le mode opératoire ne fonctionne plus » à l’ouverture n’est pas une histoire à propos d’un produit complémentaire spécial ; c’est l’état standard de Windows actuel sur les éditions cibles.

Le flux des informations d'identification de l'ouverture de session à l'authentificationAprès l'ouverture de session les secrets réels sont stockés dans LSAIso dans VTL1 ; chaque fois qu'une authentification est nécessaire, lsass dans VTL0 demande un calcul via RPC, et seul le résultat du traitement d'authentification revient à VTL0 sans que les secrets à long terme protégés eux-mêmes soient renvoyésDemander un calcul via RPCRenvoie le résultat（pas le secret）L'utilisateur ouvre une sessionlsass le traite comme guichetLes secrets réels sont stockés dans LSAIsoRequêtes d'authentification suivantes

Figure 12 : les secrets à long terme protégés eux-mêmes ne quittent jamais le coffre ; ce qui revient à VTL0 est le résultat du traitement d’authentification, tel qu’un ticket.

5.2. Savoir précisément ce qui n’est pas protégé

Credential Guard n’est pas un bouclier à tout faire. Ce qui est protégé, ce sont les hachages NTLM des informations d’identification de domaine, les TGT Kerberos (Ticket Granting Tickets), et ce qui est stocké comme informations d’identification de domaine. Les éléments suivants sont hors périmètre.8

  • Les tickets de service Kerberos (les TGT sont protégés)
  • Les informations d’identification des comptes locaux et des comptes Microsoft
  • Le vol de saisie par un enregistreur de frappe, et les attaques physiques
  • Les informations d’identification sur des chemins qui utilisent NTLMv1, MS-CHAPv2, Digest ou CredSSP
  • L’intérieur d’un logiciel tiers qui gère les informations d’identification de son propre chef

De plus, lorsque Credential Guard est activé, NTLMv1, la délégation Kerberos non contrainte et analogues deviennent inutilisables, donc les systèmes métier qui dépendent d’une authentification héritée ont besoin d’une vérification de compatibilité.8 Pas « l’activer et c’est fini », mais saisir ce qui est à l’intérieur et à l’extérieur de la portée défensive et remplir le reste avec d’autres contrôles — c’est la bonne façon de l’utiliser en pratique.

La portée défensive de Credential GuardLes hachages NTLM de domaine et les TGT, et les informations d'identification de domaine stockées, sont protégés, tandis que les tickets de service, les comptes locaux, les enregistreurs de frappe, les attaques physiques et les informations d'identification stockées en privé par une application sont hors périmètreDe quel côté de la frontière ce secret est-il ?Hachages NTLM de domaine et TGTTickets de service et comptes locauxProtégé dans LSAIsoNon protégé（d'autres contrôles sont nécessaires）Frappes, attaques physiques et stocks privés aussi

Figure 13 : la portée défensive est tracée d’une ligne claire, et l’extérieur de la ligne se remplit avec l’authentification multi-facteurs et la conception côté application.

6. Voyez-le par vous-même

Vous pouvez confirmer l’état d’exécution de VBS et de chaque fonctionnalité sur votre propre machine.

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning

Comment le lire est le suivant.9

  • Si VirtualizationBasedSecurityStatus vaut 2, VBS est activée et tourne.
  • Si SecurityServicesRunning contient 1, Credential Guard tourne ; s’il contient 2, l’intégrité de la mémoire (HVCI) tourne.

Pour confirmer l’état d’exécution dans l’interface graphique, regardez le champ « Sécurité basée sur la virtualisation » dans msinfo32 (les services qui tournent sont listés, tels que « Hypervisor enforced Code Integrity »). Le bascule « Intégrité de la mémoire » sous « Sécurité de l’appareil > Isolation du noyau » dans l’application Sécurité Windows est un écran qui reflète les réglages ; il peut paraître activé alors même qu’HVCI ne tourne pas réellement — en attendant un redémarrage juste après l’activation, ou un problème de compatibilité au démarrage — donc jugez s’il tourne d’après msinfo32 ou d’après SecurityServicesRunning de Win32_DeviceGuard.5

Il y a aussi une trace dans l’onglet Détails du Gestionnaire des tâches. Sur une machine où VBS tourne, vous verrez un processus appelé « Secure System ». LsaIso.exe est le processus qui apparaît lorsque le service Isolated LSA est hébergé dans VTL1, et il n’apparaît normalement pas dans une configuration où seule HVCI est activée. La présence ou l’absence d’un processus n’est toutefois qu’une trace, donc jugez si Credential Guard tourne d’après SecurityServicesRunning (s’il contient 1), comme ci-dessus. Les deux sont des fenêtres visibles depuis VTL0 qui correspondent au monde côté VTL1.

Comment vérifier que les fonctionnalités liées à VBS tournentConfirmer que VBS tourne en interrogeant Win32_DeviceGuard, juger Credential Guard et HVCI d'après les valeurs de SecurityServicesRunning, et regarder le journal CodeIntegrity pour les problèmes de pilotesNonOui12Win32_DeviceGuardÉtat VBS 2 ?VBS ne tourne pasContient 1 ou 2 ?Credential Guard activéHVCI activéCodeIntegrity 3087

Figure 14 : la confirmation d’état avance en trois étapes : VBS elle-même, chaque service au-dessus, et le journal lorsqu’un problème se produit.

7. Trois lectures erronées à éviter en pratique

7.1. « Protéger les privilèges administrateur suffit. VBS est une histoire côté serveur »

Ce que Credential Guard empêche, c’est que les dégâts se propagent après que les privilèges administrateur ont été pris (exfiltration de hachages et mouvement latéral). Autrement dit VBS est une couche de défense en profondeur qui suppose la compromission, et c’est sur les PC clients qu’elle est efficace. Sous Windows 11 qui remplit les exigences, l’activation par défaut est la norme, donc la bonne posture n’est pas « cela n’a rien à voir avec nous » mais « gérer la compatibilité en partant du principe que cela tourne déjà ».

Étapes de compromission et où VBS prend effetL'accès initial est couvert par d'autres contrôles tels que l'authentification multi-facteurs et la formation ; HVCI bloque l'injection de code dans le noyau après l'élévation de privilèges ; Credential Guard bloque le vol de secrets de domaine protégés et le mouvement latéral, mais n'atteint pas les secrets hors de son périmètreAccès initial（hameçonnage, etc.）Élévation de privilègesInjection de code dans le noyauVol de secrets de domaine et mouvement latéralMFA, formation et EDR couvrent ceciHVCI bloque cette étapeCredential Guard bloque ceci（secrets protégés seulement）

Figure 15 : VBS n’est pas une technologie « ne les laissez pas entrer » ; c’est une technologie « ne les laissez pas gagner une fois qu’ils sont entrés », et l’étape qu’elle garde est différente.

7.2. « Si l’intégrité de la mémoire pose un problème, désactivez-la simplement »

La désactiver fera fonctionner les choses pour le moment, mais elle abat la barrière contre l’injection de code dans le noyau en bloc. La réponse appropriée est d’abord d’identifier le pilote bloqué dans le journal CodeIntegrity et d’appliquer la version mise à jour du fournisseur. Même si vous la désactivez temporairement pour la validation, nous recommandons une exploitation qui n’en fasse pas un réglage permanent.

7.3. « Avec Credential Guard, les mots de passe ne peuvent pas être volés »

C’est une surconfiance née de la confusion de la portée défensive. Les tickets de service, les comptes locaux, les frappes elles-mêmes, et les informations d’identification stockées en privé par une application sont hors périmètre.8 L’hameçonnage et les enregistreurs de frappe ont besoin d’autres contrôles (authentification multi-facteurs, Windows Hello, et une revue de la gestion des informations d’identification côté application).

8. Résumé

  • VBS utilise l’hyperviseur pour créer un environnement isolé et protège les fonctionnalités de sécurité en partant du principe que le noyau peut être compromis.1
  • L’unité d’isolation est le VTL ; actuellement deux niveaux sont implémentés, VTL0 (le monde ordinaire) et VTL1 (le Secure Kernel et IUM).2
  • La substance de la frontière est la protection d’accès mémoire SLAT, que le logiciel à l’intérieur de la partition — y compris le noyau — ne peut pas changer.2
  • HVCI exécute la vérification d’intégrité du code dans l’environnement isolé et applique « pas exécutable tant que la vérification n’a pas passé » et « une page exécutable n’est pas inscriptible ».4 Le prix est que vous devez gérer la compatibilité des pilotes.5
  • Credential Guard isole les hachages NTLM des informations d’identification de domaine et les TGT dans LSAIso dans VTL1. À partir de Windows 11 22H2, il est activé par défaut sur les appareils qui remplissent les exigences de licence (Enterprise, Education) et les exigences matérielles (utilisez ceci ensemble avec une vérification de l’état d’exécution).67
  • Vous pouvez confirmer l’état d’exécution d’après SecurityServicesRunning de Win32_DeviceGuard (1 = Credential Guard, 2 = HVCI).9

Suite dans la partie 3, « Des machines virtuelles qui démarrent en quelques secondes — WSL2, Windows Sandbox et les conteneurs ».

Jusqu’ici nous avons regardé la virtualisation du côté « force de l’isolation ». Le dernier volet regarde du côté opposé, celui de la « légèreté », et suit où les machines virtuelles légères qui ont abandonné le poids d’une machine virtuelle complète font des économies.

Articles connexes

Domaines de conseil associés

KomuraSoft LLC prend en charge les investigations de compatibilité entre applications Windows et fonctionnalités de sécurité, l’analyse des pannes causées par des pilotes, et la validation technique des environnements de PC internes.

Références

  1. Microsoft Learn, Virtualization-based Security (VBS). Sur le fait que VBS utilise la virtualisation matérielle et l’hyperviseur Windows pour créer un environnement isolé et le traite comme racine de confiance de l’OS en partant du principe que le noyau peut être compromis ; que l’intégrité de la mémoire exécute la vérification d’intégrité du code en mode noyau à l’intérieur de cet environnement isolé ; et que SLAT est une exigence dure pour VBS. ↩ ↩2 ↩3

  2. Microsoft Learn, Virtual Secure Mode. Sur le fait que VSM est le fondement de Device Guard, Credential Guard, d’un TPM virtuel et analogues ; que l’accès aux régions isolées n’est contrôlé que via l’hyperviseur et est protégé même depuis le logiciel OS en anneau 0 ; que les VTL sont hiérarchiques avec 2 d’un maximum de 16 niveaux implémentés ; et que les protections d’accès mémoire par VTL sont inchangéables par le logiciel système à l’intérieur de la partition. ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, Isolated User Mode (IUM) Processes. Sur le fait que VSM crée des VTL en utilisant l’hyperviseur Hyper-V et SLAT ; que le Secure Kernel et IUM s’exécutent dans VTL1 ; que les trustlets marshallent les appels système vers le noyau VTL0 ; et que LSAIso s’exécute dans VTL1 et communique avec lsass via RPC. ↩ ↩2 ↩3

  4. Microsoft Learn, Memory integrity and virtualization-based security. Sur le fait que l’intégrité de la mémoire (HVCI) exécute la vérification d’intégrité du code dans un environnement isolé, et sur le fait que les pages de mémoire noyau ne deviennent exécutables qu’après avoir passé la vérification et que les pages exécutables ne deviennent pas inscriptibles. ↩ ↩2 ↩3

  5. Microsoft Learn, Memory integrity and VBS enablement. Sur le fait que l’intégrité de la mémoire est activée par défaut lors d’une installation propre de Windows 11 si le matériel est compatible ; sur la confirmation de l’état dans msinfo32 et l’application Sécurité Windows ; et sur la confirmation d’un pilote bloqué via l’identifiant d’événement 3087 dans le journal CodeIntegrity Operational. ↩ ↩2 ↩3

  6. Microsoft Learn, How Credential Guard works. Sur le fait que le LSA communique avec un processus Isolated LSA (LSAIso.exe) pour stocker des secrets lorsque Credential Guard est activé ; que les données stockées sont protégées par VBS et inaccessibles depuis le reste de l’OS ; et que le processus Isolated LSA n’héberge aucun pilote de périphérique et ne loge qu’un minimum de binaires dont la signature est vérifiée. ↩ ↩2 ↩3

  7. Microsoft Learn, Credential Guard overview. Sur le fait que Credential Guard est activé par défaut à partir de Windows 11 version 22H2 sur les appareils qui remplissent les exigences de licence, de matériel et de logiciel et n’ont pas été explicitement désactivés ; que les éditions/licences admissibles sont Enterprise (E3/E5) et Education (A3/A5), Pro étant hors périmètre ; et qu’une machine Pro qui était précédemment activée sous une licence admissible reste une cible activée par défaut après une rétrogradation. ↩ ↩2

  8. Microsoft Learn, Credential Guard protection limits. Sur le fait que les tickets de service, les comptes locaux, les enregistreurs de frappe, les attaques physiques et analogues sont hors de la portée de protection de Credential Guard ; que les TGT sont protégés tandis que les tickets de service ne le sont pas ; et que NTLMv1 et la délégation non contrainte deviennent inutilisables lorsqu’il est activé. ↩ ↩2 ↩3

  9. Microsoft Learn, Enable virtualization-based protection of code integrity. Sur la façon de confirmer l’état de VBS et de l’intégrité de la mémoire via la classe Win32_DeviceGuard, et sur la signification des valeurs de SecurityServicesRunning (1 est Credential Guard, 2 est l’intégrité de la mémoire). ↩ ↩2

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

VBS (sécurité basée sur la virtualisation) et Isolation du noyau sont-elles la même chose ?
À strictement parler, elles sont différentes. VBS est la technologie de fondation qui crée un environnement isolé avec l'hyperviseur, et « Isolation du noyau » dans l'application Sécurité Windows est le nom d'un écran qui regroupe plusieurs protections construites sur VBS. La représentative est « Intégrité de la mémoire », qui désigne HVCI (intégrité du code protégée par l'hyperviseur). Confirmez l'état d'exécution de chaque service en interrogeant Win32_DeviceGuard, pas à partir de l'affichage de l'écran.
La mémoire VTL1 peut-elle vraiment ne pas être lue, même avec des privilèges administrateur ou depuis un pilote noyau ?
Elle ne le peut pas. Les protections d'accès mémoire par VTL sont gérées par l'hyperviseur contre l'espace d'adresses physiques de la partition, et le logiciel qui s'exécute à l'intérieur de la partition ne peut pas les changer. Même le code qui s'exécute dans le noyau (anneau 0) n'est pas autorisé à accéder à la mémoire VTL1 depuis VTL0.
Pourquoi activer l'intégrité de la mémoire (HVCI) peut-il empêcher un pilote de fonctionner ?
Dans un environnement HVCI, une page noyau ne devient exécutable qu'après avoir passé la vérification d'intégrité, et les écritures vers des pages exécutables ne sont pas autorisées. Un pilote non signé, ou un pilote de conception plus ancienne qui réécrit de la mémoire exécutable, ne peut pas satisfaire cette contrainte et son chargement est bloqué. Vous pouvez confirmer le blocage dans le journal CodeIntegrity Operational (identifiant d'événement 3087 et analogues).
Que protège Credential Guard, et que ne protège-t-il pas ?
Il protège les hachages de mot de passe NTLM des informations d'identification de domaine, les TGT Kerberos, et ce qu'une application a stocké comme informations d'identification de domaine, dans un environnement isolé. Les tickets de service Kerberos, les informations d'identification des comptes locaux et des comptes Microsoft, le vol de saisie par un enregistreur de frappe, et les attaques physiques sont hors périmètre.
Où puis-je vérifier si VBS tourne ?
Regardez le champ « Sécurité basée sur la virtualisation » dans msinfo32, ou interrogez la classe Win32_DeviceGuard dans l'espace de noms root/Microsoft/Windows/DeviceGuard depuis PowerShell. Si SecurityServicesRunning contient 1, Credential Guard tourne ; s'il contient 2, l'intégrité de la mémoire (HVCI) tourne.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.

Nous contacter
Retour au blog