You may find it helpful to read our articles on Windows security and password recovery examples. Video section contains a number of movies about our programs in action
I'm trying to decrypt a DPAPI blob. In the past, everything has worked great using the logon password. Now I'm trying to decrypt a blob from a computer that is part of a windows Domain. When I load everything into WPR, it won't let me type the user password and instead wants me to use the SYSTEM and SECURITY registry keys.
Where do I get those keys?
Is this common for domain accounts or is there a different reason for this?
That's because the DPAPI blob you're trying to decrypt was encrypted with system credentials (saved by system account). So instead of using user logon password, the program needs the system credentials to decrypt the blob.
The system credentials resides in SECURITY registry and encoded with SYSKEY which can be extracted out of SYSTEM registry file. Typically the registry files are located in the following folder: C:\\Windows\\System32\\Config
So all you need to procedd with the decryption is to show the path to the registry files, eg.
C:\\Windows\\System32\\Config\\SECURITY
C:\\Windows\\System32\\Config\\SYSTEM
Thanks for the info. I'll give it a try. Is this common for domain accounts? This is the first time I have run into this even though I've used WPR on other domain accounts.
Is there a way to look at the blob header data (or the master key file header data) and tell if I need the system credentials vs the login password?
It is not common for user accounts and depends on software used to store the private data. Well to determine if you need a system credentials, open the DPAPI blob from the DPAPI blob analyzer tool and check dwFlags attribute. One of the bits (bit 3 if I remember it right) indicates that the blob requires system credentials.
I took a look at the blob in the analyzer, dwFlags is 0. That is what I see on other systems too.
Interestingly, normally on the master key file, I see a dwPolicy of 5. But, for the system that the blob I am interested in came from, I see dwPolicy of 0. Any idea what that signifies?
I tried using the SYSTEM and SECURITY files to decrypt the blob and it didn't work. Says it cannot decrypt the master key file (with the error message "Can't read SYSTEM (old) credentials"), but the hive files are readable.
I've used the master key analysis code to look at the master key file. Everything looks normal except the dwPolicy like I mentioned before, and I have a yellow block (Domain Backup Key) instead of a red block (CREDHIST GUID).
The CREDHIST file has the header, but no entries in it.
Should I be using the master key files from the user's "PROTECT" directory or from the system "PROTECT" directory (c:\\\\window\\\\system32\\\\Microsoft\\\\Protect)?
That's quite interesting. dwPolicy of 0 means that this is a Win2K system or at least the Win2K compatibility flag was set on the target system. See details here.
A masterkey file can be decoded using 3 ways: using user key, local key (win2k only), domain backup key. Grey, green and yellow correspondingly. The decryption process also depends on some flags. For example, if bit 3 of thу dwPolicy flag is set, the decryption key for the user key will be created using the SHA1 algorithm. In Windows 2000, this flag is off by default; i.e. it uses NTLM hash. So to create the user decryption key (grey color in the analyser tool), it is required a SHA1 or NTLM hash of the user password and the SYSKEY. To create the domain key (yellow) system uses a domain key that is stored in Active Directory and the SYSKEY.
The current version of the program doesnot support decryption using domain backup key. However if your masterkey file contains the local key (grey field), it can be used instead.
The masterkey of a dpapi blob can be determined uniquely by guid field of the blob structure. See here.
Consider sending me the files (dpapi blob, master key file and SYSTEM) by e-mail for more detailed analysis.
Occasionally, when testing the 'problem' DPAPI blob, we found a security flaw in Windows DPAPI system which is now actively used in new version of our Windows Password Recovery. Thanks to Michael Clark for his help in it.
English
Russian
