LSASS (Local Security Authority Subsystem Service) is the Windows process that handles interactive logons and manages authentication-related secrets in memory. Because it sits at the center of Windows authentication, attackers often try to access or dump LSASS memory to steal credentials or reusable secrets. This guide focuses on defensive detection, triage, and response—what to look for, how to treat dumps safely, and how to reduce LSASS exposure in an AD environment.
Why LSASS is a high-value target
In a typical AD environment, LSASS may temporarily hold sensitive material such as logon sessions, Kerberos tickets, NTLM-related data, and credential material depending on configuration, installed security controls, and the authentication packages in use. This is one reason attackers often pair LSASS access with lateral movement strategies across Windows fleets.
If you want the mental model for how authentication choices affect exposure, revisit NTLM authentication and Kerberos Authentication Protocols Explained.
Threat model: how credential theft via LSASS usually happens
A common pattern is: an attacker gains local admin (or equivalent rights), then attempts to read LSASS memory (directly or via a dump file), then uses recovered material to authenticate elsewhere. The exact technique varies, but the defensive signals tend to cluster around:
- Suspicious process access to LSASS (another process opening LSASS with high-privilege access rights).
- Dump file creation (minidump/full dump artifacts written to disk, often in user-writable locations).
- Abnormal parent/child process trees (script hosts, unsigned tools, LOLBins, or remote execution launching dump-related activity).
- Follow-on authentication anomalies (new logons, ticket usage, or lateral movement shortly after suspected LSASS access).
Pair LSASS-focused telemetry with identity-layer detection for best results. If you run Microsoft Defender for Identity, start with Microsoft Defender for Identity: A comprehensive overview and ensure your sensors are getting the right events via Event collection with Microsoft Defender for Identity.
First principle: treat any LSASS dump as a “credential spill”
Whether the dump is created by a malicious actor or by legitimate troubleshooting, an LSASS dump is highly sensitive. If a dump exists outside a tightly controlled debugging workflow, assume credential material may be exposed and prioritize:
- Containment: isolate the host (network containment if needed) and stop further access.
- Preservation: secure the dump file(s) with strict access control; record hashes and metadata.
- Scope: identify which users were logged on and which privileged accounts may be impacted.
- Remediation: rotate potentially exposed credentials (prioritize privileged accounts), invalidate sessions where feasible.
Where to look: common LSASS dump artifacts
Attackers often prefer places that blend into normal operations or are easy to write to. During triage, search for:
- Unexpected dump files in user profile paths (Downloads, Desktop, Temp) and public/shared locations.
- Suspicious timestamps correlated with interactive logons, remote execution windows, or maintenance tasks.
- Unusual file names that mimic crash dumps or support bundles but appear at odd times.
- Access patterns showing non-admin users reading the dump, or the dump being copied off-host soon after creation.
Legitimate sources that can confuse investigations
Not every dump is malicious. Windows Error Reporting and troubleshooting workflows can generate dumps during crashes or diagnostics. Your goal is to prove intent via context: who initiated it, what executed it, where it landed, and what happened next.
Telemetry that matters most
1) Process access to LSASS
The strongest signal is another process opening LSASS with high privileges. If you deploy Sysmon, process access telemetry can be extremely valuable for this (and it’s often easier to hunt than raw crash artifacts).
2) Process creation with suspicious trees
Look for dump-adjacent tooling spawned by script engines, remote execution, or unusual parent processes. Focus on command-line, signer, and parent-child chains rather than any single binary name.
3) Privilege use and debug rights
Reading LSASS typically requires elevated rights. Monitor for new local admin paths, token elevation, and sensitive privilege use. This is also where long-standing AD hygiene pays off—legacy permission sprawl makes it easier to get the rights needed to touch LSASS. See Excess Permissions: Lessons from Legacy Setups for a practical way to think about “how attackers get to the point where they can dump LSASS.”
4) Follow-on authentication behavior
A dump attempt becomes a real incident when it’s followed by suspicious authentication: new logons from atypical hosts, abnormal ticket usage patterns, or rapid lateral movement. Defender for Identity and well-instrumented domain controllers help here—make sure your collection is solid: Event collection with Microsoft Defender for Identity.
Safe analysis workflow (without “credential extraction” steps)
You can learn a lot from an LSASS dump without ever attempting to extract secrets. The point is to confirm compromise, understand the timeline, and scope the blast radius—while keeping the dump contained.
Step A: Secure handling and chain of custody
- Move the dump to a restricted, offline analysis location (least access, audited access).
- Record file hash, size, creation/modification times, and original path.
- Preserve surrounding artifacts: prefetch (if applicable), event logs, EDR timeline, scheduled task history.
Step B: Contextual correlation
- Identify the creator process (what wrote the file) and its parent chain.
- Correlate with logons (interactive/remote) around the creation time.
- Correlate with network activity (new outbound connections, file transfers, remote shells).
Step C: Scope impact via session awareness
Determine which users were logged on (interactive, service, RDP, scheduled task contexts) at the time of the dump. This informs which credentials to rotate first and whether you must assume privileged secrets were exposed.
Hardening: reduce the chance LSASS yields reusable secrets
You can’t remove LSASS, but you can make it harder to access and reduce what attackers get even if they manage to touch it. Prioritize these controls:
1) Enable modern Windows protections
- Credential Guard (where feasible) to reduce credential material exposure to user-mode attackers.
- Run LSASS as a protected process (PPL) to raise the bar for memory access by non-protected processes.
- Attack Surface Reduction (ASR) rules and EDR protections designed to block credential theft behaviors.
2) Remove the rights attackers need
- Reduce local admin membership; enforce Just Enough Administration where possible.
- Minimize interactive logon for privileged accounts; use tiering and hardened admin workstations.
- Watch delegation and privilege boundaries—misconfigured delegation expands who can become “local admin somewhere.”
Delegation mistakes can amplify credential exposure across servers. If you need a refresher on delegation mechanics, see Active Directory Computer Delegation tab.
3) Improve signal quality for detections
- Enable advanced auditing aligned to authentication, privilege use, and process creation.
- Deploy Sysmon (or equivalent EDR telemetry) for process access and suspicious process trees.
- Centralize logs and keep retention long enough to connect “dump attempt” to “later lateral movement.”
Hunting ideas for SIEM/EDR
Use these as patterns (adapt to your telemetry source). The goal is to detect LSASS access attempts without relying on a single IOC.
- Process access anomalies: non-security tools accessing LSASS; uncommon signers; unusual access rights.
- Dump file creation: new files with “dump-like” characteristics created by unexpected processes.
- Suspicious execution chains: script engines or remote tools spawning dump-capable binaries.
- Temporal coupling: dump creation followed by new logons from different hosts within minutes/hours.
Tip: Don’t hunt in isolation. Combine endpoint telemetry with identity-layer detection and DC-side signals. If you already run Defender for Identity, it can help connect endpoint behavior to identity compromise paths: Microsoft Defender for Identity: A comprehensive overview.
Incident response checklist
- Contain the endpoint suspected of LSASS access/dump creation.
- Identify the initiating user and process chain (parent/child relationships matter).
- Collect supporting artifacts: security logs, EDR timeline, scheduled tasks, persistence checks.
- Enumerate impacted accounts: who was logged on; which privileged sessions existed.
- Rotate credentials in priority order (privileged first), and invalidate sessions where feasible.
- Hunt for follow-on activity: lateral movement, new services, remote execution, ticket anomalies.
- Fix the root cause: initial access path, privilege escalation vector, and control gaps.
Common mistakes to avoid
- Assuming “it was just a dump”: treat it like a credential spill until proven otherwise.
- Over-focusing on one tool name: attackers swap tooling; behaviors are more durable than filenames.
- Ignoring AD hygiene: permission sprawl and weak delegation often precede LSASS access.
- Letting dumps live on endpoints: dumps should never remain accessible on production hosts.
