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

Wohin legt Windows Geheimnisse, die weder ein Administrator noch der Kernel lesen kann? Teil 2 geht von dieser Frage aus und verfolgt, wie VBS, HVCI und Credential Guard funktionieren.

Unter herkömmlichem Windows konnte ein Angreifer als Administrator einen Kerneltreiber laden, den Speicher des LSASS-Prozesses dumpen, Kennworthashes und Kerberos-Tickets stehlen und sie für laterale Bewegung zu anderen Rechnern missbrauchen.

Unter Windows 11 mit laufendem Credential Guard liegen die Hashes der geschützten Domänenanmeldeinformationen nirgendwo, wo der gewöhnliche Kernel suchen kann. Auf Geräten, die die Lizenzanforderungen (Enterprise, Education und Ähnliches) und die Hardwareanforderungen erfüllen, ist dieser Schutz ab 22H2 standardmäßig aktiv.¹ Anforderungen und tatsächlicher Laufzustand sind zwei verschiedene Dinge; wo es nicht läuft, ist die Gefahr nicht verschwunden.

Teil 1 hat die Struktur gezeigt, in der das Host-Windows in der Root-Partition auf dem Hypervisor läuft. Was dieser Artikel verfolgt, ist eine weitere Grenzlinie, die innerhalb derselben Partition gezogen wird.

„Die Tiefen der Windows-Virtualisierung“ — Alle 3 Teile

Wir betrachten denselben Windows-Hypervisor in der Reihenfolge Grundlage → Sicherheitsisolierung → Anwendung auf leichte VMs.

Voraussetzungen für diesen Artikel

Wie Sie diesen Artikel lesen

1. Zuerst das Fazit

Windows hat eine Privilegsachse namens VTL (Virtual Trust Level) hinzugefügt und die Geheimnisse in VTL1 gelegt. Der gewöhnliche Kernel, der in VTL0 läuft, kann Speicher in VTL1 nicht lesen. 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 Sicherheitsfunktionen 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 Sicherheitsfunktionen, 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 Sicherheitsfunktionen"]
        sk["Secure Kernel"]
    end
    hv["Hypervisor (erzwingt die Grenze über SLAT)"] --- vtl0
    hv --- vtl1
    ntk -.->|Kein Lesezugriff| ium

Abbildung 1: Innerhalb eines Windows gibt es zwei Welten, und der Kernel in VTL0 kann nicht auf Speicher in VTL1 zugreifen.

Wichtig ist, dass dies nicht „noch eine VM aufsetzen“ ist. VTL0 und VTL1 liegen innerhalb derselben Partition, innerhalb desselben Windows. Wie diese Teilung erreicht wird, sehen wir der Reihe nach.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (22 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Die Grenzen des Ringmodells — Wächter und Bewachtes stehen auf derselben Höhe

Die herkömmliche Windows-Sicherheit war auf der Leiter der Ringe (Privilegstufen) aufgebaut. Den Benutzermodus (Ring 3) bewacht der Kernelmodus (Ring 0). Wer bewacht dann 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 Treibern Dritter. Hat einer davon eine Schwachstelle, erhält der Angreifer Codeausführung auf Ring 0.
• Von Ring 0 aus ist alles sichtbar. Wie gut sich ein Benutzermodusprozess wie LSASS auch selbst verteidigt: Ein Angreifer, der den Kernel übernommen hat, kann dessen Speicher frei lesen. Schutzattribute und Seitentabellen verwaltet der Kernel selbst.

flowchart TB
    accTitle: Der Pfad zum Diebstahl von Anmeldeinformationen im herkömmlichen Ringmodell
    accDescr: Ein Angreifer, der über einen verwundbaren Treiber Ring 0 übernimmt, kann mit voller Kernelautorität den Speicher des LSASS-Prozesses lesen und Kennworthashes erlangen
    mal["Code des Angreifers"] -->|Nutzt einen verwundbaren Treiber aus| r0["Übernimmt Ring 0"]
    r0 --> readall["Kann den gesamten physischen Speicher lesen"]
    readall --> lsass["Holt Hashes aus dem LSASS-Speicher"]
    lsass --> lateral["Missbraucht für laterale Bewegung zu anderen Rechnern"]

Abbildung 2: Weil Wächter (der Kernel) und Bewachtes (die Geheimnisse) auf derselben Höhe stehen, ist die grundlegende Schwäche: Fällt Ring 0, fällt alles.

Was also nötig ist, ist „ein Ort höher als Ring 0“. Dieser Ort ist in Teil 1 bereits aufgetreten. Der Hypervisor läuft mit höherem Privileg als der Kernel und nimmt die Steuerung der Speicherzugriffserlaubnisse der CPU (SLAT) früh ausschließlich in Besitz. Ein Isolierbereich, den der Hypervisor bewacht, ist auch gegen Zugriff von Ring-0-Betriebssystemsoftware (Supervisor-Modus) geschützt.³

3. VSM und VTL — Der Privilegsachse eine weitere Achse hinzufügen

Dieser Abschnitt ordnet in der Reihenfolge die Funktionsgruppe, die die Isolierung bereitstellt (VSM) → die Isolierungsstufen (VTL) → der Mechanismus, der die Grenze erzwingt (SLAT) → der Code, der darin läuft. Die Namen ähneln sich, sind aber nicht dasselbe.

3.1. Virtuelle Vertrauensstufen (VTL)

Die Funktionsgruppe des Hypervisors, die diese Isolierung bereitstellt, heißt VSM (Virtual Secure Mode). VSM ist die Grundlage für Device Guard, Credential Guard, das virtuelle TPM und Ähnliches.³

Der zentrale Begriff von VSM ist die VTL (Virtual Trust Level, virtuelle Vertrauensstufe). Die wichtigsten Punkte sind folgende.³

• VTLs sind hierarchisch, und je größer die Nummer, desto höher das Privileg. VTL0 ist die unterste Stufe; VTL1 ist privilegierter als VTL0.
• Architektonisch sind bis zu 16 Stufen definiert, aber derzeit implementiert sind zwei: VTL0 und VTL1.
• Jede VTL hat unabhängigen Speicherzugriffsschutz. Diesen Schutz verwaltet der Hypervisor gegenüber dem physischen Adressraum der Partition, sodass Systemsoftware innerhalb der Partition ihn nicht ändern kann.
• Ein virtueller Prozessor hat je VTL eigenen Registerzustand und eigene Unterbrechungsmechanik; von einer niedrigeren VTL aus kann man den Zustand einer höheren VTL nicht einsehen.

flowchart TB
    accTitle: Die drei Unabhängigkeiten, aus denen VTL-Isolierung besteht
    accDescr: Speicherzugriffsschutz, Registerzustand des virtuellen Prozessors und Unterbrechungsmechanik sind je VTL unabhängig, und von einer niedrigeren VTL aus ist keines davon in einer höheren VTL berührbar
    vtl["Was je VTL unabhängig ist"] --> m1["Speicherzugriffsschutz"]
    vtl --> m2["Registerzustand des virtuellen Prozessors"]
    vtl --> m3["Unterbrechungsmechanik"]
    m1 -.-> rule["Eine niedrigere VTL kann eine höhere VTL nicht berühren"]
    m2 -.-> rule
    m3 -.-> rule

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

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

flowchart TB
    accTitle: Die vier Bereiche, die die zwei Achsen von Ringen und VTL erzeugen
    accDescr: Die Ringachse trennt Kernelmodus und Benutzermodus, die VTL-Achse trennt gewöhnliche Welt und isolierte Welt, und die Kombination ergibt vier Bereiche: gewöhnliche Apps, NT-Kernel, IUM-Trustlets und 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 jetzt zwei Privilegsachsen, und „ist es der Kernel?“ und „ist es die isolierte Welt?“ sind getrennte Fragen geworden.

3.2. Die Substanz der Grenze ist SLAT

Teil 1 hat gesagt, dass die Übersetzungstabellen der zweiten Stufe, die Gast-Physikadressen (GPA) auf tatsächliches RAM (SPA) abbilden — SLAT —, der Hypervisor hält. VSM nutzt genau diese Eigenschaft. Die Isolierung der VTL wird mit dem Hyper-V-Hypervisor und SLAT gebaut.⁴

Wenn VTL1 erklärt „dieser Speicher soll VTL0 nicht gezeigt werden“, nimmt der Hypervisor die Zugriffserlaubnis auf diese Seite aus den Übersetzungstabellen für VTL0. Von da an wird, selbst wenn der Kernel in VTL0 diese Adresse berühren will, der Zugriff auf der Stufe der Adressübersetzung der CPU verweigert. Es nützt nichts, wie der Kernel seine eigenen Seitentabellen umschreibt.

Die Seitentabellen (GVA→GPA) mögen dem Kernel gehören, aber die Übersetzung darüber hinaus (GPA→SPA) und die endgültige Zugriffserlaubnis gehören dem Hypervisor.

flowchart TB
    accTitle: Wie ein Zugriff von VTL0 auf Speicher in VTL1 verweigert wird
    accDescr: Versucht der Kernel in VTL0, Speicher in VTL1 zu lesen, kommt er durch die eigenen Seitentabellen, wird aber vom SLAT-Zugriffsschutz abgewiesen, und die Steuerung geht an den Hypervisor
    try["Der Kernel in VTL0 versucht, eine Seite in VTL1 zu lesen"] --> pt["Passiert die eigenen Seitentabellen des Kernels"]
    pt --> slat{"Erlaubt der SLAT-Zugriffsschutz es?"}
    slat -->|Keine Erlaubnis| deny["Der Hypervisor greift ein und verweigert den Zugriff"]
    slat -->|Erlaubnis vorhanden| ok["Gewöhnlicher Speicherzugriff"]
    deny -.-> point["Auf einer Schicht geschützt, die der Kernel nicht ändern kann"]

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

Teil 1 der Speicherreihe hat geschrieben, dass „VAD, PTE und Schutzattribute darüber entscheiden, ob ein Zugriff erlaubt ist“. In einer VBS-Umgebung lässt sich das so ordnen: Nachdem all das bestanden ist, wartet noch eine SLAT-Kontrolle.

3.3. 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, isolierter Benutzermodus), und die Programme, die dort laufen, heißen Trustlets (vertrauenswürdige Prozesse).⁴

Ein Trustlet kann nicht alles tun, wie ein gewöhnlicher Prozess. Die meisten Systemaufrufe werden an den NT-Kernel auf der VTL0-Seite marshallt und dort zur Verarbeitung übergeben.⁴ VTL1 ist keine „obere Welt, die alles kann“, sondern bewusst klein gebaut als ein Tresor, der Geheimnisse hält. Je weniger Code in den Tresor gebracht werden kann, desto kleiner wird die Angriffsfläche.

flowchart TB
    accTitle: Der Ablauf der Systemaufrufe eines Trustlets
    accDescr: Ein Trustlet in VTL1 verarbeitet die meisten Systemaufrufe nicht selbst; es marshallt sie an den NT-Kernel in VTL0 und empfängt nur das Ergebnis, wodurch VTL1 klein bleibt
    tl["Trustlet (IUM in VTL1)"] --> sc{"Ein Systemaufruf ist nötig"}
    sc -->|In den meisten Fällen| mar["Anfrage an den NT-Kernel in VTL0"]
    mar --> res["Empfängt nur das Ergebnis"]
    res -.-> small["VTL1 bleibt klein und die Angriffsfläche schrumpft"]

Abbildung 6: Der Tresor hat keine eigenen Anlagen; er gibt die Routinearbeit nach draußen und bewacht weiter nur die Geheimnisse.

4. HVCI — Die Codeintegrität des Kernels im Tresor prüfen

Bei HVCI sind zwei Punkte festzuhalten: wo die Prüfung stattfindet und was nach der Prüfung am Speicher erlaubt ist. Diesen Schutz und die Auswirkung auf Treiberkompatibilität sehen wir der Reihe nach.

4.1. Was geprüft wird

Die erste repräsentative Funktion, die auf VBS sitzt, ist Speicherintegrität — HVCI (hypervisorgeschützte Codeintegrität). Windows hat einen Mechanismus der Codeintegrität, der Treiber und Binärdateien im Kernelmodus vor dem Start prüft und unsignierte oder nicht vertrauenswürdige nicht laden lässt. 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 aus Abschnitt 2. Sitzt der Prüfungscode im Kernel von VTL0, kann ein Angreifer, der den Kernel übernommen hat, die Prüfung austauschen. Sitzt er in VTL1, reicht die austauschende Hand nicht hin.

flowchart TB
    accTitle: Der Unterschied je nach Ort des Prüfungscodes
    accDescr: Sitzt der Prüfungscode im Kernel von VTL0, wird er nach Übernahme des Kernels unwirksam; sitzt er in VTL1, reicht auch ein Angreifer, der den Kernel übernommen hat, nicht hin, und die Prüfung bleibt geschützt
    atk["Angreifer, der den Kernel übernommen hat"] --> q{"Wo liegt die Codeintegritätsprüfung?"}
    q -->|"Im Kernel von VTL0 (herkömmlich)"| 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 funktioniert auch nach Kompromittierung des Kernels weiter"]

Abbildung 7: Den Kontrollpunkt nicht auf die Seite zu legen, die durchbrochen werden könnte — diese Umsiedlung der Prüfungslogik ist das Wesen von HVCI.

4.2. Die Regeln für ausführbare Seiten

Die Wirkung von HVCI bleibt nicht bei der „Prüfung beim Start“. Sie legt auch der Zuteilung von Kernelspeicher Einschränkungen auf.⁵

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

Stehen diese zwei zusammen, können Sie selbst dann, wenn eine Schwachstelle wie ein Pufferüberlauf Kernelspeicher umschreiben lässt, den umgeschriebenen Inhalt nicht zur Ausführung bringen. Ausführbare Seiten lassen sich nicht umschreiben, und Seiten, die sich umschreiben lassen, sind nicht ausführbar.⁵ Die endgültige Absicherung der Ausführungsberechtigung liegt beim Ausführungsrecht auf der SLAT-Seite; das kann der Kernel in VTL0 nicht manipulieren.

flowchart TB
    accTitle: Bis eine Kernelseite in einer HVCI-Umgebung ausführbar wird
    accDescr: Eine Anforderung zum Laden eines Treibers erhält die Codeintegritätsprüfung in der isolierten Umgebung von VBS; bei Bestehen wird sie als ausführbare, nicht schreibbare Seite erlaubt, bei Nichtbestehen wird sie blockiert und im CodeIntegrity-Protokoll festgehalten
    load["Anforderung, Kernelcode zu laden und auszuführen"] --> verify{"Codeintegritätsprüfung in der isolierten Umgebung"}
    verify -->|Bestanden| exec["Als ausführbare Seite erlaubt (Schreiben verboten)"]
    verify -->|Nicht bestanden| block["Laden blockiert"]
    block --> log["Im CodeIntegrity-Operational-Protokoll festgehalten (Ereignis-ID 3087)"]
    exec -.-> wx["Schreibbare Seiten bleiben nicht ausführbar"]

Abbildung 8: Die Regel, die Ausführen und Schreiben nie zusammenfallen lässt, wird auf der VTL1-Seite geprüft, und der Kernel in VTL0 kann sie nicht umstoßen.

Verfolgt man das aus der Sicht des Angreifers, wird klar, wie die Regel greift.

flowchart TB
    accTitle: Wie Codeeinschleusung in einer HVCI-Umgebung scheitert
    accDescr: Selbst wenn eine Schwachstelle Kernelspeicher umschreiben lässt, ist eine Seite, auf die geschrieben werden konnte, nicht ausführbar, und eine ausführbare Seite lässt sich von vornherein nicht umschreiben, sodass der eingeschleuste Code nicht zur Ausführung kommt
    inj["Versuch, über eine Schwachstelle Kernelspeicher zu manipulieren"] --> which{"Welche Seite ist das Ziel?"}
    which -->|Eine schreibbare Seite| wok["Das Umschreiben gelingt"]
    which -->|Eine ausführbare Seite| xfail["Das Umschreiben 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: Welchen Eingang Sie auch nehmen, Sie landen in einer Sackgasse; darin liegt der Sinn, schreibbare Seiten und ausführbare Seiten nicht zu überlappen.

4.3. Der Preis: Treiberkompatibilität

Diese Regel kollidiert mit Treibern älteren Entwurfs. Treiber, die den eigenen Code zur Laufzeit umschreiben, keine Signatur haben oder Speicher verlangen, der zugleich ausführbar und schreibbar ist, 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 prüfen (Ereignis-ID 3087 ist die repräsentative).⁶

In vielen Fällen ist das die wahre Identität der Störung „nach dem Aktivieren von Speicherintegrität funktioniert ein Peripheriegerät nicht mehr“. Der eigentliche Weg ist die Aktualisierung auf eine HVCI-taugliche Treiberversion; das Deaktivieren von Speicherintegrität sollte als letztes Mittel gelten, das den Schutz als Ganzes aufgibt.

Wenn Sie von der Treiberentwicklung aus an dieser Prüfung beteiligt sind, siehe auch den Artikel zu Filtertreibern („Windows-Minifiltertreiber“).

flowchart TB
    accTitle: Eingrenzung, wenn unter Speicherintegrität ein Peripheriegerät nicht mehr funktioniert
    accDescr: Identifizieren Sie den blockierten Treiber im CodeIntegrity-Operational-Protokoll; der eigentliche Weg ist die Aktualisierung auf eine HVCI-taugliche Version, sonst Anfrage beim Hersteller, und Deaktivieren ist ein letztes Mittel, das nie zur Dauereinstellung wird
    sym["Ein Gerät funktioniert nach Aktivieren von Speicherintegrität nicht mehr"] --> log2["Blockierten Treiber im CodeIntegrity-Protokoll identifizieren"]
    log2 --> upd{"Gibt es einen HVCI-tauglichen Treiber?"}
    upd -->|Ja| fix2["Aktualisieren und bei aktivierter Funktion lösen"]
    upd -->|Nein| ask2["Beim Hersteller eine taugliche Version anfragen"]
    ask2 -.-> temp["Deaktivieren ist ein letztes Mittel, nie eine Dauereinstellung"]

Abbildung 10: Als Erstes schauen Sie nicht auf den Einstellungsbildschirm, sondern ins Protokoll; welche Komponente blockiert wurde, weiß Ereignis-ID 3087.

5. Credential Guard — Die Hashes liegen in LSAIso

Wo HVCI die Codeintegrität des Kernels schützt, schützt Credential Guard Anmeldeinformationen. Denkt man die Anlaufstelle, die Authentifizierung entgegennimmt, und den Ort, an dem die Geheimnisse liegen, getrennt, fügen sich Struktur und Schutzumfang zusammen.

5.1. LSASS und LSAIso

Die zweite repräsentative Funktion, die auf VBS sitzt, ist die Antwort auf das Rätsel am Anfang: Credential Guard.

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

• lsass.exe (VTL0) läuft weiterhin als Anlaufstelle der Authentifizierung, wie bisher.
• Die eigentlichen Geheimnisse hält LSAIso.exe (VTL1); von VTL0 aus ist kein Zugriff möglich.
• Die beiden kommunizieren über RPC (Remote Procedure Call).
• LSAIso hostet keinerlei Gerätetreiber und nimmt nur die Mindestmenge signierter Binärdateien auf. Die Signaturen werden gegen ein Zertifikat geprüft, dem VBS vertraut.⁷

flowchart TB
    accTitle: Wo Anmeldeinformationen sitzen, wenn Credential Guard aktiv ist
    accDescr: lsass in VTL0 kommuniziert als Anlaufstelle der Authentifizierung per RPC mit LSAIso in VTL1; die eigentlichen Hashes und TGTs geschützter Domänenanmeldeinformationen hält LSAIso, sodass ein Angreifer, der in VTL0 Administratorrechte erlangt und lsass dumpt, die geschützten Geheimnisse selbst nicht erhält
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe (Anlaufstelle der Authentifizierung)"]
        att["Angreifer (Administratorrechte)"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe (Tresor der Geheimnisse)"]
    end
    lsassP <-->|RPC| iso
    att -->|Speicherdump| lsassP
    att -.->|Reicht nicht hin| iso

Abbildung 11: Weil Anlaufstelle und Tresor getrennt wurden, liefert ein Dump von lsass die eigentlichen Hashes der geschützten Domänenanmeldeinformationen nicht mehr.

Bedingungen für die Standardaktivierung

Ab Windows 11 Version 22H2 sind VBS und Credential Guard auf Geräten, die die Lizenzanforderungen (Enterprise E3/E5, Education A3/A5) und die Hardwareanforderungen erfüllen, standardmäßig aktiv. Auf Editionen wie Pro wird Credential Guard nicht automatisch aktiviert (es gibt Ausnahmen, etwa ein Rechner, der früher unter einer qualifizierenden Lizenz aktiv war und später herabgestuft wurde).¹

Dieser Schutz der Anmeldeinformationen ist keine Sache eines besonderen Zusatzprodukts; er ist der Standardzustand aktuellen Windows auf den qualifizierenden Editionen.

flowchart TB
    accTitle: Der Fluss der Anmeldeinformationen von der Anmeldung bis zur Authentifizierung
    accDescr: Nach der Anmeldung werden die eigentlichen Geheimnisse in LSAIso in VTL1 gespeichert; jedes Mal, wenn Authentifizierung nötig ist, fordert lsass in VTL0 die Berechnung per RPC an, und nach VTL0 kehrt nur das Ergebnis der Authentifizierung zurück, nie die geschützten Langzeitgeheimnisse selbst
    signin["Benutzer meldet sich an"] --> front["lsass behandelt es als Anlaufstelle"]
    front --> store["Die eigentlichen Geheimnisse werden in LSAIso gespeichert"]
    auth["Spätere Authentifizierungsanforderungen"] --> front
    front -->|Fordert die Berechnung per RPC an| store
    store -->|"Gibt das Ergebnis zurück (nie das Geheimnis)"| front

Abbildung 12: Die geschützten Langzeitgeheimnisse selbst verlassen den Tresor nicht; was nach VTL0 zurückkehrt, ist das Ergebnis der Authentifizierung, etwa ein Ticket.

5.2. Genau wissen, was nicht geschützt wird

Geschützte Anmeldeinformationen

Credential Guard ist kein Allzweckschild. Geschützt werden NTLM-Hashes von Domänenanmeldeinformationen, Kerberos-TGTs (Ticket Granting Tickets) und Dinge, die als Domänenanmeldeinformationen gespeichert wurden.

Außerhalb des Schutzes

Folgendes liegt außerhalb des Schutzes.⁸

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

Unabhängig vom Schutzumfang auch die Authentifizierungskompatibilität prüfen

Außerdem können bei aktivem Credential Guard NTLMv1, uneingeschränkte Kerberos-Delegierung und Ähnliches nicht mehr genutzt werden; Geschäftssysteme, die von Legacy-Authentifizierung abhängen, brauchen daher eine Kompatibilitätsprüfung.⁸ Es ist nicht „aktivieren und fertig“; den Bereich innerhalb und außerhalb des Schutzes kennen und den Rest mit anderen Maßnahmen füllen — das ist der richtige Einsatz in der Praxis.

flowchart TB
    accTitle: Der Schutzumfang von Credential Guard
    accDescr: NTLM-Hashes und TGTs der Domäne sowie gespeicherte Domänenanmeldeinformationen sind geschützt, während Diensttickets, lokale Konten, Keylogger, physische Angriffe und Anmeldeinformationen, die eine App selbst speichert, außerhalb des Schutzes liegen
    scope{"Auf welcher Seite des Schutzumfangs liegt dieses Geheimnis?"} --> inA["NTLM-Hashes und TGTs der Domäne"]
    scope --> outA["Diensttickets und lokale Konten"]
    inA --> prot["In LSAIso geschützt"]
    outA --> unprot["Nicht geschützt (andere Maßnahmen nötig)"]
    unprot -.-> outB["Tastatureingabe, physische Angriffe und app-eigene Speicher sind ebenfalls außerhalb"]

Abbildung 13: Der Schutzumfang ist klar gezogen; außerhalb der Linie füllt man mit Mehrfaktorauthentifizierung und app-seitigem Entwurf.

6. Mit eigenen Augen prüfen

Den Laufzustand von VBS und der einzelnen Funktionen können Sie am eigenen Rechner prüfen. Lesen Sie den Zustand von VBS, der Grundlage, getrennt vom Zustand der Dienste, die darauf laufen.

6.1. VBS und die laufenden Dienste in PowerShell prüfen

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

Die Ausgabe lesen Sie so.⁹

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

6.2. msinfo32 und den Einstellungsbildschirm unterschiedlich lesen

Um den Laufzustand in einer GUI zu prüfen, schauen Sie auf das Feld „Virtualisierungsbasierte Sicherheit“ in msinfo32 (dort werden laufende Dienste aufgeführt, etwa „Hypervisor erzwungene Codeintegrität“).

Der Schalter „Speicherintegrität“ unter „Gerätesicherheit > Kernisolierung“ in der App Windows-Sicherheit ist ein Bildschirm, der die Einstellung widerspiegelt. Er kann auch dann auf „ein“ stehen, während HVCI tatsächlich nicht läuft — etwa während auf einen Neustart direkt nach dem Aktivieren gewartet wird oder bei einem Kompatibilitätsproblem beim Start. Ob es läuft, beurteilen Sie daher anhand von msinfo32 oder von SecurityServicesRunning in Win32_DeviceGuard.⁶

6.3. Nicht allein aus dem Vorhandensein eines Prozesses auf „läuft“ schließen

Eine Spur gibt es auch auf der Registerkarte Details des Task-Managers. Auf einem Rechner, auf dem VBS läuft, sehen Sie einen Prozess namens „Secure System“ (Sicherer Systemprozess). LsaIso.exe ist der Prozess, der erscheint, wenn der isolierte LSA-Dienst in VTL1 gehostet wird; in einer Konfiguration, in der nur HVCI aktiv ist, erscheint er normalerweise nicht.

Das Vorhandensein oder Fehlen eines Prozesses ist jedoch nur eine Spur; ob Credential Guard läuft, beurteilen Sie anhand von SecurityServicesRunning (ob es 1 enthält), wie oben beschrieben. Beides sind Fenster, die von VTL0 aus auf die Welt auf der VTL1-Seite blicken.

flowchart TB
    accTitle: Das Verfahren zum Prüfen, dass VBS-bezogene Funktionen laufen
    accDescr: Bestätigen Sie durch Abfrage von Win32_DeviceGuard, dass VBS läuft, beurteilen Sie anhand der Werte von SecurityServicesRunning, ob Credential Guard und HVCI laufen, und schauen Sie bei Treiberproblemen ins CodeIntegrity-Protokoll
    q0["Win32_DeviceGuard abfragen"] --> q1{"Ist der VBS-Status 2?"}
    q1 -->|Nein| off["VBS läuft nicht (Anforderungen und Einstellungen prüfen)"]
    q1 -->|Ja| q2{"Was enthält SecurityServicesRunning?"}
    q2 -->|Enthält 1| cg["Credential Guard läuft"]
    q2 -->|Enthält 2| hvciR["Speicherintegrität (HVCI) läuft"]
    hvciR -.-> ev["Bei Treiberproblemen das CodeIntegrity-Protokoll (3087) prüfen"]

Abbildung 14: Die Zustandsprüfung geht in drei Stufen vor: VBS selbst, jeder Dienst darauf und das Protokoll, wenn ein Problem auftritt.

7. Drei Fehldeutungen, die Sie in der Praxis vermeiden sollten

7.1. „Administratorrechte zu schützen reicht. VBS ist ein Thema für Server“

Was Credential Guard verhindert, ist die Ausweitung des Schadens nachdem Administratorrechte genommen wurden (Herausschaffen von Hashes und laterale Bewegung). Mit anderen Worten: VBS ist eine Schicht der Verteidigung in der Tiefe, die Kompromittierung voraussetzt, und gerade auf Client-PCs wirkt sie. Unter Windows 11, das die Anforderungen erfüllt, ist Standardaktivierung die Norm; die richtige Haltung ist nicht „das betrifft uns nicht“, sondern „Kompatibilität unter der Annahme verwalten, dass es bereits läuft“.

flowchart TB
    accTitle: Die Stufen der Kompromittierung und wo VBS greift
    accDescr: Den Erstzugang decken andere Maßnahmen wie Mehrfaktorauthentifizierung und Schulung; HVCI blockiert die Codeeinschleusung in den Kernel nach der Rechteausweitung; Credential Guard blockiert den Diebstahl geschützter Domänengeheimnisse und laterale Bewegung, reicht aber nicht an Geheimnisse außerhalb seines Umfangs
    s1["Erstzugang (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"]
    s3 -.-> d2["HVCI blockiert diesen Schritt"]
    s4 -.-> d3["Credential Guard blockiert das (nur geschützte Geheimnisse)"]

Abbildung 15: VBS ist keine Technik „sie nicht hereinlassen“, sondern eine Technik „sie nach dem Eindringen nicht gewinnen lassen“, und die Stufe, die sie bewacht, ist eine andere.

7.2. „Wenn Speicherintegrität ein Problem macht, einfach ausschalten“

Ausschalten lässt Dinge vorerst laufen, entfernt aber die Barriere gegen Codeeinschleusung in den Kernel als Ganzes. Der eigentliche Weg ist, zuerst den blockierten Treiber im CodeIntegrity-Protokoll zu identifizieren und dann die aktualisierte Version des Herstellers anzuwenden. Auch wenn Sie es vorübergehend zur Prüfung deaktivieren, empfehlen wir eine Betriebsweise, die das nie zur Dauereinstellung macht.

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

Das ist Übermut aus Verwechslung des Schutzumfangs. Diensttickets, lokale Konten, Tastatureingaben selbst und Anmeldeinformationen, die eine App selbst speichert, liegen außerhalb.⁸ Gegen Phishing und Keylogger braucht es andere Maßnahmen (Mehrfaktorauthentifizierung, Windows Hello und eine Überprüfung, wie die App selbst Anmeldeinformationen verwaltet).

8. Zusammenfassung

• VBS nutzt den Hypervisor, um eine isolierte Umgebung zu schaffen, und schützt Sicherheitsfunktionen unter der Annahme, dass der Kernel kompromittiert wird.²
• Die Isolierungseinheit ist die VTL; derzeit sind zwei Stufen implementiert, VTL0 (die gewöhnliche Welt) und VTL1 (Secure Kernel und IUM).³
• Die Substanz der Grenze ist der SLAT-Speicherzugriffsschutz, den Software innerhalb der Partition — den Kernel eingeschlossen — 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 „ausführbare Seiten sind nicht schreibbar“.⁵ Der Preis ist, dass Treiberkompatibilität verwaltet werden muss.⁶
• Credential Guard isoliert NTLM-Hashes und TGTs von Domänenanmeldeinformationen 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 aktiv (nutzen Sie das zusammen mit einer Prüfung des Laufzustands).⁷¹
• Den Laufzustand können Sie anhand von SecurityServicesRunning in Win32_DeviceGuard prüfen (1 = Credential Guard, 2 = HVCI).⁹

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

Bis hierher haben wir Virtualisierung von der Seite der „Stärke der Isolierung“ betrachtet. Die letzte Folge betrachtet die Gegenseite, „Leichtigkeit“, und verfolgt, wo die leichten VMs, die das Gewicht einer vollen VM abgeworfen haben, Abstriche machen.

Weiterführende Artikel

• Die Tiefen der Windows-Virtualisierung (Teil 1) — Wo läuft Ihr Windows eigentlich? Hypervisor und Partitionen
• Die Tiefen des Windows-Speichers (Teil 1) — Der Moment, in dem eine virtuelle Adresse zu physischem RAM wird: Ein Seitenfehler von Anfang bis Ende
• Windows-Minifiltertreiber
• Windows-Fehlercodes — Win32, HRESULT und NTSTATUS

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt Kompatibilitätsuntersuchungen zwischen Windows-Anwendungen und Sicherheitsfunktionen, die Analyse treiberbedingter Störungen und 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 App Windows-Sicherheit ist der Name eines Bildschirms, der mehrere auf VBS aufbauende Schutzfunktionen zusammenfasst. Die bekannteste davon ist „Speicherintegrität“; sie bezeichnet HVCI (hypervisorgeschützte Codeintegrität). Den Laufzustand der einzelnen Dienste prüfen Sie nicht anhand der Bildschirmanzeige, sondern durch Abfrage von Win32_DeviceGuard.

Kann Speicher in VTL1 wirklich nicht gelesen werden, auch nicht mit Administratorrechten oder von einem Kerneltreiber?

Er kann nicht gelesen werden. Den Speicherzugriffsschutz je 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 Speicher in VTL1 zugreifen.

Warum kann das Aktivieren von Speicherintegrität (HVCI) dazu führen, dass ein Treiber nicht mehr funktioniert?

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 prüfen (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 Schutzes.

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.