ESPecter Bootkit – neue Bedrohung in der EFI-Systempartition

ESET-Forscher haben ein bisher unbekanntes UEFI-Bootkit analysiert, das dauerhaft auf der EFI-Systempartition (ESP) verbleibt. Das Bootkit, das wir ESPecter genannt haben, wurde in freier Wildbahn entdeckt und kann die Erzwingung von Windows-Treibersignaturen umgehen, um seinen eigenen, unsignierten Treiber zu laden und seine Spionageaktivitäten zu ermöglichen. Auch aufgrund der Entdeckung des nicht verwandten FinSpy-Bootkits durch Kaspersky, kann man jetzt mit Sicherheit sagen, dass reale UEFI-Bedrohungen nun nicht mehr auf SPI-Flash-Implantate beschränkt sind, wie sie von Lojax verwendet werden.

Die Zeiten, in denen UEFI (Unified Extensible Firmware Interface) im Schatten des alten Legacy-BIOS stand, sind endgültig vorbei. Heute spielt die in den Chips moderner Computer und Geräte eingebettete Technologie eine entscheidende Rolle bei der Absicherung der Pre-OS-Umgebung und beim Laden des Betriebssystems

Als führende Technologie, die in Chips moderner Computer und Geräte eingebettet ist, spielt sie eine entscheidende Rolle. Daher ist es kaum verwunderlich, dass diese weit verbreitete Technologie auch ein verlockendes Ziel für Bedrohungsakteure darstellt, die nach ultimativer Persistenz streben.

In den letzten Jahren haben wir Proof-of-Concept-Beispiele von UEFI-Bootkits (DreamBoot, EfiGuard), geleakte Dokumente (DerStarke, QuarkMatter) und sogar durchgesickerten Quellcode (Hacking Team Vector EDK) gesehen, die auf die Existenz echter UEFI-Malware, in Form von SPI-Flash- oder ESP-Implantaten, hindeuten. Trotz alledem, wurden bisher nur drei reale Fälle von UEFI-Malware entdeckt: LoJax, entdeckt von unserem Team im Jahr 2018, MosaicRegressor, entdeckt von Kaspersky im Jahr 2019 und zuletzt das FinSpy-Bootkit, dessen Analyse gerade erst von Kaspersky veröffentlicht wurde. Während die ersten beiden Fälle in die Kategorie der SPI-Flash-Implantate fallen, gehört der letzte in die Kategorie der ESP-Implantate und ist, überraschenderweise, nicht der einzige.

Heute beschreiben wir unsere neueste Entdeckung namens ESPecter, den erst zweiten realen Fall eines UEFI-Bootkits, das in Form eines gepatchten Windows-Boot-Managers auf dem ESP verbleibt und das hier analysiert werden soll. ESPecter wurde auf einem kompromittierten Computer gefunden, zusammen mit einer User-Mode Client-Komponente, die Keylogging- und Dokumentendiebstahl-Funktionen hat. Daher glauben wir, dass ESPecter hauptsächlich zur Spionage verwendet wird. Interessanterweise konnten wir die Wurzeln dieser Bedrohung mindestens bis ins Jahr 2012 zurückverfolgen, als sie noch als Bootkit für Systeme mit Legacy-BIOS diente. Trotz des langen Bestehens von ESPecter blieben der Betrieb und das Upgrade auf UEFI bisher unbemerkt und undokumentiert. Bitte beachten Sie, dass die einzige Ähnlichkeit zwischen ESPecter und Kasperskys FinSpy im Ansatz besteht, den UEFI-Boot-Manager zu kompromittieren.

Abbildung 1. Vergleich des Legacy-Bootflows (links) und des UEFI-Bootflows (rechts) auf Windows-Systemen (Vista und neuer)

Durch das Patchen des Windows Boot Managers erreichen die Angreifer eine Ausführung der Malware in den frühen Phasen des Systemstartprozesses (siehe Abbildung 1), bevor das Betriebssystem vollständig geladen ist. Dadurch kann ESPecter die Erzwingung von Windows-Treibersignaturen (engl. Windows Driver Signature Enforcement, abgekürzt DSE) umgehen, um beim Systemstart seinen eigenen, unsignierten Treiber auszuführen. Dieser Treiber injiziert dann andere User-Mode-Komponente in bestimmte Systemprozesse, um die Kommunikation mit dem C&C-Server von ESPecter zu initiieren und dem Angreifer die Kontrolle über den kompromittierten Computer ermöglichen, was durch das Herunterladen und Ausführen zusätzlicher Malware und oder das Ausführen von C&C-Befehlen geschieht.

Obwohl Secure Boot eigentlich die Ausführung nicht vertrauenswürdiger UEFI-Binärdateien von der ESP verhindern soll, wurden wir in den vergangenen Jahren Zeugen verschiedener UEFI-Firmware-Schwachstellen, die das Deaktivieren oder Umgehen von Secure Boot ermöglichen (z.B. VU#758382, VU#976132, VU#631788, …) und Tausende von Geräten betreffen. Das zeigt, dass die Absicherung von UEFI-Firmware eine anspruchsvolle Aufgabe ist und dass die Art und Weise, wie verschiedene Anbieter Sicherheitsrichtlinien und UEFI-Dienste verwenden, nicht immer vorbildlich ist.

In der Vergangenheit haben wir über mehrere bösartige EFI-Samples in Form von einfachen UEFI-Anwendungen ohne umfangreiche Funktionen berichtet. Diese Beobachtungen zeigen, zusammen mit der gleichzeitigen Entdeckung der voll funktionsfähigen ESPecter- und FinFisher-UEFI-Bootkits, dass sich Bedrohungsakteure nicht allein auf UEFI-Firmware-Implantate verlassen, wenn es um das Erlangen von Pre-Boot-Persistenz geht. Vielmehr versuchen sie auch ihre Vorteile aus einem deaktivierten Secure Boot zu ziehen, indem sie ihre eigenen ESP-Implantate ausführen.

Wir konnten ESPecter keinem bekannten Bedrohungsakteur zuordnen. Die chinesischen Debug-Meldungen in der zugehörigen Use-Mode Client-Komponente (siehe Abbildung 2) bringen uns, mit geringer Sicherheit, zu der Annahme, dass ein unbekannter chinesischsprachiger Bedrohungsakteur hinter ESPecter steht. Derzeit wissen wir nicht, wie das Bootkit verteilt wurde.

Abbildung 2. Beispiel für chinesische Debug-Meldungen in der Use-Mode Client-Komponente

Die Evolution des ESPecter Bootkits

Anhand unserer Telemetriedaten konnten wir feststellen, dass die Anfänge dieses Bootkits mindestens auf das Jahr 2012 zurückgehen. Zu Beginn modifizierte es den Master Boot Record (MBR) um Persistenz zu erreichen und seine Autoren arbeiteten kontinuierlich an der Unterstützung von neuen Windows-Versionen. Es ist interessant, dass sich die Komponenten der Malware in all den Jahren kaum verändert haben, die Unterschiede zwischen den Versionen von 2012 und 2020 sind nicht so bedeutend, wie man erwarten würde.

Nach all den Jahren unbedeutender Veränderungen entschieden sich die Hintermänner von ESPecter offenbar dazu, ihre Malware von älteren BIOS-Systemen auf moderne UEFI-Systeme umzustellen. Um dies zu erreichen, beschlossen sie, eine legitime Windows-Boot-Manager-Binärdatei (bootmgfw.efi) auf dem ESP zu modifizierten und so gleichzeitig mehrere Windows-Versionen von Windows 7 bis einschließlich Windows 10 zu unterstützen. Wie bereits erwähnt, hat diese Methode einen Nachteil – sie erfordert, dass die Secure Boot-Funktion deaktiviert ist, um erfolgreich mit einem modifizierten Bootmanager zu booten. Es ist jedoch erwähnenswert, dass die erste Windows-Version, die Secure Boot unterstützt, Windows 8 war, was bedeutet, dass alle vorherigen Versionen für diese Persistenzmethode anfällig sind.

Bei Windows-Versionen, die Secure Boot unterstützen, müsste der Angreifer es deaktivieren. Derzeit ist nicht bekannt, wie die Betreiber von ESPecter dies erreicht haben, aber es gibt einige mögliche Szenarien:

• Der Angreifer hat physischen Zugriff auf das Gerät (in der Vergangenheit „Evil Maid“-Angriff genannt) und deaktiviert Secure Boot manuell im BIOS-Setup-Menü (üblicherweise wird das Firmware-Konfigurationsmenü weiterhin als „BIOS“ bezeichnet, auch auf UEFI-Systemen).
• Secure Boot war auf dem kompromittierten Computer bereits deaktiviert (z.B. damit der Benutzer Windows sowie andere Betriebssysteme, die Secure Boot nicht unterstützen, dual booten kann).
• Die Ausnutzung einer unbekannten UEFI-Firmware-Schwachstelle aus, die das Deaktivieren von Secure Boot ermöglicht.
• Die Ausnutzung einer bekannten UEFI-Firmware-Schwachstelle in einer veralteten Firmware-Version oder einem nicht mehr unterstützten Produkt.

Technische Analyse

Während unserer Untersuchung haben wir mehrere bösartige Komponenten entdeckt, die im Zusammenhang mit ESPecter stehen:

• Installer für die älteren MBR-Versionen des Bootkits, deren Zweck darin bestand, Persistenz auf dem Computer zu erlangen, indem der MBR des Boot-Geräts neu geschrieben wird.
• Boot-Code entweder in Form eines modifizierten Windows-Boot-Managers (bootmgfw.efi) auf UEFI-Systemen oder eines bösartigen MBR bei Legacy-Boot-Systemen.
• Ein Kernel-Modus-Treiber, der verwendet wird, um die Umgebung für die User-Mode-Payloads vorzubereiten und sie in den frühen Stadien des Betriebssystemstarts zu laden, indem sie in bestimmte Systemprozesse eingefügt werden.
• User-Mode-Payloads, die für die Kommunikation mit dem C&C-Server verantwortlich sind, die C&C-Konfiguration aktualisieren und C&C-Befehle ausführen.

Das vollständige Schema der ESPecter-Bootkit-Infektion finden Sie in Abbildung 3.

Abbildung 3. Komponenten des ESPecter-Bootkits

Persistenz im UEFI-Boot-Modus

Auf Systemen, die den UEFI-Boot-Modus verwenden, wird erreicht ESPecter Persistenz durch das Ändern des Windows-Boot-Managers bootmgfw.efi und der Fallback-Bootloader-Binärdatei bootx64.efi, die sich normalerweise in den ESP-Verzeichnissen \EFI\Microsoft\Boot\ und \EFI\Boot\ befinden. Die Modifikation des Bootloaders umfasst das Hinzufügen eines neuen Abschnitts namens .efi zum PE und das Ändern der Einstiegspunktadresse der ausführbaren Datei, sodass der Programmfluss zum Anfang des hinzugefügten Abschnitts springt, wie in Abbildung 4 gezeigt.

Vergleich von originalem (oben) und modifiziertem (unten) Windows Boot Manager (bootmgfw.efi)

Vereinfachte Bootkette

Wie das Schema links in Abbildung 5 zeigt, beginnt der Bootvorgang auf UEFI-Systemen (ohne Berücksichtigung des Firmware-Teils) mit der Ausführung der Bootloader-Anwendung, die sich in der EFI-Systempartition (ESP) befindet. Für das Windows-Betriebssystem ist dies die Windows Boot Manager-Binärdatei (bootmgfw.efi) und ihr Zweck besteht darin, ein installiertes Betriebssystem zu finden und die Ausführung an seinen Betriebssystem-Kernel-Loader – winload.efi – zu übertragen. Ähnlich wie der Bootmanager ist der OS-Kernel-Loader für das Laden und Ausführen der nächsten Komponente in der Boot-Kette verantwortlich – dem Windows-Kernel (ntoskrnl.exe).

Abbildung 5. Der typische Windows-UEFI-Bootflow (links) im Vergleich zu dem von ESPecter modifizierten Bootflow (rechts)

Wie ändert ESPecter den UEFI-Boot-Prozess?

Um seine schädliche Nutzlast erfolgreich zu platzieren, muss ESPecter Integritätsprüfungen umgehen, die vom Windows Boot Manager und dem Windows-Kernel während des Startvorgangs durchgeführt werden. Dazu sucht es nach Bytemustern, die die gewünschten Funktionen im Speicher identifizieren und patcht sie entsprechend.

Beginnend mit dem Bootloader, in unserem Fall dem Windows Boot Manager (bootmgfw.efi), beginnt das Bootkit mit dem Patchen der Funktion BmFwVerifySelfIntegrity . Diese Funktion ist für die Überprüfung der eigenen digitalen Signatur des Bootmanagers verantwortlich und soll die Ausführung eines modifizierten Bootmanagers verhindern. In Abbildung 6 sehen Sie, wie ESPecter den Speicher nach BmFwVerifySelfIntegrity mit verschiedenen Bytemustern durchsucht (um vielen verschiedenen bootmgfw.efi-Versionen umgehen zu können) und diese Funktion so modifiziert, dass sie immer Null zurückgibt, was anzeigt, dass die Überprüfung erfolgreich war.

Wie bereits erwähnt, besteht das Hauptziel des Bootloaders darin, ein installiertes Betriebssystem zu finden und die Ausführung an seinen Betriebssystem-Kernel-Loader zu übertragen. Für den Windows Boot Manager geschieht dies mit der Funktion Archpx64TransferTo64BitApplicationAsm . Daher sucht ESPecter nach dieser Funktion, um den Moment zu erwischen, in dem der OS-Loader in den Speicher geladen, aber noch nicht ausgeführt wird. Ist sie gefunden, patcht sie ESPecter, um seine eigene Umleitungsfunktion einzufügen, die den geladenen OS-Loader im richtigen Moment im Speicher ändert.

Abbildung 6. Dekompilierter Hex-Rays-Code – Suchen und Patchen der Funktion BmFwVerifySelfIntegrity

Die Änderung des OS-Loaders beinhaltet kein Patchen von Integritätsprüfungen oder anderen Funktionen. In dieser Phase ist es wichtig, dass das Bootkit seinen Code neu zuordnet, da es als UEFI-Anwendung nach der Rückkehr von seiner Einstiegspunktfunktion aus dem Speicher entladen wird. Dazu verwendet es die Funktion BlImgAllocateImageBuffer oder BlMmAllocateVirtualPages (je nach gefundenem Muster). Nach dieser Neuzuweisung fügt das Bootkit eine Umleitung (welche sich im zuvor zugewiesenen Puffer befindet) zu der Funktion ein, die für die Übertragung der Ausführung an den Betriebssystemkernel verantwortlich ist – OslArchTransferToKernel – damit es den Windows-Kernel im Speicher patchen kann, sobald er geladen ist, aber bevor er ausgeführt wird . Die letzte Stufe des Boot-Codes des Bootkits ist dafür verantwortlich, DSE zu deaktivieren, indem die Kernelfunktion SepInitializeCodeIntegrity gepatcht wird (siehe Abbildung 7 für Details).

Abbildung 7. Vergleich der mit Hex-Rays dekompilierten Funktion SepInitializeCodeIntegrity vor (links) und nach (rechts) dem Patchen im Speicher

Interessanterweise patcht der Bootcode auch die Kernelfunktion von MiComputeDriverProtection . Auch wenn diese Funktion das erfolgreiche Laden des bösartigen Treibers nicht direkt beeinflusst, fährt das Bootkit nicht mit dem Platzieren des Treibers fort, wenn es diese Funktion nicht im Kernelspeicher findet und patcht. Wir konnten den Zweck dieses zweiten Patches nicht identifizieren, gehen jedoch davon aus, dass diese modifizierte Funktion von anderen, noch unbekannten ESPecter-Komponenten verwendet werden kann.

Zusammen mit dem Patchen der Kernelfunktion fügt ESPecter eine Umleitung in die Funktion CmGetSystemDriverList ein und übergibt die Ausführung an den Windows-Kernel. Der Zweck dieser Umleitung besteht darin, einen nicht signierten bösartigen Treiber und eine verschlüsselte Konfiguration auf dem Laufwerk abzulegen, genau bevor der Kernel mit dem Laden der Systemtreiber fortfährt. Die Position der abgelegten Komponenten ist:

• \SystemRoot\System32\null.sys (Treiber)
• \SystemRoot\Temp\syslog (verschlüsselte Konfiguration)

Die Konfiguration wird von der vom Kernel-Treiber bereitgestellten User-Mode-Komponente WinSys.dll verwendet und besteht aus einem Ein-Byte-XOR-Schlüssel gefolgt von den verschlüsselten Konfigurationsdaten. Um die Konfiguration zu entschlüsseln, WinSys.dll:

1. dekodiert Base64 die Konfigurationsdaten
2. XORiert sie mit der XOR-Taste
3. dekodiert Base64 jeden durch „|“ getrennten Wert separat

Abbildung 8 zeigt ein Beispiel für eine Konfiguration, die von der EFI-Version von ESPecter gelöscht wurde. Eine komplette Liste der IP-Adressen und Domains, die wir in den Konfigurationen der ESPecter-Proben entdeckt haben, ist im Abschnitt IoCs (Indicators of Compromise) enthalten.

Abbildung 8. Entschlüsselung der von der EFI-Version des ESPecter-Bootkits gelieferten Konfiguration

Persistenz im Legacy Boot-Modus

Wie bereits erwähnt, gibt es ESPecter-Versionen, die UEFI unterstützen, und andere, die Legacy-Boot-Modi unterstützen. Im Fall des Legacy-Boot-Modus wird die Persistenz durch die bekannte Technik erreicht, bei der der MBR-Code, der sich im ersten physischen Sektor des Festplattenlaufwerks befindet, verändert wird. Daher werden wir dies hier nicht im Detail erklären, sondern nur zusammenfassen.

Wie ändert ESPecter den Legacy-Boot-Prozess?

Der bösartige MBR entschlüsselt zuerst Code, der zuvor vom Installationsprogramm auf die Festplattensektoren 2, 3 und 4 kopiert wurde, bindet den Interrupt-Handler für den Realmodus INT13h (BIOS-Sektor-Lese-Schreib-Dienste) ein und übergibt dann die Ausführung an den ursprünglichen MBR-Code, der vom Installer auf dem zweiten Sektor (Sektor 1) gesichert wurde. Ähnlich wie bei anderen bekannten MBR-Bootkits prüft der Hook-Code (in Sektor 0) beim Aufrufen des INT13h-Interrupt-Handlers, ob die Dienste 0x02 (Sektoren vom Laufwerk lesen) und 0x42 (Erweiterte Sektoren vom Laufwerk lesen) verarbeitet werden, um das Laden von bootmgr abzufangen, der Legacy-Version des Windows-Boot-Managers. Beachten Sie, dass ältere ESPecter-Versionen die BmFwVerifySelfIntegrity -Funktion in bootmgr nicht patchen müssen, da die bootmgr-Binärdatei in keiner Weise geändert wurde.

Ab diesem Zeitpunkt ist die Funktionalität des Bootcodes fast die gleiche wie in der UEFI-Version, was dazu führt, dass der bösartige Treiber (der sich zusammenhängend auf Track 0, beginnend bei Sektor 6 befindet), je nach Architektur an einem der folgenden Orte abgelegt wird:

• \SystemRoot\System32\drivers\beep.sys (x86)
• \SystemRoot\System32\drivers\null.sys (x64)

In diesem Fall wird die verschlüsselte Konfiguration nicht in der syslog-Datei abgelegt, sondern bleibt im Sektor 5 der infizierten Festplatte verborgen.

Abbildung 9. Geändertes Festplattenschema, das von der älteren ESPecter-Version verwendet wird

Kernel-Modus-Treiber

Der Hauptzweck des Treibers besteht darin, bösartige Nutzlasten im User-Mode zu laden, den Keylogger einzurichten und sich am Ende selbst zu löschen. Die Einrichtung des Keyloggers erfolgt in zwei Schritten:

• Zuerst erstellt er ein Gerät mit dem Namen \Device\WebBK, das eine Funktion bereitstellt, die IRP_MJ_DEVICE_CONTROL-Anforderungen von der User-Mode-Komponente verarbeitet. Diese Funktion unterstützt einen IOCTL-Code (Input/Output Control) (0x22C004), der verwendet werden kann, um die Registrierung einer asynchronen Prozeduraufrufroutine auszulösen, die für die Verarbeitung abgefangener Tastenanschläge verantwortlich ist.
• Das Abfangen von Tastenanschlägen erfolgt, indem CompletionRoutine für IRP_MJ_READ-Anforderungen für das Tastaturtreiberobjekt \Device\KeyboardClass0 eingerichtet wird.

Anschließend kann jeder Prozess mit der Protokollierung abgefangener Tastenanschläge beginnen, indem er seine eigene Routine definiert und diese mithilfe der benutzerdefinierten IOCTL 0x22C004 an das erstellte Geräteobjekt weitergibt.

Standardmäßig versucht der Treiber, zwei Basisnutzlasten – WinSys.dll und Client.dll – zu laden, die zusätzliche Nutzlasten herunterladen und ausführen können. Die erste, WinSys.dll, ist eine mit MPRESS gepackte DLL, die in verschlüsselter Form in die Binärdatei des Treibers eingebettet ist. Die zweite, Client.dll, wird von der WinSys.dll in die Datei \SystemRoot\Temp\memlog heruntergeladen, ebenfalls in verschlüsselter Form, mit der gleichen Verschlüsselungsmethode – ein einfaches Ein-Byte-XOR mit Subtraktion – aber nicht mit dem gleichen Schlüssel. Beide Bibliotheken werden entschlüsselt und vom Treiber im Systemverzeichnis \SystemRoot\System32\ abgelegt.

Die Ausführung sowohl der WinSys.dll- als auch der Client.dll-Bibliotheken wird erreicht, indem sie in svchost.exe bzw. winlogon.exe injiziert werden. Dazu registriert der Treiber die Image-Load-Callback-Routine NotifyRoutine mit PsSetLoadImageNotifyRoutine, mit der Folgendes ausgeführt wird:

• Der MainThread-Export aus Client.dll im Kontext des winlogon.exe-Prozesses
• Der MainThread-Export aus WinSys.dll im Kontext des svchost.exe-Prozesses

NotifyRoutine bindet den Einstiegspunkt der Prozessabbilder winlogon.exe und svchost.exe im Speicher ein, bevor sie ausgeführt werden. Dieser Hook ist dann für das Laden und Ausführen der entsprechenden Payload-DLL verantwortlich. Wie in Abbildung 10 gezeigt, wird nur das zuerst geladene svchost.exe- oder winlogon.exe-Image von der Routine verarbeitet.

Abbildung 10. Die Hex-Rays-dekompilierte NotifyRoutine prüft, ob svchost.exe oder winlogon.exe geladen wird.

User-Mode-Komponenten – WinSys.dll

WinSys.dll fungiert als Basis-Update-Agent, der regelmäßig seinen C&C-Server kontaktiert, um zusätzliche Nutzlasten herunterzuladen oder auszuführen oder einfache Befehle auszuführen. Die C&C-Adresse befindet sich zusammen mit anderen Werten wie Kampagnen-ID, Bootkit-Version, Zeit zwischen C&C-Kommunikationsversuchen und aktivem Stundenbereich in der Konfiguration, die geladen werden kann von:

• DefaultConfig-Wert in HKLM\SYSTEM\CurrentControlSet\Control-Registry
• \SystemRoot\Temp\syslog-Datei
• oder direkt vom bestimmten Festplattensektor (in der Legacy Boot-Version)

Wenn sowohl in der Registry als auch auf der Festplatte gespeicherte Konfigurationen vorhanden sind, wird die Konfiguration aus der Registry verwendet.

C&C-Kommunikation

WinSys.dll kommuniziert mit seinem Command&Controll-Server über HTTPS und die Kommunikation wird durch Senden einer HTTP-GET-Anfrage im folgenden URL-Format initiiert:

• https://<ip>/Heart.aspx?ti=<drive_ID>&tn=<campaign_ID>&tg=<number>&tv=<malware_version>

Dabei ist drive_ID der MD5-Hash der Seriennummer des Hauptsystemvolumes und die anderen Parameter sind weitere Informationen, die diese Malware-Instanz identifizieren.

Als Ergebnis kann der C&C mit der als String dargestellten Befehls-ID antworten, optional gefolgt von Befehlsparametern. Die vollständige Liste der Befehle finden Sie in Tabelle 1.

Tabelle 1. C&C-Befehle der WinSys-Komponente

User-Mode-Komponenten – Client.dll

Die zweite, vom bösartigen Treiber bereitgestellte Nutzlast, sofern verfügbar, ist Client.dll. Es handelt sich um eine Backdoor, die eine Vielzahl von Befehlen unterstützt (siehe Tabelle 2) und verschiedene automatische Daten-Ausleitungsfunktionen enthält, darunter den Diebstahl von Dokumenten, Keylogging und die Überwachung des Bildschirms des Opfers durch regelmäßige Screenshots. Alle gesammelten Daten werden in einem versteckten Verzeichnis mit separaten Unterverzeichnissen für jede Datenquelle gespeichert – die vollständige Liste der verwendeten Verzeichnispfade ist in unserem GitHub-Repository verfügbar. Beachten Sie auch, dass das Abfangen der Tastaturanschläge vom Treiber übernommen wird und der Client nur seine Protokollierungsfunktion registrieren muss, indem er IOCTL 0x22C004 an das Gerät des Treibers sendet, um abgefangene Tastenanschläge in der Datei zu speichern (Abbildung 11).

Abbildung 11. Client-Payload – Einrichten der Keylogger-Funktion durch Senden von IOCTL an den Gerätetreiber des Bootkits

Die Konfiguration für die Client-Komponente sollte sich in verschlüsselter Form im Overlay der Datei befinden. Es enthält Informationen wie die C&C-Adresse und den Port, Flags, die angeben, welche Daten gesammelt werden sollen (Tastenanschläge, Screenshots, Dateien mit bestimmten Erweiterungen), Zeitraum für den Screenshot-Thread, maximale Dateigröße für exfiltrierte Daten und eine Liste der Dateierweiterungen.

C&C-Kommunikation

Der Client legt seinen eigenen Kommunikationskanal mit dem C&C fest. Für die Kommunikation mit dem C&C verwendet er das TCP-Protokoll mit einer Einzelbyte-XOR-Verschlüsselung, die auf Nicht-Null-Nachrichtenbytes angewendet wird, die sich vom Schlüssel unterscheiden, der in der hier analysierten Kampagne 0x66 war. Die Kommunikation wird initiiert, indem Beacon-Nachrichten an das in der Konfiguration angegebene IP:PORT-Paar gesendet werden. Diese Nachricht enthält den Wert drive_ID (den MD5-Hash der Seriennummer des Hauptsystemvolumes) zusammen mit einem Wert, der die Art der Nachricht angibt, das heißt entweder eine Befehlsanforderung oder das Hochladen von gesammelten Daten.

Nach der Ausführung des C&C-Befehls wird das Ergebnis an den C&C zurückgemeldet, wobei der Ergebniscode der ausgeführten Operation, die Befehls-ID und interessanterweise jede dieser resultierenden Berichtsnachrichten ein Wasserzeichen/Tag enthält, das die breite Zeichenfolge WBKP an Offset 0x04 darstellt. Dies macht es einfacher, diese bösartige Kommunikation auf Netzwerkebene zu identifizieren.

Tabelle 2. Liste der Client-C&C-Befehle

Fazit

ESPecter zeigt, dass Bedrohungsakteure nicht mehr nur auf UEFI-Firmware-Implantate angewiesen sind, wenn es um die Persistenz vor dem Booten geht. Trotz bestehender Sicherheitsmechanismen, wie UEFI Secure Boot, investieren sie ihre Zeit in die Erstellung von Malware, die von solchen Sicherheitsmechanismen, falls sie aktiviert und richtig konfiguriert wären, leicht blockiert werden könnten.

Um sich vor Bedrohungen wie dem ESPecter-Bootkit zu schützen, stellen Sie sicher, dass

• Sie immer die neueste Firmware-Version verwenden.
• Ihr System ist richtig konfiguriert und Secure Boot aktiviert ist.
• Sie ein korrektes Privileged Account Management (PAM) anwenden, um zu verhindern, dass Angreifer auf die privilegierten Konten zugreifen können, die für die Bootkit-Installation erforderlich sind.

Indicators of Compromise (IoCs)

A comprehensive list of IoCs and samples can be found in our GitHub repository.

ESET detections

EFI/Rootkit.ESPecter
Win32/Rootkit.ESPecter
Win64/Rootkit.ESPecter

C&C IP addresses and domains from configurations

196.1.2[.]111
103.212.69[.]175
183.90.187[.]65
61.178.79[.]69
swj02.gicp[.]net
server.microsoftassistant[.]com
yspark.justdied[.]com
crystalnba[.]com

Legacy version installers

ABC03A234233C63330C744FDA784385273AF395B
DCD42B04705B784AD62BB36E17305B6E6414F033
656C263FA004BB3E6F3EE6EF6767D101869C7F7C
A8B4FE8A421C86EAE060BB8BF525EF1E1FC133B2
3AC6F9458A4A1A16390379621FDD230C656FC444
9F6DF0A011748160B0C18FB2B44EBE9FA9D517E9
2C22AE243FDC08B84B38D9580900A9A9E3823ACF
08077D940F2B385FBD287D84EDB58493136C8391
1D75BFB18FFC0B820CB36ACF8707343FA6679863
37E49DBCEB1354D508319548A7EFBD149BFA0E8D
7F501AEB51CE3232A979CCF0E11278346F746D1F

Compromised Windows Boot Manager

27AD0A8A88EAB01E2B48BA19D2AAABF360ECE5B8
8AB33E432C8BEE54AE759DFB5346D21387F26902

MITRE ATT&CK techniques

This table was built using version 9 of the MITRE ATT&CK framework.