Ausnutzung von VBS-Enklaven zur Erstellung evasiver Malware

Virtualisierungsbasierte Sicherheit (VBS) ist eine der faszinierendsten Sicherheitsentwicklungen der letzten Zeit. Die Möglichkeit, kritische Komponenten des Betriebssystems zu isolieren, hat es Microsoft ermöglicht, mit Funktionen wie Credential Guard und Hypervisor-Protected Code Integrity (HVCI) erhebliche Sicherheitsverbesserungen zu erzielen.

Eine häufig übersehene Funktion, die von VBS ermöglicht wird, sind die VBS-Enklaven . Dies ist eine Technologie, die die Isolierung eines Bereichs eines Prozesses ermöglicht, sodass dieser für andere Prozesse, den Prozess selbst und sogar den Kernel unzugänglich ist. 

VBS-Enklaven können für eine breite Palette von Sicherheitsszenarien verwendet werden. So werden sie von Microsoft genutzt, um mehrere wichtige Dienste zu implementieren, darunter die umstrittene Recall-Funktion. Darüber hinaus unterstützt Microsoft die Entwicklung von VBS-Enklaven durch Dritte und fördert aktiv deren Einführung.

Enklaven können zwar zum Schutz von Systemen beitragen, aber auch für Angreifer sehr attraktiv sein, denn eine Malware, der es gelingt, innerhalb einer Enklave ausgeführt zu werden, ist für die speicherbasierte Erkennung und Forensik möglicherweise unsichtbar.

Wir wollten uns VBS-Enklaven näher ansehen und verstehen, wie sie für böswillige Zwecke ausgenutzt werden können. In diesem Blogbeitrag werden unsere wichtigsten Erkenntnisse dazu erläutert. Wir untersuchen VBS-Enklaven, indem wir uns mit bisher nicht dokumentierten Verhaltensweisen befassen, die verschiedenen Szenarien beschreiben, in denen Angreifer Schadcode ausführen können, und uns die verschiedenen Methoden ansehen, die „Enklaven-Malware“ anwenden kann.

Wir stellen auch Miragevor, eine Speicherumgehungstechnik, die auf einem neuen Ansatz beruht, den wir „Bring Your Own Vulnerable Enclave“ (BYOVE) getauft haben. Wir werden untersuchen, wie Angreifer alte, anfällige Versionen legitimer Enklaven nutzen können, um diese Technik der heimlichen Umgehung zu implementieren.

Bisher verließ sich Windows auf die Prozessor-Ring-Ebenen, um zu verhindern, dass Nutzeranwendungen das Betriebssystem manipulieren. Diese Hardwarefunktion ermöglicht eine Trennung des Betriebssystems von Nutzeranwendungen, bei der der Kernel isoliert von den Ring‑3-Nutzermodusanwendungen in Ring 0 ausgeführt wird. Das Problem bei diesem Ansatz ist, dass Angreifer hier einen relativ einfachen Weg haben, das Betriebssystem zu kompromittieren, nämlich über Kernel-Exploits.

Der Windows-Kernel bietet eine sehr große Angriffsfläche. Eine riesige Liste von Treibern von Drittanbietern sowie eine Vielzahl von Diensten, die vom Kernel selbst bereitgestellt werden, führt zur Entwicklung eines scheinbar konstanten Stroms von Kernel-Exploits. Und mit einem solchen Exploit kann ein Angreifer potenziell jeden Aspekt des Betriebssystems kontrollieren. Die Grenze des Nutzer/Kernel-Modus erwies sich als unzureichend.

Um diese Lücke zu schließen, hat Microsoft eine zusätzliche Sicherheitsgrenze in Form von virtuellen Vertrauensebenen (Virtual Trust Levels, VTLs) in das Betriebssystem eingeführt. VTL-Berechtigungen basieren auf Speicherzugriff, das heißt, jede Vertrauensebene bietet den unter ihr ausgeführten Elementen unterschiedliche Zugriffsberechtigungen für den physischen Speicher. Diese Berechtigungen stellen unter anderem sicher, dass niedrigere VTLs nicht auf den Speicher höherer VTLs zugreifen können.

Ähnlich wie bei der herkömmlichen Prozessor-Ring-Architektur trennen VTLs das Betriebssystem in verschiedene „Modi“ der Ausführung – beginnend mit VTL0 und endend bei (potenziell) VTL16. Im Gegensatz zu Prozessor-Ringen, bei denen Ring 0 die privilegierteste Ebene ist, haben höhere VTLs mehr Rechte als niedrigere.

Windows verwendet derzeit zwei Hauptvertrauensebenen: VTL0 und VTL1 (VTL2 wird ebenfalls verwendet, ist aber nicht Gegenstand dieses Blogbeitrags). VTL0 wird verwendet, um die herkömmlichen Betriebssystemkomponenten auszuführen, einschließlich der Kernel- und Nutzermodusanwendungen. VTL1, das mehr Rechte als VTL0 hat, erstellt zwei neue Ausführungsmodi: sicherer Kernel-Modus und isolierter Nutzermodus.

Der sichere Kernel-Modus bezieht sich auf den VTL1-Ausführungsmodus „Ring 0“. Dieser Modus wird zur Ausführung des sicheren Kernels verwendet. Dies ist ein Kernel, der in VTL1 ausgeführt wird und daher mehr Berechtigungen als der normale Kernel hat. Mit diesen Berechtigungen kann der sichere Kernel Richtlinien auf dem normalen Kernel erzwingen und dessen Zugriff auf sensible Speicherbereiche einschränken.

Wie bereits erwähnt, stellt der Kernel eine große Angriffsfläche dar und ist anfällig für Kompromittierungen. Durch Entfernen einiger Berechtigungen aus dem Kernel und Übertragen dieser Rechte an den sicheren Kernel können wir die Auswirkungen einer Kernel-Kompromittierung verringern.

Theoretisch kann eine Kompromittierung des sicheren Kernels es einem Angreifer dennoch ermöglichen, das System vollständig zu kompromittieren. Dennoch ist dieses Szenario viel weniger wahrscheinlich, da der sichere Kernel sehr schlank ist und keine Treiber von Drittanbietern unterstützt, was eine deutlich geringere Angriffsfläche bedeutet.

Da Microsoft den Zugriff auf VTL1 so weit wie möglich einschränken möchte, 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. Die Option zum Signieren von Enklavenmodulen wird nur an vertrauenswürdige Dritte delegiert. Interessanterweise gibt es keine Einschränkungen dahingehend, wer diese Module laden kann. Solange sie signiert sind, kann jeder Prozess beliebige Module in eine Enklave laden.

Enklavenmodule dienen als kleine „Recheneinheiten“, die nur sehr begrenzt mit dem System interagieren oder es beeinflussen können. Aus diesem Grund sind sie auf die Verwendung eines minimalen Satzes von APIsbeschränkt, was sie am Zugriff auf die meisten Betriebssystemkomponenten hindert.

APIs, die in Enklaven verfügbar sind, werden aus dedizierten Bibliotheken importiert, die in VTL1 geladen werden. Zum Beispiel nutzen normale Prozesse die Bibliothek ntdll.dll zur Anforderung von Services vom Betriebssystem, und Enklavenmodule verwenden vertdll.dll – eine „Ersatz“-ntdll, die für die Kommunikation mit dem sicheren Kernel über Syscalls verwendet wird.

Das Konzept der Enklaven-Malware kann für Angreifer durchaus attraktiv sein, da es zwei bedeutende Vorteile bietet:

1. Ausführung in einem isolierten Speicherbereich: Der Adressbereich von Enklaven ist für alles, was in VTL0 ausgeführt wird, nicht zugänglich, einschließlich EDRs und Analysetools, was die Erkennung wesentlich komplexer macht.

2. Nicht rückverfolgbare API-Aufrufe: API-Aufrufe innerhalb einer Enklave können für EDRs unsichtbar sein. EDRs überwachen APIs im Nutzermodus, indem sie Hooks in Systembibliotheken platzieren, und sie setzen Treiber ein, um Aktivitäten im Kernel zu überwachen. API-Aufrufe, die von einer Enklave ausgelöst werden, können mit diesen Methoden nicht erkannt werden, da Enklavenaufrufe von VTL1 aus erfolgen und keine dieser „gehookten“ VTL0-Komponenten durchlaufen.

Abbildung 4 veranschaulicht diesen Vorteil: Ein normaler Prozess, der eine Windows-API aufruft, kann über einen Hook innerhalb von NTDLL oder im Kernel selbst überwacht werden. Ein Enklavenmodul durchläuft jedoch die in VTL1 befindliche vertdll und tätigt Aufrufe zum sicheren Kernel – beides für EDRs nicht zugänglich.

In Anbetracht dieses Potenzials wollten wir uns das Konzept der Enklaven-Malware näher anschauen. Um Enklaven für diesen Zweck zu nutzen, müssen zwei Fragen geklärt werden:

1. Wie können Angreifer schädlichen Code innerhalb einer Enklave ausführen?
2. Welche Techniken können Angreifer anwenden, wenn sie einmal in eine Enklave eingedrungen sind?

Wie bereits erwähnt, müssen Enklavenmodule mit einem von Microsoft ausgestellten Zertifikat signiert werden, damit sie geladen werden können, das heißt, dass nur von ihnen genehmigte Elemente ihren eigenen Code innerhalb einer Enklave ausführen können. Dennoch bleiben den Angreifern noch einige Möglichkeiten.

Erstens kann sich ein Angreifer eine Schwachstelle des Betriebssystems zunutze machen. Ein Beispiel hierfür ist die Schwachstelle CVE-2024-49706, die von Alex Ionescu (arbeitet für Winsider Seminars & Solutions) entdeckt wurde und die es einem Angreifer ermöglichen könnte, ein nicht signiertes Modul in eine Enklave zu laden. Für die Schwachstelle wurde von Microsoft zwar ein Patch bereitgestellt, entsprechend motivierte Angreifer könnten in Zukunft aber ähnliche Bugs aufspüren.

Ein zweiter unkomplizierter Ansatz wäre die Beschaffung einer legitimen Signatur. Dies könnte möglich sein, da Microsoft Enklavensignaturen über die Plattform Vertrauensvolle Signatur für Dritte zugänglich macht. Auch wenn dieses Konzept sicher alles andere als trivial ist, könnte ein fortgeschrittener Angreifer in der Lage sein, sich Zugang zu einem Element der vertrauensvollen Signatur zu verschaffen und seine eigenen Enklaven zu signieren.

Zusätzlich zu diesen beiden Optionen haben wir zwei weitere Techniken untersucht, die es Angreifern ermöglichen könnten, Code innerhalb einer VBS-Enklave auszuführen und so debugfähige Enklaven und anfällige Enklaven auszunutzen.

Das offensichtliche Problem aus Angreifersicht ist, dass es sich hierbei um ein zweischneidiges Schwert handelt: Genauso wie der Angreifer auf den Enklavenspeicher zugreifen kann, kann dies auch ein EDR tun. Und dennoch bietet es den Vorteil der Umgehung der API-Überwachung: API-Aufrufe, die vom Enklavenmodul ausgeführt werden, durchlaufen weiterhin VTL1-DLLs und den sicheren Kernel, was die Sichtbarkeit von EDRs begrenzt.

Insgesamt könnte diese Methode 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 versucht, VirusTotal und andere Quellen zu verwenden, um ein debugfähiges signiertes Enklavenmodul zu identifizieren, zum Zeitpunkt der Erstellung dieses Textes waren wir damit allerdings bislang erfolglos. Wir sind jedoch davon überzeugt, dass mit genügend Zeit und einer breiteren Akzeptanz der Enklaventechnologie einige Lecks entstehen werden.

Wir haben keine Methode gefunden, um ACG innerhalb einer Enklave zu umgehen und nicht signierten Code in diese Enklave zu laden. Theoretisch ist ein Full-ROP-Exploit möglich, der Angreifer in die Lage versetzt, z. B. in VTL1 beliebige APIs aufzurufen. Wir haben diese Richtung aber nicht weiter verfolgt. Dennoch konnten wir eine weitere interessante Anwendung für anfällige Enklaven finden, die wir später in diesem Beitragerörtern werden.

Da wir wissen, dass Enklaven ein großes Potenzial für bösartige Aktivitäten bergen und dass ein motivierter Angreifer diese durchaus starten kann, haben wir uns als Nächstes gefragt, welche Techniken für diese Art von Malware zur Verfügung stehen könnten.

Am einfachsten wäre es, Enklaven entsprechend ihrem Zweck zu verwenden. So wie eine Enklave sensible Daten vor Angreifern schützen kann, kann sie auch von Angreifern verwendet werden, um ihre eigenen „Geheimnisse“ vor VTL0-Elementen zu verbergen.

Dies könnte in vielerlei Szenarien nützlich sein – durch Speichern von Nutzlasten außerhalb der Reichweite von EDRs, durch Versiegeln von Verschlüsselungsschlüsseln, die vor Analysten verborgen bleiben, oder durch Verhindern, dass sensible Malware-Konfigurationen in Speicherauszügen gespeichert werden.

Was fortschrittlichere Optionen anbelangt, so sind viele herkömmliche Malware-Techniken innerhalb einer Enklave unmöglich zu implementieren. Da Enklaven auf eine begrenzte Untergruppe von System-APIs beschränkt sind, können sie nicht mit wichtigen Betriebssystemkomponenten wie Dateien, der Registrierung, dem Netzwerk, anderen Prozessen usw. interagieren.

Dennoch gibt es noch eine Reihe von Techniken, die innerhalb einer Enklave ausgeführt werden können und es uns ermöglichen, von den Vorteilen zu profitieren, die sich aus der Ausführung im IUM ergeben.

Durch den Zugriff auf den VTL0-Nutzermodusspeicher können wir verschiedene nützliche Techniken implementieren. Indem wir eine schädliche Enklave in einen Zielprozess laden, können wir heimlich sensible Informationen überwachen und stehlen oder Werte innerhalb des Prozesses patchen, um sein Verhalten zu ändern.

Die Implementierung dieser Techniken unter Verwendung einer Enklave hat einen erheblichen Vorteil: Wie bereits beschrieben können wir durch das Auslösen von APIs aus einer Enklave die Überwachung durch EDRs umgehen. Da der Speicherzugriff bei diesen Techniken von einer Enklave durchgeführt wird, können sie unsichtbar bleiben.

Indem sie den Prozess im Nutzermodus dazu bringen, „in ihrem Auftrag zu handeln“, können Enklaven indirekt auf das System in einer Weise zugreifen, wie es ihnen normalerweise nicht möglich ist. Eine Enklave kann z. B. eine VTL0-Routine auslösen, die aus einer Datei liest, einen Socket erstellt usw.

Es sei darauf hingewiesen, dass das Ausführen von Nutzermoduscode auf diese Weise keinen Vorteil in Bezug auf die Umgehung hat. Da der Code wie jeder andere Nutzermoduscode ausgeführt wird, kann er für EDRs sichtbar sein.

Indem wir kritische Teile unseres Codes in eine Enklave verschieben und eine Anti-Debugging-Prüfung durchführen, sind wir in der Lage, eine Malware zu erstellen, die für dynamische Analysen nahezu unangreifbar ist.  Die Malware verlässt sich darauf, dass die Enklave ordnungsgemäß ausgeführt wird, während der Nutzermodusprozess die darin ausgeführten Prüfungen nicht patchen kann. Richtig implementiert könnte dieser Ansatz nur durch das Debuggen von Hyper-V oder des sicheren Kernels umgangen werden.

Diese Schwachstelle bietet Angreifern zwei Möglichkeiten (Abbildung 16).

1. Willkürliches Schreiben innerhalb der Enklave: Ein Angreifer kann SealSettings aufrufen, um beliebige Daten zu verschlüsseln, und dann UnsealSettings aufrufen, um auf eine Zieladresse in der Enklave zu verweisen. Dies führt dazu, dass die ursprünglichen Daten in den Enklavenspeicher geschrieben werden.

2. Willkürliches Lesen innerhalb der Enklave: Ein Angreifer kann SealSettingsaufrufen und dabei eine Adresse innerhalb der Enklave als Quellpufferzeiger angeben. Dies führt dazu, dass die Enklave Daten aus dem Enklavenspeicher verschlüsselt und an einen vom Angreifer kontrollierten Ort schreibt. Der Angreifer kann diese Daten dann durch Aufrufen von UnsealSettingsentschlüsseln und so beliebige Daten aus der Enklave lesen.

Aktuell werden Enklaven nur von einer sehr begrenzten Anzahl von Anwendungen genutzt. Und selbst wenn sie umfassender eingesetzt werden sollten, werden sie nur von bestimmten Prozessen und nicht von beliebigen Prozessen geladen. Beispielsweise sollte calc.exe wahrscheinlich niemals eine VBS-Enklave laden.

Deshalb kann die anormale Verwendung von Enklaven eine großartige Erkennungschance darstellen. Sicherheitsspezialisten sollten sich dies zunutze machen, indem sie eine Baseline-Liste bekannter, legitimer Verwendungen von VBS-Enklaven erstellen und alle Abweichungen von dieser Liste kennzeichnen. Der Einsatz von Enklaven lässt sich auf zweierlei Arten erkennen: durch die Überwachung von Enklaven-APIs und durch die Erkennung von geladenen Enklaven-DLLs.

Die folgenden APIs werden zur Verwaltung von VBS-Enklaven durch einen Hosting-Prozess verwendet und weisen wahrscheinlich darauf hin, dass eine VBS-Enklave geladen wird:

• CreateEnclave
• LoadEnclaveImageW
• InitializeEnclave
• CallEnclave
• DeleteEnclave
• TerminateEnclave

Eine weitere Möglichkeit zur Erkennung einer anormalen Enklavennutzung wäre die Erkennung des Ladens von Umgebungs-DLLs, die typischerweise von Enklaven verwendet werden, d. h. vertdll.dll und ucrtbase_enclave.dll. Da diese DLLs nur von einer Enklave verwendet werden sollten, weist ihre Anwesenheit darauf hin, dass der Prozess wahrscheinlich eine Enklave verwendet.

VBS-Enklaven bieten Entwicklern ein großartiges Tool für den Schutz sensibler Bereiche ihrer Anwendungen. Wie wir gerade gezeigt haben, können sie aber auch von Bedrohungsakteuren zum „Schutz“ ihrer Malware verwendet werden. Obwohl dieses Konzept zum jetzigen Zeitpunkt eher theoretisch ist, ist es durchaus möglich, dass fortschrittliche Bedrohungsakteure in Zukunft VBS-Enklaven für bösartige Zwecke einsetzen.