Adversaries commonly abuse the Local Security Authority Subsystem Service (LSASS) to dump credentials for privilege escalation, data theft, and lateral movement. The process is a fruitful target for adversaries because of the sheer amount of sensitive information it stores in memory. Upon starting up, LSASS contains valuable authentication data such as:
- encrypted passwords
- NT hashes
- LM hashes
- Kerberos tickets
The LSASS process is typically the first that adversaries target to obtain credentials. Post-exploitation frameworks like Cobalt Strike import and customize existing code from credential theft tools like Mimikatz, allowing operators to easily access LSASS via beacons.
Adversaries use a variety of tools and methods to dump or scan the process memory space of LSASS. Whatever method they choose, the ultimate goal is to obtain credentials, move laterally, and access valuable systems. In the abstract, LSASS abuse can be categorized broadly into two substantially overlapping categories:
- native processes
- custom adversary tools
The tooling that adversaries use to extract credentials from LSASS Memory exists on a spectrum ranging from legitimate to dual-purpose to overtly malicious. More often than not, adversaries drop and execute trusted administrative tools onto their target, so we’ll organize our analysis going from legitimate to ambiguous to malicious—starting with processes.
The Windows Task Manager (taskmgr.exe) and the Windows DLL Host (rundll32.exe) are the two built-in utilities that adversaries seem to abuse most often. Task Manager is capable of dumping arbitrary process memory if executed under a privileged user account. It’s as simple as right-clicking on the LSASS process and hitting “Create Dump File.” The Create Dump File calls the MiniDumpWriteDump function implemented in dbghelp.dll and dbgcore.dll. Additionally, Rundll32 can execute the Windows native DLL comsvcs.dll, which exports a function called MiniDump. When this export function is called, adversaries can feed in a process ID such as LSASS and create a MiniDump file.
Adversaries frequently co-opt a number of Sysinternals tools to access the memory contents of LSASS. A few of the standouts include: Sysinternals Procdump, Sysinternals Process Explorer, and Microsoft’s SQLDumper.exe.
We aren’t always able to reliably differentiate when an offensive security tool is used by a red team or an adversary. In fact, as much as a quarter of our detections may be triggered by sanctioned tests, so we detect the following irrespective of intent. That said, the LSASS-abusing tools we commonly see include:
- Mimikatz
- Cobalt Strike
- Impacket
- Metasploit
- PowerSploit
- Empire
- Pwdump
- Dumpert
Other threats that have abused LSASS Memory include TrickBot, Zoremov, and Rose Flamingo.
Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.
As we did for many of the prevalent techniques in this report, we developed detection logic for LSASS Memory by understanding what is normal behavior. Monitoring processes and command lines via enterprise EDR or open source tools like Sysmon is among the best ways to learn what normal—and by extension, abnormal—looks like. On top of the process and command-line data, file and network monitoring offer valuable visibility into memory dumps and process injection.
LSASS rarely spawns child processes for legitimate reasons. Given that detection based on cross-process events or network connections can generate a lot of noise, monitoring for child processes spawning from LSASS is a great starting point for detecting LSASS memory theft.
Cross-process events offer some of the best telemetry for observing and detecting LSASS Memory abuse. It can be a challenge to track and investigate all the processes that are injected into LSASS, in part because some benign software products—like antivirus and password policy enforcement software, for example—have legitimate reasons to access and scan LSASS.
Adversaries often seek to empty the memory space of LSASS into a .dmp file. Thus, file monitoring can be an effective telemetry source for gaining visibility into this variety of credential theft. More specifically, password-cracking tools Dumpert and SafetyKatz place dump files in predictable file paths, which can enable reliable detection opportunities.
Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.
Added in Windows 10, LSASS SACL auditing records all processes that attempt to access lsass.exe, providing valuable information when an adversary attempts to steal credentials from process memory. You can enable this feature within Windows’ advanced policy configuration settings, according to Microsoft’s documentation.
Sysmon ProcessAccess events log whenever one process attempts to access another. As we’ve discussed throughout this analysis, LSASS abuse often involves a process accessing LSASS to dump its memory contents. In fact, this is so common that Microsoft uses LSASS abuse as an example in its documentation for this data source.
Image load events will log whenever a DLL is loaded by a specific process. This may provide useful visibility into adversaries abusing DLLs to dump credentials.
File creation events are a useful source of telemetry if you want to keep an eye on adversaries emptying the memory space of LSASS and creating credential dump files.
The days of detecting LSASS-abusing tools like Mimikatz via traditional methods like antivirus, common command-line arguments, and binary metadata are far behind us. Instead, start at a high level and gather what normal LSASS activity looks like before writing detection logic around abnormal behavior. We’ve got more than 20 detectors that look for various flavors of LSASS abuse. The following logic summarizes some of our most effective analytics.
Note: These detection analytics may require tuning.
One of the best ways to detect adversaries abusing LSASS is to understand what tools or processes routinely access LSASS Memory for legitimate reasons—and then build detection logic for anything that deviates from that. It’s highly unusual for many processes to open a handle into lsass.exe. The following is a generic example of a detection opportunity built around obviously suspicious cross-process events. Security teams should be able to apply this logic to catch equally suspicious activity.
process == ('powershell.exe' || 'taskmgr.exe' || 'rundll32.exe' || 'procdump.exe' || 'procexp.exe' || [other native processes that don’t normally access LSASS])
&&
cross_process_handle_to ('lsass.exe')The following example demonstrates powershell.exe obtaining a suspicious handle (requesting PROCESS_ALL_ACCESS – 0x1F0FFF) to lsass.exe:
$Handle = [Uri].Assembly.GetType('Microsoft.Win32.NativeMethods')::OpenProcess(0x1F0FFF, $False, (Get-Process lsass).Id)The following example demonstrates a likely benign instance of powershell.exe obtaining a handle to lsass.exe by accessing the Handle property of a process object as the result of running the Get-Process cmdlet:
(Get-Process lsass).HandleThe following example demonstrates using ProcDump to dump lsass.exe memory:
procdump -accepteula -ma lsassAs we discussed in the analysis section above and in our analysis of Rundll32, adversaries can create a MiniDump file containing credentials by using rundll32.exe to execute the MiniDumpW function in comsvcs.dll and feeding it the LSASS process ID. To detect this behavior, you can monitor for the execution of a process that seems to be rundll32.exe along with a command line containing the term MiniDump.
process == rundll32.exe
&&
command_line_includes ('MiniDump')The following example dumps lsass.exe process memory using rundll32.exe:
powershell.exe -c "rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump "$((get-process lsass).id)" $PWD\lsass.dmp full"Monitoring LSASS child processes is critical because it doesn’t typically spawn additional processes (other than occasional instances of conhost.exe). Our detectors for suspicious LSASS process ancestry have helped us catch a large amount of coinminer activity, along with ransomware threats. The following pseudo ]-detection analytic is a good starting point to detect LSASS abuse:
process == lsass.exe
&&
child_process == ('cmd.exe' || 'powershell.exe' || 'regsvr32.exe' || 'mstsc.exe' || 'dllhost.exe' || [unsigned binaries])Parent process monitoring is also important. The following might help detect LSASS activity involving suspicious parent processes:
parent_process == ('explorer.exe' || 'cmd.exe' || 'lsass.exe' || [renamed or relocated system binaries] || [unsigned binaries])
&&
process == lsass.exeLSASS typically runs with SYSTEM-level privileges, and therefore, security teams can detect malicious use by identifying instances of LSASS running under any non-privileged user context. In order to do this, you’ll need the ability to collect users’ security identifiers (SID) for newly launched processes. Most endpoint monitoring solutions provide this as a metadata attribute associated with a process start record. Look at instances of LSASS running without a User SID including S-1-5-18.
The Microsoft ASR rule for blocking credential theft is designed to prevent certain applications from extracting credentials from LSASS Memory.
LSASS establishes a lot of cross-process memory injection stemming from itself. We identify far fewer false positives from processes injecting into LSASS. Some password-protection and antivirus products will scan LSASS to evaluate user passwords. If approved by your help desk or IT support, these applications should be added to an allowlist as part of a continuous tuning process. Detection logic should be routinely maintained with constant tuning to prevent alert overload. Your analytics should act as a living, breathing code repository with frequent, on-the-fly adjustments to navigate your evolving environment.
Start testing your defenses against LSASS Memory using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
View atomic tests for T1003.001: LSASS Memory. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using an elevated PowerShell prompt:
rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump ((Get-Process lsass).Id) C:\Windows\Temp\lsass.dmp full| Visibility | Telemetry | Collection |
|---|---|---|
| Visibility : Process monitoring | Telemetry: A | Collection : EDR, Sysmon Event IDs 1 and 10, and Windows Event ID 4688 should collect relevant telemetry |
| Visibility : Command monitoring | Telemetry: Command-line logging will capture the context of what is executed. | Collection : EDR, Sysmon Event ID 1, and Windows Event ID 4688 should collect relevant telemetry. |
| Visibility : Module monitoring | Telemetry:
| Collection : EDR and Sysmon Event ID 7 should collect relevant telemetry. |
| Visibility : File monitoring | Telemetry:
| Collection : EDR and Sysmon Event ID 11 should collect relevant telemetry. |
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.