Home > Information > Blog > Show blog article
Show blog article
Wireless Password Recovery v4.1.5
New algorithm for loading handshakes from capture files, new options
Reset Windows Password v7.1.0
RWP now can create new SAM user accounts and supports for Win 10 Creators Update
Wireless Password Recovery v4.0.3
Some problems and bugs were fixed
Windows Password Recovery 11.2
Some improvements and speed optimization

Articles and video

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

DPAPI Secrets. Security analysis and data recovery in DPAPI (Part 2)

16:51:23 12.03.2012 posted by Passcape_Admin at 16:51:23 12.03.2012

DPAPI Credential History

What happens when changing Windows password

Recovering data from DPAPI blobs


<< Back to Part 1


DPAPI Credential History

The proper functioning of DPAPI assumes keeping all of user's previous passwords. All the previous passwords are stored as hashes in a special container file named CREDHIST, located in the %APPDATA%/Microsoft/Protect folder.

CREDHIST Structure

If we look at the credential history file as a chain, each slot with a password hash would appear as a link of the chain with the following binary structure:

typedef struct _tagCREDENTIAL_HISTORY
DWORD dwVersion;
GUID guidLink;
DWORD dwNextLinkSize;
DWORD dwCredLinkType;
ALG_ID algHash;
DWORD dwPbkdf2IterationCount;
DWORD dwSidSize;
ALG_ID algCrypt;
DWORD dwShaHashSize;
DWORD dwNtHashSize;
BYTE pSalt[0x10];
Data fields description:
DWORD dwVersion current link version of the credential history chain
GUID guidLink unique link identifier
DWORD dwNextLinkSize size of next chain link
DWORD dwCredLinkType type of password used for decrypting current link
ALG_ID algHash hashing algorithm identifier in PBKDF2
DWORD dwPbkdf2IterationCount number of iterations in PBKDF2
DWORD dwSidSize security identifier size of the data owner
ALG_ID algCrypt used data encryption algorithm
DWORD dwShaHashSize size of SHA1 hash
DWORD dwNtHashSize size of NTLM hash
BYTE pSalt[0x10] random set of binary data used for encrypting
BYTE pSid[] owner SID
BYTE pShaHash[] SHA hash
BYTE pNtHash[] NTLM hash

Figure 6 shows the data storage scheme used in CREDHIST.

CREDHIST file structure
Figure 6. CREDHIST file structure.

CREDHIST Encryption

Slots with user's hashes are stored in series, one after another. Each password hash is encrypted with the preceding hash, and the first hash is encrypted with user's current password. Therefore, to decrypt the entire chain, one needs to know user's current password (see fig. 7.)

Credentials history decryption scheme in DPAPI
Figure 7. Credentials history decryption scheme in DPAPI.

If an error occurs when decrypting the Master Key using current password, DPAPI uses the logon password to decrypt the first hash in CREDHIST and attempts to decrypt the Master Key with the first CREDHIST hash. If the Master Key still resists, the first hash in the CREDHIST history decrypts the second hash, and the operation repeats.

Different operating systems use different default parameters and algorithms for encrypting credential history (see the table 3 below). In general, the encryption algorithm is similar to the one that is used for protecting Master Keys.

OS Block cypher Hash algorithm PBKDF2 counter Password guess speed (pwd/sec)
WindowsXP 3DES SHA1 4000 76
WindowsVista 3DES SHA1 24000 12
Windows7 AES256 SHA512 5600 10
Table 3. Encryption algorithms used to decode credential history hases in DPAPI.

CREDHIST vulnerability

CREDHIST stores all the previous password hashes, even though the passwords are identical. Theoretically, there is a chance that user sets a password that has already been used before (let's call it duplicate). In that case, to recover current password, it would be sufficient to have the password from credential history, set between the current password and the duplicate.

Therefore, it is more expedient to use DPAPI with a Windows security policy that forbids entering duplicate passwords or improve DPAPI, so that it does not allow storing duplicates in CREDHIST.

What happens when changing Windows password

Password change in Windows is conventionally divided into several critical phases. First, the system checks the validity of the old password, then checks the new password for compliance with security policies and physically changes the password in the SAM or NTDS.DIT databases. In the second phase, if all goes well, it updates the internal password cache. Then there runs the DPAPI password change routine. And, finally, it updates the biometric logon credential for the user (Windows 7 and higher).

The DPAPI system is smart enough to handle various scenarios. Let's see what takes place inside DPAPI on password change. Here are the typical cases:

  • Regular password change with supplying the old password (Windows XP - Windows 7)
  • Password reset or overwrite; e.g., by administrator, without supplying old password (local PC under Win XP - Win 7)
  • Domain user password reset (Windows 2000-2008)
  • Local PC user password reset in Windows 2000

Regular password change in Windows XP - Windows 7

Windows security policy assumes the regular change of user password, and DPAPI must provide user with the same level of access to personal encrypted data as before the password change.

That is achieved by a three-step synchronization of all user's Master Keys, on the first step of which all the Master Keys undergo the decryption with the old user password, on the second step all the keys are encrypted with the new password and saved to disk, and, finally, they are backed up if the respective option is selected.

The re-encryption of all Master Keys may take very long time; therefore, it is carried out in a separate thread within the LSA. An interesting Master Key synchronization gear has been added in Windows 7: DPAPI hashes all the Master Keys within user's profile and writes the hash obtained as the result of that process to the SYNCHIST file. The next time, to determine whether any changes took place, DPAPI again hashes the entire pack of the Master Keys and compares the obtained hash with the value stored in SYNCHIST, thus preventing the unnecessary and time-consuming operation of re-encryption.

The update of the CREDHIST file precedes the operation of synchronizing the Master Keys. The old user password hash is encrypted with the new one and placed to the beginning of the hash history chain in CREDHIST. If the credential history is empty, the system creates the first link of the hash chain.

In the end, the system updates the password reset disk if it was created earlier. To do so, the system looks for the public RSA key in the certificate storage, encrypts the new password with it and writes it to user's registry, replacing the old one.

Password reset on a stand-alone PC under Windows XP - Windows 7

This is the case when, for example, Administrator manually resets user's password, or the password is erased using a password reset program.

Despite that the user maintains the ability to log on to the system, all data encrypted with DPAPI is no longer available (for example, network passwords, EFS keys, mail certificates, etc.), as the user's old password is unknown, and DPAPI is unable to decrypt the Master Key.

If after a forced password reset the old password is set again, DPAPI returns to its original state, and all the DPAPI blobs are available again.

This happens because DPAPI prudently keeps all copies of Master Keys even if they cannot be decrypted. Another way to recover the full access to the system (after a forced password reset) is using an earlier created password reset disk.

Forced domain user password reset

If DPAPI is used in the Active Directory environment (Windows 2000 - 2008), the Master Keys store two backup copies. The first copy is protected by user's current password, and the second one is encrypted with the public RSA key that belongs to the domain controller.

On a forced user password reset, DPAPI is unable to decrypt the first copy of the Master Key. Nevertheless, access to all the DPAPI blobs will be recovered using the second backup copy. The workstation sends the encrypted backup copy of the Master Key to the domain controller. The domain controller decrypts the backup copy using its private RSA key and sends the decrypted Master Key back. The workstation encrypts the Master Key all over using the new user password and updates the file with both the copies and synchronizes the other files.

Password reset on a stand-alone PC in Win2K

On stand-alone computers running under Win2K, the DPAPI password reset disk is not used. The Master Key file stores two copies. The first copy is encrypted using user's password, and the second one is using the LSA secret of DPAPI_SYSTEM, stored in the registry and available only to the system account.

Once user password is forcibly reset, DPAPI is be unable to decrypt the first copy of the Master Key, so the system decrypts the second copy automatically. Then the decrypted copy is protected with user's new password and written back to the file. All the other Master Keys also undergo the synchronization.

From the end-user's point of view, the process of accessing confidential data, protected by DPAPI, is completely continuous. To ensure the adequate protection of confidential data by DPAPI on a stand-alone PC running under Windows 2000, it is recommended to modify the SYSKEY settings, so that the system would require entering the syskey startup password or provide a syskey startup diskette on system boot.

Recovering data from DPAPI blobs

A set of tools for working with DPAPI available in the Windows Password Recovery offers broad opportunities for recovering passwords and data encrypted with DPAPI in the off-line mode, i.e. without loading user's profile. Let's review the typical scenarios of using the software.

Finding DPAPI blobs on disk

In windows, DPAPI blobs can be stored anywhere: in binary or text files, databases, registry, Active Directory, etc. Before beginning to decrypt a DPAPI blob, we must first "pull" it out and put in a proper form. To do so, we would need a search tool for finding DPAPI blobs on disk.

Launch the utility and select the source folder to be searched. Suppose, the source folder is C:/Program Data/Microsoft/Wlansvc. It contains wireless connection passwords in Windows 7.

Passwords encrypted with DPAPI are stored in the text format in XML files; therefore, we make the respective setting to search for text blobs (the option is enabled by default). Once the folder for storing found files is selected, hit the Start button.

Found DPAPI blobs will be stored in the target folder under the respective names. For example, if the program finds a DPAPI blob in file xxx.xml, it will be converted to the binary format and saved in the target folder as xxx.xml.001. If in file yyy.xml the program finds two blobs, they will be saved as yyy.xml.002 and yyy.xml.003.

Looking for WiFi passwords
Figure 8. Looking for WiFi passwords.

Finding DPAPI blobs in registry and Active Directory

Finding DPAPI blobs on disk is not that difficult. But what if you need to scan current user's registry or an Active Directory database? Access to those files is forbidden to all, including administrators.

It's difficult, but, fortunately, not impossible. For that purpose, we take advantage of a handy tool for registry and Active Directory backup, which is easy to operate even for newbies.

Launch it and then select what and where we to be backed up: registry or Active Directory. Note that parsing an Active Directory database may take long time. Now we can proceed to the DPAPI blob search utility and specify the path to the folder where we have saved the registry or ntds.dit database.

Recovering wireless connection passwords in Windows 7

Decrypting wireless connection passwords is preceded by looking up the respective DPAPI blobs in the above described C:/Program Data/Microsoft/Wlansvc folder. So, here we are going to skip its yet another description.

Launch the DPAPI decryption utility and specify the path to the extracted DPAPI blob. Wireless connection passwords are protected with the CRYPTPROTECT_LOCAL_MACHINE flag, so to recover them we would need the system Master Key from folder E:/Windows/System32/Microsoft/Protect/S-1-5-18/User.

In that folder, find the required file with the Master Key. By default, the open file dialog shows only the file we need. Path to CREDHIST in our case is not necessary, so we leave that field empty.

Once moved to the third step of the application, we mark that we don't need the user's password. Instead, we need two registry files, SYSTEM and SECURITY. Well, we specify them too. Note that you must first unlock current registry files (i.e. back them up). In the user's SID field, the program automatically places the system's SID: S-1-5-18. Leave that field and finish the decryption by obtaining the original plain-text wireless connection password in Windows 7.

Easy? Let's go further.

Recovering Facebook passwords stored in Internet Explorer

Now the problem is a bit more complicated. Let's try to recover the password for a Facebook account in Internet Explorer. To do so, we may have to do quite a bit of "tambourine dancing", so stock up on patience in advance.

Internet Explorer auto-complete passwords are stored in the registry hive HKCU/Software/Microsoft/Internet Explorer/IntelliForms/Storage2. Run Regedit and open that hive. There, you will probably see a number of binary records. We are going to need just one of them, named F6FFE33B9EF4D7CB8F5A2F41F3222D21E131ED787A.

If you do not have such a record, try creating a test password on Facebook: open the page at http://www.facebook.com/ (the www is mandatory), enter any e-mail address and the test password and then click the sign in button. When IE kindly offers to save the new password, do that. Naturally, the Facebook website will return an error, but that doesn't matter, the password has been saved.

Creating Facebook test password
Figure 9. Creating Facebook test password.

Switch back to regedit and press F5 to update the data. The registry key that stores IE passwords must get a new record named F6FFE33B9EF4D7CB8F5A2F41F3222D21E131ED787A. This tricky name is nothing but a SHA hash of the website name.

When you open it, you will see a DPAPI blob with encrypted login and password to the website. Let's export the DPAPI blob to a text file. To do so, open cmd and run the following command:

REG QUERY "HKCU/Software/Microsoft/Internet Explorer/IntelliForms/Storage2" /v F6FFE33B9EF4D7CB8F5A2F41F3222D21E131ED787A > c:/test/fb.txt

The quotes are mandatory! Our password will be saved in the ASCII format to folder c:test. You are free to set any other folder; that doesn't really matter. Now, all we need to do is to extract the binary DPAPI blob we need from the ASCII file fb.txt.

Launch the search tool, specify the source folder c:test, set the search text files option and get the binary file fb.txt.001 at the output. Finally, we can move on to the actual password recovery.

Open the respective utility and set the path to fb.txt.001. On the second step, specify the Master File, which the blob was encrypted with. All the user's Master Keys are stored in the folder %AppData%/Roaming/Microsoft/Protect/%SID%. One level higher, there is the CREDHIST file. We may be able to use it too.

The most interesting stuff begins when we move on to the third step of the application's wizard. To decrypt the Facebook password, we will need to properly set the following three parameters: user's SID, his logon password and the secret the DPAPI blob was encrypted with. The program normally extracts user's SID automatically from path to the Master Key. If that hasn't happened, you will have to obtain that parameter by hand (for example, by analyzing the CREDHIST file). Concerning user's logon password everything is clear too. But what are we supposed to do about the secret?

For the secret, when encrypting password, IE uses the name of the web page the password was entered on. The page must be entered in lowercase, as UNICODE, and terminate with a zero. If you have a HEX editor at hand and have sufficient skills to comfortably work in it, try creating that secret manually. Otherwise, simply download it here.

So, having specified the path to the file that contains the secret in the entropy setting, we finally finish our epic of recovering a Facebook password. Having decrypted it, you will see that the password, login and other system information are merged into a single data structure (Fig. 10). Don't let this bother you.

Decrypted Facebook password
Figure 10. Decrypted Facebook password.

Recovering user password without loading hashes from SAM/NTDS.DIT

For the first time ever, Windows Password Recovery allows to recover the logon password without loading user's hashes from SAM or NTDS.DIT. That was made possible because user's password participates in the Master Key encryption process. Consequently, the Master Key can be used for validating the password.

To illustrate the above, run the Master Key analysis tool and specify the path to a file with a Master Key. After a successful parsing of the Master Key, the program will show its internal structure. Right-click on it, then select the validate password using dictionary item and specify the path to any dictionary.

Despite its revolutionary character, the recovery of user's password from the Master Key is not of any practical benefit. For example, in Windows 7, the password validation goes at the speed of about 10 p/s. Theoretically, the speed can be increased by a few orders of magnitude by optimizing the encryption algorithms and engaging GPU in the validation. But even after that, the speed of password mining by Master Key compared to NTLM hash would seem ludicrous. In terms of security, DPAPI is all set.

Recovering logon password by analysing DPAPI Master
Figure 11. Recovering user's logon password by analysing DPAPI Master Key in Windows Vista.

Decrypting credential history hashes from DPAPI

Open the credential history dump tool and specify the path to the CREDHIST file, stored in the %AppData%/Roaming/Microsoft/Protect folder. If the file stores the previous user passwords, the "CREDHIST key chains" field should have a non-zero value.

Previous user passwords are stored as SHA1 and NTLM hashes. The application has a respective switch. If you select current user's CREDHIST file, entering the logon password isn't required; the program will automatically fetch it from Windows cache, simply make the respective setting. Otherwise, you would have to enter current user's password manually.

The utility supports partial dump. That means that in case the current user password is unknown, but one of the old user password is known, the program can decrypt the hashes that were used earlier, i.e. before the old password was entered.

Dumping DPAPI credential history passwords
Figure 12. Dumping DPAPI credential history passwords.


DPAPI deserves such close attention at least for the fact that it's the only password-based system that provides appropriate and thoroughly thought out protection of user's personal data. None of the operating systems has a more viable alternative to DPAPI!

We should, perhaps, mention that the first implementation of DPAPI had a number of serious flaws, which could enable a potential malefactor to easily compromise user's data protected by DPAPI.

The first pancake is known to be always lumpy. In all the sequel operating systems, beginning with Windows XP, those vulnerabilities have not merely been eliminated; the entire DPAPI system has undergone a major revision. In particular, it has adopted new encryption algorithms; that has made the Master Key password lookup speed about 1000 (!) times slower. Master Key encryption errors that potentially allowed any user to gain access to any files encrypted by EFS were fixed. The local Master Key backup system has been replaced with the password reset disk, etc.

Overall, the DPAPI encryption system has become more robust, powerful, meeting the stringent requirements of password security.

<< Back to the Part 1

Current rating RatingRatingRatingRatingRating
Avarage rating Ø 10.00
Number of votes 2
Your vote Rate this message: 1Rate this message: 2Rate this message: 3Rate this message: 4Rate this message: 5Rate this message: 6Rate this message: 7Rate this message: 8Rate this message: 9Rate this message: 10


skype hash
posted by Mike at 14:12:57 01.04.2013

i've been reading your excellent articles on encryption and DPAPI and am wondiering if you've had a chance to look att he protection mechnanisms for securing the local password for skype.

it's not too hard to recover the MD5 hash for earlier versions of skype - but under Windows 8 and the metro version of skype, it becomes a whole new story.


have you looked at W8 and skype metro?  if you have any ideas or insights into how to recover hashes from this, then i would be really interested.

keep up the sterling work!
RE: skype hash
posted by Passcape_Admin at 15:00:08 01.04.2013
Hi Mike,
Yeah, old version of Skype stored MD5 hash of user password encoded using DPAPI. Unfortunately, we haven't yet analyzed Win8 Skype protection. But it would be very interesting to look into how they protect user password now. I will post here as soon as I find out any related info.
RE: skype hash
posted by Ivan at 08:27:45 02.04.2013
I played with the Win8 Skype version yesterday trying to figure out the new protection type Mike said about. It appears that the Skype uses absolutely different way of storing its credentials now. Neither MD5 hash nor DPAPI are involved. It seems that the password is saved to Windows Vault but encryption is a bit sophisticated. I have managed to decrypt the Skype Vault entries using our Vault Explorer tool and got some weird strings. Have no idea what is it. So it is obviously that the Vault was choosen as a replacement for DPAPI container but further analysis is required to figure out the encryption type used there.

P.S. Use the following link to read more about Windows Vault:
Windows 8
posted by taz at 11:46:11 14.03.2014
Can you update what changed with Windows 8? Your software now asks for the sam file and works, but going through the process manually I can't seem to decrypt the master key anymore? Obviously I'm missing what changed in Windows 8, but I haven't been able to figure it out yet.

RE: Windows 8
posted by Passcape_Admin at 11:59:06 14.03.2014
To put it shortly: a damned lot of things were changed in Windows 8 DPAPI system. You can not decrypt Win8 DPAPI blobs the way it works in previous versions. New Master Key encryption algorithms/routins/logic are involved now. This is a topic for yet another big article.
RE: Windows 8
posted by taz at 02:27:56 15.03.2014
Thanks for the response. My computed HMACs weren't matching at all with the values in the protect\sid\guid file when trying to decrypt the master key, but skipping that portion and getting the master key with a tool like mimkatz it still doesn't let me decrypt the blob (I haven't even been able to verify the key mimikatz spits back in win8 is valid either unfortunately which is another thing I wanted to test). I just end up getting a decryption error when doing the aes decryption on the blob (I can generate the session/blob key just fine from the master and nonce with the xor padding scheme, but obviously that obviously isn't the same anymore or else the decryption arguments have changed) .

I guess I have to do some reversing of my own, I didn't expect any trouble with the custom tool I was building (not even win8 specific, but that's what I was testing on). It's been trivial to do these things in the past with all the information posted on previous versions, I've done some of it before, but when I ran in to a wall this time I searched and search and I haven't even seen anyone talking about DPAPI in Windows 8 yet...
RE: Windows 8
posted by Passcape_Admin at 09:58:25 15.03.2014
To put it shortly, now we have multiple user keys which are used to derive a key to decode the masterkey which is used to decode a DPAPI blob. Sounds funny. But the fact is the things became much more complicated. Even though we managed to reverse the logic, overall security of the new DPAPI is a subject of further analysis. The more complex a system is, the more potential vulnerabilities it has.
Key derivation
posted by Edouard Fredding at 17:45:57 25.07.2014
Hello ! 
Your documentation is just awesome !
However, I have a question about key derivation methodology between xp and seven. I read in this article that xp used sha1 for both derivation of mkKeyEncryption and datablobKeyEncryption and sha512 for both under seven. When your program analyze a datablob file and its masterkey under xp, it appears that ALG_ID field is different (HMAC for mk and SHA1 for datablob) while it's twice SHA512 for seven. 
What does this difference means about pbkdf2 treatment ? 
Is the process of key derivation the same between these os ? 
RE: Key derivation
posted by Admin at 10:27:25 26.07.2014
Hi Edouard.
Yeah, the process of key derivation is the same (PBKDF2). The only difference is in hash algorithm used. Even though the DPAPI can be configured to use different algorithms, by default this is SHA for Windows XP and SHA512 for Win 7. Windows XP has no native support for SHA512.
Add comment