An attacker with physical access can abruptly restart the device and dump RAM, as analysis of this memory may reveal FVEK keys from recently running Windows instances, compromising data encryption.
The effectiveness of this attack is, however, limited because the data stored in RAM degrades rapidly after the power is cut off.
The script flashimage.sh creates a bootable USB device for a target system by flashing an image file onto the USB storage device, which must be larger than the target system’s RAM.
To minimize downtime, abruptly restart the target system during the Windows boot process, specifically before the login screen appears, as this approach has proven effective in scenarios involving the retrieval of Full Volume Encryption Keys (FVEKs).
Investigate Real-World Malicious Links, Malware & Phishing Attacks With ANY.RUN – Try for Free
To initiate the memory dump, boot the system from the USB drive containing the Memory-Dump-UEFI application. Navigate to and execute “app.efi” within the UEFI shell.
When this is complete, the application will proceed to generate dump files in a sequential fashion until all of the system memory has been processed.
Multiple memory dumps may exist due to FAT32’s 4GB file size limit so concatenate these dumps chronologically using the provided concatDumps tool and analyze the raw memory data within the dumps using xxd for human-readable output.
Make use of searchMem to locate specific hex patterns within the concatenated dump in an effective manner and to quickly jump to their offsets within the xxd output for the purpose of conducting additional research.
NoInitRD researcher investigated Windows kernel memory pools for cryptographic keys. While traditional pool tags like FVEc and Cngb were not found on Windows 11, the key was located in two alternative memory pools, indicating a shift in key storage practices within the operating system.
The FVEK key was primarily found under the dFVE pool tag, indicating its association with BitLocker drive encryption. The key’s presence was consistent and easily located, and the key was partially found under the None tag, suggesting its allocation through the ExAllocatePool routine.
The algorithm identifier, such as 0x8004, must be appended to the obtained key in little-endian format in order to unlock the BitLocker-protected partition.
Convert the resulting hexadecimal string to binary using xxd and save it to a file, and use the dislocker tools to determine the correct algorithm identifier and unlock the drive with the generated key file.
By kernel-level debugging with WinDbg, the researcher observed BitLocker operations during the Windows boot process, which revealed that while Microsoft attempts to erase encryption keys using functions like SymCryptSessionDestroy, some keys persist on the heap, potentially due to incomplete key destruction mechanisms.
Find this News Interesting! Follow us on Google News, LinkedIn, and X to Get Instant Updates!
