Not possible to recover the VMK using WinPE based attack

[dummys]

Hello,
I'm testing your version based on the winpe, everything works until I get the image of the memory, searchvmk didn't yield result.
My os is Win 11 24H2 enterprise. I tried to dump the memory of the booted computer and logedin, I was able to recover VMK using the searchvmk tool.
I checked the bootloader in the computer, and it is still signed with 2011 certificate, so wondering why attacks didn't work. Any idea on how I can debug it ?
Is it possible that Win 11 24H2 wipe VMK from memory when booting WinPE ?

[martanne]

Hi, thanks for giving it a try.

I also noticed that the WinPE-based approach seems to be less reliable than its Linux-based counterpart.
It definitely works in principle, here is a screenshot of a successful execution:

Is it possible that Win 11 24H2 wipe VMK from memory when booting WinPE ?

Because it works sometimes, I don't think this is the case in general. But maybe it just happens under certain conditions?

As for debugging, I tried to simplify my setup as much as possible:

• avoiding GDB automation
• using default Windows 11 based WinPE instead of a customized one

However, whenever I had an assumption what the issue might be, a few reboots later this was falsified.

Sofar I mostly tried it on real hardware. A more structured approach might be to test it in a virtual setting, set appropriate breakpoints on the sensitive memory regions and investigate whether:

1. the key is loaded as expected
2. the key is unexpectedly cleared/overwritten and by what component

[dummys]

I tried to do on real hardware only as well.Do you think winPE car overwrite the key in memory when loaded ?

[martanne]

Could you please check, whether the latest commits make a difference?

[BigPanda71]

Having the same problem with a Lenovo IdeaPad 7. I need to check the SecureBoot certificate in the morning to rule out that being the issue, but I’m wondering if it has anything to do with the total RAM in the machine (which I also have to check tomorrow). Maybe with more RAM the key will sit somewhere untouched by the WinPE that’s running. Just a thought, so I’m curious how much RAM the machines you’re testing have.

Unfortunately the Linux boot freezes on Secure Boot Enabled, so I’m guessing I don’t have the third party certs to rely on that method.

[dummys]

for me it is not freezing, I get an error when third party CA is not here. I'm trying the new version of winpmem now.
I tried the newer version, and It seems that I have some vmk files, but the diskpart is failing now, it said there is no fixed disk ?
and winpmem finish with a vmk.dat of 0 size.
Now trying to use winpmem to dump full memory, and grep for my key to see if it is already inside.

[BigPanda71]

Have you tried using something like Magnet RAM Capture on an external drive in WinPE to get a full dump? I think that's what I'm going to try and see if I can find the key in the dump

[martanne]

@BigPanda71 the device I'm using has ~24 GB RAM.

Before recently switching to the WinPmem approach, I used DumpIt to dump the whole memory and then search for the VMK with the little standalone utility.

[dummys]

I tried both, and I don't have the key on both

[0x6d69636b]

I can confirm that the WinPE approach is less reliable. I tried it on a Lenovo ThinkPad X1 Carbon Gen 9 running Windows 11 24H2, but I couldn't find the VMK key

[gosec-rr]

Using WinPE I was able to receive the VMK on my Hyper-V Windows WM running on a HP ZBook Firefly AMD. On all other computers I wasnt ablte to get the VMK.

Coould there be any issues with the size of WinPE which are approx. 500MB, compared to Linux it's much more and therefore may overwrite memory?

[JustMichi]

Hi there @martanne,

I'd also like to contribute with some information to this amazing project:

• Tried on a HP ProBook 450 G10 without success:
  -> The Linux variant doesn't work at all (crashes with 0x0...0ba) -> It searches the stl-file and before that all the other s7b files are not found - I think this is what you mentioned in other posts about the missing trust to third parties. So I think the only exploit-way would be windows?
  -> The windows variant boots into the recovery environment but doesn't find the VMK.
• The README/documentation has a pitfall: After rebooting you can't have a guaranteed entry in the recovery environment with CMD as some bitlocker variants seem to disable that environment. So you HAVE to boot from a stick instead to create the initial BCD (with the exploit-windows1.bat). Maybe it's sensible to add that information in the readme? :)
• We wanted to manually search the RAM for fragments of the bitlocker key offline to analyze if maybe only part of it gets stored and the rest could, e.g., be bruteforced. But we can't dump the RAM, neither on a large enough stick, nor in the live recovery environment. Probably because it's too large (16GB).
  Thus, I second the theory of gosec-rr that at least some part of the key gets overwritten by the windows bootloader.
  But to properly analyze this, I would need to have a working memory dump.
  My current idea is to modify winpmem to split the dump creation of the files into equal chunks (e.g. 4GB each) and then later merge them on my offline system to analyze them properly.
  Any further ideas / inputs?

Kind regards & keep up the fantastic work! 💯

[gosec-rr]

@JustMichi we dumped the memory after booting into WinPE and we couldn't find a VMK key.

We tried iPXE instead of PXE for faster speed, but then the vulnerability does not exist any more, also other bootloaders are not signed.

We are still trying to figure this out, but struggling. If you got any clues it would be appreciated.