Z2A-BlackLotus Challenge: анализ bootkit-rootkit, этап 2
Анализ bootkit-rootkit второй стадии BlackLotus
Прежде чем мы окунёмся в эту божественную хрень (поверьте, это действительно божественная хрень, так как никто не может сделать это без Воли Бога (по крайней мере, таково моё мнение)) ,вот хэш файла буткита
Прежде всего, вот как выглядит здоровая система
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
Теперь, что касается моего анализа: мне так и не удалось заразить свою машину, поэтому я воспользуюсь примером из уже упомянутого поста в блоге азиатского исследователя, где показано, как должна выглядеть заражённая машина.```
// 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
=============================================================================
=============================================================================
Прежде чем мы начнём, как вообще настроить окружение для анализа EFI-модуля? Что ж, спасибо @MaverickMusic__ , в ходе обсуждения с ним он передал мне это( https://zhuanlan-zhihu-com.translate.goog/p/343293521?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-GB ). Я не полностью следовал шагам оттуда, так что вот что именно я сделал, чтобы поднять окружение:
-Во-первых, я установил edk2(https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems)
-Во-вторых, я настроил свой ovmf в режиме debug, а не release(это поможет нам позже). Вот команда build -a X64 -t VS2019 -b DEBUG -p OvmfPkg/OvmfPkgX64.dsc
-В-третьих, мне нужно было настроить windbg. Как, чёрт возьми, я это сделал? Я скачал всё по этой ссылке(git clone https://github.com/microsoft/WinDbg-Samples). Затем я скомпилировал ExdiGdbSrv.sln. Затем я следовал всему из этой ссылки(https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-qemu-kernel-mode-debugging-using-exdi), от того места, где было сказано Use regsvr32 to register the DLL in an Administrator command prompt. до PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files". Понимаю, это запутанно, но, пожалуйста, подождите терпеливо, я обязательно сделаю видео, где объясню каждый шаг! Круто, теперь, когда у нас есть настроенное окружение для отладки, как, чёрт возьми, мы отлаживаем код? Итак, запускаем qemu, в моём случае я сделал это, выполнив qemu-system-x86_64.exe -L . -bios OVMF.fd -hdd dos.img -debugcon file:debug.log -global isa-debugcon.iobase=0x402 . Как только я выполнил команду qemu, я сразу перешёл и выбрал compat_monitor0 в меню view в qemu. Когда вы это сделаете, это должно выглядеть так.
Также после выбора этого вам нужно ввести gdbserver, чтобы запустить удалённый экземпляр отладки gdb, к которому мы подключимся с помощью windbg, используя эту команду .\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64. Круто, как только мы подключимся, это будет выглядеть так
Так, теперь разберёмся с этим выводом. В нашем случае единственная значимая строка — EntryPoint=0x000062C9A8C, это что-то вроде предпочтительного адреса загрузки при запуске буткита. Для данного буткита он варьируется между 0x62C4A8C or 0x62C9A8C. Теперь можно переопределить базу программы в IDA и заниматься обычной работой :) . Наслаждайтесь остальной частью блога!
=============================================================================
Сравниваем через BinDiff оригинальный winload.efi с тем, который оставляет BlackLotus