LSASS Memory (T1003.001) is a credential access sub-technique for Windows. After a user logs on, the system generates and keeps several kinds of credential material in the memory of the Local Security Authority Subsystem Service, or LSASS. An administrative user or SYSTEM can harvest that material and use it for lateral movement with alternate authentication material.
How attackers use it
MITRE documents several routes at a high level. Credentials can be read in memory. The LSASS process memory can also be dumped to a file and analyzed elsewhere. MITRE names built-in Windows components, such as comsvcs.dll, as well as well-known tools, among the ways dumps get made. The silent process exit mechanism can be abused to create an LSASS dump through Windows Error Reporting.
A second route involves Security Support Provider (SSP) DLLs. These load into LSASS at system start and can see encrypted and plaintext passwords. The SSP configuration lives in registry keys under HKLM\SYSTEM\CurrentControlSet\Control\Lsa, named Security Packages and OSConfig Security Packages. Adding an entry there causes a new SSP to load.
Both routes need administrative or SYSTEM rights, which is why privilege hygiene matters so much here.
How to detect it
MITRE's analytic describes a chain of behavior. A non-privileged or abnormal process opens a handle to lsass.exe with full access (the value 0x1F0FFF), and then does something that suggests scraping: memory dump activity, file creation, or registry modification.
Practical data sources:
- Process access events, such as Sysmon Event ID 10 where the target image is lsass.exe, filtered to exclude your security agent.
- Process creation events (Security 4688 with command line logging, or Sysmon Event ID 1) for rundll32 loading comsvcs.dll, or for dump utilities.
- File creation events for new dump files in user or temp folders.
- Registry auditing on the two Security Packages values, since a change is rare and meaningful.
Tune by process path. A signed security product reading LSASS is expected. An unsigned binary from a user folder doing the same is not.
How to reduce the risk
MITRE lists these mitigations:
- Behavior Prevention on Endpoint: on Windows 10, enable Attack Surface Reduction rules that secure LSASS.
- Credential Access Protection: Credential Guard protects LSA secrets. MITRE notes it is not configured by default, has hardware and firmware requirements, and does not stop every form of credential dumping.
- Operating System Configuration: consider disabling or restricting NTLM, and consider disabling WDigest authentication.
- Privileged Process Integrity: on Windows 8.1 and Server 2012 R2, enable Protected Process Light for LSA.
- Privileged Account Management: avoid putting domain accounts into local administrator groups across systems, and use administrative tiers.
- Password Policies: unique, complex local administrator passwords.
- User Training: do not reuse passwords across accounts.
Reading the access mask
MITRE's analytic names the access value 0x1F0FFF. That is the full access right. Most legitimate tools that read LSASS ask for a narrower set of rights, because they do not need to do everything. A request for full access from a process that is not a security product is a good filter to start with, since it removes much of the noise.
Keep in mind that adversaries can ask for narrower rights, so treat this as one signal and not the only one.
Tuning for noise
LSASS is touched by security agents, by Windows components and by some management tools. Start with a one-week learning window. Collect every process that opens LSASS, with its path and signer. Approve the signed security and system components you recognize. What remains is your alert list, and it is usually short.
Add context to the alert. Include the parent process, the user, the host name and any file the process created right after. An analyst should be able to decide in two minutes whether the event is a vendor update or an intrusion.
First steps after an alert
- Isolate the host from the network if the process is unsigned or in a user folder.
- Collect the new files created around the event time. A dump file may still be on disk.
- List the accounts logged on to the host, since their credentials were in memory.
- Reset those credentials, starting with the privileged ones.
- Check where those accounts logged on next, using authentication logs.
Check your own environment
Read-only checks on a Windows host (reg.exe and PowerShell):
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Security Packages"
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
How to read the results:
- RunAsPPL at 1 means LSA protection is on.
- UseLogonCredential at 0 means WDigest is not storing clear text. A missing value is the default for your Windows version, so check the vendor documentation for it.
- Security Packages should list only packages you recognize. Compare against a known good host.
- In the Device Guard output, a value of 1 inside SecurityServicesRunning indicates Credential Guard is running.
Then ask who can log on to your servers as an administrator, and whether any of those accounts also log on to ordinary workstations.
Quick check
What privilege does an adversary need for LSASS memory dumping?
MITRE says material can be harvested by an administrative user or SYSTEM. That is why limiting administrator logons across systems reduces exposure.
Does Credential Guard stop all credential dumping?
No. MITRE notes it is not configured by default, has hardware and firmware requirements, and does not protect against all forms of credential dumping. Use it with the other mitigations.
Why audit the Security Packages registry values?
Adding an SSP there causes a new DLL to load into LSASS, where it can see passwords. Changes to those values should be rare, so any change deserves review.
