LSASS - Local Security Authority Subsystem Service

What is LSASS?

LSASS (in full Local Security Authority Subsystem Service) is the Windows process that handles authentication. It runs in the background as lsass.exe and checks on every sign-in whether a password is correct, either locally or against Active Directory.

What matters here is what happens after that check. LSASS does not throw the credentials away. It keeps them in memory for as long as the session lasts, so Windows can reuse them when you open a share or fetch your mail without making you type your password again. The process runs with the highest rights on the machine (SYSTEM), so only an administrator or Windows itself can reach it.

On a healthy machine there is exactly one lsass.exe, started from C:\Windows\System32. If you see two, or one that comes from somewhere else, that is almost always malware posing as the real process.

Why is LSASS interesting to attackers?

Those credentials in memory are exactly what an attacker wants. Anyone who gets hold of them can pose as the logged-in user and move further into the network.

What you can grab differs per system. Usually it is the NTLM hash, the encrypted form of the password that an attacker uses to log in to other systems without knowing the password itself. Alongside it sit Kerberos tickets, the access tokens that Windows hands out after you log in, and DPAPI keys that can decrypt stored browser passwords. On poorly maintained systems the password is sometimes even there in readable form.

That readable password was the biggest problem for years. It came from an old protocol, WDigest, which needed the password to function. Since Windows 8.1, WDigest is off by default, so on an updated system an attack no longer yields a readable password, but it still yields the hashes and tickets. Capturing this material is called credential dumping (MITRE ATT&CK T1003.001).

How does an attacker dump LSASS?

For every variant, an attacker first needs administrator rights on the machine. The simplest method needs no extra tooling at all. Open Task Manager as administrator, right-click lsass.exe and choose “Create dump file”. Windows then writes a dump of the memory to disk, which the attacker can read later on their own machine.

In our pentests it usually runs automatically. We use NetExec, which dumps LSASS remotely over the network and pulls the credentials straight out of it:

# NetExec: dump LSASS remotely and parse the credentials (requires local admin)
nxc smb 10.0.0.5 -u administrator -p Password -M lsassy

# Mimikatz: read straight from memory on the machine itself
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

# comsvcs.dll: create a dump via a built-in Windows component, without an external tool
rundll32 C:\windows\system32\comsvcs.dll,MiniDump <LSASS_PID> C:\out.dmp full

LSASS in a pentest

Once we have local admin on a workstation during an Active Directory pentest, LSASS is almost always the first thing we look at. On a machine where an administrator has just logged in, their credentials are still sitting in memory, and that gives us the key to move further into the network.

Most of the time we do not get a readable password, but we do get the NTLM hash, and that is enough for the next step. With Pass-the-Hash we log in to another system where the same administrator has rights, read LSASS there again, and repeat until we reach a domain admin. In our report we document how that chain could form. Usually it comes down to admin accounts logging in on ordinary workstations, or local passwords that are identical everywhere.

How do you prevent LSASS dumping?

You cannot fully shield LSASS, because Windows needs those credentials itself to function. But the chain an attacker walks through can be broken in several places.

• LSA Protection puts LSASS in a protected mode, so ordinary programs can no longer reach the memory, even when they run as administrator. You configure it with the registry value RunAsPPL. On clean installs of Windows 11 (22H2 and newer) in a business environment it is often already on, but after an upgrade or on standalone machines usually not.
• Credential Guard goes a step further and keeps the most sensitive data in a hardware-isolated part of Windows, separate from LSASS. From Windows 11 22H2 it is on by default on most business machines, but not on domain controllers.
• Check that WDigest is off, so no readable passwords end up in memory. Since Windows 8.1 that is the default. If the registry value UseLogonCredential is set to 1, someone deliberately turned it back on.
• Turn on the Defender ASR rule “Block credential stealing from lsass.exe”. It is especially useful on systems where LSA Protection and Credential Guard are not possible.
• Keep an eye on who accesses LSASS. An attempt to read the memory leaves clear traces in the event log (Sysmon Event ID 10), which a good EDR or SIEM will alert on.

How much a successful dump yields depends on what is in it. With LAPS and a strict separation between admin and work accounts, a domain admin’s password never ends up on an ordinary workstation, so there is far less to grab. No single measure is enough on its own, but together they break the chain in more than one place.