Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
 

T1003.001

LSASS Memory

Thanks to the amount of sensitive information it stores in memory, LSASS is a juicy target for adversaries seeking to elevate their privilege level, steal data, or move laterally.

Pairs with this song

#10

Rank

8.9%

Percent of customers affected

280

Total threat volume
 

Editor’s note: While the detection opportunities and analysis on this page are still relevant, it has not been updated since 2023. 

 

Analysis Icon

Analysis

Why do adversaries use LSASS Memory?

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.

How do adversaries use LSASS Memory?

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.

 

Associated threats

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:

Other threats that have abused LSASS Memory include TrickBot, Zoremov, and Rose Flamingo.

Microsoft’s additional LSA protections that prevent code injection into LSASS remain among the best mitigation controls for protecting LSASS Memory. In brief, this configuration setting will only allow protected processes to inject into or read the memory content of LSASS.

Visibility icon

Visibility

 

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.

Process monitoring

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.

Process access monitoring

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.

File monitoring

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.

Collection Icon

Collection

 

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.

LSASS System Access Control List (SACL) auditing

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 Event ID 10: ProcessAccess

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.

Sysmon Event ID 7: Image Loaded

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.

Sysmon Event ID 11: FileCreate

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.

Icon-threat detection

Detection opportunities

 

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.

Abnormal LSASS process access and injection

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).Handle

The following example demonstrates using ProcDump to dump lsass.exe memory:

procdump -accepteula -ma lsass

Rundll32 dumping credentials with MiniDump function

As 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"

Abnormal LSASS child and parent process relationships

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.exe

Identity-based controls

LSASS 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.

Attack Surface Reduction (ASR): Block credential stealing from LSASS

The Microsoft ASR rule for blocking credential theft is designed to prevent certain applications from extracting credentials from LSASS Memory.

Weeding out false positives

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.

Testing Icon

Testing

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.

Getting started

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

What to expect

rundll32.exe will write a full lsass.exe process dump to C:\Windows\Temp\lsass.dmp. Running from an elevated PowerShell prompt will automatically populate the lsass.exe process ID, so that it doesn’t have to be entered manually.

Useful telemetry will include:
VisibilityTelemetryCollection
Visibility :

Process monitoring

Telemetry:

A rundll32.exe process will start.

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:

comsvcs.dll will load in the rundll32.exe process.

Collection :

EDR and Sysmon Event ID 7 should collect relevant telemetry.

Visibility :

File monitoring

Telemetry:

rundll32.exe will write the lsass.exe process dump to C:\Windows\Temp\lsass.dmp.

Collection :

EDR and Sysmon Event ID 11 should collect relevant telemetry.

Review and repeat

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.

 
 
Back to Top