LSASS Driver is a kernel driver used to interact with the Local Security Authority Subsystem Service or its protected memory. Attackers may abuse such drivers to dump credentials or disable protections. Defenders should allow only trusted drivers, monitor driver loading, and investigate any attempt to access LSASS memory from kernel space.
What an LSASS driver is used for
An lsass driver sits close to the operating system’s most sensitive authentication processes, which is why it can be attractive to attackers seeking credential material or a way to weaken local protections. In practice, the term usually refers to kernel-mode activity that reaches into LSASS memory or interacts with its protection model.
That proximity matters because LSASS is not just another process, it is where credential-related material, security boundaries, and access enforcement can converge. A malicious or abused driver can turn a normally defensive kernel capability into a privileged path for data theft or tampering.
Why LSASS drivers are security sensitive
The danger is not the driver itself, but the combination of kernel privilege and visibility into authentication state. Once a driver can inspect or manipulate LSASS-related memory, it may be able to expose credentials, session material, or other secrets that should never be reachable from ordinary user mode.
This is also why trusted-driver policy matters. A signed or legitimate-looking driver is not automatically safe, and weak driver controls can create a hidden route around endpoint protections. NIST SP 800-53 Rev 5 treats system integrity and controlled access as foundational concerns, and those same ideas apply here when a kernel component reaches into authentication memory.
How organisations assess exposure and investigate abuse
Exposure review starts with knowing which systems can load kernel drivers, which security products are protecting LSASS, and whether protections such as credential isolation or PPL-like safeguards are enabled. If the environment allows untrusted or poorly governed drivers, LSASS becomes a much easier target.
Detection should focus on driver load events, unusual kernel activity against LSASS, and attempts to disable or bypass local security features. MITRE ATT&CK Enterprise Matrix is useful here because it helps map credential access and privilege escalation behaviour to observable attacker tradecraft. For defenders, driver-related review is often strongest when paired with memory access telemetry, code integrity checks, and endpoint alert triage.
Remediation and hardening choices when LSASS is in scope
When a driver-based LSASS issue is suspected, the response is usually less about one file and more about trust boundaries: remove the malicious or unnecessary driver, verify code integrity, and review whether local admin or kernel-level change paths were abused. If patching or configuration changes cannot be applied immediately, compensating controls such as strict driver allowlisting and tighter endpoint monitoring reduce the chance of repeated abuse.
Post-incident review should also consider whether credentials, tokens, or other authentication material exposed through LSASS need rotation. NIST SP 800-53 Rev 5 Security and Privacy Controls supports that control-oriented response, while PCI DSS v4.0 is a useful external reference where least privilege and account handling requirements drive stronger operational discipline around sensitive systems.
Risk and Threat Considerations
LSASS drivers are risky because they can turn a trusted kernel path into a credential-theft mechanism. The threat is especially serious when an attacker already has enough access to load or abuse a driver, since that often bypasses user-mode protections and makes defensive tooling harder to trust.
Failure mechanism: A malicious or misused driver reaches protected LSASS memory, extracts secrets, or disables defensive controls that would otherwise block credential access.
Impact: The result can be credential theft, session compromise, local privilege escalation, and follow-on lateral movement across the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | LSASS driver abuse is a system integrity problem involving trusted kernel code. |
| CM-7 — Least Functionality | Restricting unnecessary drivers reduces kernel paths that can target LSASS. | |
| IA-5 — Authenticator Management | LSASS compromise can expose authenticators and secret material that must be rotated. | |
| Recommendation — Enforce integrity checks and trusted code paths for drivers that can reach sensitive security processes. Limit driver installation and execution to only what is operationally required. Rotate exposed authenticators and revoke compromised secret material after suspected LSASS abuse. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Driver trust, loading policy, and endpoint hardening are core secure-configuration concerns. |
| Recommendation — Harden endpoints to permit only approved drivers and security settings. | ||
| MITRE ATT&CK | T1003 — OS Credential Dumping | LSASS access is a classic credential-dumping path used for secret extraction. |
| Recommendation — Map LSASS access attempts to credential-dumping detections and hunt for follow-on movement. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | LSASS driver abuse can expose credential material and other secrets. |
| Recommendation — Treat any LSASS exposure as potential secret leakage and rotate affected material. | ||
Practitioner Guidance
What to watch for: Treat any attempt to load an unfamiliar driver, tamper with code integrity, or access LSASS from kernel space as a high-priority investigation. In mature environments, the important question is not only whether the driver is signed, but whether it is necessary, approved, and consistent with the host’s intended security posture.
Practitioner takeaway: LSASS protection fails most often at the trust boundary, so driver governance and memory-access monitoring should be treated as part of the same control problem.