Virtualization-Based Security
Windows-Sicherheitsarchitektur, die den Hypervisor nutzt, um einen isolierten Speicherbereich (Virtual Trust Level 1) zu schaffen, der sicherheitskritische Prozesse selbst vor Kernel-Angriffen schützt.
Virtualization-Based Security (VBS) ist eine Sicherheitsarchitektur in Windows, die den Hypervisor verwendet, um einen vom regulären Betriebssystem vollständig isolierten Speicherbereich einzurichten. In diesem geschützten Bereich laufen sicherheitskritische Prozesse — etwa die Verwaltung von Zugangsdaten oder die Überprüfung der Code-Integrität —, die selbst dann nicht kompromittiert werden können, wenn ein Angreifer Kernel-Rechte im normalen Betriebssystem erlangt hat. VBS bildet damit die technische Grundlage für mehrere zentrale Windows-Sicherheitsfunktionen, darunter Credential Guard und HVCI (Hypervisor-Protected Code Integrity).
Virtual Trust Levels: VTL0 und VTL1
Das Kernkonzept von VBS sind zwei durch den Hypervisor getrennte Ausführungsumgebungen, sogenannte Virtual Trust Levels (VTLs). VTL0 ist das normale Betriebssystem mit Kernel, Treibern und Anwendungen. VTL1 ist der Secure Kernel — ein minimaler, vom Hypervisor geschützter Bereich, der eigene Prozesse und eigenen Speicher besitzt. Der Hypervisor stellt sicher, dass Code in VTL0 — einschließlich des Windows-Kernels — keinen Zugriff auf den Speicher von VTL1 hat. Diese Trennung erfolgt auf Hardwareebene über die Virtualisierungserweiterungen der CPU und ist daher nicht durch Software allein umgehbar.
Was VBS konkret schützt
VBS ermöglicht mehrere Sicherheitsdienste, die ohne Hypervisor-Isolierung nicht realisierbar wären. Credential Guard lagert NTLM-Hashes und Kerberos-Tickets in VTL1 aus, sodass Credential-Dumping-Tools wie Mimikatz diese nicht mehr aus dem LSASS-Speicher extrahieren können. HVCI (auch als Memory Integrity bezeichnet) überprüft in VTL1, ob Kernel-Mode-Treiber korrekt signiert sind, bevor sie geladen werden — das unterbindet BYOVD-Angriffe (Bring Your Own Vulnerable Driver). Kernel Data Protection verhindert, dass sicherheitsrelevante Kernel-Datenstrukturen zur Laufzeit manipuliert werden.
Hardwareanforderungen
VBS setzt CPU-Virtualisierungsunterstützung voraus (Intel VT-x oder AMD-V), die im UEFI/BIOS aktiviert sein muss. Darüber hinaus werden UEFI Secure Boot und SLAT (Second Level Address Translation, bei Intel als EPT, bei AMD als RVI bekannt) benötigt. Ein TPM 2.0 wird von Microsoft empfohlen und ist für den vollen Funktionsumfang — insbesondere gemessenen Start (Measured Boot) und Schlüsselschutz — erforderlich. Aktuelle Business-Hardware ab Baujahr 2018 erfüllt diese Voraussetzungen in der Regel vollständig. Ob die Hardware VBS unterstützt, lässt sich vorab über msinfo32 oder die PowerShell-Cmdlets Get-CimInstance -ClassName Win32_DeviceGuard prüfen.
Die Abhängigkeit von Hardware-Virtualisierung bedeutet auch, dass VBS in verschachtelten Virtualisierungsumgebungen — etwa bei VMs auf einem Hypervisor ohne Nested Virtualization — nicht verfügbar ist. In solchen Fällen bleiben Credential Guard und HVCI inaktiv, was bei der Planung virtualisierter Arbeitsplätze berücksichtigt werden muss.
Aktivierung und Standardverhalten
Seit Windows 11 ist VBS auf kompatibler Hardware standardmäßig aktiviert. Windows Server 2025 aktiviert VBS und HVCI ebenfalls automatisch bei Neuinstallationen auf unterstützter Hardware. Bei Windows 10 und älteren Server-Versionen muss VBS manuell über Gruppenrichtlinien, Registry oder Microsoft Intune konfiguriert werden. Der aktuelle Status lässt sich über msinfo32 unter dem Eintrag „Virtualisierungsbasierte Sicherheit" prüfen — dort zeigt Windows an, ob VBS aktiv ist und welche Dienste (Credential Guard, HVCI) im geschützten Modus laufen.
Leistungsauswirkungen
Der Betrieb des Hypervisors und die Speicherisolierung verursachen einen messbaren, aber in den meisten Geschäftsszenarien akzeptablen Performance-Overhead. Microsoft beziffert die Auswirkungen auf typische Büroanwendungen mit niedrigen einstelligen Prozentwerten. In Szenarien mit intensiver I/O-Last oder verschachtelter Virtualisierung kann der Overhead höher ausfallen.
Für die meisten Büro- und Geschäftsanwendungen ist der Unterschied im Alltag nicht spürbar. Vereinzelt berichten Unternehmen von Kompatibilitätsproblemen mit älteren Treibern, die nicht korrekt signiert sind und durch HVCI blockiert werden — diese Fälle lassen sich durch ein aktualisiertes Treiberinventar im Vorfeld identifizieren. Bei der Einführung empfiehlt sich ein Test auf repräsentativen Geräten, bevor VBS flächendeckend per GPO ausgerollt wird.
Relevanz für KMUs
VBS ist keine optionale Zusatzfunktion, sondern die Grundlage, auf der die wirksamsten Windows-Härtungsmaßnahmen aufbauen. Ohne aktiviertes VBS bleiben Credential Guard und HVCI inaktiv — und damit zwei der effektivsten Verteidigungslinien gegen Credential-Diebstahl und Kernel-Exploits. Auf modernen Windows-11-Geräten ist VBS bereits aktiv; in gemischten Umgebungen mit Windows 10 oder älteren Servern fehlt die Funktion jedoch häufig, weil sie dort nicht automatisch eingeschaltet wird. Eine systematische Prüfung über msinfo32 oder zentrale Inventarisierung zeigt schnell, wo Handlungsbedarf besteht. In Kombination mit LSASS-Schutz per RunAsPPL und einem durchdachten Active-Directory-Tiering bildet VBS das Fundament einer Defense-in-Depth-Strategie, die den häufigsten Angriffspfaden im Mittelstand die Grundlage entzieht.