Die Tiefen der Windows-Virtualisierung (Teil 2) — Speicher, den selbst der Kernel nicht sieht: Wie VBS, HVCI und Credential Guard funktionieren

Es gab eine Zeit, in der Administratorrechte das „Ziel“ für einen Angreifer unter Windows waren. Laden Sie als Administrator einen Kerneltreiber, dumpen Sie den Speicher des LSASS-Prozesses, und Sie haben Kennworthashes und Kerberos-Tickets. Von dort ist es nur noch eine Sache, mit den gestohlenen Hashes zu einem anderen Rechner zu gehen.

Auf aktuellem Windows 11 mit laufendem Credential Guard — dem Standardzustand ab 22H2 auf Geräten, die die Lizenzanforderungen wie Enterprise und Education plus die Hardwareanforderungen erfüllen — funktioniert dieses Playbook nicht. Ein Angreifer, der den Kernel vollständig genommen hat, kann den Speicher durchsuchen, so viel er will, und die tatsächlichen Hashes der geschützten Domänenanmeldeinformationen werden „innerhalb dieses Betriebssystems“ nicht gefunden. Läuft es nicht, bleibt die alte Gefahr, also lesen Sie das zusammen mit den Bestätigungsmethoden später im Artikel.

Wo sind sie also? Die Antwort ist „eine andere Welt, geschaffen innerhalb desselben PCs“. Wie wir in Teil 1 gesehen haben, läuft das Host-Windows in der Root-Partition auf dem Hypervisor („Wo läuft Ihr Windows eigentlich?“). Dieser Artikel setzt dort fort und verfolgt eine weitere Grenzlinie, die der Hypervisor innerhalb derselben Partition zieht.

Die Frage, die Teil 2 beantwortet, ist nur eine.

Wohin legt Windows Geheimnisse, die weder ein Administrator noch der Kernel lesen kann?

Zielgruppe sind Entwickler und Betreiber, die Wörter wie Kernisolierung, Speicherintegrität und Credential Guard auf einem Einstellungsbildschirm oder in einem Fehlerfall gesehen haben und die wirkliche Sache von der Mechanik her verstehen wollen. Voraussetzungen sind x64 Windows 10/11 oder aktuelles Windows Server (wie in Teil 1 setzt die Behandlung von Ringen und SLAT x64 voraus; Arm64 nutzt einen anderen Mechanismus wie Exception Levels). Erforderlicher Hintergrund sind die Begriffe Partitionen und SLAT aus Teil 1. Die Schwierigkeit ist mittel. Das Ziel ist eine Erklärung der Struktur, kein How-to zum Konfigurieren der Sicherheitsmerkmale.

1. Zuerst das Fazit

Windows hat eine Privilegsachse namens VTL (Virtual Trust Level) hinzugefügt und die Geheimnisse in VTL1 gelegt. Speicher in VTL1 kann vom gewöhnlichen Kernel, der in VTL0 läuft, nicht gelesen werden. Was die Grenze bewacht, ist nicht der Kernel selbst, sondern der Hypervisor, der die SLAT-Übersetzungstabellen hält.

Das ist das Gerüst virtualisierungsbasierter Sicherheit (VBS). VBS nutzt den Hypervisor, um eine isolierte Umgebung zu schaffen, und bringt dort Sicherheitsmerkmale unter. Es ist unter der Annahme entworfen, dass die isolierte Umgebung geschützt bleibt, selbst wenn der Kernel kompromittiert ist.¹

flowchart TB
    accTitle: Die zwei Welten, die VBS schafft
    accDescr: VTL0 und VTL1 sitzen innerhalb derselben Partition; VTL0 hält den gewöhnlichen Kernel und Apps, VTL1 den Secure Kernel und isolierte Sicherheitsmerkmale, und der Hypervisor bewacht die Grenze
    subgraph vtl0 ["VTL0（die gewöhnliche Welt）"]
        apps["Apps（Ring 3）"]
        ntk["NT-Kernel und Treiber（Ring 0）"]
    end
    subgraph vtl1 ["VTL1（die isolierte Welt）"]
        ium["Isolierte Sicherheitsmerkmale"]
        sk["Secure Kernel"]
    end
    hv["Hypervisor（erzwingt die Grenze über SLAT）"] --- vtl0
    hv --- vtl1
    ntk -.->|Kann nicht lesen| ium

Abbildung 1: Es gibt zwei Welten innerhalb eines Windows, und der VTL0-Kernel kann nicht auf VTL1-Speicher zugreifen.

Der wichtige Punkt ist, dass das nicht „eine weitere VM aufstellen“ ist. VTL0 und VTL1 liegen innerhalb derselben Partition, innerhalb desselben Windows. Wir schauen der Reihe nach, wie diese Teilung verwirklicht wird.

2. Die Grenzen des Ringmodells — Der Wächter und das Bewachte sitzen auf derselben Höhe

Herkömmliche Windows-Sicherheit war auf der Leiter der Ringe (Privilegstufen) gebaut. Der Benutzermodus (Ring 3) wird vom Kernelmodus (Ring 0) bewacht. Wer also bewacht Ring 0 — niemand kann es. Ring 0 ist das höchste Privileg.

Diese Struktur hat zwei strukturelle Schwächen.

• Der Kernel ist kein Monolith. Auf Ring 0 laufen nicht nur Windows selbst, sondern eine große Zahl von Drittanbietertreibern. Hat einer von ihnen eine Schwachstelle, erhält ein Angreifer Codeausführung auf Ring 0.
• Von Ring 0 aus ist alles sichtbar. Wie sehr sich ein Benutzermodusprozess wie LSASS auch verteidigt, sein Speicher ist frei zu lesen für einen Angreifer, der den Kernel genommen hat. Schutzattribute und Seitentabellen verwaltet der Kernel selbst.

flowchart TB
    accTitle: Der Pfad des Anmeldeinformationsdiebstahls im herkömmlichen Ringmodell
    accDescr: Ein Angreifer, der Ring 0 über einen verwundbaren Treiber nimmt, kann den LSASS-Prozessspeicher mit der vollen Autorität des Kernels lesen und Kennworthashes erhalten
    mal["Angreifercode"] -->|Nutzt einen verwundbaren Treiber aus| r0["Nimmt die Kontrolle über Ring 0"]
    r0 --> readall["Kann den ganzen physischen Speicher lesen"]
    readall --> lsass["Erhält Hashes aus LSASS-Speicher"]
    lsass --> lateral["Für laterale Bewegung zu anderen Rechnern missbraucht"]

Abbildung 2: Weil der Wächter (der Kernel) und das Bewachte (die Geheimnisse) auf derselben Höhe sitzen, ist die grundlegende Schwäche, dass mit Ring 0 alles fällt.

Was also nötig ist, ist „ein Ort höher als Ring 0“. Dieser Ort erschien bereits in Teil 1. Der Hypervisor läuft auf einem höheren Privileg als der Kernel und monopolisiert früh die Steuerung der Speicherzugriffsrechte der CPU (SLAT). Eine isolierte Region, die der Hypervisor bewacht, ist selbst gegen Zugriff von OS-Software im Ring-0- (Supervisor-)Modus geschützt.²

3. VSM und VTLs — Eine weitere Privilegsachse hinzufügen

3.1. Virtual Trust Levels (VTLs)

Die Familie von Hypervisor-Merkmalen, die diese Isolierung bereitstellt, heißt VSM (Virtual Secure Mode). VSM ist die Grundlage für Device Guard, Credential Guard, ein virtuelles TPM und Ähnliches.²

Der zentrale Begriff von VSM ist der VTL (Virtual Trust Level). Die Kernpunkte sind die folgenden.²

• VTLs sind hierarchisch, und je höher die Zahl, desto höher das Privileg. VTL0 ist das niedrigste; VTL1 ist privilegierter als VTL0.
• Architektonisch sind bis zu 16 Stufen definiert, aber was derzeit umgesetzt ist, sind zwei: VTL0 und VTL1.
• Jeder VTL hat unabhängigen Speicherzugriffsschutz. Dieser Schutz wird vom Hypervisor gegenüber dem physischen Adressraum der Partition verwaltet, sodass Systemsoftware innerhalb der Partition ihn nicht ändern kann.
• Ein virtueller Prozessor hat einen getrennten Registerzustand und eine getrennte Unterbrechungsmechanik pro VTL, und ein niedrigerer VTL kann den Zustand eines höheren VTL nicht einsehen.

flowchart TB
    accTitle: Drei Unabhängigkeiten, die VTL-Isolierung ausmachen
    accDescr: Speicherzugriffsschutz, Registerzustand des virtuellen Prozessors und Unterbrechungsmechanik sind pro VTL unabhängig, und ein niedrigerer VTL kann keines davon in einem höheren VTL berühren
    vtl["Was pro VTL unabhängig ist"] --> m1["Speicherzugriffsschutz"]
    vtl --> m2["Registerzustand des virtuellen Prozessors"]
    vtl --> m3["Unterbrechungsmechanik"]
    m1 -.-> rule["Ein niedrigerer VTL kann einen höheren nicht berühren"]
    m2 -.-> rule
    m3 -.-> rule

Abbildung 3: Nicht nur Speicher, sondern auch CPU-Zustand und Unterbrechungen zu einer getrennten Welt zu machen, ist das Dreierpaket, das kein Guckloch lässt.

Sind Ringe (0 und 3) die Achse, die „Betriebssystem und Apps“ trennt, sind VTLs eine zweite Achse, die „die gewöhnliche Welt und die isolierte Welt“ trennt. Die zwei Achsen stehen senkrecht aufeinander, und innerhalb von VTL1 gibt es ebenfalls Kernelmodus und Benutzermodus.

flowchart TB
    accTitle: Vier Regionen, die die zwei Achsen von Ringen und VTLs schaffen
    accDescr: Die Ringachse trennt Kernelmodus und Benutzermodus, die VTL-Achse die gewöhnliche Welt und die isolierte Welt, und die Kombination ergibt vier Regionen: gewöhnliche Apps, den NT-Kernel, IUM-Trustlets und den Secure Kernel
    subgraph ax0 ["VTL0（gewöhnliche Welt）"]
        a0["Ring 3: gewöhnliche Apps"]
        k0["Ring 0: NT-Kernel und Treiber"]
    end
    subgraph ax1 ["VTL1（isolierte Welt）"]
        a1["Ring 3: IUM（Trustlets）"]
        k1["Ring 0: Secure Kernel"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

Abbildung 4: Es gibt nun zwei Privilegsachsen, und „ist es der Kernel?“ und „ist es die isolierte Welt?“ wurden getrennte Fragen.

3.2. Die Substanz der Grenze ist SLAT

In Teil 1 haben wir gesagt, dass die Übersetzungstabellen der zweiten Stufe, die eine Gast-Physikadresse (GPA) auf tatsächliches RAM (SPA) abbilden — SLAT — der Hypervisor hält. VSM nutzt genau diese Eigenschaft. VTL-Isolierung entsteht mit dem Hyper-V-Hypervisor und SLAT.³

Wenn VTL1 erklärt „dieser Speicher soll VTL0 nicht gezeigt werden“, nimmt der Hypervisor das Zugriffsrecht auf diese Seite aus den Übersetzungstabellen von VTL0. Von da an, selbst wenn der VTL0-Kernel versucht, diese Adresse zu berühren, wird das in der Adressübersetzungsstufe der CPU verweigert. Es nützt nichts, dass der Kernel seine eigenen Seitentabellen umschreibt, wie er will. Die Seitentabellen (GVA→GPA) mögen dem Kernel gehören, aber die Übersetzung darüber hinaus (GPA→SPA) und das endgültige Zugriffsrecht gehören dem Hypervisor.

flowchart TB
    accTitle: Der Ablauf, mit dem Zugriff von VTL0 auf VTL1-Speicher verweigert wird
    accDescr: Versucht der VTL0-Kernel, VTL1-Speicher zu lesen, kann er seine eigene Seitentabelle passieren, wird aber durch SLAT-Zugriffsschutz verweigert, und die Steuerung geht an den Hypervisor
    try["VTL0-Kernel versucht, eine VTL1-Seite zu lesen"] --> pt["Passiert die eigene Seitentabelle des Kernels"]
    pt --> slat{"Erlaubt SLAT-Zugriffsschutz es?"}
    slat -->|Nicht erlaubt| deny["Hypervisor greift ein und verweigert Zugriff"]
    slat -->|Erlaubt| ok["Gewöhnlicher Speicherzugriff"]
    deny -.-> point["Geschützt auf einer Schicht, die der Kernel nicht ändern kann"]

Abbildung 5: Die Barriere sitzt außerhalb des Kernels, und SLAT-Schutz kann Software innerhalb der Partition nicht ändern.

In Teil 1 der Speicherreihe haben wir geschrieben, dass „VADs, PTEs und Schutzattribute entscheiden, ob Zugriff erlaubt ist“. In einer VBS-Umgebung können Sie es so ordnen: Nachdem all das passiert ist, wartet immer noch ein SLAT-Kontrollpunkt.

3.3. Der Secure Kernel und IUM

Was innerhalb von VTL1 läuft, ist nicht der gewöhnliche NT-Kernel, sondern ein kleiner Kernel namens Secure Kernel. Der Benutzermodus in VTL1 heißt IUM (Isolated User Mode), und die Programme, die dort laufen, heißen Trustlets (vertrauenswürdige Prozesse).³

Ein Trustlet kann nicht alles tun, wie ein gewöhnlicher Prozess es kann. Die meisten Systemaufrufe werden an den NT-Kernel auf der VTL0-Seite gemarshallt, und die Arbeit wird dort angefordert.³ VTL1 ist keine „obere Welt, die alles kann“; sie ist absichtlich klein gebaut, als Tresor, der Geheimnisse hält. Je weniger Code Sie in den Tresor bringen können, desto kleiner die Angriffsfläche.

flowchart TB
    accTitle: Der Ablauf der Systemaufrufe eines Trustlets
    accDescr: Ein Trustlet in VTL1 behandelt die meisten Systemaufrufe nicht selbst; es marshallt sie an den VTL0-NT-Kernel und empfängt nur das Ergebnis, was VTL1 klein hält
    tl["Trustlet（IUM in VTL1）"] --> sc{"Ein Systemaufruf ist nötig"}
    sc -->|In den meisten Fällen| mar["Anfrage wird an den VTL0-NT-Kernel gemarshallt"]
    mar --> res["Nur das Ergebnis kommt zurück"]
    res -.-> small["VTL1 bleibt klein und schrumpft die Angriffsfläche"]

Abbildung 6: Der Tresor hat keine eigenen Einrichtungen; er lagert die Alltagspflichten aus und bewacht weiter nur die Geheimnisse.

4. HVCI — Integrität von Kernelcode im Tresor prüfen

4.1. Was geprüft wird

Das erste repräsentative Merkmal, das auf VBS sitzt, ist Speicherintegrität — HVCI (hypervisor-protected code integrity). Windows hat einen Codeintegritätsmechanismus, der Kernelmodustreiber und Binärdateien vor dem Start prüft und unsignierte oder nicht vertrauenswürdige nicht lädt. HVCI führt diese Prüfung innerhalb der isolierten Umgebung von VBS aus.¹

Der Grund, die Prüfungslogik selbst nach VTL1 zu verlegen, ist genau die Schwäche in Abschnitt 2. Sitzt der Prüfungscode innerhalb des VTL0-Kernels, kann ein Angreifer, der den Kernel genommen hat, die Prüfung austauschen. Sitzt er in VTL1, reicht die austauschende Hand nicht hin.

flowchart TB
    accTitle: Der Unterschied, den der Wohnort des Prüfungscodes macht
    accDescr: Sitzt der Prüfungscode innerhalb des VTL0-Kernels, kann er durch das Nehmen des Kernels deaktiviert werden; sitzt er in VTL1, kann selbst ein Angreifer, der den Kernel genommen hat, ihn nicht erreichen, und die Prüfung bleibt geschützt
    atk["Angreifer, der den Kernel genommen hat"] --> q{"Wo lebt die Codeintegritätsprüfung?"}
    q -->|"Innerhalb des VTL0-Kernels（klassisch）"| bad["Die Prüfungslogik kann ausgetauscht werden"]
    q -->|"Isolierte Umgebung in VTL1（HVCI）"| good["Der Austausch ist außer Reichweite"]
    bad --> res1["Unsignierter Code kann im Kernel laufen"]
    good --> res2["Die Prüfung arbeitet weiter, nachdem der Kernel kompromittiert ist"]

Abbildung 7: Legen Sie den Kontrollpunkt nicht in die Seite, die durchbrochen werden könnte — diese Verlegung der Prüfungslogik ist das Wesen von HVCI.

4.2. Die Regeln für ausführbare Seiten

Die Wirkung von HVCI beschränkt sich nicht auf „Prüfung beim Start“. Sie schränkt auch die Zuteilung von Kernelspeicher ein.⁴

• Eine Kernelseite wird erst ausführbar, nachdem sie die Codeintegritätsprüfung bestanden hat.
• Eine ausführbare Seite wird nicht beschreibbar (sogenanntes W^X).

Wenn diese zwei stehen, können Sie selbst dann, wenn eine Schwachstelle wie ein Pufferüberlauf Ihnen das Umschreiben von Kernelspeicher erlaubt, den umgeschriebenen Inhalt nicht zur Ausführung bringen. Eine ausführbare Seite kann nicht umgeschrieben werden, und eine Seite, die umgeschrieben werden kann, kann nicht ausgeführt werden.⁴ Die endgültige Absicherung des Ausführungsrechts ist das Ausführungsrecht auf der SLAT-Seite, das der VTL0-Kernel nicht manipulieren kann.

flowchart TB
    accTitle: Bis eine Kernelseite in einer HVCI-Umgebung ausführbar wird
    accDescr: Eine Treiberladeanfrage erhält eine Codeintegritätsprüfung in der isolierten Umgebung von VBS; besteht sie, wird sie als ausführbare, nicht beschreibbare Seite erlaubt, und scheitert sie, wird sie blockiert und im CodeIntegrity-Protokoll festgehalten
    load["Anfrage, Kernelcode zu laden und auszuführen"] --> verify{"Codeintegritätsprüfung in der isolierten Umgebung"}
    verify -->|Bestehen| exec["Ausführbar（Schreiben verboten）"]
    verify -->|Scheitern| block["Laden wird blockiert"]
    block --> log["CodeIntegrity-Protokoll（3087）"]
    exec -.-> wx["Beschreibbare Seiten bleiben nicht ausführbar"]

Abbildung 8: Die Prüfung der Regel, die Ausführen und Schreiben nicht koexistieren lässt, geschieht auf der VTL1-Seite, und der VTL0-Kernel kann sie nicht umstoßen.

Verfolgen Sie das aus der Sicht eines Angreifers, wird klar, wie die Regel greift.

flowchart TB
    accTitle: Der Ablauf, mit dem Codeeinschleusung in einer HVCI-Umgebung scheitert
    accDescr: Selbst wenn eine Schwachstelle Ihnen das Umschreiben von Kernelspeicher erlaubt, ist eine Seite, die Sie schreiben konnten, nicht ausführbar, und eine ausführbare Seite kann von vornherein nicht umgeschrieben werden, sodass der eingeschleuste Code nicht zur Ausführung gebracht werden kann
    inj["Versuchen, Kernelspeicher über eine Schwachstelle zu manipulieren"] --> which{"Welche Seite ist das Ziel?"}
    which -->|Eine beschreibbare Seite| wok["Das Schreiben gelingt"]
    which -->|Eine ausführbare Seite| xfail["Das Schreiben selbst ist unmöglich"]
    wok --> nx["Aber diese Seite ist nicht ausführbar"]
    nx --> dead["Der eingeschleuste Code kann nicht ausgeführt werden"]
    xfail --> dead

Abbildung 9: Die Bedeutung, beschreibbare Seiten nicht mit ausführbaren Seiten zu kreuzen, ist, dass Sie, welchen Eingang Sie auch nehmen, in einer Sackgasse landen.

4.3. Der Preis in Treiberkompatibilität

Diese Regel stößt mit Treibern älteren Entwurfs zusammen. Solche, die ihren eigenen Code zur Laufzeit umschreiben, keine Signatur haben oder Speicher verlangen, der sowohl ausführbar als auch beschreibbar ist — solche Treiber können in einer HVCI-Umgebung nicht geladen werden. Die Tatsache der Blockade können Sie in der Ereignisanzeige unter Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational bestätigen (Ereignis-ID 3087 ist repräsentativ).⁵

„Nachdem ich Speicherintegrität aktiviert habe, hat ein Peripheriegerät aufgehört zu funktionieren“ — in vielen Fällen ist das die wirkliche Identität des Ärgers. Die richtige Reaktion ist, auf einen HVCI-kompatiblen Treiber zu aktualisieren; das Deaktivieren von Speicherintegrität sollten Sie als letzten Ausweg denken, der den Schutz im Ganzen aufgibt. Wenn Sie an dieser Prüfung aus Treibersicht beteiligt sind, siehe auch den Filtertreiberartikel („Windows-Minifiltertreiber“).

flowchart TB
    accTitle: Den Fall isolieren, in dem ein Peripheriegerät unter Speicherintegrität aufhört zu funktionieren
    accDescr: Identifizieren Sie den blockierten Treiber im CodeIntegrity-Operational-Protokoll; die richtige Reaktion ist, auf eine HVCI-kompatible Version zu aktualisieren, den Hersteller zu fragen, wenn keine existiert, und das Deaktivieren als letzten Ausweg zu behandeln, den Sie nicht dauerhaft machen
    sym["Ein Gerät hört auf zu funktionieren, nachdem Speicherintegrität aktiviert ist"] --> log2["Den blockierten Treiber im CodeIntegrity-Protokoll identifizieren"]
    log2 --> upd{"Gibt es einen HVCI-kompatiblen Treiber?"}
    upd -->|Ja| fix2["Aktualisieren und lösen, während HVCI an bleibt"]
    upd -->|Nein| ask2["Den Hersteller nach einer kompatiblen Version fragen"]
    ask2 -.-> temp["Deaktivieren ist ein letzter Ausweg, keine dauerhafte Einstellung"]

Abbildung 10: Das Erste, das Sie anschauen, ist nicht der Einstellungsbildschirm, sondern das Protokoll, und Ereignis-ID 3087 weiß, wer das Laden blockiert hat.

5. Credential Guard — Die Hashes liegen innerhalb von LSAIso

5.1. LSASS und LSAIso

Das zweite repräsentative Merkmal, das auf VBS sitzt, ist die Antwort auf das Eröffnungsrätsel: Credential Guard.

Herkömmliches Windows hielt NTLM-Hashes und Kerberos-Tickets im Speicher des LSA-Prozesses (lsass.exe). Wenn Credential Guard aktiviert ist, wandert die Speicherung der geschützten Geheimnisse darunter — der NTLM-Hashes von Domänenanmeldeinformationen und Kerberos-TGTs (Ticket Granting Tickets) — zu LSAIso.exe, einem Trustlet, das in IUM in VTL1 läuft.⁶

• lsass.exe (VTL0) läuft weiter als Empfang der Authentifizierungsverarbeitung, wie bisher.
• Die tatsächlichen Geheimnisse hält LSAIso.exe (VTL1) und sie sind von VTL0 aus nicht zugänglich.
• Die zwei kommunizieren über RPC (Remote Procedure Call).
• LSAIso beherbergt überhaupt keine Gerätetreiber und bringt nur das Minimum signierter Binärdateien unter. Die Signaturen werden mit einem Zertifikat geprüft, dem VBS vertraut.⁶

flowchart TB
    accTitle: Wo Anmeldeinformationen sitzen, wenn Credential Guard aktiviert ist
    accDescr: lsass in VTL0 kommuniziert mit LSAIso in VTL1 über RPC als Authentifizierungsempfang; die tatsächlichen Hashes und TGTs geschützter Domänenanmeldeinformationen hält LSAIso, sodass ein Angreifer, der Administratorrechte in VTL0 erhält und lsass dumpt, trotzdem nicht die geschützte Substanz bekommt
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe（Authentifizierungsempfang）"]
        att["Angreifer（Administratorrechte）"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe（Tresor für Geheimnisse）"]
    end
    lsassP <-->|RPC| iso
    att -->|Speicherdump| lsassP
    att -.->|Kann nicht erreichen| iso

Abbildung 11: Weil Empfang und Tresor getrennt wurden, liefert das Dumpen von lsass nicht mehr die tatsächlichen Hashes der geschützten Domänenanmeldeinformationen.

Ab Windows 11 Version 22H2 sind auf Geräten, die die Lizenzanforderungen (Enterprise E3/E5, Education A3/A5) und die Hardwareanforderungen erfüllen, VBS und Credential Guard standardmäßig aktiviert. Auf Editionen wie Pro wird Credential Guard nicht automatisch aktiviert (es gibt Ausnahmen, etwa wenn ein Rechner, der unter einer qualifizierenden Lizenz aktiviert war, später herabgestuft wird).⁷ „Das Playbook funktioniert nicht mehr“ in der Eröffnung ist keine Geschichte über ein besonderes Zusatzprodukt; es ist der Standardzustand aktuellen Windows auf den Ziel-Editionen.

flowchart TB
    accTitle: Der Ablauf von Anmeldeinformationen von der Anmeldung zur Authentifizierung
    accDescr: Nach der Anmeldung werden die tatsächlichen Geheimnisse in LSAIso in VTL1 gespeichert; jedes Mal, wenn Authentifizierung nötig ist, fordert lsass in VTL0 Berechnung über RPC an, und nur das Ergebnis der Authentifizierungsverarbeitung kommt nach VTL0 zurück, ohne dass die geschützten langfristigen Geheimnisse selbst zurückgegeben werden
    signin["Benutzer meldet sich an"] --> front["lsass behandelt es als Empfang"]
    front --> store["Die tatsächlichen Geheimnisse werden in LSAIso gespeichert"]
    auth["Nachfolgende Authentifizierungsanfragen"] --> front
    front -->|"Berechnung über RPC anfordern"| store
    store -->|"Gibt das Ergebnis zurück（gibt das Geheimnis nicht zurück）"| front

Abbildung 12: Die geschützten langfristigen Geheimnisse selbst verlassen den Tresor nie; was nach VTL0 zurückkehrt, ist das Ergebnis der Authentifizierungsverarbeitung, etwa ein Ticket.

5.2. Genau wissen, was nicht geschützt ist

Credential Guard ist kein Allzweckschild. Was geschützt ist, sind NTLM-Hashes von Domänenanmeldeinformationen, Kerberos-TGTs (Ticket Granting Tickets) und Dinge, die als Domänenanmeldeinformationen gespeichert sind. Die folgenden liegen außerhalb des Bereichs.⁸

• Kerberos-Diensttickets (TGTs sind geschützt)
• Anmeldeinformationen lokaler Konten und Microsoft-Konten
• Diebstahl von Eingaben durch einen Keylogger und physische Angriffe
• Anmeldeinformationen auf Pfaden, die NTLMv1, MS-CHAPv2, Digest oder CredSSP nutzen
• Das Innere von Drittanbietersoftware, die Anmeldeinformationen selbst verwaltet

Außerdem werden, wenn Credential Guard aktiviert ist, NTLMv1, uneingeschränkte Kerberos-Delegierung und Ähnliches unbenutzbar, sodass Geschäftssysteme, die von Legacy-Authentifizierung abhängen, eine Kompatibilitätsprüfung brauchen.⁸ Nicht „aktivieren und Sie sind fertig“, sondern erfassen, was innerhalb und außerhalb des Verteidigungsbereichs liegt, und den Rest mit anderen Steuerungen füllen — das ist der richtige Weg, es in der Praxis zu nutzen.

flowchart TB
    accTitle: Der Verteidigungsbereich von Credential Guard
    accDescr: Domänen-NTLM-Hashes und TGTs sowie gespeicherte Domänenanmeldeinformationen sind geschützt, während Diensttickets, lokale Konten, Keylogger, physische Angriffe und von einer App privat gespeicherte Anmeldeinformationen außerhalb des Bereichs liegen
    scope{"Auf welcher Seite der Schutzgrenze liegt dieses Geheimnis?"} --> inA["Domänen-NTLM-Hashes und TGTs"]
    scope --> outA["Diensttickets und lokale Konten"]
    inA --> prot["Geschützt in LSAIso"]
    outA --> unprot["Nicht geschützt（andere Steuerungen nötig）"]
    unprot -.-> outB["Tastenanschläge, physische Angriffe und app-private Speicher liegen ebenfalls außerhalb"]

Abbildung 13: Der Verteidigungsbereich ist mit einer klaren Linie gezogen, und die Außenseite der Linie wird mit Mehrfaktorauthentifizierung und Entwurf auf der App-Seite gefüllt.

6. Selbst nachsehen

Sie können den Laufzustand von VBS und jedem Merkmal auf Ihrem eigenen Rechner bestätigen.

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

Wie Sie es lesen, ist wie folgt.⁹

• Ist VirtualizationBasedSecurityStatus 2, ist VBS aktiviert und läuft.
• Enthält SecurityServicesRunning 1, läuft Credential Guard; enthält es 2, läuft Speicherintegrität (HVCI).

Um den Laufzustand in der GUI zu bestätigen, schauen Sie auf das Feld „Virtualisierungsbasierte Sicherheit“ in msinfo32 (laufende Dienste sind aufgelistet, etwa „Hypervisor enforced Code Integrity“). Der Schalter „Speicherintegrität“ unter „Gerätesicherheit > Kernisolierung“ in der Windows-Sicherheit-App ist ein Bildschirm, der Einstellungen widerspiegelt; er kann an aussehen, während HVCI tatsächlich nicht läuft — Warten auf einen Neustart direkt nach der Aktivierung oder ein Kompatibilitätsproblem beim Start —, also beurteilen Sie, ob es läuft, anhand von msinfo32 oder von SecurityServicesRunning von Win32_DeviceGuard.⁵

Es gibt auch eine Spur auf der Registerkarte Details des Task-Managers. Auf einem Rechner, auf dem VBS läuft, sehen Sie einen Prozess namens „Secure System“. LsaIso.exe ist der Prozess, der erscheint, wenn der Isolated-LSA-Dienst in VTL1 beherbergt wird, und er erscheint normalerweise nicht in einer Konfiguration, in der nur HVCI aktiviert ist. Das Vorhandensein oder Fehlen eines Prozesses ist jedoch nur eine Spur, also beurteilen Sie, ob Credential Guard läuft, anhand von SecurityServicesRunning (ob es 1 enthält), wie oben. Beide sind Fenster, die von VTL0 aus sichtbar sind und der Welt auf der VTL1-Seite entsprechen.

flowchart TB
    accTitle: Wie Sie prüfen, dass VBS-bezogene Merkmale laufen
    accDescr: Bestätigen Sie, dass VBS läuft, indem Sie Win32_DeviceGuard abfragen, beurteilen Sie Credential Guard und HVCI anhand der Werte von SecurityServicesRunning, und schauen Sie bei Treiberproblemen ins CodeIntegrity-Protokoll
    q0["Win32_DeviceGuard"] --> q1{"VBS-Status 2?"}
    q1 -->|Nein| off["VBS läuft nicht"]
    q1 -->|Ja| q2{"Enthält 1 oder 2?"}
    q2 -->|1| cg["Credential Guard an"]
    q2 -->|2| hvciR["HVCI an"]
    hvciR -.-> ev["CodeIntegrity 3087"]

Abbildung 14: Die Zustandsbestätigung verläuft in drei Stufen: VBS selbst, jeder Dienst darauf und das Protokoll, wenn ein Problem auftritt.

7. Drei Fehldeutungen, die Sie in der Praxis vermeiden

7.1. „Administratorrechte zu schützen reicht. VBS ist eine Geschichte der Serverseite“

Was Credential Guard verhindert, ist, dass Schaden sich nach dem Nehmen von Administratorrechten ausbreitet (Hashexfiltration und laterale Bewegung). Mit anderen Worten ist VBS eine Schicht der Verteidigung in der Tiefe, die Kompromittierung annimmt, und wirksam ist sie auf Client-PCs. Auf Windows 11, das die Anforderungen erfüllt, ist standardmäßig aktiviert der Standard, also ist die richtige Haltung nicht „das hat nichts mit uns zu tun“, sondern „Kompatibilität unter der Annahme verwalten, dass es bereits läuft“.

flowchart TB
    accTitle: Stufen der Kompromittierung und wo VBS greift
    accDescr: Erster Zugriff wird von anderen Steuerungen wie Mehrfaktorauthentifizierung und Schulung abgedeckt; Speicherintegrität blockiert Codeeinschleusung in den Kernel nach Rechteausweitung; Credential Guard blockiert Diebstahl geschützter Domänengeheimnisse und laterale Bewegung, erreicht aber Geheimnisse außerhalb seines Bereichs nicht
    s1["Erster Zugriff（Phishing und Ähnliches）"] --> s2["Rechteausweitung"]
    s2 --> s3["Codeeinschleusung in den Kernel"]
    s3 --> s4["Diebstahl geschützter Domänengeheimnisse und laterale Bewegung"]
    s1 -.-> d1["MFA, Schulung und EDR decken das ab"]
    s3 -.-> d2["HVCI blockiert diesen Schritt"]
    s4 -.-> d3["Credential Guard blockiert das（nur geschützte Geheimnisse）"]

Abbildung 15: VBS ist keine Technik „lass sie nicht herein“; sie ist eine Technik „lass sie nach dem Hereinlassen nicht gewinnen“, und die Stufe, die sie bewacht, ist eine andere.

7.2. „Wenn Speicherintegrität ein Problem verursacht, schalten Sie sie einfach aus“

Sie auszuschalten wird die Dinge vorübergehend zum Laufen bringen, nimmt aber die Barriere gegen Codeeinschleusung in den Kernel im Ganzen herunter. Die richtige Reaktion ist zuerst, den blockierten Treiber im CodeIntegrity-Protokoll zu identifizieren und die aktualisierte Version des Herstellers anzuwenden. Selbst wenn Sie sie vorübergehend zur Validierung deaktivieren, empfehlen wir einen Betrieb, der das nicht zur dauerhaften Einstellung macht.

7.3. „Mit Credential Guard können Kennwörter nicht gestohlen werden“

Das ist Übervertrauen aus dem Vermischen des Verteidigungsbereichs. Diensttickets, lokale Konten, Tastenanschläge selbst und von einer App privat gespeicherte Anmeldeinformationen liegen außerhalb des Bereichs.⁸ Phishing und Keylogger brauchen andere Steuerungen (Mehrfaktorauthentifizierung, Windows Hello und eine Prüfung der Anmeldeinformationsverwaltung auf der App-Seite).

8. Zusammenfassung

• VBS nutzt den Hypervisor, um eine isolierte Umgebung zu schaffen, und schützt Sicherheitsmerkmale unter der Annahme, dass der Kernel kompromittiert werden kann.¹
• Die Isolierungseinheit ist der VTL; derzeit sind zwei Stufen umgesetzt, VTL0 (die gewöhnliche Welt) und VTL1 (der Secure Kernel und IUM).²
• Die Substanz der Grenze ist SLAT-Speicherzugriffsschutz, den Software innerhalb der Partition — einschließlich des Kernels — nicht ändern kann.²
• HVCI führt die Codeintegritätsprüfung in der isolierten Umgebung aus und erzwingt „nicht ausführbar, bis die Prüfung besteht“ und „eine ausführbare Seite ist nicht beschreibbar“.⁴ Der Preis ist, dass Sie Treiberkompatibilität verwalten müssen.⁵
• Credential Guard isoliert NTLM-Hashes von Domänenanmeldeinformationen und TGTs in LSAIso in VTL1. Ab Windows 11 22H2 ist es auf Geräten, die die Lizenzanforderungen (Enterprise, Education) und die Hardwareanforderungen erfüllen, standardmäßig aktiviert (nutzen Sie das zusammen mit einer Prüfung des Laufzustands).⁶⁷
• Den Laufzustand können Sie anhand von SecurityServicesRunning von Win32_DeviceGuard bestätigen (1 = Credential Guard, 2 = HVCI).⁹

Weiter in Teil 3, „Virtuelle Maschinen, die in Sekunden starten — WSL2, Windows Sandbox und Container“.

Bisher haben wir Virtualisierung von der Seite der „Stärke der Isolierung“ betrachtet. Die letzte Folge schaut von der entgegengesetzten, der „Leichtigkeit“-Seite, und verfolgt, wo die leichten VMs, die das Gewicht einer vollen VM abgelegt haben, kürzer treten.

Weiterführende Artikel

• Die Tiefen der Windows-Virtualisierung (Teil 1) — Wo läuft Ihr Windows eigentlich? Hypervisor und Partitionen
• The Depths of Windows Memory (Part 1) — The Moment a Virtual Address Becomes Physical RAM: A Page Fault from Start to Finish
• Die Tiefen von Windows I/O (Teil 6, Finale) ── Filtertreiber und Minifilter: Warum Procmon und Virenscanner sich in die I/O einklinken können
• Decoding Windows Error Codes — The Three-Layer Structure of Win32 Errors, HRESULT, and NTSTATUS

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt Kompatibilitätsuntersuchungen zwischen Windows-Anwendungen und Sicherheitsmerkmalen, die Analyse treiberbedingter Ausfälle sowie die technische Validierung interner PC-Umgebungen.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Weiternutzung und Migration von Altbeständen
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Sind VBS (virtualisierungsbasierte Sicherheit) und Kernisolierung dasselbe?

Genau genommen sind sie verschieden. VBS ist die Grundlagentechnik, die mit dem Hypervisor eine isolierte Umgebung schafft, und „Kernisolierung“ in der Windows-Sicherheit-App ist der Name eines Bildschirms, der mehrere auf VBS aufbauende Schutzmaßnahmen gruppiert. Der repräsentative ist „Speicherintegrität“, der auf HVCI (hypervisor-protected code integrity) verweist. Bestätigen Sie den Laufzustand jedes Dienstes, indem Sie Win32_DeviceGuard abfragen, nicht anhand der Bildschirmanzeige.

Kann VTL1-Speicher wirklich nicht gelesen werden, selbst mit Administratorrechten oder von einem Kerneltreiber?

Er kann es nicht. Speicherzugriffsschutz pro VTL verwaltet der Hypervisor gegenüber dem physischen Adressraum der Partition, und Software, die innerhalb der Partition läuft, kann ihn nicht ändern. Selbst Code, der im Kernel (Ring 0) läuft, darf von VTL0 aus nicht auf VTL1-Speicher zugreifen.

Warum kann das Aktivieren von Speicherintegrität (HVCI) einen Treiber außer Betrieb setzen?

In einer HVCI-Umgebung wird eine Kernelseite erst ausführbar, nachdem sie die Integritätsprüfung bestanden hat, und Schreiben auf ausführbare Seiten ist nicht erlaubt. Ein unsignierter Treiber oder ein Treiber älteren Entwurfs, der ausführbaren Speicher umschreibt, kann diese Einschränkung nicht erfüllen, und sein Laden wird blockiert. Die Blockade können Sie im CodeIntegrity-Operational-Protokoll bestätigen (Ereignis-ID 3087 und Ähnliches).

Was schützt Credential Guard, und was schützt es nicht?

Es schützt NTLM-Kennworthashes von Domänenanmeldeinformationen, Kerberos-TGTs und Dinge, die eine App als Domänenanmeldeinformationen gespeichert hat, in einer isolierten Umgebung. Kerberos-Diensttickets, Anmeldeinformationen lokaler Konten und Microsoft-Konten, Diebstahl von Eingaben durch einen Keylogger und physische Angriffe liegen außerhalb des Bereichs.

Wo kann ich prüfen, ob VBS läuft?

Schauen Sie auf das Feld „Virtualisierungsbasierte Sicherheit“ in msinfo32 oder fragen Sie die Klasse Win32_DeviceGuard im Namespace root/Microsoft/Windows/DeviceGuard aus PowerShell ab. Enthält SecurityServicesRunning 1, läuft Credential Guard; enthält es 2, läuft Speicherintegrität (HVCI).

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.