Data Protection API

I am currently logged on as Freddy Krueger. This is the guy that’s going to be exporting certificate with the private key. It’s going to be SID protected. Let’s do it first so that we’ve got something to work on.

I’m exporting the certificate. Next, export the private key. Great.

First step: add another user

Here we are specifying who we would like to add. For example, we can add over here another user. Only these users are allowed to get access to this particular certificate. So, blee and Freddy Krueger. Okay. No password for now.

This is the feature that is leveraging the Data Protection API NG, available since Windows Server 2012 R2.

Second step: specify the file name

Next we’re going to specify some file name. For example, we can name it here, for blee or for Freddy. Save.

The question for us will be: are we able to, at some point, get access to this file?

It’s actually funny to watch this because if we want to get access to this particular PFX file, then it actually fills up automatically a password over here that is coming from the format PFX and what it is all about.

Here it’s accepting password and we go.

If it is SID protected PFX at the end we are actually encrypting the password here. That’s something that we would like to get access to.

We’ve got this for Freddy Krueger. We can copy this certificate and we can put it on somewhere in our tools folder. We’re going to be working on this.

Freddy Krueger, bring it on!

Here on the Domain Controller, in order to be able to get access to something that we call KDS Bootkey that is necessary in the case of a data protection API to grab, first of all we need to get a Bootkey. We’re going to use and grab this with our newest version of CQSecretsDumper. Let’s grab this value and this is a D9A7DB and so on.

Over here I backed up myself. I made a copy of ntds.dit. You can use Shadow Copy could be an option and copy simply that file. That’s pretty much the only thing that we need.

We would also need SYSTEM registry hive because there is Bootkey, but because we are fetching the Bootkey, that’s really the only thing that we need over here.

Now we’re ready!

Having these two items, now we are ready to move forward and extract necessary information from the ntds.dit. At some point if you’re going to be doing Shadow Copy and something goes wrong with the integrity of ntds.dit, you can always use esentutl /r edb /d and that is basically something that will auto ask to recover the particular database. Just in case you were in trouble.

Now what we’re going to do? When we’ve got this information here, we can move on into CQNTDSDTDecryptor and we’re going to be grabbing from our ntds.dit that I also copied to CQTools already. We’re going to be extracting the KDSRootkey file and we’re going to put it into kds.dit, by providing an appropriate Bootkey.

When we run that, what we’re going to get over here are different types of KDS Rootkeys and one found. It’s 9EB9 is one and another one found is C16. Technically, there are not many of those, so you can try all of them. But, the point over here is that this particular decrypted master key is the one that we’re going to be using for access to the PFX file.

You will need CQURE’s tool

Let’s bring it on. For that purpose, we’re going to use our new tool, CQDPAPINGPFXDecrypter, so that’s going to be our tool. Let’s get into this one. It takes two parameters.

First of it, it takes pfx and in our case, it’s D:\Tools\CQ_tools\forfkrueger.pfx, so this is where we had that. Here we go.

Another one is master and this is where we put our file. Enter.

As you see, successfully decrypted password. Okay.

I’m super curious right now if this is something that’s going to work for that particular pfx file. Let’s find out.

For Freddy, Next. Next. And it asks me about the password, so I’m pasting the value that we got. Display password. That’s the value. Next. As you see, this is how we are able to decrypt those PFX files.

Data protection API is not that difficult

Where’s that difficulty? Well, difficulty basically is to reverse engineer Data Protection API NG and be aware how clients are actually getting access based on their SID to their PFX files. That’s the first thing, and that’s what we did.

Second thing is to, of course, extract the information so KDSRootkey from the domain. That’s not a big deal. The deal is how to use it.

If we have a look at the structure of the PFX file, you can do this as maybe a little bit of a homework, by using the ASN editor, you will see that it’s not the easiest structure and it’s really a matter of how we are leveraging the data that we’re able to export over here.

Watch out for your data. Take intense training from CQURE CyberBytes series and implement data protection techniques in your organization.