Windows ReVaulting

Windows Vaults and Credentials allow the user to store sensitive information such as user names and passwords , that can be later used to log on web site, services and computers. In this post it will be shown how such data is protected and how you can decrypt it offline.

This post is a very late debriefing of the talk I had at SANS DFIR Summit Prague 2015 and it's the first of two posts. You can download the slides from SANS Summit Archives or from SlideShare.

introduction

I've never used Vault/Credential facility on purpose, even if the system used it without my knowledge : it's worthwhile to know that Windows autonomously uses it almost every day. In any case, we can find sensitive information there, and this is the reason I started this research, as to have a little more strings to my ODI (Offensive Digital Investigations) bow.

Windows provides two utilities to manage such credentials, the graphical Credential Manager and the command line vaultcmd: you can see them in the next two pictures.

Credential Manager

vaultcmd

When checking for credentials I strongly suggest to use both the manager and the vaultcmd since neither of these tools show all of them.

Microsoft writes here: "Credential Manager allows you to store credentials, such as user names and passwords that you use to log on to websites or other computers on a network. By storing your credentials, Windows can automatically log you on to websites or other computers. Credentials are saved in special folders on your computer called vaults. Windows and programs (such as web browsers) can securely give the credentials in the vaults to other computers and websites.".

From the previous statement we get one main lead, at least: credentials are stored in special folders. And this is exactly what I spot when monitoring and debugging my target systems: from a file system point of view, two/four different paths are used, not considering system's vaults. Inside the user profile you could find the Credentials and Vault folders into "<user>\AppData\(Local | Roaming)\Microsoft\" paths, as shown in the following pictures.

Credentials folder

Vault folder

My journey started from these folders, but there is one major requirement before going on, that is DPAPI. As we'll see, credentials and vaults protection is based on this well-known Windows technology, so it's advisable to have an overall understanding of it: you could find many references online, and even on this blog (Happy DPAPI!). One key point descends from this fact, that is all the security around credentials/vaults is solely based on the user login password.

credentials files format

Inside Credentials folders you can find zero or more files without extensions and GUIDs as names. Each file contains one "secret", which is our target: the files are independent from each other. As highlighted in the picture, the file is simple a DPAPI blob with a small header in front of it: its decryption does not pose a new challenge.

Credentials file

vault files formats

Inside Vault folders you can find zero or more GUID-named sub-directories. Inside each sub-directory there could be three types of files: one Policy.vpol, one or more <guid>.vcrd and one or more <guid>.vsch. The vpol file contains the keys needed to decrypt vcrd files whereas vsch files contain the schema needed to correctly print out the decrypted secrets. Compared to credentials folders, there is an additional encryption level. Needless to say, no vcrd file in the folder means that no secret is to be decrypted.

The Policy.vpol file is a DPAPI blob with an header containing a textual description and a GUID that should match the Vault folder name. The gold mine is obviously the blob.

Policy.vpol

Once the blob is decrypted, we get two AES keys to be used in decrypting the vcrd files.

Policy.vpol decrypted

The vcrd files show a bit more complicated format: the core part is made up by a variable length array of encrypted attributes. These attributes are encrypted with the previous AES keys and the target secret is usually the last attribute, the one presenting an IV and the only one encrypted with the 256 bits key. The following pictures should help to understand the file format.

vcrd file, 1/2

vcrd file, 2/2

For the sake of completeness here is it a brief overview of a vsch file: I didn't go further in reverse engineering schema formats, too boring. The following pictures mainly show the link between the schema GUIDs, the vault directory names and the GUIDs inside the previous files.

vsch file

vaultcmd list schema

arsenal

The previous sections were an harsh descriptions of formats without too many explanations, because I think it's better to introduce some tools to play with. You could start decrypting your credentials/vaults by using the Open Source Python code I wrote and I put into the dpapilab project on GitHub. The files related to Credentials/Vaults are four: vaultstruct.py, creddec.py, vaultdec.py and vaultschema.py.

The vaultstruct.py file contains the formats definitions, both for credentials and vaults: here you'll find pretty much all the intimate details, since the overall logic is limited. To decrypt credentials file use creddec.py and to decrypt vault files use vaultdec.py: in the next sections I'll provide some examples. The vaultschema.py file is an attempt to provide a better decrypted secrets output and it's based on my limited testbed and not, as I wrote, on a full schema reverse engineering. Something could fail, so feel free to open an issue and/or to modify the code to printout the decrypted hexadecimals. Needless to say the DPAPI kernel used by the scripts is the awesome dpapick: to use the previous scripts, first install dpapick, manually or by the Python pip utility.

The dpapilab code is not the only (Open Source) tool able to decrypt credentials/vault files: mimikatz can do it too. I'm not referring to the memory cached information, but to this command

mimikatz # dpapi::vault /cred:4EA276E76F13906751D56C95069FA718349F49EAE.vcrd /policy:Policy.vpol /masterkey:381a398a49c00b29cb1109802acc0fd1d379761

where masterkey is the SHA1 of the decrypted DPAPI master key material (the MK related to the policy file). I must do a digression right now.

<digression> Benjamin aka gentil_kiwi "fried" the novelty of my little research (open source novelty: there is at least one cool commercial tool doing credentials/vaults decryption since years). On 15 July 2015 he wrote the tweet "Full offline Credentials & Vault decryption with #mimikatz and keys (or online,as you want)" producing a bit of frustration in me... which fast disappeared when I reached him and we started to share candy vaults and to fight on decryption flows... we had a couple of funny hangouts, at least. Benjamin is a great security researcher but, above all, he is a really good guy (oh, well, even if evil_kiwi inside...)! Anyway I had a speedup on vrcd file format and moreover something to check results with. So... thank you and kudos! </digression>

Before going on with some examples, we have a strong requisite to decrypt credentials/vaults: to know the user login password. During the talk I provide a couple of well known shortcuts that could help in retrieving the password: anyway it should not be an easy task, unless... you have a memory dump. In this case you'll get many many chances to achieve the goal, thanks again to mimikatz. You could get the plaintext password, or its SHA1, or the cached DPAPI Master Keys, or even the cached credentials/vaults...  and so on.

decrypting credentials

Let's start with an example of  creddec.py usage. The black bold parameters are related to DPAPI, to get the proper master key material. The orange parameters are target credential files.

creddec in action

In the next figure we can see the beautified graphical result: creddec will not create such a nice result, just a textual one... well, I'm not an artist despite my surname.

credentials decrypted (some obfuscated...)

Please take into account that the decrypted file format was not a result of reverse engineering: I derived it using my limited testbed. So it could dramatically fail: don't blame on me, thank you.

I can testify the born of what I called double cheeseburger credential, starting from Windows 8 at least. Once this type of credential file is decrypted you get a special file format where you must put its pieces back together: then you will obtain... another DPAPI blob, this time protected by a system master key. That's the reason for its name. From creddec.py point of view you must provide the DPAPI system parameters too, as shown in the next picture in blue.

creddec vs double cheeseburger credential

This kind of credential is usually related to "WindowsLive:target=virtualapp/didlogical" data...

eating the double cheeseburger

decrypting vaults

I provide a single Vault example, but a juicy one. Windows introduced the possibility to login with a pin code or a picture shape, after having set a "normal" password: Windows 8-8.1 have a major issue, since both the pin/shape and the original password are kept in a system vault. This means no security. Credits go to Passcape for having discovered it. Let's see how to exploit this ugly thing.

vaultdec in action

Note that vaultdec requires the Vault directory as a parameter, not the single files as creddec. The result is shown in the next picture: again, the schema used to printout results is derived from data.

system vault decrypted

conclusions

We have briefly seen how Windows Credentials and Vault files are secured and how we can decrypt them, with Open Source software. Given the proper legal authority, this possibility could be exploited to access user's protected data or simply to improve security awareness.

Since the same technology is used in different Windows versions, the research has a broad coverage: for example, in a next future post we'll see how to decrypt and use Windows phone ActiveSync tokens.