TTechniqueActive Directory

Extracting Credentials from LSASS

Credential AccessintermediateT1003.00114 min

Extracting credentials from LSASS targets the Local Security Authority Subsystem Service process to recover authentication material, NT hashes, Kerberos tickets, and plaintext credentials, from memory on a compromised host. This lesson explains what LSASS holds, why extracting from it is impactful, what preconditions matter, and how to communicate the risk clearly in interviews, reports, and stakeholder conversations.

This lesson builds on

NTLM Authentication

Why it matters

LSASS is the single richest source of credential material on a Windows host. Every user who has authenticated to the system has credential material cached in the LSASS process: NT hashes, Kerberos TGTs, and in some configurations even plaintext passwords.

Understanding LSASS extraction matters because it converts a single compromised host into a launching point for lateral movement. Interviewers expect candidates to explain not just what is extracted, but why the material is there, what types of credentials are available, and what defensive controls exist.

Key Concepts

LSASS caches credentials for single sign-on — Windows stores authentication material in the LSASS process so the system can authenticate to network resources without re-prompting the user; this is the design feature that makes extraction possible
Credential types in LSASS — NT hashes (for NTLM authentication and Pass the Hash), Kerberos TGTs and session keys (for Pass-the-Ticket), and in some configurations WDigest plaintext passwords (legacy, disabled by default on newer Windows)
Who has logged in determines the value — a workstation yields one user's credentials; a server used by many administrators yields many; domain controllers yield credentials for every recently authenticated account
Local admin or SYSTEM required — reading LSASS memory requires SeDebugPrivilege (local admin) or SYSTEM-level access; this is why local privilege escalation is a prerequisite
Credential Guard isolates LSASS material — on supported systems, Credential Guard uses virtualization-based security to isolate credential material from standard LSASS memory reads; this is the most effective defense against extraction
Memory dumps versus live reading — the attacker can either read LSASS memory directly on the target (in-memory) or dump the LSASS process to a file and analyze it offline; the dump approach may evade some endpoint detection tools

Theory

Preconditions

Extracting credentials from LSASS requires local administrator or SYSTEM-level access on the target host. The LSASS process is a protected system process, and reading its memory requires elevated privileges, either through direct access (SeDebugPrivilege, typically available to local administrators) or by creating a memory dump of the process. The attacker must have already compromised the host and escalated to local admin.

On systems with Credential Guard enabled (Windows 10+ and Server 2016+), LSASS credential material is isolated in a virtualization-based security environment that prevents extraction through standard methods.

Why it works

Windows caches authentication material in the LSASS process to support single sign-on and network authentication. When a user logs into a system, interactively, via RDP, via a service, or through a scheduled task, Windows stores credential material in LSASS so the system can authenticate to network resources on the user's behalf without re-prompting for credentials. This is a design feature, not a vulnerability: single sign-on requires cached credentials.

An attacker with local admin access can read LSASS memory because SeDebugPrivilege, available to local administrators by default, grants the ability to read any process's memory. The attacker reads the cached material and obtains the same credentials that the system itself uses for network authentication.

Attacker gain

Successful LSASS extraction yields the credential material for every user who has recently authenticated to the compromised host. This typically includes NT hashes (usable for Pass the Hash), Kerberos TGTs (usable for Pass-the-Ticket), and in older configurations or specific scenarios, plaintext passwords.

The impact scales with who has logged into the system: a workstation may yield a single user's credentials, while a server, especially a jump box, RDP gateway, or shared administration host, may yield credentials for dozens of users, including administrators. Each extracted credential enables further lateral movement, creating a cascading effect where one compromised host leads to many.

Where it fits

LSASS extraction sits at the pivot point between initial compromise and lateral movement. The typical chain is: initial access → local privilege escalation → LSASS extraction → lateral movement (Pass the Hash, Pass-the-Ticket, or direct authentication).

It is one of the first techniques an attacker executes after gaining local admin on any host, because the extracted credentials determine where the attacker can move next. The technique is iterative: each newly accessed system provides its own LSASS contents, enabling further expansion across the network.

Tools / examples

Mimikatz sekurlsa::logonpasswords: reads LSASS memory directly to extract NT hashes, Kerberos tickets, and plaintext credentials for all logged-on users
comsvcs.dll MiniDump: uses a built-in Windows DLL to create a process dump of LSASS without requiring external tools
ProcDump -accepteula -ma lsass.exe: Microsoft Sysinternals tool that creates a full memory dump of LSASS for offline analysis
Mimikatz sekurlsa::minidump: parses an LSASS dump file offline to extract credential material
Nanodump / PPLBlade: specialized tools for dumping LSASS on systems with RunAsPPL or other protections enabled

Defender view

Enable Credential Guard on all supported systems (Windows 10+ and Server 2016+). Credential Guard isolates LSASS credential material using virtualization-based security, preventing extraction through standard methods.
Enable RunAsPPL (Protected Process Light) for LSASS. This prevents non-protected processes from reading LSASS memory, though it is not as strong as Credential Guard.
Monitor for LSASS access: processes opening handles to LSASS with PROCESS_VM_READ access (Sysmon Event ID 10), suspicious LSASS memory dumps, and comsvcs.dll MiniDump usage.
Minimize the number of accounts that authenticate to each host. Avoid using Domain Admin credentials on workstations or non-DC servers, as each login caches those credentials in LSASS on that host.
Implement tiered administration: Tier 0 credentials only authenticate to Tier 0 systems (DCs), Tier 1 credentials to servers, Tier 2 to workstations. This limits the blast radius of LSASS extraction on any single host.

Communication

Explain it to a stakeholder

When employees log into a computer, Windows stores their authentication credentials in memory so they can access network resources without repeatedly entering their password. An attacker who gains administrator access to any computer can read this memory and extract the credentials of everyone who has recently logged in. If an administrator logged into a workstation, the attacker now has administrator credentials. If that administrator logged into ten workstations, compromising any one of them exposes the same credentials.

The fix involves protecting the memory where credentials are stored (using Credential Guard), limiting which administrators log into which systems (tiered access), and monitoring for unusual attempts to read this sensitive memory.

Report language

Finding: Credential Extraction from LSASS Process Memory. During the assessment, the operator gained local administrator access on HOST-WS01 and extracted credential material from the LSASS process. The extraction recovered NT hashes for three user accounts and one Domain Admin account (admin_jsmith) that had recently authenticated to the system via RDP. The Domain Admin NT hash was used to perform Pass the Hash to DC01, resulting in full domain compromise. Credential Guard was not enabled on any assessed system.

Severity: Critical.

Recommendation: Enable Credential Guard on all supported systems. Implement tiered administration to prevent Domain Admin credentials from being cached on workstations. Enable RunAsPPL for LSASS. Monitor for LSASS access events.

Common weak answers

Describing LSASS extraction as 'running Mimikatz' without explaining what LSASS caches, why it caches it, or what types of credential material are available.
Not mentioning the local admin prerequisite. Extracting from LSASS requires elevated access on the compromised host; it is not something any user can do.
Treating LSASS extraction as an endpoint technique only. The real impact is what happens after extraction: the credentials enable lateral movement across the network. The technique is the bridge between host compromise and network-wide movement.
Not understanding tiered administration and why it matters. If Domain Admin credentials are cached on a workstation, compromising that workstation yields the keys to the entire domain. This is the specific scenario that tiered access prevents.
Ignoring Credential Guard as a defense. It is the strongest mitigation against LSASS extraction and is directly relevant to whether the technique will work in a given environment.

Interview answer

Extracting credentials from LSASS targets the Windows process responsible for caching authentication material. When any user authenticates to a system, interactively, via RDP, or through a service, Windows caches their credential material in LSASS for single sign-on. An attacker with local admin access can read this memory and extract NT hashes for Pass the Hash, Kerberos TGTs for Pass-the-Ticket, and sometimes plaintext passwords.

The impact depends on who has logged into the system: a workstation yields one user's credentials, but a server used by multiple administrators can yield credentials for all of them. This is why tiered administration matters: if Domain Admins log into workstations, their credentials are cached there for any attacker who gains local admin.

The most effective defense is Credential Guard, which isolates credential material in a virtualization-based security environment that standard extraction tools cannot reach.

Follow-up questions

What types of credential material can you extract from LSASS, and what can you do with each type?
Why does who has logged into a system determine the value of LSASS extraction on that host?
What is Credential Guard, and how does it change the attacker's approach?
Why is tiered administration a more architectural defense than endpoint protection alone?
If you extracted credentials from a server and found a Domain Admin hash, what would you do next and how would you explain the significance?

Study Kit