This post was migrated from my older blog.
Here is a quick story on how I “broke BitLocker”.
We recently deployed the latest EMET to our client machines utilizing SCCM. Our machines never had EMET before, but the deployment was installing the software without issue. Shortly after the install, our clients started to receive new policies they never had before.
One of these new policies changes DEP. When DEP is configured, it changes a setting in the BIOS. This is bad, at least for us as we utilize BitLocker heavily. Changes to a machine’s hardware, OS, or BIOS baseline will cause BitLocker to prompt for a recovery key. The general fix for these kind of situations is to grab the machines recovery key and unlock the machine, then suspend and re-enable BitLocker. This causes BitLocker to acknowledge the new baseline. Unfortunately, that is a very manual process that we must now perform on all the machines. There is no real work around for this.
During all the turmoil this setting caused, we discovered a few of our users do not have BitLocker recovery passwords backed up anywhere. These users were unable to get into the machine, and the service desk couldn’t assist due to the keys not being backed up. We believed these users would loose their data.
I started to think about how to get back into these machines and it hit me. When you insert a CD into a BitLockered machine, it causes the BitLocker to prompt for a recovery password. However you don’t have to provide one if you remove the CD and reboot. By removing the CD, you effectively bring the machine back to it’s expected baseline. Since it is a BIOS change, I thought, what if we just change it back. I booted one of the affected machines into PXE, opened up the debug command prompt (If enabled in SCCM, press “F8”) and entered the following command to try and change the DEP setting back:
BCDEdit /Set nx
I then rebooted the machine and *poof* Windows loading logo appeared. We were able to save a few of our users from having an unfortunate week thanks to this trick.