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

Où Windows place-t-il les secrets que ni un administrateur ni le noyau ne peuvent lire ? La partie 2 part de cette question et suit le fonctionnement de VBS, HVCI et Credential Guard.

Sous Windows traditionnel, un attaquant qui chargeait un pilote noyau en tant qu’administrateur et vidait la mémoire du processus LSASS pouvait voler les hachages de mots de passe et les tickets Kerberos, puis les utiliser pour un mouvement latéral vers d’autres machines.

Sous Windows 11 avec Credential Guard en cours d’exécution, les hachages des informations d’identification de domaine protégées ne sont nulle part où le noyau ordinaire peut chercher. Sur les appareils qui remplissent les exigences de licence (Enterprise, Education et analogues) et les exigences matérielles, cette protection est activée par défaut à partir de 22H2.¹ Les exigences et l’état d’exécution réel sont deux choses distinctes, donc le danger n’a pas disparu là où elle ne tourne pas.

La partie 1 a montré la structure dans laquelle le Windows hôte s’exécute dans la partition racine au-dessus de l’hyperviseur. Ce que cet article suit, c’est une ligne de frontière de plus, tracée à l’intérieur de cette même partition.

« Les profondeurs de la virtualisation Windows » — les 3 parties

Nous regardons le même hyperviseur Windows dans l’ordre fondement → isolation de sécurité → application aux machines virtuelles légères.

Prérequis de cet article

Comment lire cet article

1. D’abord la conclusion

Windows a ajouté un axe de privilège appelé VTL (Virtual Trust Level) et a placé les secrets en VTL1. Le noyau ordinaire qui s’exécute en VTL0 ne peut pas lire la mémoire de VTL1. Ce qui garde la frontière n’est pas le noyau lui-même, mais l’hyperviseur, qui 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 fonctions 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.²

flowchart TB
    accTitle: Les deux mondes que crée VBS
    accDescr: VTL0 et VTL1 siègent à l'intérieur de la même partition ; VTL0 tient le noyau ordinaire et les applications, VTL1 le Secure Kernel et les fonctions de sécurité isolées, et l'hyperviseur garde la frontière
    subgraph vtl0 ["VTL0 (le monde ordinaire)"]
        apps["Applications (anneau 3)"]
        ntk["Noyau NT et pilotes (anneau 0)"]
    end
    subgraph vtl1 ["VTL1 (le monde isolé)"]
        ium["Fonctions de sécurité isolées"]
        sk["Secure Kernel"]
    end
    hv["Hyperviseur (impose la frontière via SLAT)"] --- vtl0
    hv --- vtl1
    ntk -.->|Lecture impossible| ium

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

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

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (22 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

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

La sécurité Windows traditionnelle était 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 s’exécutent non seulement Windows lui-même, mais un grand nombre de pilotes tiers. Si l’un d’eux a une vulnérabilité, l’attaquant obtient l’exécution de code à l’anneau 0.
• Depuis l’anneau 0, tout est visible. Aussi bien qu’un processus en mode utilisateur tel que LSASS se défende, un attaquant qui a pris le noyau peut lire sa mémoire librement. Les attributs de protection et les tables de pages sont gérés par le noyau lui-même.

flowchart TB
    accTitle: Le chemin de vol des informations d'identification dans le modèle d'anneaux traditionnel
    accDescr: Un attaquant qui prend l'anneau 0 via un pilote vulnérable peut lire la mémoire du processus LSASS avec toute l'autorité du noyau et obtenir les hachages de mots de passe
    mal["Code de l'attaquant"] -->|Exploite un pilote vulnérable| r0["Prend l'anneau 0"]
    r0 --> readall["Peut lire toute la mémoire physique"]
    readall --> lsass["Obtient les hachages depuis la mémoire de LSASS"]
    lsass --> lateral["Détourné pour un mouvement latéral vers d'autres machines"]

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 donc, 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 s’approprie tôt le contrôle des permissions d’accès mémoire du processeur (SLAT). Une région isolée gardée par l’hyperviseur est protégée même contre l’accès depuis le logiciel d’OS de l’anneau 0 (mode superviseur).³

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

Cette section procède dans l’ordre l’ensemble de fonctions qui fournit l’isolation (VSM) → les niveaux d’isolation (VTL) → le mécanisme qui impose la frontière (SLAT) → le code qui s’exécute à l’intérieur. Les noms se ressemblent, mais ce ne sont pas la même chose.

3.1. Les niveaux de confiance virtuels (VTL)

L’ensemble de fonctions de l’hyperviseur qui fournit cette isolation s’appelle VSM (Virtual Secure Mode). VSM est le fondement de Device Guard, Credential Guard, le TPM virtuel et analogues.³

Le concept central de VSM est le VTL (Virtual Trust Level). Les points essentiels sont les suivants.³

• Les VTL sont hiérarchiques, et plus le numéro est grand, plus le privilège est élevé. VTL0 est le plus bas ; VTL1 est plus privilégié que VTL0.
• L’architecture définit jusqu’à 16 niveaux, mais ce qui est actuellement implémenté, ce sont deux : VTL0 et VTL1.
• Chaque VTL a ses propres protections d’accès mémoire indépendantes. L’hyperviseur gère ces protections sur 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 un mécanisme d’interruptions distincts par VTL, et un VTL inférieur ne peut pas regarder l’état d’un VTL supérieur.

flowchart TB
    accTitle: Les trois indépendances qui constituent l'isolation VTL
    accDescr: Les protections d'accès mémoire, l'état des registres du processeur virtuel et le mécanisme d'interruptions sont indépendants par VTL, et un VTL inférieur ne peut toucher aucun d'eux dans un VTL supérieur
    vtl["Ce qui est indépendant par VTL"] --> m1["Protections d'accès mémoire"]
    vtl --> m2["État des registres du processeur virtuel"]
    vtl --> m3["Mécanisme d'interruptions"]
    m1 -.-> rule["Un VTL inférieur ne peut pas toucher un VTL supérieur"]
    m2 -.-> rule
    m3 -.-> rule

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

Si les anneaux (0 et 3) sont l’axe qui sépare « l’OS et les 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.

flowchart TB
    accTitle: Les quatre régions créées par les deux axes des anneaux et des VTL
    accDescr: L'axe des anneaux sépare le mode noyau du mode utilisateur, l'axe des VTL sépare le monde ordinaire du monde isolé, et la combinaison produit quatre régions : applications ordinaires, noyau NT, trustlets IUM et Secure Kernel
    subgraph ax0 ["VTL0 (monde ordinaire)"]
        a0["Anneau 3 : applications ordinaires"]
        k0["Anneau 0 : noyau NT et pilotes"]
    end
    subgraph ax1 ["VTL1 (monde isolé)"]
        a1["Anneau 3 : IUM (trustlets)"]
        k1["Anneau 0 : Secure Kernel"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

Figure 4 : Il y a désormais deux axes de privilège, et « est-ce le noyau ? » et « est-ce le monde isolé ? » sont devenues des questions distinctes.

3.2. La substance de la frontière est SLAT

La partie 1 a dit que les tables de traduction de second niveau qui font correspondre les adresses physiques de l’invité (GPA) à la RAM réelle (SPA) — SLAT — sont tenues par l’hyperviseur. VSM utilise précisément cette propriété. L’isolation des VTL est construite en utilisant l’hyperviseur Hyper-V et SLAT.⁴

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 de VTL0 tente de toucher cette adresse, l’accès est refusé au stade de la traduction d’adresses du processeur. Peu importe comment le noyau réécrit ses propres tables de pages.

Les tables de pages (GVA→GPA) peuvent appartenir au noyau, mais la traduction au-delà (GPA→SPA) et la permission d’accès finale appartiennent à l’hyperviseur.

flowchart TB
    accTitle: Comment un accès de VTL0 à la mémoire de VTL1 est refusé
    accDescr: Lorsque le noyau de VTL0 tente de lire la mémoire de VTL1, il peut passer ses propres tables de pages mais est refusé par la protection d'accès SLAT, et le contrôle passe à l'hyperviseur
    try["Le noyau de VTL0 tente de lire une page de VTL1"] --> pt["Passe les tables de pages du noyau lui-même"]
    pt --> slat{"La protection d'accès SLAT l'autorise-t-elle ?"}
    slat -->|Pas d'autorisation| deny["L'hyperviseur intervient et refuse l'accès"]
    slat -->|Autorisation présente| ok["Accès mémoire ordinaire"]
    deny -.-> point["Protégé à une couche que le noyau ne peut pas changer"]

Figure 5 : La barrière se tient hors du noyau, et la protection SLAT ne peut pas être changée par le logiciel à l’intérieur de la partition.

La partie 1 de la série sur la mémoire a écrit que « le VAD, le PTE et les attributs de protection décident si un accès est autorisé ». Dans un environnement VBS, on peut l’ordonner ainsi : après que tout cela a été passé, un 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 de VTL1 s’appelle IUM (Isolated User Mode), et les programmes qui s’y exécutent s’appellent des trustlets (processus de confiance).⁴

Un trustlet ne peut pas tout faire comme un processus ordinaire. La plupart de ses appels système sont marshalés vers le noyau NT du côté VTL0, qui est chargé d’effectuer le travail.⁴ VTL1 n’est pas un « monde supérieur qui peut tout » ; elle est délibérément construite petite, comme un coffre-fort qui tient des secrets. Moins il y a de code que l’on peut faire entrer dans le coffre, plus la surface d’attaque est petite.

flowchart TB
    accTitle: Le flux des appels système d'un trustlet
    accDescr: Un trustlet en VTL1 ne traite pas lui-même la plupart des appels système ; il les marshale vers le noyau NT de VTL0 et ne reçoit que le résultat, ce qui maintient VTL1 petite
    tl["Trustlet (IUM en VTL1)"] --> sc{"Un appel système est nécessaire"}
    sc -->|Dans la plupart des cas| mar["Demande au noyau NT de VTL0"]
    mar --> res["Ne reçoit que le résultat"]
    res -.-> small["VTL1 reste petite et la surface d'attaque rétrécit"]

Figure 6 : Le coffre-fort n’a pas d’installations propres ; il envoie les corvées à l’extérieur et continue de ne garder que les secrets.

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

Pour HVCI, deux points à saisir : où la vérification est effectuée et ce qui est autorisé sur la mémoire après la vérification. Nous regardons cette protection, puis son effet sur la compatibilité des pilotes.

4.1. Ce qui est vérifié

La première fonction représentative qui repose 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 les binaires en mode noyau avant qu’ils ne démarrent, et refuse de charger ceux qui ne sont pas signés ou pas de confiance. HVCI exécute cette vérification à l’intérieur de l’environnement isolé de VBS.²

La raison de déplacer la logique de vérification elle-même en VTL1 est précisément la faiblesse de la section 2. Si le code de vérification siège à l’intérieur du noyau de VTL0, un attaquant qui a pris le noyau peut substituer la vérification. S’il est en VTL1, la main qui substitue n’y atteint pas.

flowchart TB
    accTitle: La différence selon l'emplacement du code de vérification
    accDescr: Si le code de vérification siège dans le noyau de VTL0, il est neutralisé une fois le noyau pris ; s'il est en VTL1, même un attaquant qui a pris le noyau n'y atteint pas et la vérification reste protégée
    atk["Attaquant qui a pris le noyau"] --> q{"Où se trouve la vérification d'intégrité du code ?"}
    q -->|"Dans le noyau de VTL0 (traditionnel)"| bad["La logique de vérification peut être substituée"]
    q -->|"Environnement isolé en VTL1 (HVCI)"| good["La substitution est hors de portée"]
    bad --> res1["Du code non signé peut s'exécuter dans le noyau"]
    good --> res2["La vérification continue de fonctionner après compromission du noyau"]

Figure 7 : Ne pas placer le poste de contrôle à l’intérieur du côté qui pourrait être percé ; ce déménagement de la logique de vérification est l’essence d’HVCI.

4.2. Les règles des 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.⁵

• 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 jamais inscriptible (ce qu’on appelle W^X).

Avec ces deux règles en place, même si une vulnérabilité telle qu’un dépassement de tampon permet de réécrire la mémoire noyau, on ne peut pas faire exécuter le contenu réécrit. Les pages exécutables ne peuvent pas être réécrites, et les pages que l’on peut réécrire ne sont pas exécutables.⁵ Le fondement final de la permission d’exécution est le droit d’exécution côté SLAT, que le noyau de VTL0 ne peut pas manipuler.

flowchart TB
    accTitle: Jusqu'à ce qu'une page noyau devienne exécutable dans un environnement HVCI
    accDescr: Une demande de chargement de pilote reçoit la vérification d'intégrité du code dans l'environnement isolé de VBS ; si elle passe, elle est autorisée comme page exécutable et non inscriptible ; si elle échoue, elle est bloquée et enregistrée dans le journal CodeIntegrity
    load["Demande de chargement et d'exécution de code noyau"] --> verify{"Vérification d'intégrité du code dans l'environnement isolé"}
    verify -->|Réussite| exec["Autorisée comme page exécutable (écritures interdites)"]
    verify -->|Échec| block["Chargement bloqué"]
    block --> log["Enregistré dans le journal CodeIntegrity Operational (identifiant d'événement 3087)"]
    exec -.-> wx["Les pages inscriptibles restent non exécutables"]

Figure 8 : La règle qui ne laisse jamais coexister exécution et écriture est vérifiée du côté VTL1, et le noyau de VTL0 ne peut pas la renverser.

La retracer du point de vue de l’attaquant montre clairement comment la règle prend effet.

flowchart TB
    accTitle: Comment l'injection de code échoue dans un environnement HVCI
    accDescr: Même si une vulnérabilité permet de réécrire la mémoire noyau, une page sur laquelle on a pu écrire n'est pas exécutable, et une page exécutable ne peut pas être réécrite au départ, donc le code injecté ne peut jamais être exécuté
    inj["Tenter de falsifier la mémoire noyau via une vulnérabilité"] --> which{"Quelle page est la cible ?"}
    which -->|Une page inscriptible| wok["La réécriture réussit"]
    which -->|Une page exécutable| xfail["La réécriture elle-même est impossible"]
    wok --> nx["Mais cette page n'est pas exécutable"]
    nx --> dead["Le code injecté ne peut pas être exécuté"]
    xfail --> dead

Figure 9 : Quelle que soit l’entrée que vous prenez, vous aboutissez à une impasse ; c’est tout le sens de ne jamais laisser se chevaucher pages inscriptibles et pages exécutables.

4.3. Le prix : la compatibilité des pilotes

Cette règle entre en collision avec les pilotes de conception plus ancienne. Un pilote qui réécrit son propre code à l’exécution, qui n’a pas de signature, ou qui exige de la mémoire à la fois exécutable et inscriptible, ne peut pas être chargé dans un environnement HVCI.

Le fait du blocage se confirme dans l’Observateur d’événements sous Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational (l’identifiant d’événement 3087 est le représentant).⁶

Dans beaucoup de cas, c’est la véritable identité du problème « après avoir activé l’intégrité de la mémoire, un périphérique a cessé de fonctionner ». La voie principale est la mise à jour vers une version de pilote compatible HVCI ; désactiver l’intégrité de la mémoire doit être regardé comme un dernier recours qui abandonne la protection en bloc.

Si vous êtes impliqué dans cette vérification du côté du développement de pilotes, voir aussi l’article sur les pilotes filtres (« Pilotes minifiltres Windows »).

flowchart TB
    accTitle: Diagnostic lorsqu'un périphérique cesse de fonctionner sous l'intégrité de la mémoire
    accDescr: Identifiez le pilote bloqué dans le journal CodeIntegrity Operational ; la voie principale est la mise à jour vers une version compatible HVCI, sinon une demande au fournisseur, et la désactivation est un dernier recours qui n'est jamais une configuration permanente
    sym["Un périphérique cesse de fonctionner après activation de l'intégrité de la mémoire"] --> log2["Identifier le pilote bloqué dans le journal CodeIntegrity"]
    log2 --> upd{"Existe-t-il un pilote compatible HVCI ?"}
    upd -->|Oui| fix2["Mettre à jour et résoudre en laissant la fonction activée"]
    upd -->|Non| ask2["Demander une version compatible au fournisseur"]
    ask2 -.-> temp["La désactivation est un dernier recours, jamais une configuration permanente"]

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 quel pilote a été bloqué.

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

Là où HVCI protège l’intégrité du code du noyau, Credential Guard protège les informations d’identification. Si l’on sépare le guichet qui accepte l’authentification et le lieu où les secrets sont conservés, la structure et le périmètre de protection s’emboîtent.

5.1. LSASS et LSAIso

La deuxième fonction représentative qui repose sur VBS est la réponse à l’énigme 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), par exemple — passe à LSAIso.exe, un trustlet qui s’exécute en IUM en VTL1.⁷

• lsass.exe (VTL0) continue de s’exécuter comme guichet du traitement d’authentification, comme auparavant.
• Les secrets eux-mêmes sont tenus par LSAIso.exe (VTL1) et ne sont pas accessibles depuis VTL0.
• Les deux communiquent via RPC (Remote Procedure Call).
• LSAIso n’héberge aucun pilote de périphérique et n’accueille que le jeu minimal de binaires signés. Les signatures sont vérifiées contre un certificat auquel VBS fait confiance.⁷

flowchart TB
    accTitle: Où siègent les informations d'identification lorsque Credential Guard est activé
    accDescr: lsass en VTL0, comme guichet d'authentification, communique avec LSAIso en VTL1 via RPC ; les hachages et TGT réels des informations d'identification de domaine protégées sont tenus par LSAIso, donc un attaquant qui obtient des privilèges administrateur en VTL0 et vide lsass n'obtient toujours pas les secrets protégés eux-mêmes
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe (guichet d'authentification)"]
        att["Attaquant (privilèges administrateur)"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe (coffre-fort des secrets)"]
    end
    lsassP <-->|RPC| iso
    att -->|Vidage mémoire| lsassP
    att -.->|N'atteint pas| iso

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.

Conditions d’activation par défaut

À partir de Windows 11 version 22H2, VBS et Credential Guard sont activés par défaut sur les appareils qui remplissent les exigences de licence (Enterprise E3/E5, Education A3/A5) et les exigences matérielles. Sur des éditions telles que Pro, Credential Guard n’est pas activé automatiquement (il y a des exceptions, par exemple une machine qui a été activée sous une licence éligible par le passé et a ensuite été rétrogradée).¹

Cette protection des informations d’identification n’est pas l’affaire d’un produit additionnel spécial ; c’est l’état standard de Windows actuel sur les éditions éligibles.

flowchart TB
    accTitle: Le flux des informations d'identification de la connexion à l'authentification
    accDescr: Après la connexion, les secrets réels sont stockés dans LSAIso en VTL1 ; chaque fois que l'authentification est nécessaire, lsass en VTL0 demande le calcul via RPC, et seul le résultat du traitement d'authentification revient en VTL0, sans que les secrets à long terme protégés eux-mêmes ne soient jamais renvoyés
    signin["L'utilisateur se connecte"] --> front["lsass le traite comme guichet"]
    front --> store["Les secrets réels sont stockés dans LSAIso"]
    auth["Demandes d'authentification ultérieures"] --> front
    front -->|Demande le calcul via RPC| store
    store -->|"Renvoie le résultat (jamais le secret)"| front

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

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

Informations d’identification protégées

Credential Guard n’est pas un bouclier universel. Ce qu’il protège, ce sont les hachages NTLM des informations d’identification de domaine, les TGT Kerberos (Ticket Granting Tickets), et ce qui a été stocké comme informations d’identification de domaine.

Hors périmètre

Les éléments suivants sont hors périmètre.⁸

• 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 lui-même les informations d’identification

Indépendamment du périmètre de protection, vérifier aussi la compatibilité d’authentification

De plus, lorsque Credential Guard est activé, NTLMv1, la délégation Kerberos non contrainte et analogues ne peuvent plus être utilisés, donc les systèmes métier qui dépendent d’une authentification héritée ont besoin d’une vérification de compatibilité.⁸ Ce n’est pas « l’activer et c’est fini » ; connaître l’intérieur et l’extérieur du périmètre de protection et combler le reste par d’autres mesures — c’est le bon usage en pratique.

flowchart TB
    accTitle: Le périmètre de protection de Credential Guard
    accDescr: Les hachages NTLM et TGT du domaine 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 qu'une application stocke elle-même sont hors périmètre
    scope{"De quel côté du périmètre de protection se trouve ce secret ?"} --> inA["Hachages NTLM et TGT du domaine"]
    scope --> outA["Tickets de service et comptes locaux"]
    inA --> prot["Protégé dans LSAIso"]
    outA --> unprot["Non protégé (d'autres mesures sont nécessaires)"]
    unprot -.-> outB["Frappes clavier, attaques physiques et stockages propres à l'application sont aussi hors périmètre"]

Figure 13 : Le périmètre de protection est tracé d’une ligne nette, et l’extérieur de la ligne se comble par l’authentification multifacteur et la conception côté application.

6. Vérifier de vos propres yeux

Vous pouvez vérifier l’état d’exécution de VBS et de chaque fonction sur votre propre machine. Lisez l’état de VBS, le fondement, séparément de l’état des services qui s’exécutent dessus.

6.1. Vérifier VBS et les services en cours d’exécution dans PowerShell

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

Lisez la sortie comme suit.⁹

• 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.

6.2. Lire msinfo32 et l’écran de paramètres différemment

Pour vérifier l’état d’exécution dans une interface graphique, regardez le champ « Sécurité basée sur la virtualisation » dans msinfo32 (les services en cours d’exécution y sont listés, par exemple « Intégrité du code imposée par l’hyperviseur »).

Le basculeur « 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 le paramètre. Il peut paraître activé même pendant qu’HVCI ne tourne pas réellement, par exemple pendant qu’un redémarrage est en attente juste après l’activation, ou lorsqu’il y a un problème de compatibilité au démarrage. Jugez donc s’il tourne d’après msinfo32 ou d’après SecurityServicesRunning dans Win32_DeviceGuard.⁶

6.3. Ne pas juger « en cours d’exécution » d’après la seule présence d’un processus

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 LSA isolé est hébergé en 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 décrit plus haut. Les deux sont des fenêtres, visibles depuis VTL0, sur le monde du côté VTL1.

flowchart TB
    accTitle: La procédure pour vérifier que les fonctions liées à VBS tournent
    accDescr: Confirmez que VBS tourne en interrogeant Win32_DeviceGuard, jugez si Credential Guard et HVCI tournent d'après les valeurs de SecurityServicesRunning, et consultez le journal CodeIntegrity pour les problèmes de pilotes
    q0["Interroger Win32_DeviceGuard"] --> q1{"Le statut VBS vaut-il 2 ?"}
    q1 -->|Non| off["VBS ne tourne pas (vérifier exigences et paramètres)"]
    q1 -->|Oui| q2{"Que contient SecurityServicesRunning ?"}
    q2 -->|Contient 1| cg["Credential Guard tourne"]
    q2 -->|Contient 2| hvciR["Intégrité de la mémoire (HVCI) tourne"]
    hvciR -.-> ev["Pour les problèmes de pilotes, consulter le journal CodeIntegrity (3087)"]

Figure 14 : La vérification d’état procède en trois étapes : VBS elle-même, chaque service au-dessus, et le journal lorsqu’un problème survient.

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

7.1. « Protéger les privilèges administrateur suffit. VBS est une affaire de serveurs »

Ce que Credential Guard empêche, c’est l’extension des dégâts après que les privilèges administrateur ont été pris (extraction 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 porte. Sous Windows 11 qui remplit les exigences, l’activation par défaut est la norme, donc la bonne posture n’est pas « cela ne nous concerne pas » mais « gérer la compatibilité en partant du principe que c’est déjà en cours d’exécution ».

flowchart TB
    accTitle: Les stades de compromission et l'endroit où VBS agit
    accDescr: L'accès initial est couvert par d'autres mesures telles que l'authentification multifacteur et la formation ; HVCI bloque l'injection de code dans le noyau qui suit l'élévation de privilèges ; Credential Guard bloque le vol des secrets de domaine protégés et le mouvement latéral, mais n'atteint pas les secrets hors de son périmètre
    s1["Accès initial (hameçonnage et analogues)"] --> s2["Élévation de privilèges"]
    s2 --> s3["Injection de code dans le noyau"]
    s3 --> s4["Vol des secrets de domaine protégés et mouvement latéral"]
    s1 -.-> d1["MFA, formation et EDR couvrent cela"]
    s3 -.-> d2["HVCI bloque cette étape"]
    s4 -.-> d3["Credential Guard bloque cela (secrets protégés uniquement)"]

Figure 15 : VBS n’est pas une technique « ne pas les laisser entrer » ; c’est une technique « ne pas les laisser gagner une fois qu’ils sont dedans », et le stade qu’elle garde est différent.

7.2. « Si l’intégrité de la mémoire pose un problème, il suffit de l’éteindre »

L’éteindre fera fonctionner les choses pour le moment, mais retire en bloc la barrière contre l’injection de code dans le noyau. La voie principale est d’abord d’identifier le pilote bloqué dans le journal CodeIntegrity, puis d’appliquer la version mise à jour du fournisseur. Même lorsque vous la désactivez temporairement pour validation, nous recommandons une pratique d’exploitation qui n’en fait jamais une configuration permanente.

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

C’est une surconfiance née de la confusion du périmètre de protection. Les tickets de service, les comptes locaux, les frappes clavier elles-mêmes et les informations d’identification qu’une application stocke elle-même sont hors périmètre.⁸ L’hameçonnage et les enregistreurs de frappe exigent d’autres mesures (authentification multifacteur, Windows Hello, et une revue de la façon dont l’application elle-même gère les informations d’identification).

8. Résumé

• VBS utilise l’hyperviseur pour créer un environnement isolé et protège les fonctions de sécurité en partant du principe que le noyau sera compromis.²
• 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).³
• La substance de la frontière est la protection d’accès mémoire SLAT, que le logiciel à l’intérieur de la partition, noyau compris, ne peut pas changer.³
• HVCI exécute la vérification d’intégrité du code dans l’environnement isolé et impose « non exécutable tant que la vérification n’est pas passée » et « les pages exécutables ne sont pas inscriptibles ».⁵ Le prix est qu’il faut gérer la compatibilité des pilotes.⁶
• Credential Guard isole les hachages NTLM et les TGT des informations d’identification de domaine dans LSAIso en 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 cela conjointement avec une vérification de l’état d’exécution).⁷¹
• L’état d’exécution se vérifie d’après SecurityServicesRunning dans Win32_DeviceGuard (1 = Credential Guard, 2 = HVCI).⁹

La 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é de la « force de l’isolation ». Le dernier volet regarde du côté opposé, 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

• Les profondeurs de la virtualisation Windows (partie 1) — Où s’exécute réellement votre Windows ? L’hyperviseur et les partitions
• Les profondeurs de la mémoire Windows (partie 1) — L’instant où une adresse virtuelle devient de la RAM physique : un défaut de page de bout en bout
• Pilotes minifiltres Windows
• Les codes d’erreur Windows — Win32, HRESULT et NTSTATUS

Domaines de conseil associés

KomuraSoft LLC prend en charge les investigations de compatibilité entre applications Windows et fonctions de sécurité, l’analyse des défaillances dues aux pilotes, et la validation technique des environnements PC internes.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Valorisation des actifs existants et accompagnement à la migration
• Contact

Références

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, ce sont des choses distinctes. 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 plus représentative est « Intégrité de la mémoire », qui désigne HVCI (intégrité du code protégée par l'hyperviseur). L'état d'exécution de chaque service se vérifie en interrogeant Win32_DeviceGuard, pas à partir de l'affichage de l'écran.

La mémoire de VTL1 peut-elle vraiment ne pas être lue, même avec des privilèges administrateur ou depuis un pilote noyau ?

Elle ne peut pas l'être. Les protections d'accès mémoire par VTL sont gérées par l'hyperviseur sur 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 de 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, dans un environnement isolé, 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. 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.