This has been ported over to my GitHub site and is not longer being maintained here. For any issues, comments or updates head here.
Scenario
The system had Full Disk Encryption (FDE) via McAfee SafeBoot and I had recently changed my Windows password but apparently
fat fingered it from what I thought I had changed it to which left me unable to
authenticate to Windows. The OS and SafeBoot were working properly and
I had valid credentials to login to the SafeBoot file system (SBFS)...this is because it used separate credentials from my Windows credentials.
Considerations
Even though I could authenticate to SafeBoot and decrypt the
OS, I wasn’t able to boot off of anything else (Kon-boot, Ophcrack etc.) after
authenticating to SafebBoot or prior to entering the SafeBoot environment.
Since my Windows passphrase was over 18 characters (don’t
ask me why) a dictionary attack wasn’t on the list of possible solutions. While rainbow tables were next on my list, LM
was turned off and the key space for my passphrase would have been too big to tackle. There
was the option to try and unlock it via FireWire (Inception) but since this was
a Windows 7 x64 with SP1 and 8 GB of memory it was unlikely to work in its release at that time.
Trials
In order to recover/troubleshoot SafeBoot you can use the WinTech
CD. Once you boot your system from
the WinTech CD the first thing that you must do is open up WinTech (start >
Programs > SafeBoot WinTech) and enter the daily access code.
After successfully authorizing yourself the next step is to
authenticate to SafeBoot. This can be
done three different ways:
Since I had valid credentials for this particular SafeBoot
group I chose the first option - to "Authenticate From SBFS". If all goes well you’ll see authorized and authenticated in
the bottom of the program.
You now have the ability to mount your decrypted file system and browse it with an explorer within the BartPE environment or from cmd. My first thought was to copy off the SAM and
SECURITY files but again, lack of LM hashes and my long passphrase were telling me nope, try another way.
As such, I decided to try the old Sticky Keys trick. For those of you who are unaware of what I
mean, Sticky Keys is an accessibility feature within Windows meant to allow a
user to be able to hold down two or more keys at a time when they would
otherwise be unable to. This feature is
enabled by default on Windows installations and is therefore highly reliable as
another option. To make sure this was a
possible solution I hit the ‘Shift’ key five times once I was at the Windows
login screen. If your settings haven’t
been altered and Sticky Keys is enabled you’ll be presented with:
By switching the Sticky Keys application with a command
prompt on the system you can take advantage of this feature and reset a local
user’s password or create a new local user.
Usually, this trick would be carried out by either booting the system
from a Windows installation disk and utilizing the recovery console or by
mounting the file system within a live Linux instance. The issue that came up again is that neither
of them would have sufficed since the OS file system would still be encrypted.
Resolution
Once I was authorized and authenticated to the SBFS I opened
cmd within WinTech and did the following:
- Created a copy of the Sticky Keys application:
> copy c:\Windows\system32\sethc.exe c:\Windows\system32\sethc.bak
1 file(s) copied. - Tried to replace the Sticky Keys application with a copy of the command prompt:
> copy /y c:\Windows\system32\cmd.exe c:\Windows\system32\sethc.exe
Access is denied.
0 file(s) copied.
The first time around I received an "Access Denied" error in this step, as depicted above. This is something I hadn't run into before because every time I had previously performed this trick I was working on a Windows XP system - but this time it was a Windows 7 system. After some troubleshooting I realized this error was due to enhanced protections on the System32 files that Windows 7 has over Windows XP...so the ownership/permissions on this file need to be modified. - Within SafeTech, Start > Programs > File Management > MS Explorer.
- Right click on sethc.exe > Properties > Security > Advanced
- Change the current owner (TrustedInstaller) to Administrators (in my case)
- Change the permissions of who you changed ownership to (Administrators in this example) to "full control"
- I attempted to replace the Sticky Keys application again with a copy of command prompt:
> copy /y c:\Windows\system32\cmd.exe c:\Windows\system32\sethc.exe
1 file(s) copied.
Victory! - Then, after a system restart I pressed the Shift key 5x at the Windows login. If all went well then the command prompt should now pop up and allow us to add a new user or reset an existing users password:
- At which point I could just do the first of those two, reset my Windows password:
> net user <username> <new password>
While not a super exciting post, it was something that I had to think about for a sec. and hopefully these little notes will help someone else out there if they ever run into the same situation.
