For many of us in cybersecurity, we know that credential theft is part of almost all attacks within a network. Arguably, one of the most known forms of credential stealing is surrounding clear-text credentials by accessing lsass.exe. Almost synonymous with credential stealing is the popular tool Mimikatz, which is able to access the LSASS (Local Security Authority Subsystem Service) memory space and extract these clear-text credentials. While dumping clear-text credentials in LSASS is a critical concern, it is only a piece of the bigger picture of the Windows credential model.
But how much do we really understand about the LSASS and other components of Windows credential management? How do they work? What do they store? Why are they a target for attackers? What protections can we put in place?
In Part 1, I’ll do a deep dive into Windows authentication and credential management to shed more light into how it works and where vulnerabilities lie.
According to Microsoft, in Windows authentication, credential management refers to the underlying process that takes credential material from the user to present to the authentication target. On a non-domain joined computer, the authentication target is the Security Accounts Manager (SAM) database on the local machine. In the case of a domain joined computer, the authentication target is the domain controller through the WinLogon service.
Security information that is stored locally in the host is located in the registry under HKEY_LOCAL_MACHINE\SECURITY. Information found in this registry can include:
- Policy settings
- Default security values
- Account information
- Cached logon credentials
- Copy of the SAM database (write-protected)
The Local Security Authority (LSA) is a protected system process that’s purpose is to authenticate users on the local system. Collectively, LSA handles the local security aspects on the computer (local security policy) and provides translation between names and security identifiers (SIDs).
The Local Security Authority Subsystem Service (LSASS) is also a part of the LSA framework. LSASS is the process that keeps track of security policies and accounts that are in use on a system. Specifically, LSASS stores credentials in memory for users active on the machine. The purpose of keeping these credentials in memory is for a form of single sign on, where the user does not have to reinput credentials for network resources, shares, or services within the domain.
I’ll start with breaking down LSASS as it is generally the most well-known component of LSA. According to Microsoft documentation, LSASS stores credentials in memory on behalf of users with active Windows sessions. The purpose of storing these credentials is so that users can access network resources, file shares, mail, and more without having to re-authenticate to each individual service.
LSASS stores credential material in various forms, including:
- Reversibly encrypted plaintext
- Kerberos Tickets
- NT hashes
- LM hashes
Credentials are cached to LSASS whenever a user authenticated in an interactive manner. The following types of activity will put the user’s credential material into memory:
- Starting a local session
- Starting an RDP session
- Running a task via RunAs
- Running an active Windows Service
- Running a scheduled task
- Running a batch job
- Running a task by utilizing a remote administration tool
Things to consider: When you need to execute commands/processes on a host, know what will and will not put credential material into memory. When investigating, look for users that may be performing the above activities on the impacted host.
By default, LSASS stores credentials associated with logon sessions related to those activities outlined above since the last restart, of which have not been closed (logged off). This means that once a user is logged off, LSASS may clear the credentials after a certain period of time, which varies by operating system and security settings (default is 30 seconds in Windows versions 8.1+. Older systems may not always clear credentials after logoff without patches).
Things to consider: Ensure hosts are fully patched and credential clearing is enabled. Any user authenticated when a potential credential dump occurs will likely need their password reset. On legacy hosts, there may not be any clearing of credentials, even after logoff. All users on these systems (when unpatched) may need a password reset.
As you may have already guessed, the reason LSASS is such a high-value target for attackers is that it contains credential material for users, which can be used to pivot throughout the environment.
When an attacker gains their initial foothold into the environment, they almost never land at their target host or permission set. For example, if their phishing email to the accounting department was successful, these users are probably not able to access databases, domain controllers, medical records, etc.
Nearly all forms of lateral movement require credential material to move throughout an environment.
Mimikatz is arguably the most well-known/publicized way of dumping LSASS. Mimikatz was created in 2007 by Benjamin Delpy as a tool to experiment with Windows security and LSASS functionality. It has the ability to access LSASS credential material, Kerberos tickets, create tokens, pass-the-hash, and more. The project is ongoing and new modules are added on a regular basis.
Mimikatz functionality was part of the 2017 NotPetya attacks, where it would search for clear-text passwords in WDigest and other credential material within LSA.
This toolset is open-source and can readily be downloaded from the GitHub repository. Mimikatz requires local administrator rights to the host on which it will be used. This is because it has to assume “Debug” privileges as it uses Windows debugging functionality to access the LSASS memory space.
A typical Mimikatz execution flow will look similar to the following (Windows 10):
As seen in the graphic above, Mimikatz will attempt to pull credential material from multiple sources, including MSV, TSPKG, WDIGEST, KERBEROS, SSP, and CREDMAN. These were all seen in the LSA model diagram at the beginning of this blog.
From an attacker’s perspective, Mimikatz is not a very OPSEC (Operations Security) friendly tool when trying to gain credential material. This is because it is a very well-known toolset and is almost immediately caught by antivirus and security vendors, even when at rest on disk. Because of this, attackers will typically do one of the following: Execute Mimikatz in memory, create their own custom tool, or use other legitimate programs that can also dump the memory space of LSASS. I won’t cover memory injection and exploit development in this blog, but I will touch on a few other alternative methods to access LSASS with legitimate, known programs.
Things to consider: It is always important to know legitimate ways to dump credential material because even if the processes are not malware, they can still be used maliciously.
Procdump is a tool that was created by Mark Russinovich and Andrew Richards that is now part of the windows Sysinternals tool suite. It is readily available for download from Microsoft’s website. The tool was designed to be used for debugging applications for CPU usage and creating crash dumps so the root cause could be determined.
Like many of the Sysinternals administrator tools (such as PsExec), this legitimate program has been abused by attackers. The reason being, this is a legitimate Microsoft program, and antivirus and security providers are less likely to alert as this process being malware (this is not always the case, some vendors will flag on activity associated with this process when associated with LSASS). Below is an example of using the tool (administrator context is needed to dump LSASS).
To be more “stealthy,” (as some security vendors will flag “lsass.exe”) attackers can also specify the process by the PID.
This file can now be taken offline (outside of the network on a different host) and be ingested by Mimikatz through its minidump module.
A lesser known way of dumping LSASS is by using the task manager, which is built into Windows. From an administrator context, a dump file can be created for any process by right-clicking on it within the task manager and selecting “Create Dump File”.
Not all credential material is stored in memory within the LSASS process. Some of the credential material may also be stored on the hard disk drive, only accessible to SYSTEM account processes on the host. The reason these credentials are stored is that in some cases they may need to survive after a reboot, such as the case with cached credentials.
Cached credentials are encrypted user credentials that are used when the authentication authority cannot be reached. For example, if your domain joined workstation cannot reach the domain controller to validate your credentials, your machine will use the cached credentials to authenticate you in the meantime. Without these credentials, you would be unable to authenticate without an active connection to the domain controller.
Cached credentials are not the only material that can be stored in the LSA secrets. According to Microsoft, other examples of stored secrets include:
- The account password for the computer’s Active Directory machine account
- Account passwords for Windows Services
- Account passwords for scheduled tasks
- Account passwords for IIS application pools/websites
- Passwords for Microsoft accounts
LSA secrets are stored in an encrypted form within the registry at HKEY_LOCAL_MACHINE/Security/Policy/Secrets. The parent keys to decrypt the secrets are also stored within the registry at HKEY_LOCAL_MACHINE/Security/Policy. This is significant because as I mentioned, system level processes are able to access these registers to decrypt the data that lies within them. If an attacker is able to establish a SYSTEM level context on a host, they can dump the LSA secrets as easily as credentials within LSASS.
Mimikatz also contains functionality to access these secrets on a host.
First, we need to establish a system context, so we will use the “token::elevate” command within Mimikatz. Once the SYSTEM context is assumed, we are able to access the LSA secrets.
Things to consider: Just because there may be no credential material within LSASS memory, this does not mean that there will not be credential material stored on the drive within the LSA secrets. This material can still be used for lateral movement.
The vulnerabilities I’ve outlined above are critical to understand what mitigations can be put in place to protect against Windows credential stealing. In Part 2, I’ll walk through what these mitigations could look like so you can proactively protect your organization.
MITIGATING CREDENTIAL STEALING WITH RELIAQUEST GREYMATTER
GreyMatter, ReliaQuest’s SaaS security platform, helps mitigate credential stealing by integrating and normalizing data from disparate technologies including SIEM, EDR, multi-cloud, and point tools to provide a unified view for detecting, investigating, and threat hunting – all within the GreyMatter UI. Through GreyMatter, security teams can leverage custom detection content to identify and investigate activity that may indicate credential theft. With an integrated threat hunting feature, GreyMatter allows for a security teams to proactively search over large periods of time for suspicious LSASS activity on an EDR. By automating across the security lifecycle, ReliaQuest GreyMatter aggregates, de-dupes and enriches alerts from across your security ecosystem to serve up a research package, providing analysts with all of the telemetry and recommendations they need, in one place, to prosecute and remediate threats.