TTechniqueActiveDirectory
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.
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.
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.
MITRE · Official MITRE ATT&CK reference for LSASS credential dumping, including procedure examples, detection, and mitigations
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.
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.
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.
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.
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.
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.