How do attackers use LSASS Driver?

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.

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.

Related resources from NHI Mgmt Group

• How do attackers use list planting?
• How do attackers use invisible Unicode?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?