Attackers use an LSASS driver to interact with or protect access to the Local Security Authority Subsystem Service process, often to load code, weaken protections, or support credential theft. Defenders should watch for unauthorised driver installation, suspicious kernel activity, and attempts to access LSASS-related memory or security controls.
What an LSASS driver is used for in an attack path
Attackers use an lsass driver because kernel-level code can change what is visible, protected, or enforceable around the Local Security Authority Subsystem Service process. In practice, that can help them weaken safeguards, interact with LSASS from below user-mode defenses, or set up credential theft and post-compromise access.
The important distinction is that the driver is usually an access-enabling mechanism, not the end goal. The goal is often to reach secrets, tokens, or security material held in memory, or to bypass the protections that would otherwise block direct inspection or tampering.
Why LSASS drivers matter to defenders
LSASS is attractive because it sits near the trust boundary for authentication and logon material. If an attacker can load a malicious or abused driver, they may gain a path around ordinary endpoint controls, memory protections, or application-layer monitoring. That makes driver events, kernel activity, and changes in protection state more important than the driver name alone.
Defenders should treat any driver associated with LSASS access as a high-signal event, especially when it appears outside a known management or security product. The phrase “driver” matters less than whether the code is being used to mediate privileged access to a security-critical process.
An LSASS-focused tradecraft path also fits a broader persistence and evasion pattern, because kernel components can be used to stay resident, hide activity, or support follow-on actions after initial access. NHIMG’s Persistence Techniques Guide is a useful companion when you are tracing how one privileged foothold turns into longer-lived control.
What to look for and what to do next
The first check is whether the system actually needed the driver. If the answer is no, then unsigned or unexpected driver installation, new kernel services, or unusual protection changes around LSASS deserve immediate review. Correlate driver load timing with suspicious logon activity, process injection indicators, and any memory access that targets LSASS-related protection paths.
Where a driver may have been used to support credential theft, treat the event as possible compromise of authentication material rather than a simple malware alert. That means you should validate whether reusable secrets, cached credentials, or session material may have been exposed and whether lateral movement followed.
If you want a threat-centric view of how attackers combine credential access, privilege abuse, and follow-on movement after a foothold, NHIMG’s The State of NHI & AI Agent Breach Report 2026 provides useful incident-pattern context for the kinds of secrets and identities attackers target after initial access.
Risk and Threat Considerations
LSASS driver abuse is risky because it can undermine the controls defenders rely on to protect authentication material. Once kernel-level access is in play, the attacker may be able to interfere with memory protections, blind detection logic, or make credential theft harder to observe than a normal user-mode intrusion.
Failure mechanism: The attacker loads or abuses a driver to operate below standard endpoint protections, enabling access to LSASS memory, weakening safeguards, or hiding malicious activity while credential material is exposed or extracted.
Impact: The result can be account compromise, privileged session theft, and faster lateral movement across the environment, especially if the exposed credentials belong to administrators or services with broad reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses 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 |
|---|---|---|
| MITRE ATT&CK | T1003 — OS Credential Dumping | LSASS-driver abuse is commonly used to reach credential material in memory. |
| Recommendation — Map LSASS-access activity to credential-dumping detection and hunt for memory access around LSASS. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Unexpected drivers and kernel tampering affect system integrity and protection controls. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Driver loads and LSASS access require reviewable telemetry for detection and response. | |
| CM-7 — Least Functionality | Restricting unnecessary drivers reduces the attack surface for kernel abuse. | |
| Recommendation — Enforce integrity checks for drivers and block unauthorized kernel components. Correlate driver events, process activity, and LSASS access indicators in audit review. Allow only approved drivers and remove unnecessary kernel-loading capability. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Driver abuse often exploits weak baseline hardening and permissive software settings. |
| CIS-8 — Audit Log Management | Driver installation and LSASS-targeted activity need durable logs for investigation. | |
| Recommendation — Harden endpoints to block unsigned or unapproved drivers and kernel changes. Centralize and retain logs for driver loads, service creation, and LSASS-related events. | ||
Practitioner Guidance
What to verify: Confirm whether the driver was installed by an approved security, hardware, or management product. If not, treat the load as suspicious and inspect the parent process, service creation event, signature status, and any change in LSASS protection state.
Decision rule: If the driver touched LSASS-related protections or coincided with memory access alerts, prioritize containment and credential exposure assessment before spending time on malware family attribution.
What good looks like: LSASS remains protected by approved hardening controls, driver loads are explainable, and endpoint telemetry can show who installed what, when, and why. The practitioner takeaway is that LSASS driver abuse is usually about privileged access path manipulation, so the response should focus on exposure scope and credential impact, not just the binary itself.