LSASS Memory

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:

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

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.

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.

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.