mjdxpwho is your #BestFediFriend? mine is probably @shodansafari
| plan.cat | https://plan.cat/~morb |
| github | https://github.com/m0rb |
@morb
- 619 Followers
- 190 Following
- 2.4K Posts
DEFILE_ID.DIZ
deletgit@da_667 I'm surprised *there aren't a myriad of beyond-invasive tuber and root veg species
Rairii 
hi everyone
given one #bitlocker #0day is already out there, here's my own bitlocker 0day, I added it to my repo listing bitlocker attacks.
Introducing "ram leak": https://github.com/Wack0/bitlocker-attacks#ram-leak
As we all know, the boot environment allows booting from a ramdisk. This involves loading a file from disk into RAM, as expected.
However, "file" and "disk" can be arbitrarily chosen, and "disk" being a BitLocker encrypted partition is a supported scenario. Using another trick (same one used with bitpixie earlier) it's possible to get the keys derived without going through the legacy integrity validation checks too if relevant.
You can see where this is going. It's possible to leak any file from a bitlocker encrypted OS partition into RAM as long as you can get the keys derived (ie, TPM-only scenario).
The catch is that booting into the NT kernel marks that memory area as free so it could get overwritten there, but there are other ways to dump the memory area, and a PoC is included with my preferred method (it's only a PoC so just displays a hexdump of the first sector of the file)
The video shows successful exploitation in my test VM, it has secure boot enabled (you can tell because VMware shows an efi shell option on the boot menu when secure boot is disabled).
#infosec #windows
given one #bitlocker #0day is already out there, here's my own bitlocker 0day, I added it to my repo listing bitlocker attacks.
Introducing "ram leak": https://github.com/Wack0/bitlocker-attacks#ram-leak
As we all know, the boot environment allows booting from a ramdisk. This involves loading a file from disk into RAM, as expected.
However, "file" and "disk" can be arbitrarily chosen, and "disk" being a BitLocker encrypted partition is a supported scenario. Using another trick (same one used with bitpixie earlier) it's possible to get the keys derived without going through the legacy integrity validation checks too if relevant.
You can see where this is going. It's possible to leak any file from a bitlocker encrypted OS partition into RAM as long as you can get the keys derived (ie, TPM-only scenario).
The catch is that booting into the NT kernel marks that memory area as free so it could get overwritten there, but there are other ways to dump the memory area, and a PoC is included with my preferred method (it's only a PoC so just displays a hexdump of the first sector of the file)
The video shows successful exploitation in my test VM, it has secure boot enabled (you can tell because VMware shows an efi shell option on the boot menu when secure boot is disabled).
#infosec #windows