How can security teams detect LSASS driver abuse?

What LSASS driver abuse looks like in telemetry

lsass driver abuse usually shows up as a kernel component interacting with the Local Security Authority in ways that do not match the normal endpoint baseline. The strongest signals are driver loads that are unsigned, newly introduced, or bundled with software that has no legitimate reason to touch credential-related memory, especially on systems where credential protection should already be active.

Look for the sequence, not just one event. A suspicious service install, followed by a driver load and then unusual access to LSASS-associated memory, is more actionable than any single indicator in isolation. On mature estates, detection is often a correlation problem across service creation, image load, and process access telemetry.

Because attackers often hide behind legitimate system mechanisms, the key is to distinguish expected security software from uncommon kernel activity. That means knowing which drivers are approved on each endpoint class, which products legitimately inspect LSASS, and which administrator actions can explain the event without assuming compromise.

How to separate malicious driver activity from normal endpoint tooling

Start with the trust boundary around the driver itself. A driver may be benign even if it is new, but novelty should force review when the publisher, file path, hash, or installation path is outside the standard build. Driver abuse becomes more suspicious when the module is unsigned, unexpectedly installed, or associated with tools that normally do not need kernel access.

Next, validate whether the driver’s behavior matches its stated purpose. Security products may inspect protected processes for telemetry or remediation, but they usually do so in a repeatable and documented way. If the driver appears on only a subset of hosts, loads outside standard maintenance windows, or is paired with unexplained service creation, the probability of abuse rises quickly.

It also helps to treat LSASS protection as an asset baseline, not a single control. Even if the process is protected, defenders still need visibility into memory access attempts, service changes, and driver load ancestry so they can tell whether the access attempt was expected, blocked, or part of a broader compromise path.

Detections that add real value for this technique

High-fidelity detection usually comes from combining kernel, service, and process telemetry. Watch for drivers that are newly installed, not present in the normal software inventory, or loaded by services with unusual names, unusual file locations, or short-lived lifetimes. Correlate that with access to processes that should be difficult to inspect, especially when the access pattern does not match the endpoint’s security stack.

Alerting should also account for privilege context. If a low-value host process or an unfamiliar service suddenly gains the ability to reach LSASS-related memory, that is often more important than the mere fact that a driver exists. A good detection rule asks whether the driver is both uncommon and functionally capable of exposing credentials or authentication material.

For ATT&CK-oriented detection work, mapping the activity to MITRE ATT&CK Enterprise Matrix helps teams anchor the alert to credential access and privilege abuse patterns rather than treating it as generic driver noise. Teams that need a broader operational view can also use SANS Security Resources to align telemetry with incident-handling workflows, and NIST Cybersecurity Framework 2.0 to structure detect and respond coverage around endpoint integrity.

Practitioner Guidance

What to verify: Confirm whether each flagged driver is signed, expected on that endpoint class, and tied to an approved vendor or change record. The fastest false-positive reducer is a known-good inventory of security and hardware drivers that are allowed to interact with protected processes.

Decision rule: If you see a new or unsigned driver plus an unexpected service installation on a host that stores privileged sessions, treat it as a potential credential-access event and investigate before assuming it is routine maintenance. If the driver is from an approved security product, validate its normal behavior against the vendor baseline rather than dismissing the alert.

What good looks like: Mature detection gives you a clear chain from service creation to driver load to protected-process access, with enough context to tell whether the activity was blocked, permitted, or attempted by an approved control. That level of visibility makes LSASS abuse much easier to triage quickly.

Practitioner takeaway: The detection problem is less about finding a single malicious driver than about proving that a driver’s installation, trust status, and process-access behavior fit the expected endpoint baseline.

Related resources from NHI Mgmt Group

• Guide: Persistence Techniques Guide
• Why is the abuse of NHIs a priority for security teams?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• What is the difference between SAST and DAST for security teams?