BlackLotus-analysis-stage2-bootkit-rootkit-stage

Análise do bootkit-rootkit do estágio 2 do BlackLotus

Antes de mergulharmos nesta merda divina (acredite, isto é uma merda divina, pois ninguém pode fazer isso sem a Vontade de DEUS (pelo menos essa é a minha opinião sobre isto)), aqui está o hash para o arquivo do bootkit

Antes de tudo, é assim que um sistema saudável se parece

``` 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

Agora, na minha análise, nunca consegui infectar minha máquina, então usarei o exemplo do post do blog do pesquisador asiático já referenciado, que é assim que um infectado deve parecer.```
    // 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 começarmos, como se configura o ambiente para a análise de um módulo efi afinal? Bem, os créditos vão para @MaverickMusic__ , durante uma discussão com ele ele me passou isto( https://zhuanlan-zhihu-com.translate.goog/p/343293521?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-GB ). Não segui completamente os passos de lá, então aqui está exatamente o que fiz para deixar o ambiente pronto e funcionando :

-Primeiro instalei o edk2(https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems)

-Segundo, configurei meu ovmf como debug e não release(isso nos ajudará mais tarde). Aqui está o comando build -a X64 -t VS2019 -b DEBUG -p OvmfPkg/OvmfPkgX64.dsc

-Terceiro, tive que configurar meu windbg. Como diabos eu fiz isso? Baixei tudo deste link(git clone https://github.com/microsoft/WinDbg-Samples). Então compilei ExdiGdbSrv.sln. Depois segui tudo deste link(https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-qemu-kernel-mode-debugging-using-exdi), desde onde dizia Use regsvr32 to register the DLL in an Administrator command prompt. até PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files". Confuso, eu sei, mas por favor aguarde com paciência, pois com certeza farei um vídeo explicando cada passo! Legal, agora que temos um ambiente configurado para depuração, como diabos depuramos o código? Então iniciamos o qemu; no meu caso, executei qemu-system-x86_64.exe -L . -bios OVMF.fd -hdd dos.img -debugcon file:debug.log -global isa-debugcon.iobase=0x402. Assim que executei o comando do qemu, fui imediatamente e selecionei compat_monitor0 no menu view do qemu. Deve ficar assim quando você fizer isso.

além disso, depois de selecionar isso, você deve digitar gdbserver para iniciar uma instância remota de depuração gdb à qual vamos nos anexar com o windbg usando este comando .\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 Legal, então assim que nos conectarmos, vai ficar assim

``` 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 ```

Muito legal, agora, para dar sentido a essa saída, no nosso caso a única linha relevante é EntryPoint=0x000062C9A8C, que é como o endereço de carregamento preferido sempre que executamos o bootkit. Especificamente para o bootkit, ele varia entre 0x62C4A8C or 0x62C9A8C. Agora podemos fazer o rebase do programa no ida e fazer nosso trabalho normal :) . Aproveite o resto do blog!

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

Fazendo BinDiff do winload.efi original com o que foi dropado pelo blacklotus