Skip to content

User activity

DPAPI and Credential Manager

DPAPI and Credential Manager cheat sheet: master keys, Windows Vault, what secrets they hold, offline decryption requirements and credential-theft traces.

Location
%APPDATA%\Microsoft\Protect\<SID>\
Proves
Which secrets a user stored (RDP, browser, Wi-Fi, app creds) and, offline, their plaintext
Timestamps
Blob and master-key file $SI/$FN times (NTFS, UTC); master-key GUID files carry an internal modification time
Retention
Persist until the account or credential is deleted; old master keys are kept so older blobs stay decryptable
Access
SYSTEM or the owning user; master-key and Credentials files are readable but decryption needs the user secret or domain backup key
Type
File / file system
Windows
XPVista / 78 / 8.11011
KAPE target
No dedicated target
Velociraptor
No dedicated target
  • SecretsDump: For authorized incident response only.

What it is

The Data Protection API (DPAPI) is the Windows service that encrypts secrets on behalf of applications so they never have to store a key themselves. Wi-Fi passwords, saved RDP credentials, browser cookie and password keys, scheduled-task passwords and many application secrets are all DPAPI-protected blobs. Each blob is encrypted with a per-user (or per-machine) master key, which is itself derived from the user's password (or a machine secret) and, in a domain, backed up to the domain controller. The Credential Manager and Windows Vault are the user-facing stores that hold many of those blobs. For an investigator, these files answer two questions: what secrets did this account keep, and (given the right key material) what were they.

Location

ItemPath
User master keys%APPDATA%\Microsoft\Protect\<SID>\<GUID>
Machine master keys%WINDIR%\System32\Microsoft\Protect\S-1-5-18\
Credential Manager blobs%LOCALAPPDATA%\Microsoft\Credentials\, %APPDATA%\Microsoft\Credentials\
Vault%LOCALAPPDATA%\Microsoft\Vault\, %APPDATA%\Microsoft\Vault\, %WINDIR%\System32\config\systemprofile\AppData\...\Vault\
DPAPI backup key (DC)LSA secret on the domain controller (extracted offline)

The Protect\<SID> folder also contains a Preferred file naming the current master-key GUID. Exact layout is stable across Vista through Windows 11; XP used an older master-key format.

What it proves

  • That secrets were stored by the account: a Credential Manager entry for a server, share or website shows the user saved credentials for it, even before you decrypt anything.
  • What the secret was, only after successful decryption with the correct key material. The blob metadata alone does not reveal the plaintext.
  • It does not prove the credential was ever used, nor by whom. Presence of a master key does not by itself indicate theft; DPAPI blobs are created in normal use.

Key fields

FieldMeaning
Master-key GUIDFile name under Protect\<SID>; each blob references the GUID that protects it
Blob GUID / descriptionCredential target (for example Domain:target=TERMSRV/host for saved RDP)
Protected dataAES/3DES-encrypted secret, unlocked via the master key
PreferredPoints to the currently active master key
Backup key referenceIndicates domain backup (bk-<domain>) was available at creation

Timestamps

Master-key and Credentials files carry standard NTFS $STANDARD_INFORMATION and $FILE_NAME timestamps (UTC on disk). The creation time of a master-key GUID file approximates when the account or its password was first set on this host; a new master key often appears after a password change. Do not read blob file times as the moment a credential was used.

Retention and clearing

Master keys are not deleted when a password changes; Windows keeps old keys so older blobs remain decryptable, which is useful long after the fact. Credential Manager entries persist until the user removes them (cmdkey /delete or Control Panel). Deleting a profile removes the Protect\<SID> folder, but shadow copies or backups often retain earlier copies. See volume shadow copies for recovery.

Collection

Collect the master-key folders, Credentials and Vault folders, plus the SAM/SECURITY/SYSTEM registry hives (for local secrets and boot key) together, because decryption needs them as a set.

cmdkey /list
robocopy %APPDATA%\Microsoft\Protect E:\case\Protect /E /COPY:DAT
robocopy %LOCALAPPDATA%\Microsoft\Credentials E:\case\Credentials /E /COPY:DAT

Offline decryption requires one of: the user's plaintext password, their NTLM hash, or the domain DPAPI backup key (extracted from the DC, which decrypts any domain user's master keys). Document which you used for chain of custody.

Parsing tools

  • SharpDPAPI (open source): enumerates and, with a password/hash/backup key, decrypts master keys, credentials, vaults and RDP/browser secrets. Named factually here for defensive triage.
  • impacket dpapi.py (open source): the masterkey, credential and vault subcommands parse and decrypt blobs offline from collected files; pairs with secretsdump output.
  • DataProtectionDecryptor (NirSoft, free GUI): decrypts DPAPI data given the user login password or key.
  • mimikatz dpapi:: modules parse the same structures; treat any mimikatz presence on the host itself as suspicious.

Investigation tips

  • Saved RDP credentials (Domain:target=TERMSRV/* in Credential Manager) are a common pivot for lateral movement; correlate with RDP connections.
  • Browser password and cookie keys are DPAPI-protected; a decrypted key lets you read the browser artifacts store.
  • Access to Protect\<SID> or Credentials by an unusual process, or a copy of these folders staged for exfiltration, can indicate credential theft. Treat this as a lead to corroborate, not proof on its own.
  • On a domain compromise, extraction of the DPAPI domain backup key from a domain controller lets an attacker decrypt every user's secrets; check DC access around the incident window.
  • Machine master keys under S-1-5-18 protect service and scheduled-task credentials; do not overlook them when only user data seems present.

Related artifacts

Glossary terms

Guides

All artifacts on one page: cheat sheet