The Finer Details of LSA Credential Recovery

Evan McBroom

REcon 2025 · Day 3 · Main Track · Reverse Engineering

Overview

Windows Local Security Authority (LSA) credential recovery has been a cornerstone of post-exploitation tradecraft for years, but the field's public knowledge base has a critical gap: the gap between t

Watch on YouTube

Visual summary for The Finer Details of LSA Credential Recovery by Evan McBroom
Visual summary for The Finer Details of LSA Credential Recovery by Evan McBroom

Key moments

  1. 2:18 LSASS internals: Mimikatz source mapped to Windows credential structures
  2. 10:46 SSP DLL architecture: two forms of credential storage providers
  3. 22:52 Deep dive: AVL tree structure storing active LSA credential nodes
  4. 35:36 Undocumented field: enumeration for active vs. deleted credential entries
  5. 40:52 Mitigations section: Credential Guard, WDigest disabling, and logical bypasses
  6. 43:22 Using Microsoft documentation to reverse undocumented LSA structures
  7. 50:32 Extended attack surface: credentials stored beyond LSASS user memory

The Finer Details of LSA Credential Recovery

Speakers: Evan McBroom, Systems Developer, SpecterOps

Conference: REcon 2025

YouTube: https://www.youtube.com/watch?v=G2CfMWXLU1U

Overview

Windows Local Security Authority (LSA) credential recovery has been a cornerstone of post-exploitation tradecraft for years, but the field's public knowledge base has a critical gap: the gap between the well-known offline techniques (dumping from a powered-off drive) and what can actually be recovered from a live system's LSASS memory once you already have access. Most public knowledge points to Mimikatz source code — but that source code is notoriously difficult to follow, was reverse-engineered rather than built from official structures, and does not match what private symbol leaks show Microsoft actually uses internally.

In this talk, Evan McBroom of SpecterOps presents a fresh, authoritative map of LSASS credential data structures using the actual Microsoft types obtained from private PDB symbol leaks, Windows source code repositories, and patent filings. He covers every major authentication package — MSV1, Kerberos, PKUTU, WDigest, TSPkg, and CloudAP — showing exactly which data structures store credentials, how to enumerate them using public symbols (rather than byte signatures), and what Mimikatz is missing. He then surveys modern mitigations — Credential Guard, PPL (Protected Process Light), NTLMv1 removal — and presents logical bypasses for each, including a technique for evading Credential Guard's TGT session key protection.

The talk culminates in a "final scorecard" showing which credential types are still recoverable from a fully hardened Windows 11 24H2 enterprise system — and the answer is: more than most defenders expect.

Background

▶ Watch: LSASS internals: Mimikatz source mapped to Windows credential structures (2:18)

LSA is the Windows subsystem responsible for authenticating users. When a logon session is created, LSASS (the LSA Subsystem Service process) receives the user's credentials, routes them through a set of loaded Authentication Packages (APs), and stores credential material in various in-memory data structures. These structures persist as long as the logon session exists.

The challenge for researchers — and the reason this area is hard to get right — is that the data structures are undocumented, and most public knowledge comes from reverse engineering work done without access to the actual Microsoft-internal type definitions. Mimikatz, the canonical tool for this work, uses byte signatures to locate structures in memory rather than public symbols, which makes it brittle across Windows versions and harder to understand.

Two developments changed what is possible:

  1. Private PDB symbol leaks: At some point, private debug symbols for Windows 10 were distributed outside Microsoft and uploaded to the Internet Archive. These PDBs contain the actual internal type names and structure layouts Microsoft engineers use. While they cover Windows 10 builds, they largely match Windows 11 24H2 in practice.
  2. Windows source code leaks on GitHub: Source code for NT 3.5 through 5.2 (the Windows Research Kernel) is available, providing historical design context. The Windows Research Kernel (version 5.2) is particularly valuable since many core LSA structures remain stable through Windows 11.

McBroom also maintains the LSA Whisperer Development Kit (LWDK) — a library in a branch of his LSAWhisperer GitHub repository that exposes all the private PDB-derived credential-related types in usable C++ form.

Key Findings

▶ Watch: Deep dive: AVL tree structure storing active LSA credential nodes (22:52)

Most Authentication Packages Are Not Covered by Mimikatz

McBroom's central finding is that Mimikatz, despite being the gold standard for credential recovery, enumerates only a subset of the credential data structures in LSASS. Specifically:

  • About half of the credential data structures covered in this talk are not supported by Mimikatz at all. For packages like Kerberos, PKUTU, and WDigest, there are additional credential list and context list structures beyond what Mimikatz accesses.
  • Some packages with multiple credential-bearing data structures are only partially enumerated — and the structure Mimikatz happens to enumerate may sometimes be empty while the un-enumerated one is populated.

Byte Signatures Are Almost Never Necessary

Mimikatz locates most of its data by scanning LSASS memory for known byte patterns — a technique that requires ongoing updates as Windows changes. McBroom demonstrates that for virtually every credential structure, public symbols provide a global variable that directly points to the start of the data structure's linked list or tree. Byte signatures are needed in exactly one case he found: the TS_USER_BC_CONTEXT_TABLE in TSPkg, for which Microsoft removed the public symbol while keeping the structure in memory (its name was recovered from the leaked private PDBs).

Magic values (unique 4-byte constants embedded in structures) can substitute for public symbols in most remaining cases, since they are unique enough that a memory scan will reliably locate the correct structure type.

Credential Guard Has More Bypasses Than Generally Known

Credential Guard primarily protects MSV1 and Kerberos credentials by isolating them in a VSM (Virtual Secure Mode) enclave. A Credential Guard bypass discovered by Kerry Coburn (presented at SO-CON) demonstrated that Credential Guard's check preventing TGT session key exfiltration compares the SPN against the literal string KRB_TGT. Since the Kerberos RFCs define several valid encoding schemes for SPNs, alternative encodings pass the check and return a usable TGT with a valid session key. At the time of this talk, Microsoft had patched only one encoding scheme — the others remain viable research areas.

NTLMv1 Is Not Actually Removed

Microsoft publicly announced removal of NTLMv1 from Windows 11 24H2 and Server 2025. McBroom disputes this, demonstrating that the LM20GetChallengeResponse API in the MSV1 authentication package still accepts a server challenge and returns a full NTLMv1 response — unless Credential Guard is enabled. This means that in environments without Credential Guard (which requires Enterprise or Education licensing), NTLMv1 responses can still be requested and then cracked using a rainbow table (controlling the server challenge eliminates the salt, allowing precomputed lookups).

Technical Deep Dive

▶ Watch: Undocumented field: enumeration for active vs. deleted credential entries (35:36)

LSASS Architecture: Authentication Packages and the SPM

When a logon occurs, WinLogon sends credentials to LSASS, which routes them through the Security Package Manager (SPM) — an undocumented internal subcomponent. The SPM distributes credentials to all registered authentication packages. Each package is a DLL implementing either:

  • Authentication Package (AP) functionality — logic for authenticating a user (e.g., comparing hashes against the local SAM)
  • Security Package (SP) functionality — implementing an on-the-wire protocol (e.g., NTLM, Kerberos)

Many DLLs implement both. For credential recovery, only AP functionality matters.

The Global LSA Logon Session List (MSV1)

The global LogonSessionList / LogonSessionTable variable (retrievable from public symbols) points to a doubly-linked list. Each entry has:

  • PackageCredentials → singly-linked list with a CredentialsList member
  • The CredentialsList member contains a single DPAPI-encrypted blob

After DPAPI decryption, the result is the MSV1 Primary Credential structure. On modern Windows (post-10.0.16299/1607), this structure contains:

  • Username, domain name
  • A SecretsWrapper pointing to a CredISOObject (the Credential Guard API handle)
  • A CredentialKey (shown in Mimikatz output labeled as DPAPI) — usable to decrypt DPAPI-protected user data
  • A Secrets union: either cleartext data (NTLM hash, SHA hash — if Credential Guard is off) or an opaque encrypted blob (if Credential Guard is on)

MSV1 also maintains a separate package-local CredentialList (global variable, public symbols, doubly-linked list) containing plaintext passwords, usernames, and a magic tag value (CRED_ACTIVE or CRED_DELETED). This same magic value is reused by Kerberos — scanning memory for it will find both MSV1 and Kerberos structures.

Kerberos Data Structures

The Kerberos package (Vista and later) maintains:

  • Logon session list (global variable, AVL tree after Vista — not a doubly-linked list)
  • CredMan credentials → doubly-linked list → PrimaryCredential structure (plaintext passwords, ticket caches, PINs)
  • ExtraCreds → encryption keys used for TGT pre-authentication (ekeys in Mimikatz output — stored as StoredCredential typed members post-Vista)
  • Context list (global variable, doubly-linked list with its own unique magic value) — contains session keys for active Kerberos contexts
  • Session key list (global variable, doubly-linked list) — ASN.1-encoded session keys paired with tickets

Mimikatz does not enumerate the context list or session key list. These can contain session keys for tickets that would otherwise appear unusable.

PKUTU (Public Key User-to-User)

PKUTU is a Kerberos extension protocol for intra-ID (Azure AD) joined hosts. Its usage is expected to grow as Microsoft pushes more organizations to intra-ID. The package uses:

  • Credential table (global variable, AVL tree) → SecondaryCredentialPrimaryCredential (ticket caches, peer-to-peer keys)
  • Context list — no global symbol found; scrape memory using the unique magic value. Contains AssociatedCredentials → ticket caches and peer-to-peer keys
  • Every structure in PKUTU has a unique magic value for memory scraping

Microsoft has not added PKUTU to Credential Guard's protection scope. McBroom recommends this as a priority defensive improvement.

WDigest

WDigest is disabled by default on modern Windows (registry key UseLogonCredential must be set to 1 to re-enable it). When enabled, it maintains three data structures, all findable via public symbols:

  1. LogonSessionList — the only structure Mimikatz enumerates; stores username, domain, plaintext password
  2. ContextList — a doubly-linked list; can also store plaintext credentials (not enumerated by Mimikatz)
  3. CredentialList — a doubly-linked list; can also store plaintext credentials (not enumerated by Mimikatz)

Enumerating all three maximizes credential recovery from WDigest.

TSPkg (Terminal Services / RDP)

TSPkg stores credentials for RDP authentication:

  • Credential table (global variable, AVL tree) → credential structure → two PrimaryCredential members (plaintext passwords)
  • Context table — requires byte signatures because the global variable TS_GLOBAL_CONTEXT_TABLE was removed from public symbols on newer Windows (name recovered from private PDBs as TS_USER_BC_CONTEXT_TABLE). An AVL tree with a Context member containing credential key, primary creds, and encryption keys. Notably uses an enumeration (0 or 1) rather than a magic value for active/deleted state — the one structure in the talk that cannot be scraped by magic value.

Mimikatz does not enumerate the TSPkg context table.

CloudAP

The Cloud Authentication Package handles logon via intra-ID (Azure AD) or Microsoft accounts. It stores:

  • Logon sessions (global variable, doubly-linked list) → UserCacheEntry → user-specific credentials (PRT for intra-ID, POP cookie/token for Microsoft accounts)
  • Alternative enumeration via a second global variable pointing directly to the user entry list

This is the most unstable package: data structures change frequently across Windows versions, private symbols are not available for Windows 11, and the credential format varies by account type. McBroom recommends this as the highest-priority research area for the community.

Mitigations and the Final Scorecard

| Mitigation | Effect |

|---|---|

| Disable WDigest | Removes all WDigest credentials |

| LSASS as PPL | Prevents LSASS memory access entirely (without a bypass) |

| Credential Guard | Blocks MSV1 NTLM/SHA hashes, Kerberos TGT session keys |

| NTLMv1 "removal" | Does NOT remove NTLMv1 response generation (unless Credential Guard enabled) |

Remaining credentials after full mitigation stack + logical bypasses:

  • PPL bypass → all credentials not protected by Credential Guard (CloudAP, PKUTU, TSPkg)
  • Credential Guard TGT bypass (Kerry Coburn technique) → valid TGT with session key
  • LM20GetChallengeResponse API call → NTLMv1 response (if Credential Guard not enabled) → crackable to NTLM hash for pass-the-hash
  • MSV1 GetCredentialKey API → credential key → DPAPI decryption capability
  • CloudAP API calls → PRT / POP token → cloud authentication as the user

Demo / Proof of Concept

▶ Watch: Using Microsoft documentation to reverse undocumented LSA structures (43:22)

McBroom did not present an exploitation demo in this talk. The presentation is primarily a research and documentation exercise: producing the "treasure maps" (his term) of data structure layouts that someone writing their own credential recovery tool would need. The flowchart slides on his GitHub serve as implementation guides.

He references his broader LSA Whisperer tool (presented at SO-CON 2024) as the practical implementation of the API call-based credential recovery described in the mitigations bypass section.

Defensive Implications

▶ Watch: Extended attack surface: credentials stored beyond LSASS user memory (50:32)

For defenders and blue teamers:

  • Enable Credential Guard if you are on Enterprise or Education licensing. It materially limits what can be extracted even from a compromised system with PPL bypassed.
  • The NTLMv1 "removal" in Windows 11 24H2 is incomplete — unless Credential Guard is enabled, NTLMv1 responses can still be generated on demand. Do not treat the announcement as a complete mitigation.
  • Adding PKUTU to Credential Guard's protection scope is a high-priority gap, especially as intra-ID adoption grows.
  • Microsoft should consider replacing magic values in authentication package structures with proper state enumerations (as TSPkg's context table already does). This would break memory-scraping-based credential recovery without relying on the fragile PPL boundary.

For red teamers:

  • Stop relying on Mimikatz byte signatures; use public symbols for a more reliable, less fragile implementation.
  • Enumerate all credential data structures per package (not just the ones Mimikatz accesses) — context lists and credential lists in Kerberos and WDigest can contain credentials when the primary list is empty.
  • The LM20GetChallengeResponse API call with a controlled server challenge is a highly actionable technique in environments without Credential Guard — specify a challenge that aligns with a known rainbow table to instantly convert a live NTLM response into a reusable hash.
  • The Kerberos SPN encoding bypass for Credential Guard TGT session key exfiltration remains valid for all but one encoding scheme — additional bypass variants are likely available.

For tool developers:

  • The LSA Whisperer Development Kit (LWDK branch of the LSAWhisperer repo) provides ready-to-use C++ type definitions derived from private PDBs, covering all structures discussed in this talk.
  • The private Windows 10 PDBs on the Internet Archive match Windows 11 24H2 structures well enough to be used as primary references; validate against Ghidra analysis of the 24H2 modules.

Key Takeaways

  • Mimikatz covers roughly half of the available credential data structures in LSASS. Writing your own tool with public symbols will recover more credentials from more packages.
  • Public symbols are almost always sufficient. Byte signatures are needed in only one case (TSPkg context table); magic values can substitute for public symbols in most other cases.
  • Credential Guard is not a complete solution, but it is the most impactful mitigation available. Its Kerberos TGT protection has a known bypass (SPN encoding schemes), and NTLMv1 response generation remains available without it.
  • PKUTU is an unprotected growth vector. As intra-ID adoption increases, the credentials PKUTU handles will become more valuable — and they are not currently covered by Credential Guard.
  • The CloudAP package is the most valuable underexplored research target. Its structures are unstable, lack published private PDB coverage for Windows 11, and store credentials for cloud authentication that are increasingly the highest-value targets in enterprise environments.

About the Speaker

Evan McBroom is a systems developer at SpecterOps on the Internal and Community Products team, where he writes Windows C++ tooling for red team operators and open-sources as much as possible. He is the developer of the LSA Whisperer tool (presented at SO-CON 2024) and maintains the LSA Whisperer Development Kit as a community reference library for LSA credential recovery research. He also contributes to the Mythic C2 framework and the Ghostwriter report management platform. He credits Benjamin Delpy (author of Mimikatz) as the foundational influence on this area of research.

Reviews

Dr. Zero (Offensive Security Researcher) — STRONG ACCEPT

The most authoritative public map of LSASS credential structures ever produced — required reading for anyone writing post-exploitation tooling, and a direct rebuke to a decade of Mimikatz cargo-culting.

Heather Calloway (CISO) — WEAK

Rigorous LSA credential structure documentation for people who write offensive Windows tooling — genuinely useful for that audience, but the defensive guidance is thin and the governance story is absent, which limits what I can take back to a room that needs to know what to do with this.

→ Top-rated talks at REcon 2025

All talks from REcon 2025