Fix LSASS.exe High CPU & Memory from Credential Theft Attempts

EP
Erropedia Team
📅 August 29, 2026 📅 Updated Sep 12, 2026 👁 18 views Cybersecurity & Malware Intermediate
LSASS.exe pegging CPU or eating RAM usually means credential theft tools are probing it. Here's how to stop the attack and lock it down.

Quick answer for the pros: Enable Protected Process Light (PPL) for LSASS and roll out Windows Defender Credential Guard — that kills 90% of the tools causing this.

Here's the thing: LSASS legitimately spikes during logons. But when it sits at 100% CPU or climbs past 2GB RAM for no reason, you're almost always looking at a credential theft tool — Mimikatz, ProcDump, or some custom malware — trying to read your password hashes right out of memory. They hook into LSASS, force it to churn, and that's your red flag. On a normal Windows 10/11 or Server 2016+ box, LSASS idles under 100MB. Any sustained spike means somebody's poking it.

Don't bother killing LSASS. It'll restart, and the attack continues. The real fix is to lock the process down so the tools can't touch it.

Why This Happens

Attackers want your NTLM hashes or plaintext credentials. LSASS caches them, so it's the prime target. Tools like Mimikatz use OpenProcess with debug privileges, then read memory directly. If LSASS runs unprotected, that's game over. The spike you see is LSASS struggling under the debugger's load or the tool hammering it with queries.

Step-by-Step Fix: Turn on PPL

  1. Open an elevated PowerShell or CMD.
  2. Check if PPL is already enabled:
    reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL
    If you get 0x1, you're set. If the key's missing or 0x0, continue.
  3. Set the registry value:
    reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1 /f
  4. Reboot. That's it.

PPL starts LSASS as a protected process. Standard read/write access is blocked, so Mimikatz-style attacks fail. You'll see errors in the event log if they try.

If That Doesn't Stop It: Enable Credential Guard

PPL blocks most tools, but some persistence mechanisms still get through. That's where Credential Guard comes in. It isolates LSASS secrets in a virtualized container. Even if LSASS is compromised, the hashes stay safe. Enable it via Group Policy:

  1. Open gpedit.msc (or Group Policy Management for AD).
  2. Navigate to Computer Configuration → Administrative Templates → System → Device Guard.
  3. Set Turn On Virtualization Based Security to Enabled.
  4. Under Credential Guard Configuration, select Enabled with UEFI lock.
  5. Reboot twice (once for the feature, once for the lock).

Note: Credential Guard needs virtualization (VT-x/AMD-V) and UEFI Secure Boot. On older hardware, you'll get a warning. Skip it only if you're out of options.

Alternative Fix: Audit and Kill the Offending Process

If the spike continues, you've got something that's already running with admin rights. Find it:

  1. Open taskmgr and sort by CPU or Memory.
  2. Look for anything with a random name in C:\Users\<user>\AppData\ or C:\Windows\Temp.
  3. Check event logs for OpenProcess failures on LSASS:
    wevtutil qe Security /q:"*[System[(EventID=4656)]]" /f:text /c:10
  4. Kill the process with taskkill /F /IM <name.exe>, then run a full Defender scan.

Honestly, if PPL and Credential Guard are on, you shouldn't need this. But in a messy environment, sometimes a tool like SystemInformer (formerly Process Hacker) can show you exactly who's touching LSASS.

Prevention: Lock It Down Before It Happens

The real fix is to stop credential theft at the source. Besides PPL and Credential Guard, do this:

  • Enforce LSA protection via policy: set HKLM\SYSTEM\CurrentControlSet\Control\Lsa → RunAsPPL to 1 across all machines with GPO.
  • Disable NTLM where possible — most attacks target NTLM hashes. Set Network security: Restrict NTLM policies.
  • Limit local admin rights. Credential theft tools need admin or SYSTEM privileges. Fewer admins, fewer attack vectors.
  • Use Windows Defender Application Control or AppLocker to block unknown executables from running in the first place.
Pro tip: Don't rely solely on antivirus. Modern credential theft tools are fileless — they inject directly into LSASS. PPL and Credential Guard are your only real barriers.

One more thing: after you enable PPL, test with a tool like Mimikatz on a test machine to confirm it's blocked. You'll see an error like ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x5). That means it's working.

This isn't a one-off fix. You need both PPL and Credential Guard for proper defense. Do it now, before the next attack lands.

Related Errors in Cybersecurity & Malware
0XC00002DF 0XC00002DF: SAM needs boot key password fix Kill Locky ransomware and recover your files Pop-up ads with browser closed — here's the fix Task Manager Disabled? Fix Admin-Blocked Access Now
LSASS.exe high CPU LSASS.exe high memory credential theft prevention Windows Defender Credential Guard Protected Process Light LSASS protection registry audit credential validation

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.