Password Recovery Software

DPAPI Credential History

• Credential History in DPAPI
• CREDHIST data structure
• CREDHIST encryption
• CREDHIST vulnerability

What happens when changing Windows password

• Password change and DPAPI
• Regular password change
• Forced password reset (stanalone PCs under Windows XP - Windows 7)
• Forced domain user password reset
• Password reset (local PC Win2K)

Recovering data from DPAPI blobs

• Recovering data from DPAPI blobs
• Finding DPAPI blobs on disk
• Looking for DPAPI blobs in registry and Active Directory
• Recovering wireless connection passwords in Windows 7
• Recovering Facebook passwords stored in Internet Explorer
• Recovering user password without loading hashes from SAM/NTDS.DIT
• Decrypting credential history hashes from DPAPI

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];
} CREDENTIAL_HISTORY, *PCREDENTIAL_HISTORY;

Figure 6 shows the data storage scheme used in CREDHIST.

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.)

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.
 

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.

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.

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.

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.

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.

Conclusion

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.