What to remove to prevent being mounted in Virtual Machines?

O

OpenSource Ghost

Member
Ehanced BitLocker PIN + TPM + SecureBoot and 3rd party drive encryption tools with pre-boot authentication (BestCrypt or VeraCrypt or DiskCryptor) are typical solutions that can prevent attacker from successfully mounting victim's OS image on attacker's machine. In case attacker uses Virtual Machine on his/her PC/laptop to mount victim's OS image, what components can NTLite remove from victim's OS image to make such image as incompatible with being mounted on VM's as possible?

For example, some VM's rely on legacy drivers that victim's OS image may not need, but attacker's VM requires. Microsoft AHCI driver is not needed at by those running OS on Intel VMD RAID 19.X drivers, but many VM's do not support Intel VMD drivers.

Are there other components NTLite can remove to make OS images un-mountable in QuebesOS VM's or Docker VM's?
 
Can you explain or link to it, how does one uses a Virtual Machine to mount victim's OS image without the encryption key for it - to run that OS with the VM to begin with?
 
There's several points of confusion here.

1. Data can be read from any mounted disk volume, whether physical or virtual disk, without booting in another VM. This is why volume-level encryption from BitLocker or other software is required to deny access.

2. Any running VM sits on top of the host OS platform. Your VM doesn't require AHCI or RAID drivers, because it's not reading from a physical device unless the host OS is doing a pass-thru of a mapped local disk. Your host OS is mounting underlying disks through its host-level drivers, and providing the hosted VM access through the virtual disk layer.

3. Docker images are not complete OS images, but an application container. Containers are a form of virtualization for running pre-installed application stacks, but they're not bootable. This isn't a true virtual machine, it's more like a virtual host session.

Breaking a VM so it doesn't boot is a different thing from protecting a VM content's from being read.
 
I understand that data can be read from any decrypted disk volume, but can any decrypted Windows OS installation/instance be mounted to run inside VM on a different machine with different hardware and impersonate/clone the original machine 1:1???

I only have experience with VirtualBox and it does not mount Windows 10/11 images that require unsupported specialized drivers to boot and run the OS when similar legacy drivers are removed from OS images via NTLite in offline mode before OS is deployed. I can still get the data if encryption is not used and VM is not needed for that, but I can't mount the cloned OS to run on different hardware in VirtualBox VM if boot disk cannot load OS with legacy/generic drivers.

Intel VMD 19.X is just an example. If Windows OS 10/11 (with Intel VMD drivers pre-integrated) is installed on a machine with Intel VMD enabled in UEFI before OS is deployed, then disabling Intel VMD in UEFI in the future prevents machine from booting/loading installed OS. Trying to do so results in "Unsupported Boot Device" BSOD. Plain AHCI drivers cannot be used to load Windows 10/11 OS installed on Intel VMD. If VM environmentbdoes not support Intel VMD drivers, then it cannot mount OS installed on Intel VMD volume and emulate/mimic original machine.
 
VirtualBox and VMware are virtual machine emulators, not hypervisors. They can't pass thru VMD physical access, so VMD drivers have zero meaning in those environments.

VMD drivers themselves are a separate nightmare, regardless of whether you use NTLite. This is made clear from by all the complaints from the experienced IT community. Read all the Reddit comments out there.

Intel's current-gen VMD drivers are ass. Either you have to jump through their exact hoops, or admit defeat and disable RAID mode (resorting to normal AHCI drivers). If you're not using VMD for RAID, then you decide if it's worth following their arcane instructions to get a working image.

From what others have posted online, injecting VMD drivers can break non-VMD (AHCI) controller support.

My point is neither NTLite or VirtualBox is a contributing factor in this mess.
 
garlin said:
VirtualBox and VMware are virtual machine emulators, not hypervisors. They can't pass thru VMD physical access, so VMD drivers have zero meaning in those environments.

VMD drivers themselves are a separate nightmare, regardless of whether you use NTLite. This is made clear from by all the complaints from the experienced IT community. Read all the Reddit comments out there.

Intel's current-gen VMD drivers are ass. Either you have to jump through their exact hoops, or admit defeat and disable RAID mode (resorting to normal AHCI drivers). If you're not using VMD for RAID, then you decide if it's worth following their arcane instructions to get a working image.

From what others have posted online, injecting VMD drivers can break non-VMD (AHCI) controller support.

My point is neither NTLite or VirtualBox is a contributing factor in this mess.
Click to expand...
I think I have more to learn about virtualization to underatand it correctly.

As far as Intel VMD goes, it simply requires Intel VMD drivers to be integrated into OS offline before installation and once OS is installed, you can't boot OS disk through AHCI drivers. RAID enablement is not required for VMD to force drives under its mapping and prevent AHCI from working on boot disks if OS is installed when VMD was enabled.

Thank you for a prompt response!
 
You must log in or register to reply here.
Back
Top