Detecting LSASS Memory Dumping

In the Windows Credentials room, we learned about many locations where Windows stores its credentials. The memory of the LSASS process is the first of them. In this room, you will learn what it stores, how threat actors dump it, and what to do to detect and prevent their attempts.

Learning Objectives

• Discover LSASS dumping techniques observed in real intrusions
• Learn how to utilize Windows event logs to detect the dumping
• Explore how to confirm the dumping even if the logs aren't there
• Most importantly, learn how to mitigate LSASS dumping

Prerequisites

• Complete the Windows Credentials room

Lab Access

Before moving forward, start the lab by clicking the Start Lab Machine button below. The VM opens in split view and takes about 2 minutes to fully load. You may also want to use DefenseBox for this room by clicking Start DefenseBox. It isn't required, but it's useful for experimenting with the artifacts and digging deeper than the room's practical exercises cover.

Set up your virtual environment

To successfully complete this room, you'll need to set up your virtual environment. This involves starting both your DefenseBox and Lab Machines, ensuring you're equipped with the necessary tools and access to tackle the challenges ahead.

Defender machine

Status:Off

Lab machine

Status:Off

Start Lab Machine

LSASS Overview

LSASS (Local Security Authority Subsystem Service) is a critical Windows process responsible for enforcing security policies and managing user logons. We've covered the process in detail in the Windows Credentials room. What you should know for this room is that LSASS is backed by the C:\Windows\System32\lsass.exe image, is always running on any Windows machine, and stores lots of sensitive data in its memory:

• NT hashes of logged-on users (both local and domain)
• Requested Kerberos tickets (TGTs and service tickets)
• And even more, depending on the system settings

Methods of LSASS Dumping

The bullet list above explains why LSASS dumping is the most common technique (MITRE (opens in new tab)) used by adversaries to access credentials and escalate privileges. All methods of LSASS dumping boil down to three simple steps: access the host, access its process memory (SYSTEM privileges required), and then parse credentials from it offline or directly on the victim's host. The next sections will show some examples.

Built-In Microsoft Tools

LSASS memory can be accessed with multiple legitimate Windows utilities, such as Task Manager, Process Explorer, and ProcDump. As an example, here is how HAFNIUM, a China-based hacking group, used (opens in new tab) ProcDump to dump LSASS:

# Note: ProcDump is a Windows-signed software
PS C:> c:\windows\temp\procdump -accepteula -ma lsass.exe C:\windows\temp\lsass

Assuming the adversaries have GUI access, such as when inside an RDP session, they may simply open the built-in Task Manager as Administrator, right-click the LSASS process, and create its memory dump (saved as %Temp%\lsass.DMP). This simple method was used by Sandworm APT in the recent campaign (opens in new tab) involving DynoWiper, a destructive data-wiping malware:

Dumping With LOLBins

There are a few other Windows binaries that can be abused to dump LSASS, such as sqldumper.exe (part of MS SQL Server) and comsvcs.dll (a core library used by COM+ services). You can check all of them at the LOLBAS project page (opens in new tab). The comsvcs.dll method is used the most, although it may require SYSTEM privileges in some scenarios. Here is how it looks in the simplest form and in the more complex Gentleman ransomware case (opens in new tab):

           # Simplest dumping example (MiniDump is a function inside comsvcs.dll)
rundll32 C:\windows\system32\comsvcs.dll,MiniDump LSASS_PID lsass.dmp full

# Gentleman ransomware example (#+0000^24 is an ordinal number for MiniDump)
CmD.eXe /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do ^
rundll32.exe C:\windows\System32\comsvcs.dll,#+0000^24 ^%B \Windows\Temp\im4.txt full
        

Dumping With Windows API

Lastly, attackers can create custom dumping programs that rely on the Windows API, specifically the MiniDumpWriteDump function or its lower-level NT* alternatives. Mimikatz, PowerSploit, Nanodump, Cobalt Strike, and other offensive tools use exactly this method by default. Let's see how it looked in the case (opens in new tab) of the APT41 campaign:

           # Note: mi.exe is a renamed Mimikatz binary
C:\mi.exe "privilege::debug" "sekurlsa::logonpasswords full" exit >> C:\log.tx
        

Advanced Dumping Methods

The methods explained above will eventually fade out because of the LSA Protection feature (more about it in Task 5). Attackers will need to switch to advanced techniques, bring their own malicious drivers, or develop exploits. With time, LSASS dumping will become a cat-and-mouse game between defenders and attackers, so be prepared to see new techniques and exploits every few months. For example:

• WSASS (opens in new tab) uses a trusted WerFaultSecure.exe process to dump protected LSASS
• KslDump (opens in new tab) exploits a preinstalled Windows Defender driver to bypass LSA Protection
• Nanodump (opens in new tab) utilizes a wide range of bypass and defense-evasion techniques

Parsing LSASS Content

Once LSASS memory is dumped using any of the methods above, the credentials from it must be extracted. Attackers typically either use one tool that can both access and parse LSASS memory directly on the host (like Mimikatz), or exfiltrate the dump and parse it offline (usually with Pypykatz (opens in new tab)). In any case, parsing the memory is trivial for attackers, and impossible for defenders to detect, so the whole battle is around dumping LSASS memory and preventing it.

Practice

• Access the lab VM and open CMD as Administrator
• Run klist sessions and note which users are logged in
• Locate Mimikatz in the Task 2 folder and answer the questions

Detection Via Process Access

The most reliable log-based detection is monitoring process access to lsass.exe, as nearly every dumping tool must open a handle to it. Start with Sysmon Event ID 10 (or Security Event ID 4656 as an alternative) and check whether any process accessed LSASS during the incident timeline. Below is a clear example of LSASS dumping: SourceImage is ProcDump, TargetImage is lsass.exe, and GrantedAccess is 0x1FFFFF - a mask commonly associated with dumping utilities (more on that in the next section):

Sysmon Event ID 10 (Process Access)

Process Access Mask

To access a Windows process, you need to specify the requested privileges, or access mask. According to the documentation (opens in new tab), the 0x1FFFFF (PROCESS_ALL_ACCESS) mask grants full access to process memory and is commonly used by dumping tools. By contrast, legitimate processes usually request less permissive masks that can't be used for LSASS dumping, such as 0x0400 (PROCESS_QUERY_INFORMATION). You can use access masks to:

• Filter out Sysmon noise and focus only on high-risk masks, as shown in the screenshots below
• Attribute the mask to a specific dumping method or tool (e.g., Mimikatz sekurlsa uses 0x1010)

Examples from the NextronSystems Sysmon config (opens in new tab) and the Elastic rule repository (opens in new tab)

Detection Via Process Creation

If Sysmon Event ID 10 wasn't enabled, check Sysmon Event ID 1 (or its Security Event ID 4688 alternative) and look for the creation of suspicious processes from the previous task, such as ProcDump or rundll32 loading comsvcs.dll. Even the simplest regex rules may still work against modern threats. Let's also see how to prepare for the most common defense evasion techniques attackers apply when dumping LSASS:

Evasion 1: Renamed LOLBin

Attackers often rename ProcDump and other LOLBins they use before dumping LSASS, but you can still detect them by using the OriginalFileName and Description Sysmon fields, which are parsed from the PE header. This (opens in new tab) Sigma rule will give you a good starting point for detecting such behavior:

An example of a renamed ProcDump (legitapp.exe) dumping LSASS
The OriginalFileName field reveals the true origin of the malware

Evasion 2: Masqueraded Comsvcs.dll

With the comsvcs.dll technique, attackers can copy and rename the DLL, hide its MiniDump function behind an ordinal number, and choose an arbitrary name for the resulting LSASS dump. Check out the screenshot below for an example. This (opens in new tab) Sigma rule will give you a good start for automated detection, but during DFIR it's still best to look through the logs manually so as not to miss anything.

A combination of a renamed comsvcs.dll (audiodbg.dll) and an LSASS dump file (report.log).
Such a combination is hard to detect with regex, but it stands out during a manual log review

Evasion 3: PowerShell

Adversaries may also use PowerShell cmdlets, such as PowerSploit's Out-Minidump. To detect this, supplement your hunt with logs like PowerShell/Operational Event ID 4104. These logs will give you the full PowerShell payloads, even if they are hidden inside scripts. Remember that Sysmon doesn't log PowerShell session history, so it won't capture the script execution or its content.

PowerShell/Operational Event ID 4104 showing the malicious content of runner.ps1

Detection Via File Creation

You can also focus on hunting for dump files, which are typically saved with .dmp, .mdmp, .save, and .bin extensions. Even if the extension is custom, you can look for dump files inside the common staging directories, such as %Temp% and %AppData%. Not all tools leave dump files on disk, but you can still look for them in file creation logs, namely Sysmon Event ID 11 (or its Security Event ID 4663 alternative).

Sysmon Event ID 11 confirming an LSASS dump by the PowerShell process

Summary Table

Practice

The SOC team spotted a malicious WindowsTweaker.exe process on the FS-EU-01 file server. They have asked for your expert help to investigate its Credential Access activities, specifically to confirm whether that process dumped LSASS. The related Sysmon logs were already exported for you in the Task 3 folder. Investigate the logs and answer the questions.

OS Artifacts

There are many artifacts that can show process execution, such as Prefetch, Amcache, and AppCompatCache. You can parse them and hunt for suspicious filenames resembling offensive tools (mimi.exe, pd.exe) or generic malware (a.exe, xjho8i.exe). The Amcache UnassociatedFileEntries artifact might be the most useful to you, as it stores SHA1 hashes of the dropped binaries. In the example below, the hash would confirm pd64.exe is actually a renamed ProcDump utility.

One more tiny observation: if you ever notice an empty myeasylog.log file, it might indicate ProcDump usage. This file is created in the same folder the ProcDump binary is located in the first time you run it.

Filesystem Artifacts

Apply the same workflow as for the Sysmon Event ID 11, just using MFT records and the USN journal. The USN will give a history of the dump files (creation timestamp, renames, copies to the collection directory), and MFT will supply you with the absolute path to the file. Keep in mind that even something like familyphotos.png may be a disguised LSASS dump. To confirm, correlate with other evidence and check if the file is still on disk.

USN log showing the creation of an LSASS dump file

MFT record showing the absolute path to the created dump

Hunting Dumps With YARA

Most tools output LSASS memory content in the Windows MiniDump format. The magic header for this format is 4D 44 4D 50 (MDMP). You can use YARA to scan the whole disk and look for files starting with these bytes, even if the dump file was renamed. Note that modern LSASS dumping tools can change the header at runtime (example (opens in new tab)), so the method is not bulletproof.

A unique MDMP header of the lsass.DMP file

Practice

Your colleagues from the SOC noticed suspicious activity on yet another server, but logging wasn't properly configured there. The Amcache entries and filesystem artifacts were already parsed and exported for you in the Task 4 folder; feel free to use Timeline Explorer on the DefenseBox, or just review the CSV files with Notepad. Once again, your task is to verify whether LSASS dumping has occurred and answer the questions below.

LSA Protection (RunAsPPL)

LSA Protection, also known as RunAsPPL, is a great kernel-level feature we mentioned in Task 2. It makes LSASS a protected process, and restricts access to it to a few system processes (which are protected processes, too). This feature can't easily be disabled and mitigates all classic attack methods we described in this room. Try running Mimikatz or ProcDump on a Windows 11 host, and both should fail because of this feature:

Configuring LSA Protection via Registry

LSA Protection has been available since Windows Server 2012 R2, and enabled by default since Windows Server 2025 and Windows 11 22H2. Enabling or disabling LSA Protection requires a reboot. Since Windows Server 2022 it also supports UEFI Secure Boot lock, so that you'd need physical access to the device to unset the lock. You can manage LSA Protection via the registry:

Configuring LSA Protection via GPO

From Windows Server 2022 onwards, you can also enable LSA Protection at scale via GPO. Note another toggle in the screenshot below: "Allow custom SSPs and APs to be loaded into LSASS". Standard LSA Protection already restricts SSP/AP DLLs to Microsoft-signed ones, but you can enable the second toggle for maximum protection, too (just test first, as it can break legitimate packages).

Vulnerable Driver Blocklist

There is one popular technique to bypass LSA Protection -  BYOVD (Bring Your Own Vulnerable Driver). In this technique, adversaries download a signed but vulnerable driver, load it into the kernel, and then exploit it to tamper with LSA Protection from the kernel space. Windows prevents such abuse by maintaining a blocklist of known vulnerable drivers, which has been integrated into Defender since Windows 11 22H2 / Server 2022. For older systems, the blocklist can be deployed via WDAC policy by following Microsoft documentation (opens in new tab).

A small selection of the drivers that Microsoft blocks (download the full blocklist here (opens in new tab))

A section specifically for blocking all drivers published by Mimikatz's author

Credential Guard

RunAsPPL protects the LSASS process from being dumped, but Credential Guard removes credentials from LSASS entirely. With it enabled, OS credentials live in a separate virtualized layer, unreachable by regular processes or even the kernel drivers we covered above. It can't be disabled without a reboot, and it makes LSASS dumping mostly useless, since NTLM hashes and Kerberos tickets are no longer stored there. Enabled by default since Windows 11 22H2 and Windows Server 2025, it would be an ideal protection if not for the nuances below.

What is the catch with Credential Guard?

• Works only on domain-joined machines
• Doesn't work on domain controllers by design
• Only available in Windows Enterprise edition
• Has hardware and virtualization prerequisites
• Can break legacy protocols and applications
  (For example, it doesn't work on Exchange Server)

Practice

For this task, let's test how LSA Protection works with Mimikatz.

• Enable LSA Protection by setting the RunAsPPL registry value to 1
• Reboot the lab VM (do it from the Windows GUI, not the TryHackMe interface)
• Try running Mimikatz again; you should receive an error shown below

           // Run Mimikatz with RunPPL set to 1
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords
ERROR [REDACTED]; Handle on memory (0x00000005)
        

• Mimikatz can bypass LSA Protection by installing its own signed driver (BYOVD technique)
• Install the driver by following the commands below (must be run after privilege::debug)

           // Install the Mimikatz driver
mimikatz # !+
[+] 'mimidrv' service successfully registered

// Use the driver to unprotect LSASS
mimikatz # !processprotect /remove /process:LSASS.EXE
Process : LSASS.EXE
PID 616 -> 00/00 [0-0-0]

// Try again!
mimikatz # sekurlsa::logonpasswords
        

• You should be able to dump LSASS now, even with LSA Protection enabled
• To mitigate this bypass, you'd need to enable the Vulnerable Driver Blocklist

Coming back to the beginning, how do credentials appear in LSASS? They typically appear there whenever a user logs in to the machine. If you don't log in, your credentials won't be present in LSASS. No matter whether protections from Task 5 are enabled or not, never log in on untrusted devices or regular workstations as a Domain Admin. Instead, apply the tiered AD model (opens in new tab), and don't forget about proper monitoring with Sysmon!