How to create LSASS memory dump? - Red team diaries

One of the most widely used techniques by adversaries during Red Team engagements and real-world cyberattacks is OS Credential Dumping via LSASS (Local Security Authority Subsystem Service) Memory, categorized as MITRE ATT&CK technique T1003.001. This method involves extracting user credentials stored in memory, specifically from the LSASS process, which is responsible for enforcing security policies and handling authentication within Windows operating systems. By accessing this sensitive process, attackers can retrieve credential hashes, plaintext passwords, or Kerberos tickets, which they can then use for lateral movement and privilege escalation.

From an attacker's perspective, LSASS memory dumping is a highly effective and often low-effort method for gaining access to privileged accounts. Once an attacker dumps credentials from LSASS, they can use tools such as Mimikatz, Procdump, or task manager-based dumping to extract and decrypt stored authentication data. This can allow adversaries to impersonate legitimate users, bypass authentication mechanisms, and escalate privileges within the environment. The ability to retrieve credentials from LSASS is particularly useful in post-exploitation scenarios where attackers seek to establish long-term persistence and move laterally across a network with minimal detection.

From a defensive standpoint, preventing and detecting LSASS credential dumping is critical for protecting an organization’s infrastructure from unauthorized access. Security teams must implement a combination of least privilege access, credential hardening, and monitoring strategies to mitigate this risk. Key defensive measures include enabling LSASS protection (RunAsPPL), restricting local admin privileges, and deploying endpoint detection and response (EDR) solutions that can detect suspicious memory access patterns. Additionally, defenders can monitor event logs for anomalous process behavior, such as unauthorized access to lsass.exe or the creation of suspicious dump files. Implementing network segmentation and enforcing multi-factor authentication (MFA) can also reduce the impact of compromised credentials by limiting an attacker's ability to pivot within the network.

By understanding how attackers exploit LSASS memory and implementing robust security controls, organizations can strengthen their defenses against credential-based attacks. Red Teaming exercises that simulate LSASS dumping techniques allow security teams to validate their detection capabilities and improve their incident response processes, ensuring they are well-prepared to counter real-world threats.

Before an attacker can successfully dump credentials from the LSASS (Local Security Authority Subsystem Service) process, several key prerequisites must be met. These conditions determine whether the attack will succeed and how stealthy it can be.

To access the LSASS process memory, an attacker must have high privileges, typically Local Administrator or SYSTEM rights. This is because LSASS is a protected process, and lower-privileged users cannot interact with it directly. Attackers often achieve these privileges by exploiting misconfigurations, privilege escalation vulnerabilities, or mismanaged user roles.

Modern Windows versions implement several security mechanisms to prevent unauthorized access to LSASS:

• Protected Process Light (PPL) – On Windows 10 and later, LSASS runs as a protected process, preventing tools like Mimikatz from directly interacting with it. Attackers may need to disable PPL or bypass it.
• Credential Guard – If Windows Defender Credential Guard is enabled, LSASS does not store reusable credentials, significantly reducing the effectiveness of credential dumping.

That's it for the theory. During Red Teaming tests, I have had multiple opportunities to extract data from LSASS, and in almost all cases, the protective mechanisms for this process were not active. Credential Guard is not available in all versions of Windows 10 and Windows 11 and requires some effort to enable. Protected Process Light (PPL) has been enabled by default since Windows 10 version 1903, but in practice, many systems do not have this mechanism turned on.

We will cover bypassing Protected Process Light (PPL) and Credential Guard to dump LSASS in future blog posts. At this point we will focus on a simple scenario when our main enemy in LSASS dumping will be the antivirus software.

In general, we have a range of ready-made solutions at our disposal for LSASS dumping. These include both simple tools or scripts as well as functions available in larger solutions. We can use, among others:

Built-in Windows Tools and Living-Off-the-Land Binaries (LOLBins) with process dump capabilities:

• Comsvcs.dll
• Taskmgr.exe
• NtCore (nssm)
• Windows Error Reporting (WER) Service
• ProcDump

Offensive Security Tools / C2 Implants :

• Mimikatz
• Sharpdump
• Pypykatz
• Out-Minidump.ps1
• Meterpreter (Metasploit)
• Cobalt Strike Beacon
• Sliver C2
• Brute Ratel

The problem with the first group is the ease of detecting their use (or even their presence on a machine) by the security team based on file hashes or other simple IoC.

For the second group, we must consider the possibility of detection by security tools running in the system. Before using them, we need to take a series of actions that will allow us to achieve our goal.

To illustrate the problem, let's take a look at how the antivirus engines available on VirtusTotal perceive some of these tools.

As you can see, the detection rate is very high in general. But it is worth to mention that by removing comments and renaming some of the variables and functions we can lower detection rate.

Example: I took Out-Minidump.ps1 script and in a few minutes created Out-MiniGet.ps1 that is doing the same operations but after removing comments and renaming variables and functions the detection decreased from 32 to just 12 engines.

To achieve our goal and dump the memory of the LSASS process, we will use Visual Studio to build our own small command-line tool. This tool replicates the behavior of other utilities and performs the following steps:

• Acquires SeDebugPrivilege (implemented in the EnableDebugAbility function)
• Searches for a handle to the LSASS process (iterating over the results obtained from CreateToolhelp32Snapshot)
• Opens the LSASS process (using the OpenProcess function)
• Dumps the memory and saves it to a file (using the MiniDumpWriteDump function)

For anyone with some knowledge of Windows security, this set of function calls may appear purely malicious.

This raises the question—how will antivirus solutions perceive such an application?

As seen in the above VirusTotal screenshot, our application did not raise significant concerns. Only six antivirus engines concluded that it was doing something malicious.

The application's code is shown below and it works as follow:

• It calls our custom EnableDebugAbility() function (presented on next screenshot) to get SeDebugPrivilege permission. This is necessary to be able to dump lsass in our scenario.
• It dynamically creates lsass.exe string - which is in fact this simple trick to decrease detection rate from 6 to just 4.
• Next, it looks for LSASS PID by iterating on list of running processes using WIN API CreateToolhelp32Snapshot.
• It creates handle to lsass process using OpenProcess function.
• Finally, WIN API MiniDumpWriteDump is called to make dump of lsass process and write it to file.

You can also find the code in our repository at: https://github.com/brovar/red_team_education/tree/main/credential_access/simple_lsass_dumper Of course, the code has been posted there for educational purposes only.

Preventing LSASS credential dumping requires a multi-layered security approach, combining built-in Windows protections, endpoint hardening, and least privilege principles. Below are key mitigation strategies to reduce the likelihood of successful LSASS credential extraction.

• Enabling LSASS Protection forces lsass.exe to run as a Protected Process Light (PPL), preventing non-signed or unauthorized processes from accessing its memory.
• To enable it, modify the registry:
  
  

  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1 /f

• This setting helps block tools like Mimikatz from directly interacting with LSASS.

• Windows Defender Credential Guard (WDCG) prevents LSASS from storing reusable plaintext credentials in memory, making dumping attacks significantly less effective.
• To enable Credential Guard via Group Policy:
  
  

  Computer Configuration -> Administrative Templates -> System -> Device Guard -> Turn On Virtualization Based Security

• This feature uses Virtualization-Based Security (VBS) to isolate sensitive data, preventing direct access from compromised processes.

• By default, SeDebugPrivilege allows admin-level users to inspect processes, including LSASS. Restricting this privilege prevents unauthorized access.
• Use Group Policy to enforce User Rights Assignment:
  
  

  Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Debug programs

• Additionally, enabling LSA Protection Mode prevents unprivileged users from dumping LSASS memory.

• Tools like Mimikatz, ProcDump, and Task Manager can be blocked using Windows Defender Application Control (WDAC) or AppLocker.
• Example AppLocker rule to prevent unauthorized dumping tools:
  
  

  New-AppLockerPolicy -RuleCollectionType Executable -XmlPolicy "C:\Applocker.xml"

• This ensures that only trusted applications can execute within the environment.

• Attackers often escalate privileges to dump LSASS. Implementing Just Enough Administration (JEA) and removing unnecessary local admin rights significantly reduce risk.
• Use LAPS (Local Administrator Password Solution) to rotate local admin credentials frequently, preventing reuse.

• Modern EDR tools (CrowdStrike, SentinelOne, Microsoft Defender ATP) provide real-time monitoring and block unauthorized LSASS access.
• Enabling Tamper Protection prevents attackers from disabling security tools to execute credential dumping attacks.

By implementing these security measures, organizations can significantly reduce the risk of LSASS credential dumping, making it much harder for attackers to extract sensitive authentication data.

While mitigation reduces the attack surface, active detection is critical to identifying and responding to LSASS dumping attempts. Security teams can leverage SIEM solutions like Splunk and ELK, as well as endpoint monitoring to detect malicious activity.

• Suspicious access to lsass.exe is a strong indicator of credential dumping. Monitor for processes opening LSASS using:
  Splunk Query:

  index=windows EventCode=4688 
  | where (ParentProcessName="C:\\Windows\\System32\\lsass.exe" AND ProcessName IN ("procdump.exe", "mimikatz.exe", "taskmgr.exe"))

  
  ELK Query:

  { 
    "query": "process where process.parent.name == \"lsass.exe\" and process.name in (\"procdump.exe\", \"mimikatz.exe\", \"taskmgr.exe\")" 
  }

• Attackers often dump LSASS memory to a file before exfiltration. Look for suspicious dump files in system directories:
  Splunk Query:

  index=windows EventCode=4656 
  | where ObjectName LIKE "C:\\Windows\\Temp\\lsass.dmp" OR ObjectName LIKE "C:\\Users\\Public\\*.dmp"

  
  ELK Query:

  {
    "query": "file where file.path == \"C:\\Windows\\Temp\\lsass.dmp\" or file.path == \"C:\\Users\\Public\\*.dmp\""
  }

• Attackers may use rundll32.exe, comsvcs.dll, or Procdump to dump LSASS. Detect their execution with:
  Splunk Query:

  index=windows EventCode=4688 
  | where ProcessName IN ("rundll32.exe", "comsvcs.dll", "procdump.exe") AND CommandLine LIKE "%lsass%"

  
  ELK Query:

  {
    "query": "process where process.name in (\"rundll32.exe\", \"comsvcs.dll\", \"procdump.exe\") and process.command_line contains \"lsass\""
  }

• Attackers may assign SeDebugPrivilege to gain access to LSASS. Detect privilege escalation:
  Splunk Query:

  index=windows EventCode=4673 
  | where PrivilegeList="SeDebugPrivilege"

  
  ELK Query:

  {
    "query": "event where event.code == 4673 and event.privilege_list == \"SeDebugPrivilege\""
  }

• Sysmon logs direct memory access attempts, which is useful for detecting stealthy LSASS memory reads.
  Splunk Query:

  index=sysmon EventCode=10 
  | where TargetImage="C:\\Windows\\System32\\lsass.exe"

  
  ELK Query:

  {
    "query": "event where event.code == 10 and event.target_image == \"C:\\Windows\\System32\\lsass.exe\""
  }

• Monitor for processes attempting to access LSASS handles.
  
  Splunk Query:

  index=sysmon EventCode=4656 OR EventCode=10 
  | where ObjectName LIKE "%lsass.exe%" 

  
  ELK Query:

  { 
    "query": "event where event.code in (4656, 10) and event.object_name contains \"lsass.exe\"" 
  }

Dumping LSASS memory is a well-known technique for extracting credentials, and attackers have a variety of tools at their disposal, including Mimikatz, ProcDump, and custom scripts/binaries. Since accessing LSASS memory can be done through multiple methods—direct access, process injection, or kernel exploits—it remains a common tactic. Even if standard protections like PPL (Protected Process Light) are enabled, skilled attackers can bypass them by modifying kernel structures or using direct memory reads. Additionally, writing a custom LSASS dumping tool is relatively easy, making detection harder if proper defensive measures aren’t in place.

Defending against LSASS dumping requires a layered security approach that includes mitigation and detection strategies. Mitigation techniques include enabling LSASS PPL, enforcing Credential Guard, restricting debug privileges, and deploying EDR solutions to block unauthorized memory access. However, since no security control is foolproof, security teams must also focus on detection by monitoring for suspicious LSASS access, unusual process behavior, and privilege escalations. Using Splunk, ELK, and Sysmon, defenders can track process execution, memory dumps, and suspicious handle requests to quickly identify and respond to credential dumping attempts.

By understanding both the offensive and defensive perspectives, organizations can better prepare for real-world attacks and strengthen their security posture against MITRE OS Credential Dumping - LSASS Memory.