LSASS.exe is a core Windows security process, and it should almost always be running from C:\Windows\System32\lsass.exe. It handles logons, password changes, access tokens, and local security policy checks. If it stops, Windows usually becomes unstable or restarts. If a fake copy appears elsewhere, or another process tries to read its memory, that can point to credential theft.
TLDR: LSASS.exe is normal, but abuse of LSASS is one of the most common ways attackers steal Windows credentials. For example, in a 500 device office, even one unmanaged admin workstation with cached credentials can give an intruder a path to many systems. A healthy LSASS process usually sits in System32, runs as Local Security Authority Process, and does not spawn random child processes. Security teams should watch for memory dumps, odd file paths, and tools such as ProcDump, Mimikatz, or suspicious calls to comsvcs.dll.
What LSASS.exe Does
LSASS stands for Local Security Authority Subsystem Service. Windows uses it to enforce local security rules. It checks credentials during sign in, creates access tokens, validates password changes, and works with authentication packages such as Kerberos and NTLM.
In plain terms, LSASS is the bouncer at the door. It decides whether an account is valid and what that account can touch after logon. That makes it useful. It also makes it a favorite target for criminals.
Where the Real LSASS.exe Should Be
A real LSASS process should normally meet these conditions:
- File path: C:\Windows\System32\lsass.exe
- Process name: lsass.exe, not lssas.exe, lsassa.exe, or similar tricks
- Publisher: Microsoft Windows
- User context: SYSTEM
- Parent process: usually started by Windows during boot
It drives administrators crazy that attackers often use names that differ by one letter. A fake lssas.exe in a user profile folder can fool rushed reviews. The path matters as much as the name.
Normal LSASS Activity
LSASS uses memory and CPU like any other process, but it should not behave like a random utility. On most client machines, it uses modest CPU during normal work. Short spikes can happen during sign in, domain authentication, password resets, or group policy activity.
Normal signs include:
- CPU spikes during user logon or domain contact
- Network traffic to domain controllers in business environments
- Security event log entries for logon events, such as Event ID 4624
- Kerberos and NTLM authentication activity
- No strange child processes launched from LSASS
If LSASS uses high CPU for a long time, the cause may still be boring. Bad domain controller contact, broken authentication loops, misconfigured services, or antivirus scanning can all cause noise. Still, long spikes deserve review, especially on servers.
Why Attackers Target LSASS
LSASS can hold sensitive authentication material in memory. Depending on the system settings, this may include password hashes, Kerberos tickets, NTLM data, or other credential artifacts. Attackers want that data because it can help them move from one system to another.
Common abuse methods include:
- Memory dumping: copying LSASS memory to a file for offline analysis
- Credential extraction: using tools such as Mimikatz after a dump is created
- Pass the hash: using NTLM hashes without knowing the clear text password
- Pass the ticket: stealing Kerberos tickets for access to services
- Process injection: trying to run malicious code near or inside trusted processes
Signs of Malicious LSASS Abuse
The most worrying sign is not that LSASS exists. It should exist. The concern is other software trying to touch it in ways normal software should not.
Security teams should investigate these red flags:
- LSASS running from the wrong folder, such as AppData, Temp, or Downloads
- Dump files created from LSASS, often with extensions such as .dmp
- ProcDump usage against LSASS, such as procdump.exe -ma lsass.exe
- Rundll32 abuse using comsvcs.dll MiniDump
- Unknown tools opening handles to LSASS memory
- EDR alerts for credential access behavior
- Unexpected admin logons after a suspected dump
- Named pipes or scripts tied to credential dumping tools
Honestly, it feels like some built in Windows tools make this harder than it should be. Task Manager can create a dump in seconds if permissions allow it. That single click can turn a normal help desk session into a security incident if the file is copied out.
How to Check LSASS Safely
Administrators should avoid killing LSASS. Ending it can force a restart or crash the system. Safer checks include reviewing the process path, digital signature, command line, and related security events.
Useful checks include:
- Open Task Manager and confirm the process name is Local Security Authority Process.
- Use Process Explorer from Microsoft Sysinternals to verify signature and path.
- Check whether LSASS is running from C:\Windows\System32.
- Review Windows Security logs for unusual logon patterns.
- Search for recent .dmp files on the machine.
- Check EDR or antivirus alerts for credential access behavior.
How to Protect LSASS Credentials
Strong LSASS protection starts with reducing what attackers can steal. The following controls are practical and widely used:
- Enable Windows Defender Credential Guard where supported. It isolates secrets using virtualization based security.
- Enable LSA protection with RunAsPPL to make LSASS harder to tamper with.
- Limit local administrator rights. Admin access often makes dumping easier.
- Disable WDigest credential caching unless a legacy need exists.
- Use unique local admin passwords through Windows LAPS.
- Block known dump tools with Microsoft Defender, App Control, or EDR rules.
- Monitor command lines for procdump, rundll32, and suspicious PowerShell.
- Patch Windows and domain systems on a regular cycle.
What to Do If LSASS Abuse Is Suspected
If a dump or fake LSASS process is found, the system should be treated as compromised. The response should be quick and careful. Disconnect the device from the network if active theft is suspected. Preserve logs and suspicious files before wiping anything, unless business risk requires immediate containment.
Recommended response steps include:
- Isolate the endpoint from the network.
- Collect EDR data, Windows logs, file hashes, and process details.
- Find the user accounts active on the host before and during the event.
- Reset passwords for exposed accounts, starting with administrators.
- Invalidate Kerberos tickets where needed.
- Search other systems for the same tool, hash, command, or dump file name.
- Review domain controller logs for lateral movement.
One compromised LSASS dump can expose more than one account. A shared admin password can make the damage far worse. That is why unique passwords and least privilege matter so much.
FAQ
Is LSASS.exe a virus?
No. The real lsass.exe is a legitimate Windows process. A fake file using a similar name or running from the wrong folder may be malware.
Can LSASS.exe be disabled?
No. LSASS is required for Windows security and authentication. Disabling or killing it can crash the system or force a restart.
Why is LSASS using high CPU?
High CPU can happen during logons, domain issues, password changes, or authentication loops. If the spike lasts, administrators should check logs, domain connectivity, and signs of credential dumping.
What is an LSASS dump?
An LSASS dump is a copy of the process memory. Attackers may use it to extract hashes, tickets, or other credential data.
How can LSASS be protected?
Common protections include Credential Guard, LSA protection with RunAsPPL, least privilege, Windows LAPS, application control, strong EDR monitoring, and blocking suspicious dump activity.
What is the safest first check?
The safest first check is to verify that LSASS is signed by Microsoft and running from C:\Windows\System32\lsass.exe. The process should not be ended during routine checks.
