Microsoft's Data Protection API (DPAPI) has long been the silent workhorse of Windows credential management, encrypting everything from browser passwords to Wi‑Fi keys. But a newly released tool—DPAPISnoop—is drawing sharp attention to an obscure artifact that DPAPI leaves behind: the CREDHIST file. This file stores a user's historical password hashes, and DPAPISnoop can rip them out and prep them for offline brute‑force attacks. In June 2026, security researcher Cryptika published the open‑source tool alongside a detailed technical write‑up, and the impact is immediate for both forensics practitioners and defenders trying to lock down enterprise Windows environments.

The discovery is not that CREDHIST exists—Microsoft has documented it for years—but that an attacker who obtains a single DPAPI master key can silently extract years of previous passwords. Those hashes, often representing weaker or reused credentials, crack quickly with modern hardware. The result: a lateral‑movement goldmine that can outlive daily domain‑admin password rotations.

The DPAPI and CREDHIST: A Hidden Vault of Password History

To understand DPAPISnoop, you first have to grasp how DPAPI guards secrets. DPAPI uses a master key derived from the user's login password to symmetrically encrypt blobs of data. Those blobs are stored on disk, and as long as the master key is available—either by decrypting it from the user's profile or fetching it from memory—the secrets can be recovered. This mechanism protects the Windows Credential Manager, browser auto‑fill databases, certificate private keys, and a host of other sensitive material.

CREDHIST is one of those protected blobs. You'll find it at %APPDATA%\Microsoft\Protect\CREDHIST. When a user changes their password, Windows saves a hash of the old password inside this file. The purpose is not to be user‑friendly; it's to enforce Group Policy settings like "Enforce password history" and "Minimum password age." If a user tries to reuse one of the last N passwords, Windows checks the CREDHIST blob to see if the proposed new password's hash matches a stored entry.

The core problem: CREDHIST entries are not discarded when a password policy's history limit is reached. Once written, they persist until the file is manually deleted—which almost nobody does. Over time, the file accumulates years of past passwords. And because the entire file is a single DPAPI blob, anyone who can decrypt it can potentially retrieve every historical hash, not just the ones still enforced by the policy.

Inside DPAPISnoop: How the Tool Works

DPAPISnoop automates what was previously a manual, multi‑tool forensic process. It needs two pieces: the DPAPI master key and the CREDHIST file itself. In a forensic lab, examiners might extract the master key from a memory image using tools like Mimikatz's sekurlsa::dpapi or from the offline decryption of the master‑key file if they already possess the user's password. In an offensive scenario, an attacker who escalates to local administrator privileges can obtain the master key directly—either by dumping LSASS memory, injecting into a process that runs as the target user, or decrypting the master‑key file with the user's stored password hash.

Once fed those inputs, DPAPISnoop performs the DPAPI decryption and then parses the internal structure of the CREDHIST blob. Each historical entry contains not a raw NTLM hash, but a password‑derived value used by Windows' own internal comparison routines. Cryptika's tool extracts these values and formats them for popular hash‑cracking utilities, specifically Hashcat mode 14000 (DPAPI master key) and a custom mode for the CREDHIST entries. The output is a clean hash list that can be thrown at dictionary attacks, rule‑based mutations, and brute‑force masks.

The tool also includes a feature to verify that the decrypted blob is valid by checking a known magic byte, reducing false positives when working with damaged or truncated files. This makes it faster for forensic analysts to triage evidence without worrying about corrupted data.

Offline Attacks on Historical Credentials

When DPAPISnoop produces that list of historical hashes, it unlocks a unique kind of offline attack. The hashes correspond to passwords the user has already abandoned—often because the organization forced a change. Users tend to recycle small permutations: "Summer2024!" becomes "Summer2025!" or "CompanyName#1" becomes "CompanyName#2." An attacker who cracks even one old password can then guess the pattern for the current one.

Worse, many users carry the same password across personal and work accounts. A historical hash may match a credential scrambled in a third‑party breach database. Armed with that match, the attacker doesn't even need to crack the hash; they can look up the plaintext from a breach‑corpus lookup service. This turns DPAPISnoop's output into an instant pivot point, even when the current Active Directory password is invisible to traditional credential‑dumping tools.

Forensic and Offensive Implications

For forensic investigators, DPAPISnoop closes a gap that has existed since DPAPI was introduced in Windows 2000. Previously, extracting CREDHIST was possible but required chaining together multiple tools and understanding the blob's binary layout. Now, an examiner can quickly produce a timeline of password changes, map out password‑reuse patterns, and establish whether a suspect's historical credential fit a known weak‑password profile. This directly aids in insider‑threat investigations and can reveal accounts that an attacker may have used before leaving the organization.

For red teams and penetration testers, the tool represents one more post‑exploitation prize. It requires high‑integrity access, but once inside, DPAPISnoop can scalp credential histories that other tools ignore. The extracted hashes often crack faster than the current NTLM hash because they represent older, less‑stringent password policies. In one demonstration, Cryptika’s team cracked 90 percent of historical hashes within 30 minutes using consumer‑grade GPUs. That success rate suggests that any organization that enforces password history for more than a few cycles is sitting on a stockpile of easily‑recoverable credentials.

Defensive Strategies

Mitigating DPAPISnoop—and the broader threat of offline DPAPI attacks—requires a layered approach. First, protect the DPAPI master key. The master key is encrypted with a key derived from the user's password and is stored on disk; if an attacker can learn the password or dump it from memory, the master key is compromised. Enabling Credential Guard inside Windows Defender isolates LSASS and prevents trivial memory dumping. Configuring Secure Boot and Boot Manager revocations ensures attackers can't load an unsigned driver to scrape master keys from memory at boot time.

Second, limit the visibility of CREDHIST. Group Policy offers no built‑in way to clear historical entries once they exceed the history‑count threshold. Administrators can, however, delete the file if it's not needed—though this must be done carefully, because the file is also used to enforce password history during password changes. A safer approach is to reduce the password‑history count itself, which limits the number of recent passwords stored (but older entries may still linger in the blob until the next password change forces a pruning). Microsoft could address this by adding a cleanup routine that truncates the blob after a password change, but no such mechanism currently exists.

Third, monitor for suspicious DPAPI access. Security information and event management (SIEM) solutions can flag processes that access the master‑key files or the CREDHIST path. Unusual reads by non‑Microsoft processes should trigger an alert. For high‑security environments, consider enabling Windows Defender Application Control to restrict which binaries can invoke DPAPI functions.

Finally, move beyond passive credential hygiene. Implement multi‑factor authentication so that even a cracked historical password can't grant access to critical systems. Track password‑reuse across accounts using tools like Microsoft Entra Password Protection, which detects when a user attempts to set a password that matches a known compromised password. And educate users that changing "password1" to "password2" doesn't help when DPAPISnoop can harvest both.

Expert Commentary on the Risk

Cryptika’s disclosure emphasizes that DPAPISnoop is not a zero‑day; it's a tool that democratizes a known forensic technique. "Administrators have long underestimated the forensic value—and offensive risk—of DPAPI's historical cache," Cryptika wrote in the accompanying blog. "CREDHIST is like finding a box of old house keys under the welcome mat. The current key may be hidden, but those old ones still open doors." The researcher urges Microsoft to add an official mechanism for purging CREDHIST on a schedule and for enterprises to treat DPAPI blobs as sensitive data that needs explicit protection.

Other security researchers have validated the tool in lab tests. One incident responder, speaking on condition of anonymity, said that DPAPISnoop had already been used to resolve a five‑year‑old insider‑threat case by linking a historical password to a document that had been encrypted with an older credential. "The file was protected with a password that had been changed three times since the document was created," they explained. "DPAPISnoop let us pull the hash of the exact password used when the document was locked, crack it, and open the file. That was previously a manual, hit‑or‑miss operation."

What Comes Next

DPAPISnoop’s release will likely spur a wave of improvements to DPAPI security. Microsoft could update the CREDHIST blob format to expire old entries automatically or tie decryption to a TPM‑bound key that isn't cachable in memory. Until then, defenders must assume that a compromise of the local system equals a total compromise of the user's past credentials. The tool also reinforces why physical security remains critical: a lost or stolen laptop that isn't encrypted with BitLocker and secured with a TPM can be trivially imaged, and DPAPISnoop can then be run against the disk offline.

In the near term, security teams should audit their password‑history policies. Do you really need to remember the last 24 passwords? Drop that number to 5 or 10, and the CREDHIST blob shrinks. Combine that with regular—and enforced—multi‑factor authentication, and the value of those old hashes drops dramatically. Windows admins should also test DPAPISnoop in their own labs to understand how much history they're exposing and use that data to harden their environments.

DPAPISnoop is available on GitHub under a permissive license. Cryptika plans to maintain it as a modular library so other tools can integrate CREDHIST parsing without reinventing the DPAPI wheel. For forensic examiners, it will become a staple. For attackers, it’s yet another reminder that Windows hides a wealth of memories just waiting to be unearthed.