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

Command ID Description URL
1 or 4 Exit. -
2 Upload various system info (CPU name, OS version, memory size, ethernet MAC address, list of installed software, etc.) to the predefined URL using the HTTP POST. https://<ip>/GetSysteminfo.aspx
3 Download or download and execute file into one of the predefined locations (listed in IoCs ) from the predefined URL using HTTP GET. https://<ip>/UpLoad.aspx?ti=<drive_ID>
5 Restart PC via ExitProcess (for Windows Vista only). N/A
6 Download new configuration from the predefined URL using HTTP GET and save it in the registry. https://<ip>/ModifyIpaddr.aspx?ti=<drive_ID>

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

Command ID Beschreibung
0x0000 Backdoor stoppen.
0x0064 Von C&C empfangene Befehlszeile ausführen und Ausgabe mit Pipes erfassen.
0x00C8 Befehle für Abmeldung, Abschaltung, Neustart oder Herunterfahren ausführen, abhängig vom Wert des Parameters dieses C&C-Befehls.
0x012C Je nach Wert des Parameters einen Screenshot des Vordergrundfensters oder einen vollständigen Screenshot machen, oder die Parameter für die automatische Screenshot-Erstellung ändern.
0x0190 führt verschiedene Dateisystemoperationen aus.
0x01F4 Gesammelte Daten und Dateien hochladen.
0x0258 führt verschiedene servicebezogene Befehle aus.
0x02BC führt verschiedene prozessbezogene Befehle aus.
0x0320 Konfigurationswerte ändern.
0x0384 Keylogger stoppen/starten, abhängig vom Wert des Parameters.

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.

Tactic ID Name Description
Execution T1106 Native API ESPecter leverages several Windows APIs: VirtualAlloc , WriteProcessMemory, and CreateRemoteThread for process injection.
Persistence T1542.003 Pre-OS Boot: Bootkit ESPecter achieves persistence by compromising Windows Boot Manager (bootmgfw.efi) located on the ESP, or by modifying the MBR on Legacy Boot systems.
T1547 Boot or Logon Autostart Execution ESPecter replaces the legitimate null.sys or beep.sys driver with its own malicious one in order to be executed on system startup.
Defense Evasion T1055.001 Process Injection: Dynamic-link Library Injection ESPecter’s driver injects its main user-mode components into svchost.exe and winlogon.exe processes.
T1564.001 Hide Artifacts: Hidden Files and Directories ESPecter’s Client.dll component creates hidden directories to store collected data.
T1564.005 Hide Artifacts: Hidden File System ESPecter bootkit installers for Legacy Boot versions use unallocated disk space located right after the MBR to store its code, configuration and malicious driver.
T1140 Deobfuscate/Decode Files or Information ESPecter uses single-byte XOR with subtraction to decrypt user-mode payloads.
T1562 Impair Defenses ESPecter patches Windows kernel function directly in memory to disable Driver Signature Enforcement (DSE).
T1036.003 Masquerading: Rename System Utilities ESPecter bootkit installers for Legacy Boot versions copy cmd.exe to con1866.exe to evade detection.
T1112 Modify Registry ESPecter can use DefaultConfig value under HKLM\SYSTEM\CurrentControlSet\Control to store configuration.
T1601.001 Modify System Image: Patch System Image ESPecter patches various functions in Windows Boot Manager, Windows OS loader and OS kernel directly in memory during the boot process.
T1027.002 Obfuscated Files or Information: Software Packing ESPecter’s WinSys.dll component is packed using the MPRESS packer.
T1542.003 Pre-OS Boot: Bootkit ESPecter achieves persistence by modifying Windows Boot Manager (bootmgfw.efi) located on the ESP or by modifying the MBR on Legacy Boot systems.
T1553.006 Subvert Trust Controls: Code Signing Policy Modification ESPecter patches Windows kernel function SepInitializeCodeIntegrity directly in memory to disable Driver Signature Enforcement (DSE).
T1497.003 Virtualization/Sandbox Evasion: Time Based Evasion ESPecter’s WinSys.dll component can be configured to postpone C&C communication after execution or to communicate with the C&C only in a specified time range.
Credential Access T1056.001 Input Capture: Keylogging ESPecter has a keylogging capability.
Discovery T1010 Application Window Discovery ESPecter’s Client.dll component reports foreground window names along with keylogger information to provide application context.
T1083 File and Directory Discovery ESPecter’s Client.dll component can list file information for specific directories.
T1120 Peripheral Device Discovery ESPecter’s Client.dll component detects the insertion of new devices by listening for the WM_DEVICECHANGE window message.
T1057 Process Discovery ESPecter’s Client.dll component can list running processes and their loaded modules.
T1012 Query Registry ESPecter’s WinSys.dll component can check for installed software under the Registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall.
T1082 System Information Discovery ESPecter user-mode payloads can collect system information from the victim’s machine.
T1124 System Time Discovery ESPecter’s WinSys.dll component can use GetLocalTime for time discovery.
Collection T1119 Automated Collection ESPecter’s Client.dll component can automatically collect screenshots, intercepted keystrokes and various files.
T1025 Data from Removable Media ESPecter’s Client.dll component can collect files with specified extension from removable drives.
T1074.001 Data Staged: Local Data Staging ESPecter’s Client.dll component stores automatically collected data into a hidden local directory.
T1056.001 Input Capture: Keylogging ESPecter has keylogging functionality.
T1113 Screen Capture ESPecter’s Client.dll component has screen capture functionality.
Command and Control T1071.001 Application Layer Protocol: Web Protocols ESPecter’s WinSys.dll component communicates with its C&C server over HTTPS.
T1573.001 Encrypted Channel: Symmetric Cryptography ESPecter’s Client.dll component encrypts C&C traffic using single-byte XOR.
T1105 Ingress Tool Transfer ESPecter’s user-mode components can download additional payloads from C&C.
T1104 Multi-Stage Channels ESPecter’s user-mode components use separate C&C channels.
T1095 Non-Application Layer Protocol ESPecter’s Client.dll component uses TCP for C&C communication.
Exfiltration T1020 Automated Exfiltration ESPecter’s Client.dll component creates a thread to automatically upload collected data to the C&C.
T1041 Exfiltration Over C2 Channel ESPecter exfiltrates data over the same channel used for C&C.
T1029 Scheduled Transfer ESPecter’s Client.dll component is set to upload collected data to the C&C every five seconds.