DPAPI Demystified: Abusing The Windows Data Protection API One Secret At A Time

Hello Bides. Uh happy for having me. Um this is my first time on stage and so please bear with me. Um welcome to my talk and we are going to demystify DP API. My name is Daniel. I'm a red teamer and former penetration tester. Most of the time penetration testing since one year red teaming. Um, I'm working with Code White and uh, as an offensive security person, I like credentials and I want to show you one of my favorite ways to uh, to actually get some. So, who wants to learn about DP API? Great. What is DP API? On a Microsoft Windows system, you encounter this many many times. With that, credentials are stored which are

on the other hand very valuable for attackers. Um as the access is hard to uh distinct from legitimate usage. It is quite valuable and crucial uh for penetration testers and red teams alike to retrieve that. Where do we have DP API secrets? The usage is all over the system. So you have credentials that are saved uh from within the task scheduleuler. You have credentials uh in the credential manager holding loon credentials for your active directory domain. Um the credentials necessary for your AAD connect secrets uh are stored that way. And um a whole bunch of third party tools use DP API uh for their secret protection. You maybe encountered um a secret encryption in for example a

.NET web config file and of course the credential manager and browsers um encrypt web credentials with DP API. For example, um Google Chrome uh has some sort of DPAPI encryption and in the past uh Microsoft Edge and the Internet Explorer always relate um relied on uh DPAPI encryption. So let's go into the internals. The data protection application programming interface really long and boring um consists of actually only two methods which is great. Uh there are a C and a C# or PowerShell version um which is crypt protect data um which maps to protect in for example PowerShell and the crypt unprotect data maps to unprotect that's quite easy right the idea of DP API is basically

encryption at rest so when Microsoft designed the the the data protection API The idea was that if an attacker managed to fetch these encrypted credentials from for example a backup, they should be safe against attackers retrieving these credentials in plain text and they did well quite a good job um developing a system which works but that has some caveats. The hardest part of a crypto system is key management and uh for Microsoft they have automatically built it in. So a user will normally not be involved in DP API uh encryption and the internals of it. So Microsoft manages automatically. We can see here um the important files and directories. We differentiate uh for these listings between the system user

which is above the administrator user um which has a somewhat special role in DPAPI. Uh we can see here um the master key directories. We have two of them which uh are only differentiated by a subfolder called user. Um and we will we will get to that specific folder or to the differentiation eventually later on. The system credential files are um found in uh the system profile app data her directory uh partly in local partly in roaming but um they are stored there. For example, if you configure a separate set of user credentials that should run a task at 12 a.m. as an administrator, the credentials will be stored under this location.

Here we can see a directory listing uh for the master key directory. Um we have uh the system uh security identifier name as directory and we have um for example uh the um the preferred file um which holds the current active master key. The preferred file is 24 bytes uh large. So it only hold the actual factual uh uh name of the currently active uh master key go ID for the user. Um we have uh the master keys stored which is quite interesting um for attackers when they only have access to the uni uh uh access to the user context um in their app data roaming profile which is quite common for an active directory setup uh because as a user I

want to have my secrets on that PC and the next morning on the other PC and that is where these credentials will be transferred. or two. Um the credential files are stored also here in the app data local and roaming directory. Um yeah, so it's it's it's quite typical to the system profile, but it's it's just in the app data user directory. We can see here a directory listing um of the master key directory which is slightly different. We have here for example the catist file that stores old user passwords but encrypted. For example, when a password change is initiated by active directory or or by the user um there uh will be um an encrypted uh version of the old

password. Um and when the password change will be conducted uh actually the Sunist will be checked um if master keys need to be re-encrypted with the user's password so the new password and if the password hashes that are stored in the Suncast file um are not uh changed uh re-encryption of the master key um will happen. Maybe I have left that out. The master key of system and user so every master key um is basically encrypted with um the user's password. So in order to retrieve the master key from the encrypted master key file um an attacker or a user need to know the uh essentially the password. What we also see here is a file uh

prefixed with a BK dash. That is um the public key of the of the backup master key used to additionally encrypt each user's master key. That sounds quite complex and I won't go into details here because we focus on the users client machine. But I I can assure you uh the the domain backup master key is also a fun topic to dive in. So we can see here the directory that uh holds the user credentials. You may have noticed in all these in all these directory listings that I'm uh I need to append the slash a to the dear command because these are uh sometimes system files, sometimes protected files and you won't see them otherwise.

So this is the most easy way to list those files. Um the uh user credential files are also just global unique identifiers but missing dashes. Uh and as a rule of thumb, master keys have dashes and are lowerased. Credential files have no dashes and are all uppercased. That's relatively simple. So what can we do with this? Now we assume that we want to extract the files for offline usage for now. Uh and if the password is known, we can decrypt the master key, use the master key and the user's security identifier which is crucial uh to decrypt a credential file and then we can enjoy the plain text credentials. So most of the time if you're an you're

an attacker and you have access to a user context for example you have successfully fished a target or you have um for example gathered uh the NT hash or uh the clear text password from somewhere and are accessing uh and accessing a system where the user has stored credentials in the app data. um directory for example, you can um pull them off uh for example via SMB um and can decrypt these files locally. The beauty of it is you only uh conduct um file access uh signals. So it is quite low noise um for defenders uh to actually notice that someone um retrieved the credential files or the master key. Let's assume we don't have the password

but we want uh uh but we badly want it. What we can do is we can use the master key for offline password brute force which is quite good.

This works most of the time quite well as we can see here. Um but there is one caveat. It is slow like 10 like uh 11 times slower than cracking a dcc2 hash. Um but the context to get this opportunity is within the current user. So you don't have to to dump uh the Elas process or you don't have to dump the SAM um or whatnot uh to retrieve these these domain cache credentials as a user in the user context. You can just fetch the master keys to you. So um bad passwords and password policies help in this case and as red teamers we humbly accept password policies that match season changes. We can see here um a credential hex

dump. Um why would I want to show you such a hex stump? It's quite easy because sometimes you are in an assessment or in an engagement and you are like okay what is this file even doing? What is this file even about? And if you have a look at such a file you can see here um in yellow uh the version information. The first one is from the credential file itself. The second one is from the master key no from the credential go ID and the third one is from the master key go ID. We can see in uh blue the size of the credential file and the most important one is the green one which is the master

key go ID that matches the credential file. So in order uh to decrypt the credential file you have to find the uh the matching master key which is important um as it only opens up to the right key. Another note this is little Indian most of the things on a Windows system are little Indian not all but most. So the credential file is also a little engine and you can notice uh the 3A 4A CF33 in the hex dump. Um and when we go and use for example the impact uh uh the example script um from the impact project. Um there is the DP API PIS script that um that gives us a summary of information even if we don't have um

the uh password or the master key for the credential file. Um we can see here in green the uh GID master key and that is the one we need to retrieve. So I have now talked about the internals of DPAPI. Um and you may now wonder what these secrets even look like. Um there are common ways to store DP API secrets. And uh the most common ones are um as um they are stored in registry as a binary array, a plain serialized PowerShell secure string in a file or a PowerShell PS credential structure serialized and an XML file, a manually encrypted blob, or all of the above with multiple layers of B 64 for good

measure. it happens. So here I uh found an encrypted string in a registry in my lab environment. The parent registry uh key holds the value civilization 6.exe. Nice. The example also shows how to decrypt from registry with PowerShell. So you don't need the current user's password because you're in the current user's context and can utilize the currently loaded master key for that user to decrypt DP API blobs.

The next example is uh PowerShell's secure string. And this is one thing that uh you may encounter quite some time because there's a popular tutorial out there recommending this way of storing credentials um for PowerShell automation. Um and if you retrieved such a file in your engagement and can't and can't uh I can't decrypt it. Um there is one one thing you need to know. You have just fetched an UTF-16 file from the Windows system. You need to convert it to UTF8. Strip the first three bytes. Strip the last two bytes. treat the written content as real hex values then it should work. That's one one thing that uh will maybe cost you 10 to 60 minutes.

Um but uh the other thing is you can just copy and paste uh the text uh and treat it as a hex value. Um this is a PS credential structure serialized with CLI XML. um we can just decrypt the password value by treating the text as hex content as formally with the secure string. But um it is also recommended sometimes to export this PS credential structure to more conveniently handle um um credential storage encryption and usage. As a side note, this only works in the current users context, of course. I want to give you an impression on how DP API content can be programmatically created. So I have two functions for you. Uh the first one is get protect and

the other one unsurprisingly is get unprotect. Um for both functions we use an enome field of current user. We can uh see it there and there. Um and we pass our secret uh via uh dollar secret and dollar secret bytes to um protect and unprotect. And we leave the second argument empty. We will cover that later. And this is an example of encryption and decryption using DP API. uh and should serve as an orientation for when you start looking at a hex of a file and you're like okay what are you now maybe you get an idea now what you're looking at next on what is DPAPI entropy you may ask well let's see in the former example we had the uh

dollar null um value supplied to the protect function um and that is actually the entropy value. This is thought of by Microsoft as an application specific key. Without it, other applications can decrypt secrets created by the user or other apps. So it is some sort of secret but you get the idea. um they thought of encryption at rest. But then there was this problem of how do we handle this uh in the same context of the user when another application that might be malicious wants to decrypt secrets from another let's say storage or location or registry. So they came up with the entropy and every application need to come up with some sort of entropy. Uh for example the

the popular um automation software shi comes with the entropy key shakleti. So it's not that hard to uh to get the information what the the entropy is as an attacker but is um but it is some light barrier and it is of course crucial for the uh decryption process.

What is the data protection scope? That is another fun one and actually my favorite. Let's see. In our PowerShell example, we also set a data protection scope. So that one was current user. C or PowerShell knows only two values. The first one is current user is current user um which is uh zero. um that results in encryption with the current users's uh master key. So fine. The other one is local machine which is one that results in encryption with a machinewide master key. So okay, what is this local machine about? According to Microsoft documentation, the local machine enumeration value allows multiple accounts to unprotect data. Use this value only when you trust every account on a computer.

For most situations, you should use the current user value. Okay, so we have user, we have system, we have local machine. Let's see what that means. Our first gotcha, secrets protected with local machine context can be unprotected by all users of the system. Recall that master key directory for system there was a user directory. Master keys in there are used for the current user context. So user means current user context. Uh and master keys one level above are used for the local machine context. It may happen that that developers are confused on how or when uh to use the local machine context and uh they might be mistakenly uh choose it for protecting information that should be

only be accessible by system. For example, imagine an application that um uh performs administrative tasks on a system um has for example uh also service privileges but need that specific um named account. Um and if the developers mistakenly select for the DP API context the local machine because well the credentials are for the local machine. That is a mistake. Um then every user on the system can use these machinewide master keys to unprotect the credentials if they have access to the destination. The second gotcha is um the unprotect function itself. Um so Hamberwolf has found a critical vulnerability by exploiting this behavior and that is a really interesting one for me uh at least. uh

they send an O cookie to the web app that gets DP API decrypted with the current user context and their plan was extract a master key from the appliance of that web application mostly the oldest one encrypt the cookie with admin with an administrative value they know using the extracted master key. Choose the local machine context for protect send the cookie and on the other side the local machine DPAPI encrypted secret um uh gets decrypted and they have admin access. And the reason why is DPAPI unprotect has no concept of local machine or current user. Unprotect uses the underlying C API. the um crypt unprotect data and according to the documentation there are no flags

that uh reflect that um that specific option. So unprotected will always look into the encrypted DP API uh data stream and there the flag is set for current user or local machine.

Thank you everyone for listening. If you have any questions, please let me know.

Who would like to start with the questions? Raise your hand, please.

And I will start with one. >> Um, sorry I did not fully get the last privilege escalation. Why did we get the admin access? They managed to uh fetch an old master key from the local machine context of that image of the web application which is normally used in HyperV or another virt uh uh virtualization uh platform and plugged in as an appliance. Um, and they managed to use that quite old master key or the or the oldest one they could find to have the um um the most um targets affected. Um and used that master key to encrypt or to protect with the local machine scope a value they know is administrative. And the web application has no other

choice when that cookie uh goes through the unprotect function to unprotect the cookie with all the local machine keys. So the appliance know and they're logged in which is quite novel I think.

Next question please.

Then I will come with a question. As a blue teamer, how could I detect a abuse of a DP API by an attacker? >> That is that is quite challenging because on uh in the offline context uh you can only know that uh some remote source tries to read that file. for example, the master key and in a short period of time maybe a credential file. um looking at file access to the master key from um maybe a source like a service process uh might be something to be on to or something odd like why would notepad x access uh a master key file but that is very um attacker tooling specific so it is quite hard to um have

an eye on the master keys of a user

Last question for someone.

And I would still have another question. It's so nice to talk to you. Um, how about hygiene? How can you do something good in your company to do good hygiene for the not abuse of DP API? >> This applies to basically every crypto system that tries to protect credentials at rest. For example, also password managers, users, and administrators alike do not need to have a password.txt txt file next to the credentials that are encrypted. So um a DP API or every other encrypted password manager may be uh rendered useless when plain text credentials are stored uh accessible to an attacker. So this uh should utterly be avoided. >> Thank you very much. So everybody let's

again give a big applause to our D