Z2A-BlackLotus Challenge analyse du bootkit-rootkit de l'étape 2
BlackLotus stage 2 bootkit-rootkit analysis
Avant de plonger dans cette merde divine (croyez-moi, c'est de la merde divine, car personne ne peut faire ça sans la Volonté de DIEU (du moins c'est mon avis sur la question)), voici le hash du fichier bootkit
Tout d'abord, voici à quoi ressemble un système sain
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
Maintenant, dans mon analyse, je n'ai jamais réussi à infecter ma machine, donc j'utiliserai l'exemple du billet de blog du chercheur asiatique déjà référencé, qui montre à quoi est censé ressembler un appareil infecté.```
// 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
=============================================================================
=============================================================================
Avant de commencer, au fait, comment configurer l'environnement pour l'analyse d'un module EFI pour commencer ? Eh bien, merci à @MaverickMusic__ , lors d'une discussion avec lui, il m'a donné ceci( https://zhuanlan-zhihu-com.translate.goog/p/343293521?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-GB ). Je n'ai pas suivi les étapes telles quelles, alors voici exactement ce que j'ai fait pour mettre l'environnement en place :
-Premièrement, j'ai installé edk2(https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems)
-Deuxièmement, j'ai configuré mon ovmf en debug et non en release (cela nous aidera plus tard). Voici la commande build -a X64 -t VS2019 -b DEBUG -p OvmfPkg/OvmfPkgX64.dsc
-Troisièmement, j'ai dû configurer mon windbg. Comment diable ai-je fait ? J'ai téléchargé tout depuis ce lien(git clone https://github.com/microsoft/WinDbg-Samples). Puis j'ai compilé ExdiGdbSrv.sln. Ensuite, j'ai suivi tout ce qui est indiqué sur ce lien(https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-qemu-kernel-mode-debugging-using-exdi), depuis l'endroit où il était écrit Use regsvr32 to register the DLL in an Administrator command prompt. jusqu'à PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files". Je sais que c'est déroutant, mais soyez patient, car je vais certainement faire une vidéo où j'expliquerai chaque étape ! Bon, maintenant que nous avons un environnement configuré pour le débogage, comment diable déboguer le code ? On démarre donc qemu ; dans mon cas, je l'ai fait en exécutant qemu-system-x86_64.exe -L . -bios OVMF.fd -hdd dos.img -debugcon file:debug.log -global isa-debugcon.iobase=0x402 . Aussitôt la commande qemu exécutée, je suis allé sélectionner compat_monitor0 dans le menu View de qemu. Cela devrait ressembler à ceci lorsque vous faites cela.
aussi, après avoir sélectionné cela, vous devez saisir gdbserver pour démarrer une instance distante de gdb, à laquelle nous nous attacherons avec windbg à l'aide de cette commande .\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 Cool, une fois que nous nous y connectons, cela ressemblera à ceci
Trop bien, maintenant, pour donner un sens à cette sortie, dans notre cas la seule ligne pertinente est EntryPoint=0x000062C9A8C qui est en quelque sorte l'adresse de chargement préférée chaque fois qu'on exécute le bootkit. Plus précisément, pour le bootkit, elle varie entre 0x62C4A8C or 0x62C9A8C. On peut maintenant rebaser le programme dans IDA et faire notre travail habituel :) . Profitez du reste du blog !