LSASS Credential Theft: Step-by-Step Attack Chain and Defenses
Attackers bypass modern authentication by reading plaintext secrets directly from the memory of the Windows security process, a method that renders many traditional password policies ineffective.
Threat actors compromise the Local Security Authority Subsystem Service to extract cached credentials. They inject code into its memory space or dump its process state. This yields plaintext passwords and Kerberos tickets. Defense requires restricting access to the LSASS process and monitoring for specific injection techniques.
The Value of the Local Security Authority
The Local Security Authority Subsystem Service, known as LSASS, is a critical Windows process responsible for enforcing security policies. It handles logon requests and generates access tokens for users and applications. Because it mediates authentication, it must store credentials to verify identities against domain controllers. This storage requirement creates a high-value target for attackers. If an adversary gains control of LSASS, they can extract secrets without needing to crack hashes or intercept network traffic.
The process does not store passwords in plain text by default in modern Windows environments. However, certain legacy protocols and configuration choices force the system to keep secrets in memory longer than necessary. Attackers exploit this gap. They do not need to break encryption; they simply need read access to the memory space where LSASS operates. This is why privilege escalation is the primary prerequisite for this attack vector.
Stage 1: Initial Privilege Escalation
An attacker cannot read LSASS memory with standard user privileges. Windows protection mechanisms prevent ordinary applications from accessing the memory of system-critical processes. Therefore, the first step is always gaining elevated rights. This often happens through exploiting a vulnerability in a locally installed application or abusing a misconfigured service. The attacker might also leverage stolen credentials that have administrative privileges.
Imagine a scenario where a user opens a malicious document that exploits a flaw in a PDF reader. The exploit grants the attacker system-level access. With this access, the attacker can now interact with protected system resources. Without this initial elevation, the LSASS attack chain fails immediately. This stage highlights the importance of application hardening and least privilege principles. If the initial foothold is low-privilege, the attacker must spend more time finding an escalation path, increasing the chance of detection.
Stage 2: Process Discovery and Validation
Once elevated, the attacker must confirm that LSASS is running and identify its Process Identifier. This is rarely a difficult step. The process name is consistent across Windows versions. The attacker typically runs a simple command or uses a script to list running processes. They look for "lsass.exe". This step is usually silent and generates no alerts. It is a routine part of post-compromise reconnaissance.
This stage is where many detection solutions fail to trigger. Listing processes is a legitimate administrative task. Security tools must distinguish between an administrator checking system health and an adversary preparing for credential theft. Context matters. If the process listing occurs immediately after a privilege escalation event, it becomes suspicious. This is where integrating data from different sources helps. A threat intelligence program can provide indicators of compromise that help correlate these benign-looking actions with known attack patterns.
Stage 3: Credential Extraction Method
Attackers use two primary methods to extract credentials from LSASS: process dumping and code injection. Process dumping involves creating a copy of the LSASS memory on disk. Tools like Procdump are commonly used for this. The resulting file can be analyzed offline to find passwords and tokens. This method is noisy. It creates a new file and accesses a protected process, which often triggers alerts.
Code injection is stealthier. The attacker forces LSASS to load a malicious dynamic-link library. This library runs inside the LSASS memory space. It reads the credentials and sends them back to the attacker's tool. No new files are created on disk. The malicious code exists only in memory. This technique is harder to detect because it mimics legitimate inter-process communication. Techniques like Reflective DLL injection allow the code to load without touching the disk at all.
Stage 4: Data Exfiltration
After extracting the credentials, the attacker must move them out of the compromised system. The stolen data includes plaintext passwords, NTLM hashes, and Kerberos tickets. These artifacts allow the attacker to move laterally within the network. They can log into other systems using the stolen identities. This is known as pass-the-hash or pass-the-ticket attacks. The data is often encrypted before exfiltration to avoid detection by network monitors.
The attacker might use legitimate administrative tools to move the data. For instance, they could use PowerShell to encode the credentials and send them via HTTPS. This blends the malicious traffic with normal web browsing. Defending against this stage requires monitoring for unusual data flows. Large uploads from a workstation to an unknown external IP are a red flag. SOAR platforms can automate the response to such events, isolating the host before further data is lost.
See also: How Windows Malware Removal Works: The Hidden Persistence Layer · Remote Desktop Abuse: Definition, Vectors, and Mitigation
Where the Chain Breaks
You can interrupt this attack at several points. The most effective defense is preventing the initial privilege escalation. Enforcing least privilege ensures that most users cannot access LSASS. Even if they are compromised, the attacker cannot proceed. Additionally, disabling legacy authentication protocols reduces the amount of sensitive data stored in memory. If LSASS does not hold plaintext credentials, there is nothing to steal.
Monitoring for process injection is another critical control. Look for attempts to inject code into lsass.exe. This is rarely legitimate. Most applications do not need to inject code into the security subsystem. Behavioral analytics can detect this anomaly. Furthermore, restricting the ability to create memory dumps prevents the easier, noisier extraction method.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Privilege Escalation | Attacker gains admin rights | Application patching, least privilege policies |
| Process Discovery | Attacker identifies LSASS PID | Monitoring for unusual process enumeration after escalation |
| Credential Extraction | Memory dump or code injection | Blocking write access to LSASS, detecting injection APIs |
| Exfiltration | Data sent to attacker C2 | Network egress filtering, anomaly detection on data flows |
The Hidden Cost of Detection
Detecting LSASS attacks is challenging because the techniques evolve. Attackers use custom tools that do not match known signatures. This leads to false positives in threat detection if the detection rules are too broad. Alerting on every memory access to LSASS will overwhelm the security team. You must tune your detections to look for specific sequences of events. For example, a process listing followed by a memory dump attempt is more suspicious than a standalone process list.
Breach and attack simulation can help validate your defenses. By running simulated attacks, you can see if your tools catch the injection or dump attempts. This allows you to adjust your rules before a real adversary exploits the gap. It also helps train your analysts on what the telemetry looks like. False positives in threat detection decrease when you understand the normal baseline behavior of your systems.
Beyond Passwords
LSASS theft is not just about passwords. It captures Kerberos tickets and other authentication tokens. This allows attackers to bypass password policies entirely. Even if you enforce complex passwords, the attacker can use the stolen ticket to authenticate. This is why cyber espionage groups favor this technique. It provides persistent access that is difficult to revoke. Changing passwords does not invalidate existing Kerberos tickets. You must reset the Kerberos keys to stop this type of access.
Scheduled task abuse is often used in conjunction with LSASS theft. After extracting credentials, the attacker might create a scheduled task to maintain persistence. This ensures they can re-access the system even if the initial compromise is closed. Understanding the full attack chain helps you defend against these secondary tactics. Attacker reconnaissance often precedes the selection of targets. If an attacker has been mapping your network, they likely know which systems hold high-value accounts.
Final Considerations
Defending against LSASS credential theft requires a layered approach. You must reduce the attack surface by limiting administrative privileges. You must monitor for suspicious process behaviors. You must understand that credentials are not just passwords. They are tokens and hashes that can be reused. Regularly review your detection rules and test them with YARA rules that identify known malicious patterns. Keep your systems updated to patch vulnerabilities that allow initial access. The goal is to make the attack chain too long and too noisy for the adversary to complete.
Key takeaways
- LSASS holds plaintext credentials only when legacy protocols like NTLM are active or when specific Windows features are enabled.
- Code injection into LSASS is harder to detect than full process dumping because it leaves fewer forensic artifacts.
- Restricting administrative privileges and disabling unnecessary credential caching reduces the value of a compromised LSASS process.
LSASS theft relies on extracting live memory from the security process, which requires elevated privileges and often bypasses password complexity rules. Implement strict least-privilege controls and monitor for process injection attempts to disrupt the attack chain early.
Frequently asked questions
Does disabling NTLM stop LSASS credential theft?
Disabling NTLM reduces the amount of plaintext data stored in memory, but attackers can still extract Kerberos tickets and other authentication tokens that do not rely on NTLM.
Can antivirus software detect code injection into LSASS?
Traditional antivirus software often misses code injection because no malicious file is written to disk. Behavioral monitoring or EDR solutions are more effective at detecting this activity.
Is process dumping always malicious?
No, administrators may dump LSASS memory for troubleshooting. However, this is rare. Frequent or unexpected dumps, especially from non-administrative accounts, are highly suspicious.
How do I know if my Kerberos tickets have been stolen?
You typically cannot know directly. If you suspect a compromise, you must reset the Kerberos keys for the affected account to invalidate any stolen tickets.
How this guide was produced: written by the Sandbox Dispatch editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
