We are pretty sure you will find it interesting as it covers one of the hot (if not the hottest) subjects of the past 6 years: DPAPI and DPAPI-NG. We have been working with DPAPI related subjects since then and we are proud to say that we are the first in this small world to discover the following:
DPAPI used in Active Directory and usage of the private key stored as a LSA Secret on a domain controller (we have called it a ‘backup key’ and it is a key corresponding to the backup public key stored in %Appdata%\Microsoft\Protect\<SID>\BK-<NETBIOSDOMAINNAME> when user is in the domain). The private key (backup key) allows decrypting literally all of the domain user’s secrets (passwords / private keys / information stored by the browser).
In other words that means that someone having the private key (backup key) is able to take over all of the identities and their secrets in the whole enterprise. We all know that Domain Admin can do a lot, but who knew that this much… This touches a bit a subject of trust to domain admins and that ‘Domain Admin’ should be more technical account rather than used by the human being.
Our tool CQMasterKeyAD was presented in the wild at TechDays 2015 in the Netherlands (you can find the recording + you will see extended edition of our tool at Microsoft Ignite 2016 HERE). In general we are soooo happy and proud that after months of research we got what we wanted and we brought the DPAPI research to the next level.
We moved on to the DPAPI-NG. Here comes our new research
DPAPI-NG used in the SID-protected PFX files. This is a subject that we will describe today with the continuation in September 2016 in Atlanta. When in the previous discovery we are able to get access to private keys, here it is a bit different. And this is the subject we would like to tell you about the possibility that showed up into our eyes about a week ago. In short words:
but by generating (again here comes our tool: CQDPAPINGPFXDecrypter.exe) the SID and user’s token. On the top of that we also did full DPAPI-NG forensics. Our research affects Windows 8, Windows 8.1, Windows 10 and related Windows Server versions.
Stay tuned until Microsoft Ignite in September 2016 in Atlanta!
Describing the problem and why you should be interested
First of all, before we take you to the dungeons of SID-protected PFX and their architecture and why it is (right now thanks to us, just saying!) not so difficult to decrypt them, we need to tell you something about DPAPI-NG so that you have the appropriate mindset when reading this article.
DPAPI was a mechanism introduced in Windows 2000 and it allowed to protect user’s secrets very well but it did not allow to share the secrets between users. Mainly because it was based on the users’ passwords’ hash and the user’s SID. In Windows Vista Microsoft took a new approach: DPAPI-NG. Currently, the only way to see DPAPI-NG in action by the regular user is the scenario where we pass the certificate containing user’s private key to another user. This is what we call a PFX file. PFX stores the private key so it has to be protected and it can be done in the various ways. Private keys stored in the PFX files are protected by passwords but we all know that this is not working well in the real life. We reuse passwords, write them down and we do not pass them in the safe way, not to mention the situation where passwords are just… forgotten. Microsoft addressed this problem: we still use password, it is automatically generated (we see it as a password with 44 characters that work) but it is protected by using DPAPI-NG.
The question here is very simple: who can see this password? That’s why we think you may be interested.
A bunch of technical details of the discovery
SID-protected PFX functionality was introduced in Windows 8 / Windows Server 2012. SID-protected PFX can be created by exporting the certificate with the exportable private key in order to get the PFX file. The first step is to go to the Certificate Manager console (certmgr.msc):
Exporting the certificate with the private key – step 1
Exporting the certificate with the private key – step 2
Exporting the certificate with the private key – step 3
The steps above allow us to export PFX which protection depends on multiple factors, where one of them is user’s SID. Even though you leave the password field empty, the password is generated and it is also one of the hidden methods to get access to the PFX files. In short words, the request to protect the file triggers the RPC to the Active Directory server in order to negotiate security contexts and initialize or access its root key objects in the Active Directory database. These objects are replicated amongst other Active Directory databases and they remain unchanged regardless the restarts. Later on, during the encryption process, a root key is used as one of the encryption components.
In order to understand the SID-protected PFX structure we suggest to have a look first how it looks like:
SID-protected PFX file structure
The red frame in the above picture is a DPAPI-NG SID-Protected PFX Password with its decryption components that we have to use to get access to the password and effectively to the private key. You can also notice user’s SID corresponding to it (in green).
User’s SID from the domain
In general: even though there is an only SID-protection implemented (we did not specify a password), there is still a random password being used and it can be even seen during the import phase:
Importing the data from the PFX file
Repeating the question: who has access to the password?
The obvious answer is: CQURE\fkrueger. Well… not necessarily 😉
Decrypted password from the SID-protected PFX file
The true answer is quite surprising: not only the owner but also other people 🙂
If you are interested in more details related to the whole process read this document: [MS-GKDI]: Group Key Distribution Protocol. Unfortunately, even though the document is quite detailed it does not contain all the necessary details to move forward, not only Server part is not complete but also Client part is totally not there. That is the whole beauty of this and this is the only additional and reasonable document that could be a good reference here. More detailed stuff is going to be published by us after Microsoft Ignite 2016 in Atlanta.
Why was it so difficult to figure out?
Of course, it is known since the very beginning that they key necessary for the decryption must be somewhere in the Active Directory. Even though different researchers tried to understand this mechanism, it was too complicated because it uses very hard to analyze parts of the operating system (mainly DPAPI-NG and LSA). Until today there is literally no documentation related and no working utility to decrypt the protected data.
What is the key breakthrough and implication here?
Offline decryption of the SID-Protected PFX files and the possibility to read the PFX password from the SID-Protected PFX file by a person who is not authorized to access the private key.
When will there be more details?
You will see the complete scenario and a lot of details regarding SID-protected PFX files decryption process at Microsoft Ignite that will take place September 26 through Friday, September 30, 2016 at the Georgia World Congress Center in Atlanta, Georgia. See you there!
There is one thing more to be mentioned at the very end. The CQURE research and tools, the DPAPI-NG itself and everything we described here is not related to any bug. It works exactly as designed by Microsoft and it works great. But every single time when we see any encryption, we in our Team ask ourselves a question: where is a key and how we can steal and then use it. And we did it as described above. In simpler words: your secrets are as safe as your AD database. Yet another reason to really care about it.
Michał Grzegorzewski (Mgrzeg)