Fantastic clear-text passwords and where to collect them (Part 2 - Windows)
A DFIR.ch deep-dive on stealthier alternatives to LSASS dumping for harvesting Windows cleartext credentials, covering WDigest re-enablement, PowerShell ConsoleHost_history.txt, AD user-attribute leaks, Group Policy Preferences (GPP) cPassword, and rogue Security Support Provider (SSP), Password Filter DLL, and Network Provider DLL registration. Each technique is illustrated with real incident-response case data (registry commands, malicious DLL names like kerberos_sp.dll and mimilib.dll, and exfiltrated log paths), paired with Sysmon Event ID 13/11 detection guidance and hardening recommendations (disabling custom SSPs, Protected Event Logging).
What it is
Part 2 of a DFIR practitioner's series on collecting cleartext Windows credentials without noisy LSASS memory dumping. The summary covers the techniques; what it can't carry are the verbatim commands, exact paths, and the specific defensive settings the post names.
How it works
The WDigest trick doesn't extract passwords itself — it makes LSASS start caching cleartext again. After setting the key, plaintext is only captured for subsequent interactive logons, so an attacker sets it and waits (or forces a re-auth). The author's incident showed cleartext appearing under the Mimikatz log's wdigest section. Note the post's framing: even a Task Manager LSASS dump was flagged "Detected, not Blocked" by EDR — the technique exists because detection ≠ prevention, especially off-hours without 24x7 SLA.
What to do
The re-enable command (attacker-side; treat any occurrence as high-severity):
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /fDetection — Sysmon Event ID 13 on:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredentialBecause WDigest caching is off by default on Windows 8.1 / Server 2012 R2 and later, any modification is anomalous — the post says trigger a high-severity alert unconditionally, not on a threshold.
PowerShell history hunting (both sides use it) lives at:
C:\Users\*\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txtTwo defensive levers the summary omits:
- Snaffler — run it yourself as a blue-teamer to find plaintext cred files before attackers do; pair with a Canarytoken on file shares.
- Microsoft Defender for Endpoint "Notify Unsafe App" setting (set to Enabled) logs and warns when users save passwords in Notepad/WordPad/Office. The post warns this generates user prompts and support calls, so socialize it first.
Caveats
This is a practitioner writeup with incident anecdotes, not a controlled study — the "buy Raccoon Stealer logs / leaked VPN creds" section is illustrative context, not a technique with a fix. The WDigest requirement (plaintext only on logons after the key is set) means detection has a window before any credential is actually exposed; catching the registry write is the intervention point, not the dump.
Organisations named here
- MS14-025
- WDigest
CVEs named here
- CVE-2023-36036
Technologies named here
- Windows 8.1
- Snaffler
- Mimikatz
- Windows Server 2012 R2
- mimilib.dll
- Windows 10
- Windows Server 2025
- DetectRaptor Velociraptor artifact
- Active Directory
- Canarytoken
- Microsoft Defender for Endpoint
- Group Policy Preferences / SYSVOL
- Microsoft Defender for Identity
- Sysmon
- PSReadLine
- Invoke-LoginPrompt
- Windows
- PowerShell
Techniques named here
- LSASS memory dumping
- WDigest UseLogonCredential abuse
- Rogue Security Support Provider registration
- Malicious Password Filter DLL
- Malicious Network Provider DLL
- Group Policy Preferences cPassword extraction
- Credentials in Active Directory attributes
- Credentials in files / command history
- Fake login prompt credential harvesting
- Stealer log / leaked credential purchase
- Killing LSASS after SSP registration
Threat actors named here
- ProjectSauron
- Raccoon Stealer
- Unnamed threat actor
Related in Offensive Security