Win 10 64-bit MBR Bootkit

[JMC31337]

Working on a bootkit rootkit for Win 10 64-bit MBR versions

All checksums and digital sig verifications have been bypassed

Dump all modifications as it goes along

This is completed Stage 1:

1) access bootmgr (compressed) via volume mount WMI API avoiding mounts

2) decompress bootmgr -> obtaining bootmgr.exe

3) patch the digital sig verifier

4) sig the exe with This program cannot be ran in ZZZ mode

5) patch the PE header checksum location with proper checksum

6) re-compress the bootmgr.exe -> bootmgr

7) overwrite the OS default bootmgr

=====

Ill explain more later, im tired

File password: infected

MBRBaby.rar

[JMC31337]

STAGE 2:

After modifying winload.exe in the same manner i.e., "cannot be ran in ZZZ mode" bootmgr triggered a second checksum/signature validiation

This is the portion of the code that changes the jns to jmp forcing bootmgr to accept winload despite its 0xC0000428 checksum triggering

//Mod up bootmgr checksum /sig validation for winload
                    //jns loc_420b05
                    //mov eax,[ebp+0x2c]

                    //change to
                    //jmp loc_420b05
                    //mov eax,[ebp+0x2c]
                    //eb 2c
                    //8b 45 2c


                    for (int z = 0; z < bmExeBuffer.Length; z++)
                    {

                        if (bmExeBuffer[z] == 0x79 && bmExeBuffer[z + 1] == 0x2C && bmExeBuffer[z + 2] == 0x8B && bmExeBuffer[z + 3] == 0x45 && bmExeBuffer[z + 4] == 0x2C)
                        {

                            bmExeBuffer[z] = 0xEB;


                        }
                    
                    }

the rar file is included below

If prior readings are correct (such as info here: http://alexhixon.com/projects/booty/booty.html) the next step would be modifications allowing unsigned driver loading

but im still looking into this for Win10 

MBRBaby_Stage2.rar

[JMC31337]

For stage 3 winload has to be patched in order to allow testsigning of drivers

similar to bcdedit /set testsigning on

Noticed in Bootkits and Rootkits a brief reference to 16000048h as a bcd option (which can be seen in winlaod.exe)

However, i noticed the Test Mode watermark and one byte patch to keep it from showing up and allow test signed (self signed) drivers to be loaded into the kernel

Tested with included KMDF driver and OSRLoader

Next step is to go about loading the driver without the use of a third party tools like OSRLoader

 Either by adding extra space into winload.exe or registry controlset 

 

 

MBRBaby_stage3.rar

Edited February 11, 2022 by JMC31337
Smaller Rar archive & cleaner C#

[JMC31337]

Thnx for the like it’s noted I did hard code directories n users into exe and sys driver - which will be fixed in final PoC release 

[JMC31337]

Stage 4: Another patch to allow modifications to ntoskrnl.exe (here again it’s been sig’s ZZZ)

 

noticed that setting the driver reg key to boot type will not work 

 

reversing the load process showed me an unsigned driver will be loaded every boot  when set automatic none (registry) with osrloader

 

This happens from within ntos so in order to try to bypass registry (if possible) the ‘PoC driver’ needs to be loaded from within ntoskernel api

 

Last stage step 5: trying to load the PoC driver every boot 

 

(Right click run as admin)

MBRBaby_stage4.rar

[JMC31337]

Stage 4 UPDATE

Got deep fast… smh lulz

read my source code comments for explanation 

This works for vm and main disk OS thus far  

 

Updated source 

Program.cs

[JMC31337]

Hang with me folks why I get this code tightened up for both VM and main disk OS… the above is so-so now that I notice it’ll play nice with VM and gets buggy down the road later steps for main disk

 trying to get this to be a universal win10 64 mbr

[JMC31337]

Stage 4 Final

post updates if something new comes along 

 

Program.cs

Edited March 5, 2022 by JMC31337
Cleaner code

[JMC31337]

Before moving to stage 5 a little recap explanation:

For win10 there’s a bootmgr a winload and ntoskrnl doing main heavy loading 

 

recommend bootkits and rootkits as a good book reference for a good start reference 

 

BOOTMGR

I had to use bochs do reverse bootmgr and in order to do that bootmgr must me accessed off the reserved partition

 grabbing access  to that was tricky and I decided to use wmi api to find that partition then use win32 createfile to access it through volume mount name instead of the typical physicaldisk seen for mbr access

it’s header holds all the sizes of the compressed bootmgr.exe and uncompressed size along with a checksum of the bootmgr.exe

this compression method has changed from os to os:

 

 ret = RtlDecompressBufferEx(4, bmExeBuffer, bmExeBuffer.Length, bmgrx, bmgrx.Length, ref dstsize, wspace); 

express huffman compressed (using a tool bmplus will make this ez (watch for fake copies,) but I needed an api myself and researched,  finding that in order to properly decompress this a ‘workspace’ buffer was needed and again, this required an api (tried to reverse bmplus but there was no easy string references and this was taking long time with bochs booting anyways so I decided to scrap the reversing and just research)

 using that xpresshuffman I uncompressed and i tagged the header with ZZZ and recalculated the checksum while finding all the security checks mcsft implemented for digital signature of winload 

bootmgr checks the checksum of winload and itself to see if they’ve been tampered and these had to be nop shot out

once done it’s tagged patched compressed self (bootmgr holds bootmgr.exe,) will load bootmgr.exe and load winload

Winload doesn’t care about bootmgr nor bootmgr.exe (actually each staged load cares less about its previous stage’s state)

winload will run a checksum of itself so that any modifications done to it flags a sig error and the checksum routine will compare results to its pe header checksum which is why it needs updated after any code changes (patches.)

winload goes out to see if any boot options (bcdedit stuff) are set and amongst those are the infamous test mode allowing unsigned drivers to be loaded 

additionally winload hold the flag for the watermark the OS puts into place to alert the user you’re wide open if an admin priv token comes along 

These had to be patched to allow test mode, disable watermark

winload also checks ntos for any checksum changes 

it also goes into depth looking at ntos pe header section table characteristics (sections denoting rwx locations once loaded into memory) any not meeting default standards for ntos flag an error so that had to be bypassed

This served as guidance a lil for winload- http://alexhixon.com/projects/booty/booty.html

This helped a lot with bochs debugging mbr and bootmgr - https://thestarman.pcministry.com/asm/mbr/index.html#Win7

This helps with ez high get privs as admin - http://www.mikeobrien.net/blog/taking-ownership-and-setting-admin

 

duscuss ntos later 

[JMC31337]

There’s a few ways to load drivers into ntos

for a real in depth explanation check out 

ntos allows EVC certificates signed by mcsft for extended verification for boot drivers, ntos has driver certification signing for normal drivers

Generally the registry key controlset loads drivers after ntos kicks off its boot drivers and this is most commonly used way

there was ways such as SYSTEM LOAD AND CALL IMAGE but that was old days and I haven’t even looked into too much for win10 (see eg Rootkits: Subverting the Windows Kernel)

my idea was now that all the driver security had been disabled and I’ve turned the first section into RWX I can execute code straight off the kernel (if you’re using windbg it’s ez to test this on an infected system nt+0xaf660) I figured let’s try stage 5 via storing the Unicode struct for the driver in that rwx section (there’s enough padded space to probably shove a lil driver as well if someone could find kernel api to map the driver into Loadimage kernel call,) hijack the ntos right before the os transition call (which fires off the profile session and login stuff,) and load the root kit as last driver (yes for most bang for the buck you want your driver load before any others because the first driver has first control but alas.)

Sure I could’ve grabbed the privs off the admin right click run and inserted the control set key pointing a driver hidden on disk and once the driver kicks in start using kernel api to hide keys n files from casual gui searching

But that’s too ez and been done all over

that’s the idea and more on this as I go

 

its noted of ya want the most secure free right to load unsigned driver remove the RWX section of the code and remove the 22 nips against the lock bit opcode (inside ntos,) and I may have blown too many holes who knows I gotta test this as well later

if anyone has anything to add please do share 

 

[Marius]

very nice

[JMC31337]

About to get better 

New stage 4 final 

here’s what happened 

my original shellcode location was in hal pointer table entries (took me month of first shutdown bsod to figure this out)

here’s the corrected stage 4 final

sorry i was lost in no land in a kernel full of undocumented stuff 

moving onward to a ZwOpenFile 

tested sleep hibernation lock logins shutdowns installed vs2022 

and stable as heck bbl

Program.cs

[JMC31337]

Stage 5

drop the sys driver into c:\
here’s the thing, vs2022 x64 doesn’t play _asm very nice so I had to go in there add the opcode into the sys driver 

suppose an array would’ve sufficed but whatever 

I decided to just nop-loop the driver (hence your logged in user won’t be able to delete it bcuz I’ll be sys locked)

the virus write the required opcode into ntos that loads the driver 

and fires off the remote thread of the driver (leave to the next person to irp callback or even call driver entry, miconstructloader is registry intensive so it was avoided)

the remote thread is the nop-loop

shellcode_api text file included for easy viewing

 

 

el fin

we own mcsft win 10 mbr (and loading stealth drivers from other drivers)

SHELLCODE_API_OPCODE.txt MBRBaby.rar