What is LSASS - Part 1

Keeping it simple: LSASS (Local Security Authority Subsystem Service) handles user authentication (access to the domain via the Domain Controller (DC) or locally using the Security Access Manager (SAM) table) and enforces security policies.

Since credentials are stored in LSASS memory, LSASS is a popular target for credential harvesting. See MITRE AT&CK T1003.001.  And as an analyst, you’ll want to know what to look for to identify these types of attacks.

Let’s look at LSASS during local authentication versus domain authentication.

Note: I am not a system administrator for Active Directory nor an expert, so this page will likely change as I become more familiar with the topic. However, the information provided here is based on reputable sources such as Microsoft’s official documentation and other credible security experts.

Local Authentication (via SAM table)

I’ve rewritten this several times as it is frustrating. Here are the two authentication targets in the environment: SAM for local and the DC for domain access.

A local account’s ability to access resources is limited to what that local machine has defined (see the SAM database), whereas a domain account (the machine it is on is recognized by the domain controller) now has access to resources within that domain. Think of a bedroom versus an entire house.

Now that we have gotten that out of the way, what does local authentication look like?

Let’s take a look at the local login flow:

winlogon.exe → logonui.exe → lsass.exe

Windows Logon (winlogon.exe) manages the user logon flow. One of the most important steps is launching the GUI for you as a user to input your username and password. This GUI is the logonui.exe. Winlogon.exe passes these credentials (which were given by the user to logonui.exe), and LSASS is used for verification.

Now, initially in my head, I thought:

A. Why doesn’t someone attempt to just dump winlogon.exe or logonui.exe?

Based on the digging I’ve done, it is just important to know that these two processes can be thought of as “credential movers” versus “credential holders”. Oversimplification, yes, but again, they exist to handle login flow, not keep track of user credentials like lsass does.

Attackers are going to go for the path of least resistance.

If you want to know more about the Windows Logon process, The Windows Process Journey — LogonUI.exe (Windows Logon User Interface Host) by Dr. Boutnaru is so helpful!

So now that we understand how a user can log on, let’s take a look at how LSASS validates credentials locally.

LSASS uses authentication packages to validate credentials. In this case, for a local user logging in, LSASS will use the package MSV1_0; MSV1_0 accepts a username and a hashed password that will be compared to the SAM database. If a match is found, then the user can log in.

SAM database contains local user account information (such as credentials); a copy of the SAM database is in the registry. SAM database is also referenced in MITRE ATT&CK (Technique T1003.002).

That’s enough for today, my brain hurts.