Cached Domain Credentials in Vista/7 (aka why full drive encryption is important)

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:

Encrypted Directory


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:

Permission Denied - Kali

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.


Dumping 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:

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:

Cachedump Fail

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:

Creddump in action

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:

Cracked with John

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.




5 Tips for Safer Online Shopping

Use good password practices

No surprise here – it seems to be on the top of every list of this kind, but people still don’t listen. Passwords are still (and will continue to be) the weakest form of authentication. In a perfect security utopia passwords would not exist, but since we’re not there (yet) everyone relies on them. The two main rules on passwords are: make them complex, and make them unique. Complex doesn’t necessarily mean you need thirty random character monstrosities that only a savant could remember, but avoid dictionary words and don’t think that you’re safe by just appending numbers or special characters. The first thing an attacker will do is take every English word in the dictionary and append random characters to the end of it. Yep, “password1989!” is just as (in)secure as “password”. Lastly, passwords should be unique to each site. This is an even bigger sin that most people (myself included) are guilty of. We have one good password so we use it for everything. The problem with this is obvious: if it gets compromised an attacker has access to everything. When LinkedIn’s passwords were compromised last year I realized I was using the same password for all my social media accounts, leaving all those vulnerable too. You don’t need to make an attacker’s job easier for him or her by reusing passwords. Make them work for each one they need to crack.

Store sensitive data in secure locations

Hopefully, you’ve followed the first rule and have unique, complex passwords for every site you visit. Now, how to remember them all? This is where I love to recommend password managers. Password managers securely store all your log in information in an easily accessible location. I emphasize “securely” here, because I see far too many people with word documents called “My Passwords” or the like sitting on their desktops. This is a goldmine for any attacker who has access to it. I’ve even seen theses “password” files being shared unencrypted in the cloud, so people can pull them up on their phones or tablets to remember their passwords on-the-go. Please don’t do this. Now if you lose your phone you also lose every password to every secure site you have.

Instead, use a password manager like 1PasswordLastPass, or KeepPass to name a few popular ones. These encrypt and store your sensitive information (not just passwords, but also SSNs, CC numbers, etc..) in an easy to access format. You encrypt your “wallet” of passwords with one very secure password (the only one you ever need to remember), and can even additionally encrypt them with a private key. A private key works just like a physical key – you need a copy of it to access the file. Keep it on a USB stick on your keychain and a backup in a fire-proof safe.

Watch out for HTTP(S)

Ever notice how some sites start with https:// as opposed to http:// ? That little ‘s’ at the end makes a whole world of difference. When it’s present it means that you have established a trusted and encrypted connection with the website. Its security purpose is two-fold: all data between you and the site is encrypted and cannot be eavesdropped, and you have established through a chain of trust that the website you are visiting is, in fact, who they say they are.

For example, this is what the address bar on Firefox looks like when I have a secure connection to Bank of America:

https bar

Notice the ‘https’ and the padlock icon. If you are ever on a webpage that is asking you to enter sensitive information (like a password) and you don’t see something similar, don’t enter it! There could be any number of reasons why you are not connected via HTTPS, including benign ones, but it’s better to be safe than sorry. Likewise, if you ever receive a warning from your browser like this:

https error

It means that the browser cannot verify the website is actually who it says it is. Phishing sites can imitate legitimate logins down to the smallest detail, but they cannot imitate their SSL certificate. If you see this type of warning when trying to access a well-known site, get out immediately! There could be legitimate problem with the website or your browser, but more likely somebody is impersonating them and trying to fool you!

Install those nagging updates

Microsoft actually does an excellent job of patching vulnerabilities when they arise; the problem is most people don’t install them. Every other Tuesday new patches and updates are released to the public. Microsoft will also release patches out-of-bounds (OOB), meaning as needed and not waiting for the next Tuesday, for serious vulnerabilities. These patches are a great way to fix security holes but also offer a nasty catch. Attackers use these patches to see where the holes were.

Every “Patch Tuesday” attackers will reverse engineer the Windows updates to discover new vulnerabilities and then attempt to target machines that have not applied the update yet. It’s akin to a car manufacturer releasing a statement saying “this year and model car can be unlocked with a toothpick, so apply this fix.” Now every car thief in the world knows to look out for that year and model, and if the fix hasn’t been applied they know to try a toothpick.

This is why it’s imperative to keep your computer up to date. The “Conficker” worm that ran rampant in 2009 exploited a security vulnerability that was patched by Microsoft almost immediately. Part of the reason it spread so successfully was people’s reluctance to install new Windows updates. It preyed on out-of-date systems.

Likewise, many online exploits will use common vulnerabilities found in different software, like Flash, Java, or even the browsers. When software that you use online prompts you to install an update – do it!

So the next time your computer asks you to restart to install updates, go grab a cup of coffee and let it do its thing. It’ll save you in the long run.

(note: Mac users are not exempt! Install those updates from Apple as well!)

It’s okay to be a little paranoid

My last tip is more of a paradigm shift than a tip for when you are conducting business online. It’s okay to be a little paranoid. The old mantra “if it’s too good to be true, it probably is” has never been more applicable when it comes to common phishing schemes. I’m sure most people know by now to not trust a pop-up that says “You’ve won an iPad – click here!”, but modern phishing techniques are much more subtle – and much more dangerous.

One of the only times I’ve ever fallen victim to a phishing scheme was when “Paypal” emailed me asking me to confirm a large purchase because it was suspicious. Since I didn’t make the order I immediately thought I had been compromised. I went into panic mode, clicked the link, entered my password….and, wait, I just entered my Paypal password into a site I don’t even recognize. They got me.

It’s okay to mistrust emails and links. If something seems phishy (pun intended) then exit out. Services like Paypal and online banks will never ask for personal information over email, chat, or any avenue besides their main website. If you have an issue, go to their website, ensure that ‘s’ is in your address bar, and do your business from there. If you’re still not convinced, find their 800 number and call them. The point is, if I had stayed calm for a second and thought it was strange Paypal was asking me to urgently log in via an email message, I would have gathered myself, gone to their official site to log in and then looked for any alerts or suspicious activity. I could have even called them.

Trying not to sound too misanthropic here, but when it comes to dealing with sensitive information online it’s better to not trust someone initially then it is to trust them implicitly. Your bank account information won’t be deleted and nothing bad will happen if you don’t immediately update your password, so take a second to make sure what you’re doing is actually legit.