During Red Team engagements, Data Protection API ( DPAPI ) often arises when recovering browser material, extracting saved credentials, or acquiring and decrypting user Master Keys. While revisiting DPAPI internals , another art e fact caught our attention : CREDHIST . When a user changes their password, old DPAPI blobs still need to be decrypted , so Windows maintains a password history chain that allows previous DPAPI password material to be recovered. After some investigation into CREDHIST, we have updated DPAPISnoop to support extracting CREDHIST entries into offline - crackable hash lines, alongside its existing Mas ter Key has h extraction functionality. That change opened an interesting path where previously recovered passwords could now be used to identify a user’s password pattern s over time. GitHub - DPAPIsnoop : https://github.com/nettitude/DPAPIsnoop Background DPAPI has been covered extensively over the years by Passcape , Mimikatz , SpecterOps , DPAPI ck , and many others. The usual DPAPI target is the user's Mas ter Key, as recovering it allows decryption of the user's DPAPI - protected blobs. CREDHIST has also been previously documented in “Recovering Windows Secrets and EFS Certificates Offline” ( 2010 ) . DPAPIc k implemented offline recovery, Mimikat z can parse it, Dissect can process it, and commercial tooling has supported it for many years . The gap explored here was whether, given access to a user's CREDHIST entries, hashes could be extracted for offline cracking and the rest of the chain walked? Looking at the file A CREDHIST file sits under the user's DPAPI protection directory , %APPDATA%\Microsoft\Protect. T he file’s structure has been previously documented and can be seen below . (Click to zoom) Of interest are the following fields : T he user's SID (Security Identifier) T he hash algorithm T he encryption algorithm T he PBKDF2 (Password-Based Key Derivation Function 2) round count A 16 - byte IV ( Initialisation Vector) T he encrypted historical material C redential history entries are stored sequentially as a chained series of encrypted hashes. Each entry is encrypted with key material derived from a n older password , while the newest entry uses material derived from the user's current password. (Click to zoom) Therefore , c racking the newest CREDHIST entry recovers the user’s current password. Additionally, CREDHIST entries in the middle of the chain can be extracted and attacked directly as standalone hashes. In that case, a successful crack recovers the password material that protects that specific entry, while the decrypted entry reveals the next older password’s SHA1/NTLM material. Why this is useful In most modern Windows environments, CREDHIST entries typically use SHA-512 PBKDF2 with AES-256 and 8,000 rounds, which aligns with the DPAPI Mas ter Key protection. On older CREDHIST entries , however , the cracking cost can be substantially lower . Legacy 3DES + HMAC-SHA1 entries use SHA-1 based PBKDF2, which is significantly faster to attack than SHA-512. The practical difference between attacking a Master Key hash and a CREDHIST hash is that cracking a CREDHIST entry provides historical SHA1 and NTLM material directly. Furthermore, additional value comes from password intelligence , where historical passwords often reveal predictable user patterns . Ask yourself: how many times have you found notes or files containing old passwords? Now consider how those could be used to unlock previous entries and gain insight into a user's password habits. Tooling To facilitate the retrieval of hashes, the open - source C# tool DPAPISnoop was extended to extract CREDHIST entries alongside DPAPI Master Key hashes. When provided with the current password or its SHA1 value, the tool can also decrypt the CREDHIST chain directly. For e ach extracted CREDHIST entry , the tool output s an offline - crackable hash – the structure of which can be seen below, starting with the identifier $ credhist $ . (Click to zoom) Additionally, t wo new H ashcat modes were implemented: 15920 - DPAPI CREDHIST entry using 3DES + HMAC-SHA1 15930 - DPAPI CREDHIST entry using AES-256 + SHA-512 Their source code can be found on our GitHub . P ull requests to upstream Hashcat are the next step. In practice Running the tool as a non -administrator user will only fetch the current user ’s Master Key hash and CREDHIST hashes, as can be seen below: We can then take the above hashes and feed them into Hashcat using the newly developed modules (15920 and 15930): After H ashcat recovers a password, it can then be pass ed back to DPAPISnoop . The tool tr ies the password against every entry from newest to oldest and walks from the first entry it can decryp t : Defensive Considerations This behavio u r is not a Windows vulnerability. It is a consequence of DPAPI’s password history design and is similar to other existing DPAPI tradecraft. Domain backup keys, Master Key files, browser state keys and Credential Manager blo...