Kernel ETW ist das beste ETW

Präambel

Ein wichtiges Merkmal von Secure-by-Design-Software ist die Generierung von Überwachungsprotokollen, wenn privilegierte Vorgänge ausgeführt werden. Diese nativen Überwachungsprotokolle können Details zum internen Softwarestatus enthalten, die für Sicherheitsanbieter von Drittanbietern unpraktisch sind, um sie im Nachhinein hinzuzufügen.

Die meisten Windows-Komponenten generieren Protokolle mithilfe der Ereignisablaufverfolgung für Windows (ETW). Diese Ereignisse legen einige der internen Abläufe von Windows offen, und es gibt Szenarien, in denen Endpunktsicherheitsprodukte davon profitieren, sie zu abonnieren. Aus Sicherheitsgründen sind jedoch nicht alle ETW-Anbieter gleich.

Die erste Überlegung ist in der Regel die Zuverlässigkeit des Ereignisanbieters selbst, insbesondere des Ortes, an dem die Protokollierung erfolgt. Befindet es sich innerhalb des Clientprozesses und ist trivial anfällig für ETW-Manipulationen? Oder ist es vielleicht etwas sicherer als in einem RPC-Server-Prozess? Im Idealfall stammen die Telemetriedaten jedoch aus dem Kernel. Angesichts der Sicherheitsgrenze zwischen Benutzer und Kernel bietet dies stärkere Manipulationsschutzgarantien als bei In-Process-Telemetriedaten. Dies ist die von Microsoft empfohlene Vorgehensweise. Wie Elastic Endpoint verwendet auch Microsoft Defender für Endpunkt Kernel-ETW anstelle von anfälligen ntdll Hooks im Benutzermodus.

Beispielsweise kann ein Angreifer einen In-Process-Hook im Benutzermodus auf leicht ntdll!NtProtectVirtualMemory vermeiden, aber das Umgehen eines PROTECTVM-ETW-Ereignisses des Kernels ist wesentlich schwieriger. Oder zumindest sollte es das sein.

Das Sicherheitsereignisprotokoll ist im Grunde nur ein persistenter Speicher für die Ereignisse des ETW-Anbieters Microsoft-Windows-Security-Auditing. Überraschenderweise ist das Sicherheitsereignis 4688 für die Prozesserstellung kein Kernel-Ereignis. Der Kernel sendet die Daten an den Dienst der lokalen Sicherheitsautorität (lsass.exe) und gibt ein ETW-Ereignis aus, das vom Ereignisprotokoll verarbeitet werden soll. Die Daten könnten also innerhalb dieses Serverprozesses manipuliert werden. Vergleichen Sie dies mit dem ProcessStart -Ereignis des Microsoft-Windows-Kernel-Process-Anbieters, das direkt vom Kernel protokolliert wird und Berechtigungen auf Kernelebene erfordert, um einzugreifen.

Die zweite Überlegung ist dann die Zuverlässigkeit der Informationen, die protokolliert werden. Möglicherweise vertrauen Sie der Ereignisquelle, aber was ist, wenn sie nur blind vom Client bereitgestellte Daten protokolliert, die außerhalb des protokollierten Ereignisses liegen?

In diesem Artikel konzentrieren wir uns auf Kernel-ETW-Ereignisse. Diese sind in der Regel am sicherheitsrelevantesten, da sie schwer zu umgehen sind und sich häufig auf privilegierte Aktionen beziehen, die im Namen eines Clientthreads ausgeführt werden.

Als Microsoft den Kernel-Patch-Schutz einführte, waren Sicherheitsanbieter in ihrer Fähigkeit, den Kernel zu überwachen, erheblich eingeschränkt. Angesichts der begrenzten Anzahl von Kernelerweiterungspunkten, die von Microsoft bereitgestellt wurden, waren sie zunehmend gezwungen, sich auf asynchrone ETW-Ereignisse zu verlassen, um nachträglich die Sichtbarkeit von Kernelaktionen zu gewährleisten, die im Namen von Schadsoftware ausgeführt wurden.

Angesichts dieser Abhängigkeit ist die öffentliche Dokumentation von Telemetriequellen des Windows-Kernels leider etwas spärlich.

Kernel-ETW-Ereignisse

Es gibt derzeit vier Arten von ETW-Anbietern , die wir in Betracht ziehen müssen.

Zum einen gibt es ältere und moderne Varianten von "Event Provider":

• Ältere (MOF-basierte) Ereignisanbieter
• Moderne (manifestbasierte) Ereignisanbieter

Und dann gibt es noch ältere und moderne Varianten von "Trace Provider":

• ÄltereWindows-WPP-Ablaufverfolgungsanbieter(Software Trace Preprocessor)
• Moderne TraceLogging-Ablaufverfolgungsanbieter

Die Unterscheidung zwischen "Ereignis" und "Spur" ist hauptsächlich semantischer Natur. Ereignisanbieter werden in der Regel im Voraus beim Betriebssystem registriert, und Sie können die verfügbaren Telemetriemetadaten überprüfen. Diese werden in der Regel von Systemadministratoren zur Fehlerbehebung verwendet und sind oft halb dokumentiert. Aber wenn etwas wirklich, wirklich schief geht, gibt es (versteckte) Trace-Anbieter. Diese werden in der Regel nur von den ursprünglichen Softwareautoren für die erweiterte Fehlerbehebung verwendet und sind nicht dokumentiert.

In der Praxis verwendet jede Datei ein etwas anderes Format, um ihre Ereignisse zu beschreiben und zu registrieren, was zu geringfügigen Unterschieden in der Art und Weise führt, wie die Ereignisse protokolliert werden - und, was noch wichtiger ist, wie die potenziellen Ereignisse aufgelistet werden können.

Moderne Kernel-Ereignisanbieter

Die modernen Kernel-ETW-Anbieter sind nicht streng dokumentiert. Registrierte Ereignisdetails können jedoch über die Trace Data Helper API vom Betriebssystem abgefragt werden. Das PerfView-Tool von Microsoft verwendet diese APIs, um das Registrierungsmanifest des Anbieters zu rekonstruieren, und Pavel Yosifovichs EtwExplorer verpackt diese Manifeste dann in eine einfache GUI. Sie können diese durch Tabulatoren getrennten Wertedateien von registrierten Manifesten aus aufeinanderfolgenden Windows-Versionen verwenden. Eine einzelne Zeile pro Ereignis ist sehr nützlich für das Grepping, obwohl andere inzwischen die rohen XML-Manifeste veröffentlicht haben.

Dies sind jedoch nicht alle möglichen Windows ETW-Ereignisse. Dies sind nur diejenigen, die standardmäßig beim Betriebssystem registriert sind. Beispielsweise werden die ETW-Ereignisse für viele Serverrollen erst registriert , wenn dieses Feature aktiviert ist.

Legacy-Kernel-Ereignisanbieter

Die Legacy-Kernelereignisse werden von Microsoft dokumentiert. Meist.

Legacyanbieter sind auch innerhalb des Betriebssystems als WMI EventTrace-Klassen vorhanden. Anbieter sind die Stammklassen, Gruppen sind die untergeordneten Klassen, und Ereignisse sind die untergeordneten Elemente.

So durchsuchen Sie die Legacyereignisse auf die gleiche Weise wie moderne EreignisseUm die Legacyereignisse auf die gleiche Weise wie moderne Ereignisse zu durchsuchen, wurden diese Klassen analysiert und das ursprüngliche MOF (größtenteils) rekonstruiert. Diese MOF-Unterstützung wurde dem EtwExplorer hinzugefügt, und durch Tabulatoren getrennte Wertzusammenfassungen der Legacyereignisse, bei denen diese Klassen analysiert und das ursprüngliche MOF (größtenteils) rekonstruiert wurden. Diese MOF-Unterstützung wurde zu EtwExplorer und tabulatorgetrennten Wertzusammenfassungen der veröffentlichten Legacyereignisse hinzugefügt.

Das vollständig rekonstruierte Windows Kernel Trace MOF finden Sie hier (oder in einem tabellarischen Format hier).

Von den 340 registrierten Altereignissen wurden nur 116 dokumentiert. In der Regel muss jedes Legacy-Ereignis über ein bestimmtes Flag aktiviert werden, aber auch diese wurden nicht dokumentiert. Es gab einen Hinweis in der Dokumentation für die Trace Ereignisse des Kernel-Objekt-Managers . Es wurde PERF_OB_HANDLEerwähnt, eine Konstante, die in den Headern des neuesten SDK nicht definiert ist. Glücklicherweise kamen Geoff Chappell und das Windows 10 1511 WDK zur Rettung. Diese Informationen wurden verwendet, um der KrabsETW-Bibliothek von Microsoft Unterstützung für PERFINFO_GROUPMASK Kernel-Ablaufverfolgungsflags hinzuzufügen. Es stellte sich auch heraus, dass die Object Trace-Dokumentation falsch war. Diese nicht öffentliche Konstante kann nur mit einer nicht dokumentierten API-Erweiterung verwendet werden. Glücklicherweise enthalten öffentliche Microsoft-Projekte wie PerfView häufig Beispiele für die Verwendung nicht dokumentierter APIs.

Da sowohl Manifeste als auch MOFs auf GitHub veröffentlicht wurden, können die meisten Kernelereignisse jetzt mit dieser Abfrage gefunden werden.

Interessanterweise verschleiert Microsoft häufig die Namen von sicherheitsrelevanten Ereignissen, sodass die Suche nach Ereignissen mit einem generischen Namenspräfix wie task_ zu einigen interessanten Ergebnissen führt.

Manchmal deutet das Schlüsselwort auf den Zweck des Ereignisses hin. Beispielsweise ist task_014 in Microsoft-Windows-Kernel-General mit dem Schlüsselwort KERNEL_GENERAL_SECURITY_ACCESSCHECK.

Und zum Glück sind die Parameter fast immer gut benannt. Wir könnten vermuten, dass task_05 in Microsoft-Windows-Kernel-Audit-API-Calls mit OpenProcess verwandt ist, da es Felder mit den Namen TargetProcessId und DesiredAccessprotokolliert.

Eine weitere nützliche Abfrage ist die Suche nach Ereignissen mit einem expliziten ProcessStartKey Feld. ETW-Ereignisse können so konfiguriert werden, dass sie dieses Feld für den Protokollierungsprozess enthalten, und jedes Ereignis, das diese Informationen für einen anderen Prozess enthält, ist häufig sicherheitsrelevant.

Wenn Sie eine bestimmte API im Sinn hatten, können Sie deren Namen oder Parameter abfragen. Wenn Sie z. B. Named Pipe-Ereignisse verwenden möchten, können Sie diese Abfrage verwenden.

In diesem Fall gehört Microsoft-Windows-SEC jedoch zu den integrierten Microsoft-Sicherheitstreibern, die von Microsoft Defender für Endpunkt (MDE) verwendet werden. Dieser Anbieter ist offiziell nur für MDE verfügbar, obwohl Sebastian Feldmann und Philipp Schmied gezeigt haben, wie man eine Sitzung mit einem AutoLogger startet und die Ereignisse dieser Sitzung abonniert. Dies ist derzeit nur für MDE-Benutzer nützlich, da der Treiber sonst nicht für die Ausgabe von Ereignissen konfiguriert ist.

Aber was ist mit Trace-Anbietern?

Moderne Kernel-Ablaufverfolgungsanbieter

TraceLogging-Metadaten werden als undurchsichtiges Blob in der Protokollierungsbinärdatei gespeichert. Glücklicherweise wurde dieses Format von Matt Graeber umgekehrt. Wir können Matts Skript verwenden, um alle TraceLogging-Metadaten für ntoskrnl.exezu dumpen. Ein Beispielabbild von Windows 11 TraceLogging-Metadaten finden Sie hier.

Leider behält die Metadatenstruktur allein die Korrelation zwischen Anbietern und Ereignissen nicht bei. Es gibt interessante Anbieternamen, wie z.B. Microsoft.Windows.Kernel.Security und AttackSurfaceMonitor, aber aus unserem Metadaten-Dump geht noch nicht hervor, welche Ereignisse zu diesen Anbietern gehören.

Legacy-Kernel-Ablaufverfolgungsanbieter

WPP-Metadaten werden in Symboldateien (PDBs) gespeichert. Microsoft fügt diese Informationen in die öffentlichen Symbole für einige, aber nicht alle Treiber ein. Der Kernel selbst erzeugt jedoch keine WPP-Ereignisse. Stattdessen können dem älteren Windows-Kernelablaufverfolgungsereignisanbieter nicht dokumentierte Flags übergeben werden, um die älteren Ablaufverfolgungsereignisse zu aktivieren, die normalerweise nur für Microsoft-Kernelentwickler verfügbar sind.

Wie geht es weiter?

Wir verfügen jetzt über Kernelereignismetadaten für jede der vier Varianten des ETW-Anbieters, aber eine Liste von ETW-Ereignissen ist nur unser Ausgangspunkt. Die Kenntnis des Anbieters und des Ereignisschlüsselworts reicht möglicherweise nicht aus, um die erwarteten Ereignisse zu generieren. Manchmal ist ein zusätzlicher Konfigurationsregistrierungsschlüssel oder API-Aufruf erforderlich. In den meisten Fällen müssen wir jedoch nur die genauen Bedingungen verstehen, unter denen das Ereignis protokolliert wird.

Genau zu wissen, wo und was protokolliert wird, ist entscheidend, um Ihre Telemetriedaten und ihre Grenzen wirklich zu verstehen. Und dank der Verfügbarkeit von Decompilern haben wir die Möglichkeit, gerade genug umzukehren. In IDA nennen wir dies "F5 drücken". Ghidra ist die Open-Source-Alternative und unterstützt Scripting ... mit Java.

Für Kernel-ETW sind wir besonders an EtwWrite Aufrufen interessiert, die von Systemaufrufen aus erreichbar sind. Wir möchten so viele Parameterinformationen wie möglich von der Aufrufsite erhalten, einschließlich aller zugeordneten Informationen zu öffentlichen Symbolen. Dies bedeutete, dass wir den Aufrufgraphen durchlaufen mussten, aber auch versuchen mussten, die möglichen Werte für bestimmte Parameter aufzulösen.

Die notwendigen Parameter waren die RegHandle und die EventDescriptor. Ersteres ist ein undurchsichtiges Handle für den Anbieter, und letzteres stellt ereignisspezifische Informationen bereit, z. B. die Ereignis-ID und die zugehörigen Schlüsselwörter. Ein ETW-Schlüsselwort ist ein Bezeichner, der zum Aktivieren einer Reihe von Ereignissen verwendet wird.

Noch besser war, dass diese Ereignisdeskriptoren in der Regel in einer globalen Konstante mit einem öffentlichen Symbol gespeichert wurden.

Wir verfügten über ausreichende Ereignismetadaten, mussten aber dennoch das undurchsichtige Anbieterhandle, das zur Laufzeit zugewiesen wurde, wieder in die Metadaten zum Anbieter auflösen. Dafür brauchten wir auch die EtwRegister Anrufe.

Das typische Muster für moderne Kernelereignisanbieter bestand darin, die GUID des konstanten Anbieters und das Laufzeithandle in globalen Symbolen mit öffentlichen Symbolen zu speichern.

Ein weiteres gefundenes Muster waren Aufrufe von EtwRegister, EtwEwriteund EtwUnregister, alle in derselben Funktion. In diesem Fall haben wir die Lokalität genutzt, um die Anbieter-GUID für das Ereignis zu finden.

Moderne TraceLogging-Anbieter verfügten jedoch nicht über zugeordnete öffentliche Symbole pro Anbieter, um einen Hinweis auf den Zweck der einzelnen Anbieter zu geben. Matt Graeber hatte jedoch das TraceLogging-Metadatenformat umgekehrt und dokumentiert, dass der Anbietername mit einem festen Offset von der Anbieter-GUID gespeichert wird. Den genauen Anbieternamen zu haben, ist sogar noch besser als nur das öffentliche Symbol, das wir für moderne Ereignisse wiederhergestellt haben.

Damit blieben nur die Legacy-Anbieter übrig. Sie schienen weder öffentliche Symbole noch Metadaten-Blobs zu haben. Einige Konstanten werden an eine nicht dokumentierte Funktion mit dem Namen EtwTraceKernelEvent übergeben, die den eventuellen ETW-Schreibaufruf umschließt.

Diese Konstanten sind in den Windows 10 1511 WDK-Headern (und den System Informer-Kopfzeilen ) vorhanden, sodass wir diese Ereignisse mit den Konstantennamen bezeichnen können.

Dieses Skript wurde kürzlich für Ghidra 11 aktualisiert, zusammen mit verbesserter Unterstützung für TraceLogging und Legacy-Ereignisse. Ihr findet es jetzt auf GitHub hier - https://github.com/jdu2600/API-To-ETW

Eine Beispielausgabe für den Windows 11 Kernel finden Sie hier.

Unsere bisher anonymen Microsoft-Windows-Kernel-Audit-API-Calls Ereignisse werden durch dieses Skript schnell entlarvt.

Symbol und enthaltende Funktion für Microsoft-Windows-Kernel-Audit-API-Calls-Ereignisse

Mit dem Aufrufpfad und den Parameterinformationen, die vom Skript wiederhergestellt werden, können wir auch sehen, dass das SECURITY_ACCESSCHECK Ereignis von früher mit der SeAccessCheck-Kernel-API verknüpft ist, aber nur in einer Funktion mit dem Namen SeLogAccessFailureprotokolliert wird. Nur das Protokollieren von Fehlerbedingungen kommt bei ETW-Ereignissen sehr häufig vor. Für die Problembehandlung ist der ursprüngliche ETW-Anwendungsfall in der Regel am nützlichsten, und die Implementierung in den meisten Komponenten spiegelt dies wider. Leider ist aus Sicherheitsgründen oft das Gegenteil der Fall. Die erfolgreichen Vorgangsprotokolle sind in der Regel nützlicher, um bösartige Aktivitäten zu finden. Daher ist der Wert einiger dieser Altereignisse oft gering.

Die moderne Secure-by-Design-Praxis besteht darin, sowohl Erfolge als auch Fehler für sicherheitsrelevante Aktivitäten zu überwachen, und Microsoft fügt weiterhin neue sicherheitsrelevante ETW-Ereignisse hinzu, die dies tun. Der Vorschau-Build von Windows 11 24H2 enthält z. B. einige interessante neue ETW-Ereignisse im Microsoft-Windows-Threat-Intelligence -Anbieter. Es bleibt zu hoffen, dass diese vor der Veröffentlichung für Sicherheitsanbieter dokumentiert werden.

Das Ausführen dieses Decompilerskripts über interessante Windows-Treiber und Dienst-DLLs bleibt dem Leser als Übung überlassen.