Virtualisierte (Un-)Sicherheit: Wie Angreifer VBS-Enklaven instrumentalisieren können

Angreifer suchen immer nach neuen Wegen, Malware auf einem Host bereitzustellen und auszuführen, ohne entdeckt zu werden. Wir haben einige innovative Techniken zur Ausführung von Malware in einer virtualisierungsbasierten Sicherheitsenklave (VBS) erforscht und gängige Sicherheitsvorkehrungen umgangen. Auf 8. August 2025 habe ich diese Angriffsfläche in einer Präsentation auf der DEF CON 33 in Las Vegas behandelt.

VBS ist Teil der Sicherheitsimplementierung von Microsoft und erstellt eine virtuelle Umgebung zur Isolierung kritischer Betriebssystemkomponenten. VBS-Enklaven ermöglichen die Isolierung eines Prozessbereichs, sodass dieser für andere Prozesse, den Prozess selbst und sogar den Kernel unzugänglich ist. 

VBS-Enklaven können zwar die Sicherheit verbessern, bieten aber auch verlockende Möglichkeiten für Angreifer. Das liegt daran, dass Malware, die in einer Enklave ausgeführt wird, für die häufig verwendete speicherbasierte Erkennung und Forensik möglicherweise unsichtbar ist. Wir haben diese Idee untersucht und eine Reihe von Möglichkeiten gefunden, wie VBS-Enklaven potenziell missbraucht werden könnten.

Es ist wichtig, das Konzept der virtuellen Vertrauensebenen (Virtual Trust Levels, VTLs) zu verstehen, das VBS-Enklaven zugrunde liegt. Jede Vertrauensebene bietet den unter ihr ausgeführten Elementen unterschiedliche Zugriffsberechtigungen für den physischen Speicher. Niedrigere VTLs können nicht auf den Speicher höherer VTLs zugreifen. 

Windows verwendet derzeit zwei Hauptvertrauensebenen:  VTL0 wird verwendet, um die herkömmlichen Betriebssystemkomponenten auszuführen, einschließlich der normalen Kernel- und Nutzerausführungsmodi. VTL1, das über mehr Berechtigungen als VTL0 verfügt, erstellt zwei neue Ausführungsmodi: den sicheren Kernel-Modus und den isolierten Nutzermodus.

• Der sichere Kernel-Modus wird zur Ausführung des sicheren Kernels verwendet, der in VTL1 ausgeführt wird und daher mehr Berechtigungen als der normale Kernel hat. Der sichere Kernel kann Richtlinien auf dem normalen Kernel erzwingen und dessen Zugriff auf sensible Speicherbereiche einschränken. Da der sichere Kernel sehr schlank ist und keine Treiber von Drittanbietern unterstützt, stellt er eine deutlich geringere Angriffsfläche dar.
• Der isolierte Nutzermodus wird zur Ausführung sicherer Prozesse verwendet – ein spezieller Nutzermodusprozess, der die Speicherisolierungsfunktionen von VTL1 nutzt. Auf den Speicher im isolierten Nutzermodus kann mit keinem VTL0-Code zugegriffen werden. Dies schließt den normalen Kernel ein.

Zusammengenommen ergeben VTL0 und VTL1 vier Ausführungsmodi: 

• Ring 0 VTL0 – normaler Kernelmodus
• Ring 0 VTL1 – sicherer Kernel-Modus
• Ring 3 VTL0 – normaler Nutzermodus
• Ring 3 VTL1 – isolierter Nutzermodus

VBS-Enklaven erzeugen einen Bereich eines Nutzermodusprozesses im isolierten Nutzermodus, in den wir DLLs laden können, die als „Enklavenmodule“ bezeichnet werden. Diese werden zu einer „vertrauenswürdigen Ausführungsumgebung“ mit Daten und Code, die für alle in VTL0 ausgeführten Elemente nicht zugänglich sind. Dies ermöglicht die Isolierung sensibler Vorgänge gegenüber Angreifern, die das System kompromittieren könnten.

Da der Zugriff auf VTL1 eingeschränkt ist, muss eine DLL, die in eine Enklave geladen wird, mit einem speziellen, von Microsoft ausgestellten Zertifikat ordnungsgemäß signiert werden. Jeder Versuch, ein Modul ohne eine solche Signatur zu laden, schlägt fehl. Obwohl nur vertrauenswürdige Dritte Enklavenmodule signieren können, gibt es keine Einschränkungen dahingehend, wer diese Module laden kann. Solange sie signiert sind, kann jeder Prozess beliebige Module in eine Enklave laden.

VBS-Enklaven sind aus verschiedenen Gründen für Angreifer attraktiv. Erstens ist der Adressbereich von Enklaven für alles, was in VTL0 ausgeführt wird, nicht zugänglich – einschließlich EDR-Tools (Endpoint Detection and Response) und Analyse-Tools. Zweitens können API-Aufrufe aus einer Enklave heraus für EDRs unsichtbar sein.

In Anbetracht dessen haben wir untersucht, wie Angreifer Schadcode in einer Enklave ausführen können. Darüber hinaus haben wir untersucht, welche Techniken sie einsetzen könnten, sobald ihre Malware aktiv war. In diesem Blogbeitrag werden wir unsere Entdeckung vorstellen.

Ein VBS-Enklavenmodul kann so konfiguriert werden, dass es debugfähig ist. Enklavenmodule werden in VTL1 ausgeführt. Daher ist deren Debugging normalerweise nicht möglich, denn der Debugger kann nicht auf den Speicher der Enklave zugreifen, um Daten abzurufen oder Breakpoints zu setzen. Wir haben aber festgestellt, dass ein debugfähiges Enklavenmodul bei Ausführung weiterhin in VTL1 geladen wird. 

Um das Debuggen zu ermöglichen, implementiert der sichere Kernel einige Ausnahmen, die auf debugfähige Enklavenmodule angewendet werden. Die Speicherberechtigungen in einem debugfähigen Enklavenmodul können auch durch den VTL0-Prozess geändert werden. Die vom Modul verarbeiteten Daten können leicht zugänglich gemacht werden.

Dies untergräbt effektiv den Hauptzweck von VBS-Enklaven, nämlich einen Speicherabschnitt von VTL0 zu isolieren. Aus diesem Grund rät Microsoft den Entwicklern dringend, keine debugfähigen Enklavenmodule zu auszuliefern.

Wenn ein Angreifer Zugriff auf ein beliebiges debugfähiges signiertes Enklavenmodul erhält, kann er die Ausführung von VTL1-Code erreichen, indem er einige von mir auf der DEF CON beschriebene Schritte durchführt. Dies bringt für den Angreifer ein Risiko mit sich. Genauso wie der Angreifer auf den Enklavenspeicher zugreifen kann, ist dies auch für ein EDR möglich. Der Angriff kann jedoch die API-Überwachung umgehen, was die Transparenz einer EDR-Lösung einschränken kann.

Diese Methode kann nützlich sein, um ein unauffälliges „Semi-VTL1“-Implantat zu entwickeln, das einige der Vorteile nutzt, die sich durch die Ausführung innerhalb einer Enklave ergeben.

Wir haben untersucht, ob ein Angreifer eine Version der BYOVD-Technik (Bring Your Own Vulnerable Driver) verwenden könnte, um Malware in einer VBS-Enklave auszuführen. Dabei wird ein signiertes Enklavenmodul mit einer Schwachstelle gefunden.

Dies führte uns zu CVE-2023-36880, einem VBS-Enklavenmodul, das von Microsoft Edge genutzt wird. Diese Schwachstelle wurde von Alex Gough vom Chrome Platform Security Team entdeckt und ermöglicht es einem Angreifer, beliebige Daten in der Enklave zu lesen und zu schreiben. 

Wir haben versucht, das Lese-/Schreib-Primitiv zu auszunutzen, um den Enklave-Stack mit einer ROP-Kette (Return Oriented Programming) zu überschreiben, was uns letztendlich die Ausführung von Shellcode innerhalb der Enklave ermöglichte. Wir fanden jedoch heraus, dass Enklaven vor der Ausführung von nicht signiertem Code durch Arbitrary Code Guard (ACG) geschützt sind. ACG blockiert die Ausführung von Code, der zur Laufzeit erstellt wird (Abbildung). 

Wir haben (noch) keine Methode gefunden, um ACG innerhalb einer Enklave zu umgehen und unsignierten Code in diese zu laden – theoretisch ist jedoch ein Full-ROP-Exploit möglich.

Wir haben eine Technik zur Umgehung von Speicherscans erprobt, die wir „Mirage“ getauft haben. Sie ist inspiriert von Gargoyle, einer Umgehungsmethode, bei der eine Payload erzeugt wird, die ständig zwischen einem harmlosen und einem „bewaffneten“ Zustand wechselt. 

Mirage erreicht dies durch einen Wechsel zwischen VTL1- und VTL0-Speicher. Mirage speichert Shellcode im VTL1-Enklavenspeicher, überträgt ihn regelmäßig über die Sicherheitslücke zurück an VTL0, führt den Shellcode aus und löscht ihn dann umgehend aus dem VTL0-Speicher.

Die Nutzlast ist resistent gegen Speicherscans und -auszüge, da sie die meiste Zeit in VTL1 verborgen ist. Während der Ruhephase ist die Payload nicht nur „getarnt“, sondern auch unzugänglich. Außerdem erfolgt das Schreiben des Shellcodes in VTL0 durch die Enklave außerhalb der Reichweite von EDR-Tools, was eine Erkennung durch Überwachungsfunktionen schwierig macht.

Eine weitere interessante Anwendung für Enklaven-Malware ist das Anti-Debugging. Innerhalb der Enklave ausgeführter Code bleibt für VTL0-Anwendungen, einschließlich Debuggern, unzugänglich und verschafft der Malware so einen erheblichen Vorteil.

Wir haben eine Reihe von Ansätzen untersucht. Da die Enklave auf den VTL0-Prozessadressbereich zugreifen kann, ist es ihr möglich, den PEB (Process Environment Block) manuell zu lesen und den Wert des Flags BeingDebugged zu überprüfen. Wird ein Debugger erkannt, kann der Prozess von der Enklave beendet werden.

Wir haben uns auch eine zeitbasierte Anti-Debugging-Technik angesehen, die Prozessortaktzyklen verwendet, um die Zeit zwischen verschiedenen Enklavenaufrufen zu messen und den Prozess zu beenden, wenn eine erhebliche Verzögerung erkannt wird.

Indem wir zusätzlich zu einer Anti-Debugging-Prüfung kritische Teile unseres Codes in eine Enklave verschieben, sind wir in der Lage, eine Malware zu erstellen, die sehr widerstandsfähig gegenüber dynamischen Analysen ist. Richtig implementiert könnte dieser Ansatz nur durch das Debuggen von Hyper-V oder des sicheren Kernels umgangen werden.

Derzeit werden Enklaven nur von einer begrenzten Anzahl von Anwendungen genutzt. Deshalb kann die anormale Nutzung bzw. Ausnutzung von Enklaven eine großartige Erkennungschance darstellen. Um diese Chance zu nutzen, können sich Abwehrspezialisten auf Folgendes konzentrieren:

• Erstellen einer Baseline-Liste bekannter, legitimer Verwendungen von VBS-Enklaven und Kennzeichnung von Abweichungen
• Überwachung von Enklaven-APIs auf Anomalien
• Überwachung des Ladens von Enklave-DLLs, das auf einen neuen Prozess hinweisen kann
• Nutzen anderer Sicherheitstechniken, die zur Isolierung kritischer Systeme und Anwendungen entwickelt wurden, wie z. B. Mikrosegmentierung

VBS-Enklaven bieten ein effektives Tool für den Schutz sensibler Bereiche von Anwendungen. Sie können aber auch von Bedrohungsakteuren zum „Schutz“ ihrer Malware verwendet werden. Wie ich in meiner DEF CON-Präsentation erläutert habe, sind die Strategien für Enklavenangriffe derzeit weitgehend theoretischer Natur. Wir können jedoch davon ausgehen, dass versierte Cyberkriminelle eigene Untersuchungen durchführen, um Schwachstellen zu finden, die es ihnen ermöglichen, VBS-Enklaven für bösartige Zwecke zu nutzen. 

Wenn Sie die Nutzung von Enklaven in Ihrer Umgebung unter Kontrolle behalten wollen, sollten Sie als Erstes einen Vorsprung gegenüber der sich entwickelnden Bedrohung verschaffen.

Lesen Sie meinen vorherigen Blogbeitrag Ausnutzung von VBS-Enklaven zur Erstellung evasiver Malware, um eine umfassende technische Erklärung zu erhalten.