Analisi bootkit-rootkit della sfida Z2A-BlackLotus stage 2
Analisi del bootkit-rootkit stage 2 di BlackLotus
Prima di addentrarci in questa merda divina(credimi, questa è una merda divina perché nessuno può farlo senza la volontà di DIO(almeno questa è la mia opinione)) ,ecco l'hash del file bootkit
Prima di tutto, ecco come appare un sistema sano
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
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
Ora nella mia analisi non sono mai riuscito a infettare la mia macchina, quindi userò l'esempio del post del blog del ricercatore asiatico già citato, che è così che dovrebbe apparire una macchina infetta.```
// 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
=============================================================================
=============================================================================
Prima di iniziare, come si fa, comunque, a configurare l'ambiente per l'analisi di un modulo efi? Beh, il merito va a @MaverickMusic__, durante una discussione con lui mi ha passato questo( https://zhuanlan-zhihu-com.translate.goog/p/343293521?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-GB ). Non ho seguito completamente i passaggi di quel link, quindi ecco esattamente cosa ho fatto per avere l'ambiente operativo:
-Primo ho installato edk2(https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems)
-Secondo ho configurato il mio ovmf come debug e non release(questo ci aiuterà più avanti). Ecco il comando build -a X64 -t VS2019 -b DEBUG -p OvmfPkg/OvmfPkgX64.dsc
-Terzo ho dovuto configurare il mio windbg. Come diavolo ho fatto? Ho scaricato tutto da questo link(git clone https://github.com/microsoft/WinDbg-Samples). Poi ho compilato ExdiGdbSrv.sln. Poi ho seguito tutto da questo link(https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-qemu-kernel-mode-debugging-using-exdi), da dove diceva Use regsvr32 to register the DLL in an Administrator command prompt. fino a PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files". Lo so, è confuso, ma abbi pazienza, perché di sicuro farò un video in cui spiego ogni passaggio! Bene, ora che abbiamo un ambiente configurato per il debug, come diavolo facciamo a fare il debug del codice? Quindi avviamo qemu; nel mio caso l'ho fatto eseguendo qemu-system-x86_64.exe -L . -bios OVMF.fd -hdd dos.img -debugcon file:debug.log -global isa-debugcon.iobase=0x402. Una volta eseguito il comando di qemu, sono subito andato a selezionare compat_monitor0 dal menu View di qemu. Dovrebbe apparire così quando lo fai.
inoltre, dopo aver selezionato questo, dovresti digitare gdbserver per avviare un'istanza remota di gdb per il debug, alla quale ci collegheremo con windbg usando questo comando .\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64. Bene, una volta connessi, apparirà così
Quindi, per dare un senso a questo output, nel nostro caso l'unica riga rilevante è EntryPoint=0x000062C9A8C, che è come l'indirizzo di caricamento preferito ogni volta che eseguiamo il bootkit. Nello specifico per il bootkit varia tra 0x62C4A8C or 0x62C9A8C. Ora possiamo ribasare il programma in IDA e svolgere il nostro normale lavoro :) . Godetevi il resto del blog!
=============================================================================
Bindiffing del winload.efi originale con quello rilasciato da blacklotus