Recently, I was conducting a security policy audit of a mid-size tech company and asked if they were using any form of disk encryption on their employee’s workstations. They were not, however they pointed me to a policy document that required all “sensitive” files to be stored in an encrypted folder on the User’s desktop. They assumed that this was adequate protection against the files being recovered should the laptop be lost or stolen.
Unfortunately, this is not the case. Without full disk encryption (like BitLocker), sensitive system files will always be available to an attacker, and credentials can be compromised. Since Windows file encryption is based on user credentials (either local or AD), once these creds are compromised, an attacker would have full access to all “encrypted” files on the system. I will outline an attack scenario below to stress the importance of full drive encryption.
If you are not familiar, Windows has a built in file encryption function called Encrypting File System (EFS) that has been around since Windows 2000. If you right click on a file or folder and go to Properties->Advanced you can check a box called “Encrypt contents to secure data”. When this box is checked, Windows will encrypt the folder and its contents using EFS, and the folder or file will appear green in Explorer to indicate that it is protected:
Now only that user will be able to open the file. Even Administrators will be denied from viewing it. Here a Domain Admin (‘God’) is attempting to open the encrypted file that was created by a normal user (‘nharpsis’):
According to Microsoft’s TechNet article on EFS, “When files are encrypted, their data is protected even if an attacker has full access to the computer’s data storage.” Unfortunately, this is not quite true. The encrypted file above (“secret.txt”) will be decrypted automatically and viewable whenever ‘nharpsis’ logs in to the machine. Therefore to view the files, an attacker only needs to compromise the ‘nharpsis’ account.
In this attack scenario, we will assume that a laptop has been lost or stolen and is powered off. There are plenty of ways to mount an online attack against Windows or extract credentials and secret keys straight from memory. Tools like mimikatz or the Volatility Framework excel at these attacks.
For a purely offline attack, we will boot from a live Kali Linux image and mount the Windows hard drive. As you can see, even though we have mounted the Windows partition and have read/write access to it, we are unable to view files encrypted with EFS:
Yes you read that right. We are root and we are seeing a “Permission denied”.
Commercial forensic tools like EnCase have functionality to decrypt EFS, but even they require the username and password of the user who encrypted it. So the first step will be to recover Ned Harpsis’s credentials.
There are numerous ways to recover or bypass local accounts on a windows machine. SAMDUMP2 and ‘chntpw’ are included with Kali Linux and do a nice job of dumping NTLM hashes and resetting account passwords, respectively. However, in this instance, and the instance of the company I was auditing, these machines are part of a domain and AD credentials are used to log in.
Windows caches domain credentials locally to facilitate logging in when the Domain Controller is unreachable. This is how you can log in to your company laptop when traveling or on a different network. If any domain user, including admins, have logged in to this machine, his/her username and a hash of his password will be stored in one of the registry hives.
Kali Linux includes the tool ‘cachedump’ which is intended to be used just for this purpose. Cachedump is part of a larger suite of awesome Python tools called ‘creddump’ that is available in a public svn repo: https://code.google.com/p/creddump/
Unfortunately, creddump has not been updated in several years, and you will quickly realize when you try to run it that it does not work on Windows 7:
This is a known issue and is discussed on the official Google Code project.
As a user pointed out, the issue persisted over to the Volatility project and an issue was raised there as well. A helpful user released a patch file for the cachedump program to work with Windows 7 and Vista.
After applying the patches and fixes I found online, as well as some minor adjustments for my own sanity, I got creddump working on my local Kali machine.
For convenience’s sake, I have forked the original Google Code project and applied the patches and adjustments. You can find the updated and working version of creddump on the Neohapsis Github:
Now that I had a working version of the program, it was just a matter of getting it on to my booted Kali instance and running it against the mounted Windows partition:
Bingo! We have recovered two hashed passwords: one for ‘nharpsis’, the user who encrypted the initial file, and ‘god’, a Domain Admin who had previously logged in to the system.
Cracking the Hashes
Unlike locally stored credentials, these are not NT hashes. Instead, they are in a format known as ‘Domain Cache Credentials 2′ or ‘mscash2′, which uses PBKDF2 to derive the hashes. Unfortunately, PBKDF2 is a computation heavy function, which significantly slows down the cracking process.
Both John and oclHashcat support the ‘mscash2′ format. When using John, I recommend just sticking to a relatively short wordlist and not to pure bruteforce it.
If you want to attempt to use a large wordlist with some transformative rules or run pure bruteforce, use a GPU cracker with oclHashcat and still be prepared to wait a while.
To prove that cracking works, I used a wordlist I knew contained the plaintext passwords. Here’s John cracking the domain hashes:
Note the format is “mscash2″. The Domain Admin’s password is “g0d”, and nharpsis’s password is “Welcome1!”
I also extracted the hashes and ran them on our powerful GPU cracking box here at Neohapsis. For oclHashcat, each line must be in the format ‘hash:username’, and the code for mscash2 is ‘-m 2100′:
Accessing the encrypted files
Now that we have the password for the user ‘nharpsis’, the simplest way to retrieve the encrypted file is just to boot the laptop back into Windows and log in as ‘nharpsis’. Once you are logged in, Windows kindly decrypts the files for you, and we can just open them up:
As you can see, if an attacker has physical access to the hard drive, EFS is only as strong as the users login password. Given this is a purely offline attack, an attacker has unlimited time to crack the password and then access the sensitive information.
So what can you do? Enforce full drive encryption. When BitLocker is enabled, everything in the drive is encrypted, including the location of the cached credentials. Yes, there are attacks agains BitLocker encryption, but they are much more difficult then attacking a user’s password.
In the end, I outlined the above attack scenario to my client and recommended they amend their policy to include mandatory full drive encryption. Hopefully this straightforward scenario shows that solely relying on EFS to protect sensitive files from unauthorized access in the event of a lost or stolen device is an inadequate control.