Z2A-BlackLotus Challenge etapa 2 análisis de bootkit-rootkit
Análisis del bootkit-rootkit de la etapa 2 de BlackLotus
Antes de sumergirnos en esta mierda divina (créeme, esto es mierda divina ya que nadie puede hacer esto sin la Voluntad de DIOS (al menos esa es mi opinión al respecto)) ,aquí está el hash del archivo bootkit
Primero lo primero, así es como se ve un sistema saludable
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
Ahora, en mi análisis, nunca logré infectar mi máquina, así que usaré el ejemplo de la publicación del blog del investigador asiático ya referenciado, que es así como se supone que se ve una infectada.```
// 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
=============================================================================
=============================================================================
Antes de comenzar, ¿cómo se configura el entorno para el análisis de un módulo efi? Bueno, el crédito es para @MaverickMusic__ , durante una discusión con él me pasó esto( https://zhuanlan-zhihu-com.translate.goog/p/343293521?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-GB ). Ahora no seguí completamente los pasos de ahí, así que esto es exactamente lo que hice para tener el entorno funcionando :
-Primero instalé edk2(https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems)
-Segundo, configuré mi ovmf como debug, no release (esto nos ayudará más adelante). Aquí está el comando build -a X64 -t VS2019 -b DEBUG -p OvmfPkg/OvmfPkgX64.dsc
-Tercero tuve que configurar mi windbg. ¿Cómo demonios hice esto? Descargué todo desde este enlace(git clone https://github.com/microsoft/WinDbg-Samples). Luego compilé ExdiGdbSrv.sln. Después seguí todo desde este enlace(https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-qemu-kernel-mode-debugging-using-exdi), desde donde decía Use regsvr32 to register the DLL in an Administrator command prompt. hasta PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files". Sé que es confuso, pero ten paciencia, ¡definitivamente haré un video donde explicaré cada paso! Bien, ahora que tenemos un entorno configurado para depuración, ¿cómo demonios depuramos el código? Entonces iniciamos qemu; en mi caso lo hice ejecutando qemu-system-x86_64.exe -L . -bios OVMF.fd -hdd dos.img -debugcon file:debug.log -global isa-debugcon.iobase=0x402 . Una vez ejecuté el comando de qemu, fui inmediatamente y seleccioné compat_monitor0 desde el menú view de qemu. Debería verse así cuando haces eso.
también después de seleccionar esto, debes ingresar gdbserver para iniciar una instancia remota de depuración de gdb a la que nos adjuntaremos con windbg usando este comando .\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 Bien, una vez que nos conectemos, se verá así
Bien, ahora para darle sentido a esta salida, en nuestro caso la única línea relevante es EntryPoint=0x000062C9A8C, que viene a ser la dirección de carga preferida cuando ejecutamos el bootkit. Específicamente para el bootkit varía entre 0x62C4A8C or 0x62C9A8C. Ahora podemos reubicar el programa en ida y hacer nuestro trabajo normal :) . ¡Disfrutad el resto del blog!
=============================================================================
Bindiffing del winload.efi original con el que suelta BlackLotus