BlackLotus-analysis-stage2-bootkit-rootkit-stage

BlackLotus Stage-2-Bootkit-Rootkit-Analyse

Bevor wir in diese göttliche Scheiße eintauchen (glaub mir, das ist göttliche Scheiße, denn niemand kann das ohne Gottes Willen tun (zumindest ist das meine Meinung dazu)), hier ist der Hash für die Bootkit-Datei

Das Wichtigste zuerst: So sieht ein gesundes System aus

``` C:\Windows\system32>BCDEdit

Windows Boot Manager

identifier {bootmgr} device partition=\Device\HarddiskVolume9 path \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI description Windows Boot Manager locale en-US inherit {globalsettings} default {current} resumeobject {3f80ecd0-df10-11ed-bafc-80a84b2564bb} displayorder {current} toolsdisplayorder {memdiag} timeout 30

Windows Boot Loader

identifier {current} device partition=C: path \Windows\system32\winload.efi description Windows 10 locale en-US inherit {bootloadersettings} recoverysequence {3f80ecd2-df10-11ed-bafc-80a84b2564bb} displaymessageoverride Recovery recoveryenabled Yes isolatedcontext Yes allowedinmemorysettings 0x15000075 osdevice partition=C: systemroot \Windows resumeobject {3f80ecd0-df10-11ed-bafc-80a84b2564bb} nx OptIn bootmenupolicy Standard

Nun, in meiner Analyse gelang es mir nie, meinen Rechner zu infizieren, daher verwende ich das Beispiel aus dem bereits referenzierten Blogbeitrag des asiatischen Forschers, der zeigt, wie ein infizierter Rechner aussehen soll.```
    // Windows Boot Manager
    // --------------------
    // identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
    // description             Windows Boot Manager
    // locale                  en-US
    // inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
    // bootdebug               Yes
    // displayorder            {57e1b615-0355-11ec-abb0-005056c00008}
    // timeout                 30

    // Windows Boot Loader
    // -------------------
    // identifier              {57e1b615-0355-11ec-abb0-005056c00008}
    // device                  boot
    // path                    \system32\hvloader.efi
    // description             Hoy la disco se flota
    // locale                  en-US
    // inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
    // truncatememory          0x10000000
    // avoidlowmemory          0x1000
    // nointegritychecks       Yes
    // testsigning             Yes
    // isolatedcontext         Yes
    // osdevice                boot
    // systemroot              \
    // ems                     Yes

=============================================================================

=============================================================================

Bevor wir loslegen: Wie richtet man überhaupt die Umgebung für die Analyse eines EFI-Moduls ein? Nun, der Dank gebührt @MaverickMusic__ , während einer Diskussion mit ihm hat er mir das hier gegeben ( https://zhuanlan-zhihu-com.translate.goog/p/343293521?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-GB ). Nun, ich bin den Schritten dort nicht ganz gefolgt, also hier ist genau das, was ich getan habe, um die Umgebung zum Laufen zu bringen:

-Zuerst habe ich edk2 installiert(https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems)

-Zweitens habe ich mein ovmf als Debug konfiguriert, nicht als Release(das wird uns später helfen). Hier ist der Befehl build -a X64 -t VS2019 -b DEBUG -p OvmfPkg/OvmfPkgX64.dsc

-Drittens musste ich meinen windbg konfigurieren. Wie zum Teufel habe ich das gemacht? Ich habe alles von diesem Link heruntergeladen(git clone https://github.com/microsoft/WinDbg-Samples). Dann habe ich ExdiGdbSrv.sln kompiliert. Dann bin ich allem von diesem Link gefolgt(https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-qemu-kernel-mode-debugging-using-exdi), von der Stelle, an der Use regsvr32 to register the DLL in an Administrator command prompt. stand, bis zu PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files". Ich weiß, das ist verwirrend, aber bitte hab etwas Geduld, denn ich werde auf jeden Fall ein Video machen, in dem ich jeden Schritt erkläre! Cool, jetzt wo wir eine eingerichtete Umgebung zum Debuggen haben, wie zum Teufel debuggen wir den Code? Also starten wir QEMU – in meinem Fall habe ich es durch Ausführen von qemu-system-x86_64.exe -L . -bios OVMF.fd -hdd dos.img -debugcon file:debug.log -global isa-debugcon.iobase=0x402 . Sobald ich den QEMU-Befehl ausgeführt hatte, ging ich sofort und wählte compat_monitor0 aus dem View-Menü von QEMU. Es sollte so aussehen, wenn du das tust.

Außerdem solltest du nach der Auswahl gdbserver eingeben, um eine entfernte Instanz des GDB-Debugging zu starten, mit der wir uns mit windbg über diesen Befehl verbinden .\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 Cool, sobald wir uns verbunden haben, wird es so aussehen

``` So how do we set up a breakpoint in order to debug the bootkit? Well that's we we compiled the ovmf image as debug rather than release. If you specifically start qemu with that command you'll have qemu run and debug messages will be logged in a file called debug.log , which looks like this ```

So cool, um diesen Output zu verstehen: Für unseren Fall ist die einzige relevante Zeile EntryPoint=0x000062C9A8C, die so etwas wie die bevorzugte Ladeadresse ist, wenn wir das Bootkit ausführen. Speziell für das Bootkit variiert sie zwischen 0x62C4A8C oder 0x62C9A8C. Jetzt können wir das Programm in ida rebasen und unsere normale Arbeit erledigen :) . Genießt den Rest des Blogs!