From zero to SYSTEM on full disk encrypted Windows system (Part 1)

Intro

Whether you want to protect the operating system components or your personal files, a Full Disk Encryption (FDE) solution allows you to keep track of the confidentiality and integrity. One of the most commonly used FDE solutions is Microsoft Bitlocker®, which due to its integration with the Trusted Platform Module (TPM) as well as the Active Directory environment makes it both user-friendly and manageable in a corporate environment.
When the system is protected with a FDE solution, without a pre-boot password, the login or lock screen makes sure attackers with physical access are not able to gain access to the system.
In this post we will explain how an attacker with physical access to an active directory integrated system (e.g. through stealing) is able to bypass the login or lock screen, obtain a clear-text version of the user’s password and elevate his privileges to that of a local administrator or SYSTEM. This can be accomplished via two security vulnerabilities which affects all Windows versions (from Vista to 10) and abusing a standard “security” feature.

These two vulnerabilities, discovered with the help of my colleague Tom Gilis were reported to Microsoft however only one vulnerability is patched at the time of writing (CVE-2016-0049 / MS16-014).
The other one, which allows you to elevate your privileges to that of a local administrator or SYSTEM is still under investigation by Microsoft and is not yet disclosed here.
Acknowledgement by Microsoft: https://technet.microsoft.com/en-us/library/security/mt674627.aspx

Step 1 – Hibernation – Your friendly neighbourhood password dumper

Speaking for myself, and probably a lot of other users, shutting down a laptop has become a thing of the past. In order to be able to rapidly start using your system when travelling from one place to another, we put it into sleep (or hibernation) mode, essentially putting all processes on hold to be easily resumed when needed.
Although in order to resume your session after sleep or hibernation, you’ll have to enter your password on the lock screen (or at least I hope so), the system has your password stored somewhere in memory in order to resume the different processes. We want the system to dump the contents of the memory on disk so we can recover it later. Hibernation is there to the rescue, but we need to be able to force the system into hibernation, creating the HIBERFIL.SYS.
Luckily, the default configuration of a laptop running Windows depicts going into hibernation if the battery hits a critical low. This feature, by default at set 5%, ensures you don’t lose any unsaved documents when your battery dies.

So the first step, in case the laptop is running but put in sleep (or hibernation), is letting the battery die by playing the waiting game...
Once we force the laptop into hibernation mode we reboot it and move to the next step.

Step 2 – Bypassing the login or lock screen

Before we move on, we would like to give credit to Ian Haken, who discovered the original vulnerability affecting Windows Authentication. He presented his findings at BlackHat Europe 2015 which inspired us to investigate further.
In order for the original attack to work, the following prerequisites should be met:

• The target machine is member of a Windows domain
• The domain user (the target) has previously logged into the machine and his password is cached locally
• (Optional however pointless without) Full Disk Encryption without any pre-boot authentication (e.g. BitLocker With TPM integration)

If these conditions were met, an attacker needed to create a rogue Kerberos server with the targets user account’s password set to a value of choice and indicated as expired.
Upon login attempt, Windows would then prompt the user to change the password before continuing.

Once the password change procedure is completed, the cached credentials on the machine are updated with the new password set by the attacker.
Because the system is not able to establish a secure connection, the password is not updated on the Kerberos server but still allows the attacker to login when the system no longer has an active network connection (using the cached credentials)

A pretty straight forward attack but the vulnerability has been out there for years overlooked by many people.
Now that the original vulnerability is clear, we want to explain how we managed to bypass this. (More information about the original vulnerability can be found in Ian’s whitepaper here.)
The original patch which was rolled out by Microsoft (KB3105256 - Microsoft Security Bulletin MS15-122) actually changes the flow of the password change feature. It first checks if there is a trust between the domain controller and the target machine before changing the password on the target machine.

We had to find a way to make the workstation believe the Kerberos server, in our case a rogue Windows domain controller with the same FQDN is a genuine one.
In a normal situation, when a computer joins a domain a computer object is created in the active directory which holds various attributes from this system. One of those is the Service-Principal-Name (SPN) attribute which is used for mutual authentication with an instance of a service on the workstation.
This SPN is the name by which a client uniquely identifies an instance of a service.
Knowing that this information is used to establish mutual authentication we created a computer object with the name of our target machine (which can be easily found). We then moved on to change the servicePrincipalName attribute by adding the following values:

• HOST/computername
• HOST/computername.domain

Now follow the same procedure as before (change the user’s password and mark it as expired) and you will be able to change the change the cached password. Disconnect the system from the network and use the newly set password to bypass the login screen and gain full access to the system as the original user.
Although the authentication has been bypassed, we still only have the (limited) privileges of the victim’s account (taking into consideration this is not an local administrator). This is where the next step comes in, in which we explain how you can obtain full local administrative privileges just by using standard Windows functionalities and thus not relying on any vulnerable installed software.

Step 3 – Privilege escalation to SYSTEM

At the time of writing, the vulnerability has not yet been patched by Microsoft and thus cannot be disclosed. Once more information can be safely shared, this post will be updated.
Read it here.