What Is LSASS Dumping? How Attackers Steal Credentials

• LSASS dumping is a technique where attackers extract sensitive credentials from the memory of the Windows Local Security Authority Subsystem Service LSASS process.
• It’s commonly performed post compromise on Windows servers or endpoints, especially Active Directory domain members, to harvest password hashes and tickets for lateral movement.
• This matters because stealing credentials from LSASS can escalate an intrusion from one machine to the entire network, a key step in many advanced persistent threat and ransomware attacks.
• Mitigations include Windows security features like Credential Guard and LSA Protection RunAsPPL to lock down LSASS, plus vigilant EDR monitoring for suspicious process access to LSASS memory.
• Mimikatz, an open-source tool released by Benjamin Delpy in 2011 and tracked by MITRE ATT&CK as S0002, is the best-known LSASS credential dumper. The "What Is Mimikatz?" section below explains what it does, which incidents used it, and how to detect and block it.

LSASS dumping is a credential stealing technique in which an adversary with high privileges pulls the contents of the LSASS process’s memory to retrieve user authentication secrets. LSASS Local Security Authority Subsystem Service is a critical Windows process responsible for enforcing security policy and managing user logins. When users log on, LSASS stores their credential materials in memory including NTLM password hashes, Kerberos tickets, and sometimes plaintext passwords to facilitate authentication. In an LSASS dumping attack, these in memory secrets are dumped and copied out so that attackers can crack passwords or reuse credentials directly for impersonation.

This technique has become pervasive in modern cyberattacks because it effectively turns one compromised machine into a stepping stone for full domain compromise. If an attacker obtains admin or SYSTEM access on a Windows host, they can dump LSASS and harvest credentials of other users potentially including domain administrators enabling immediate privilege escalation and lateral movement across the network. From state sponsored APT groups to ransomware gangs, many threat actors leverage LSASS dumping as a core tactic in their playbooks. It is frequently observed in intrusions on Active Directory domain environments, on premises servers, and even cloud hosted Windows VMs which function similarly to on prem Windows in this context. Note: This discussion focuses exclusively on Windows. Other operating systems handle credential storage differently, so LSASS dumping is a Windows specific attack.

DeepStrike's Red Teaming Services can include credential-access activity against endpoints, where agreed in scope, to test whether controls such as Credential Guard, LSA Protection and your EDR hold.

How LSASS Dumping Works

Prerequisites: In order to dump LSASS memory, an attacker must first gain administrative or SYSTEM level privileges on the target Windows machine. LSASS runs as a protected system process, so normal users cannot access its memory. Attackers often achieve this level of access through earlier steps in the kill chain such as local privilege escalation exploits or compromised admin credentials. Once running code with high privileges, the attacker can directly interact with LSASS.

Memory extraction methods: There are multiple ways to perform LSASS dumping, ranging from built in admin utilities to specialized hacker tools:

• Using legitimate system tools: Attackers may abuse Windows’ own capabilities to dump process memory. For example, the Windows Task Manager when run as an administrator allows memory dumps of processes via a simple right click Create Dump File, which internally calls the MiniDumpWriteDump API. Another common technique is running the Sysinternals utility ProcDump to create a full memory dump of LSASS. Even the rundll32.exe utility can be invoked with the Microsoft comsvcs.dll library to generate a dump of LSASS via an exposed MiniDump function. These approaches use legitimate, signed binaries often called LOLBins Living off the Land Binaries to carry out the dumping, helping attackers blend in with normal admin activity.
• Using dedicated credential dumping tools: More overt methods involve tools explicitly designed for extracting credentials. The most infamous is Mimikatz, which can either create an LSASS dump or read process memory directly to extract passwords and hashes in real time. Variants and alternatives like Pypykatz a Python implementation and Cobalt Strike’s nanodump module use similar techniques to avoid detection for instance, nanodump creates a minidump of LSASS entirely in memory to evade writing a dump file to disk. These tools often leverage Windows APIs e.g. ReadProcessMemory or MiniDumpWriteDump or inject code into LSASS to copy its memory contents. Attackers may also develop custom in memory dumpers to bypass signature based detection.
• Offline dumping: In some cases, attackers might obtain LSASS memory without executing dumping code on the host. For example, if they gain access to virtualization infrastructure, they can snapshot a running VM’s memory. A known technique is using VMware’s snapshot feature to retrieve a VM’s .vmem file which contains RAM contents and later extract LSASS data from it. This is an advanced scenario, but it illustrates that OS level controls can be bypassed if the hypervisor or cloud management layer is compromised.

Once the LSASS memory is captured typically as a .dmp or .bin file, the attacker transfers that dump off the victim machine for analysis. Using tools like Mimikatz or other credential parsers, they can then extract credentials from the dump offline at their leisure. This offline analysis is safer for the attacker because it avoids further running suspicious code on the victim host. The credentials obtained include password hashes NTLM hashes of user passwords, Kerberos tickets TGTs/TGSs used in domain authentication, and sometimes plaintext passwords notably, if WDigest authentication was enabled or if a user recently entered credentials that are still stored in memory. With these in hand, the attacker can proceed to use the credentials for malicious purposes.

Real World Examples

Attack scenarios: LSASS dumping is extremely prevalent in real world attacks, appearing in both targeted intrusions and opportunistic malware campaigns. For instance, during the 2016 Ukraine power grid cyberattack, the Sandworm threat group used Mimikatz to dump LSASS and gather credentials. Similarly, China linked APT1 and Russian linked APT28 have long been known to employ LSASS dumping via Mimikatz or custom tools as part of their operations. More recently, Microsoft reported that groups like HAFNIUM and GALLIUM nation state actors incorporated LSASS credential dumping in their techniques, and the method has also become common in the ransomware as a service ecosystem. Ransomware affiliates often use commodity malware like TrickBot or QakBot which include modules to dump LSASS, enabling the criminals to obtain a domain admin foothold before deploying ransomware broadly.

Even living off the land tactics include LSASS dumping. Threat actors have been observed simply using built in admin tools to dump credentials without needing custom malware. A report from Microsoft shows that between March and August 2022, some popular ways to dump LSASS were via comsvcs.dll invoked by rundll32, the Sysinternals ProcDump.exe, and even Task Manager all legitimate Windows or Microsoft signed utilities. These were used by various adversaries tracked by Microsoft as groups like Storm 0270 and Storm 0300 to avoid easy detection. Of course, dedicated hacker tools like Mimikatz remain in heavy use as well, sometimes in modified forms to evade antivirus.

Legitimate uses: While normally an attack technique, dumping LSASS isn’t always malicious. In digital forensics and incident response DFIR, security analysts might create an LSASS memory dump from a compromised server to analyze what credentials were in memory and assess the breach’s scope. This can help identify which accounts may have been stolen by an attacker. LSASS dumps are also utilized in malware analysis: researchers examine them to understand how a credential stealing malware operates and what data it targets in the authentication subsystem. Apart from security, a systems engineer might rarely dump LSASS or any process for troubleshooting a crash or hung process, but that is an infrequent scenario. Essentially, outside of very specific IT tasks, any instance of LSASS dumping in production is a red flag and is overwhelmingly likely to be malicious.

Common environments: LSASS dumping is primarily a concern on Active Directory domain environments, since that’s where its value is highest. An attacker on a regular Windows 10/11 workstation might dump LSASS to get that user’s credentials, but dumping a Domain Controller’s LSASS or a server where admins frequently log in can yield far more powerful credentials like Kerberos keys or admin hashes. Thus, we often see attackers focusing this technique on critical servers or admin workstations. Whether on physical machines or cloud hosted Windows VMs, the technique and impact remain the same. It’s a cornerstone of post exploitation toolkits in Windows networks, often appearing alongside related credential theft techniques such as dumping the SAM/NTDS databases or grabbing cached credentials, all aimed at moving through the network.

What Is Mimikatz?

Mimikatz is an open-source Windows security tool, written by French researcher Benjamin Delpy, that extracts authentication secrets from memory, mainly from the LSASS process. Those secrets include NTLM password hashes, Kerberos tickets and, on older or misconfigured systems, plaintext passwords. MITRE ATT&CK tracks it as software S0002, a "credential dumper" classified as a tool rather than malware. It's the tool most closely associated with LSASS dumping, which is why it appears throughout this guide.

Origin: from a 2011 proof of concept to an attacker staple

Delpy, then an IT manager at a French government institution, built Mimikatz as a side project. He wanted to learn more about Windows security and to prove to Microsoft that WDigest authentication kept an encrypted copy of each user's password in memory next to the key needed to decrypt it, according to WIRED's 2017 profile of the tool. Delpy says Microsoft didn't treat his 2011 report as a real flaw, so he released Mimikatz publicly in May 2011 as a closed-source program. The name combines the French slang "mimi" (cute) with "katz": cute cats.

Adoption was fast. WIRED reports that Mimikatz was used in the September 2011 breach of the DigiNotar certificate authority, and that Delpy published the source code on GitHub in 2012. Microsoft added the ability to turn off WDigest credential caching in Windows 8.1 in 2013 and later disabled it by default. Delpy kept adding features, so today's Mimikatz is a broad toolkit for Windows authentication research rather than a single trick.

What Mimikatz can do (the concepts)

MITRE ATT&CK maps Mimikatz to more than a dozen techniques. In plain terms they fall into four groups:

• Read credentials stored on the host: LSASS memory (T1003.001), the Security Account Manager database (T1003.002), LSA secrets (T1003.004), Windows Credential Manager (T1555.004) and passwords saved in web browsers (T1555.003).
• Reuse what it steals: pass the hash (T1550.002) and pass the ticket (T1550.003) let an attacker authenticate with a hash or Kerberos ticket instead of a password. This is the engine of lateral movement in Windows domains.
• Forge or abuse domain trust: golden and silver tickets (T1558.001 and T1558.002), DCSync (T1003.006), which asks a domain controller to replicate password data, and a rogue domain controller (T1207).
• Other credential material and persistence: stealing or forging certificates (T1649), exporting private keys (T1552.004), Security Support Provider persistence (T1547.005) and SID-History injection (T1134.005).

Every one of these needs high privileges first: local administrator or SYSTEM on the host, and replication rights in the domain for DCSync. Mimikatz is a post-exploitation tool. It turns an existing foothold into wider access, which is why privilege escalation usually comes first. This guide deliberately leaves out module names and command syntax: defenders don't need them to detect or block the behavior.

Why defenders care about Mimikatz

It's everywhere. MITRE's S0002 entry lists dozens of threat groups and campaigns that have used Mimikatz, from state actors such as Sandworm Team, APT28 and APT29 to the financially motivated FIN7, the Akira ransomware group, Scattered Spider and the SolarWinds compromise campaign. If you only prepare for one credential-theft tool, this is the one.

It's public and easy to change. Because penetration testers and red teams use it legitimately, the source code is openly available. Attackers recompile, rename and reimplement it, and Pypykatz (mentioned above) reimplements its parsing in Python. Detection that depends on a file name or hash alone will miss these variants, so defenders have to watch the behavior: something reading LSASS memory.

One run can cost you the domain. A single successful run on a server where a domain admin has logged on can hand an attacker the keys to every system. Delpy made the point himself to WIRED: "If Mimikatz has been used to steal your passwords, your main problem is not Mimikatz." The root causes are privilege sprawl and credentials left on machines that don't need them.

Well-known incidents that used Mimikatz

• NotPetya (June 2017): CISA's alert on NotPetya says the first and, in most cases, most effective way the malware spread was "a modified version of the Mimikatz tool" that stole Windows credentials. It then used those credentials with WMIC or PsExec to reach other systems, and used EternalBlue against unpatched hosts. CISA updated the alert on February 15, 2018, to reflect the U.S. government's attribution of NotPetya to the Russian military. WIRED reports that it paralyzed thousands of computers at companies including Maersk, Merck and FedEx.
• BadRabbit (October 2017): according to WIRED, this ransomware worm also paired Mimikatz with leaked NSA exploits so that it could spread through networks on its own.
• DigiNotar (2011): within months of its release, Mimikatz was used in the breach of the Dutch certificate authority. The fraudulent certificates issued in that intrusion were used to spy on Iranian users, and DigiNotar went bankrupt, as WIRED recounts.
• Nation-state and ransomware operations: MITRE ATT&CK lists Mimikatz in the SolarWinds compromise campaign (C0024) and in the toolkits of groups such as Sandworm Team and APT28. The Sandworm and APT28 examples in the Real World Examples section above are part of the same pattern.

The pattern is consistent: Mimikatz is rarely how attackers get in. It's the step that turns one compromised host into many, so that's where detection pays off.

How to detect Mimikatz activity

Watch for what any credential dumper has to do, not for the tool's name. These signals complement the Detection & Monitoring section above:

• Process access to LSASS: Sysmon Event ID 10 (ProcessAccess). Microsoft's Sysmon documentation says this event enables detection of hacking tools that read LSASS memory to steal credentials, and that it should be filtered to remove expected access. Allow-list your EDR and backup agents and alert on everything else. Windows Security events 4656 and 4663 add the same view when handle auditing is on.
• Debug privilege before LSASS access: a process that enables SeDebugPrivilege (event 4703, when that auditing is on) and then opens lsass.exe is a strong combination.
• Stolen credentials being used: NTLM network logons (event 4624) and Kerberos ticket requests (events 4768 and 4769) for privileged accounts from hosts that don't normally use them, and directory replication requests (event 4662) from a machine that isn't a domain controller, a classic DCSync signal.
• Tampering with LSASS protections: changes that turn off LSA protection, Credential Guard or Defender settings usually come right before a dumping attempt. Alert on them.
• Antivirus and EDR hits: most security products flag known Mimikatz builds. Treat a hit as evidence of hands-on-keyboard activity, not as the end of the investigation.

If you confirm Mimikatz activity, follow your incident response plan: isolate the host, assume every credential that was cached on it is compromised, reset those accounts, and if domain controllers or the KRBTGT account were exposed, plan a full KRBTGT reset.

How to prevent Mimikatz from working

• Credential Guard: Microsoft's Credential Guard overview says it uses virtualization-based security to protect NTLM hashes, Kerberos TGTs and stored domain credentials, so malware with administrative privileges can't extract them. It's on by default from Windows 11 22H2 and Windows Server 2025 for domain-joined, non-DC devices that meet the license and hardware requirements. It isn't recommended on domain controllers and doesn't protect the Active Directory database or the SAM.
• LSA protection (RunAsPPL): available since Windows 8.1 and Windows Server 2012 R2, it stops nonprotected processes from reading LSASS memory or injecting code into it, according to Microsoft's LSA protection guide. Use it with UEFI lock and Secure Boot so a registry change can't simply switch it off, and use the audit mode (on by default from Windows 11 22H2) to find incompatible plug-ins before you enforce it.
• ASR rule "Block credential stealing from the Windows local security authority subsystem": a Microsoft Defender rule supported on Windows 10 1803 and later, Windows 11 and Windows Server. Microsoft's ASR rules reference notes that it doesn't support Warn mode and doesn't raise EDR alerts or user notifications, so pair it with the process-access telemetry above.
• Credential hygiene: keep WDigest credential caching off, put privileged accounts in the Protected Users group, use LAPS for unique local admin passwords, keep domain admins off workstations (tiered administration), and grant SeDebugPrivilege only where it's needed.

Testing your defenses against Mimikatz-style credential theft

The only safe way to know whether these controls hold is authorized, scoped testing. During an internal penetration test, testers work under written rules of engagement, usually on agreed hosts. They check whether Credential Guard and LSA protection are actually running, whether the ASR rule is in block mode, whether your SOC sees and escalates LSASS access, and how far stolen credentials would travel. Mapping the results to the MITRE ATT&CK framework shows which techniques you detect, which you block and which you miss. DeepStrike's red teaming services can include this credential-access testing where it's agreed in scope.

Why LSASS Dumping Is Important

LSASS dumping is vitally important to defenders because it represents a tipping point in an attack. Once an adversary successfully steals credentials from LSASS, they can impersonate users and escalate privileges at will. In many cases, this is the difference between an attacker containing their activity to one compromised host versus gaining control over an entire domain. With extracted password hashes, an attacker can perform similar lateral movement methods like Pass the Hash to authenticate to other systems without cracking the passwords. If Kerberos tickets TGTs are obtained, they might perform Pass the Ticket or even craft Golden Tickets to persist indefinite domain access. In short, a successful LSASS dump often leads directly to widespread lateral movement and complete enterprise compromise.

From a security impact perspective, LSASS dumping undermines the fundamental trust in authentication. Windows is designed to keep credentials safe, but this technique exploits the necessary presence of credentials in memory. The adversary is effectively stealing keys to the kingdom: for example, a domain admin’s hash or plaintext password from memory can be used to log into domain controllers or critical servers, thereby leapfrogging the attacker’s privileges from local admin on one box to domain administrator across the environment. This cascading effect is why credential dumping and LSASS in particular is categorized under Credential Access in the MITRE ATT&CK framework and is considered one of the most critical phases to detect and block.

There are also operational and business implications. If attackers automate LSASS dumping as many malware families do, they can gather dozens of credentials within minutes of breaching a network. This not only accelerates the breach but also makes incident response far more challenging, responders must assume multiple accounts including potentially high privilege accounts are compromised. Ultimately, the presence of LSASS dumping in an attack almost always correlates with higher damage: data theft, ransomware deployment, or destructive actions become much more feasible once the attacker has legitimate credentials. For this reason, protecting LSASS and monitoring for its abuse is a high priority in enterprise cybersecurity today.

Common Abuse or Misuse

Attackers abuse LSASS in a variety of ways precisely because it is such a high value target. Here are common patterns in how this technique is leveraged and why it’s so effective:

• Abusing trusted processes: As noted, adversaries often hijack trusted Windows processes or admin tools to perform the dump. This abuse of allowed applications makes the activity harder to spot. For example, running rundll32.exe with a DLL like comsvcs.dll to dump LSASS appears, at first glance, like a legitimate system operation. Similarly, using ProcDump or Process Hacker, another admin tool to create a dump file, can fly under the radar if such tools are not strictly controlled. Even the built-in Windows Error Reporting WER mechanism has been exploited to silently create LSASS dumps by triggering a fake crash and capturing the dump via WerFault.exe. These tactics illustrate the lengths attackers go to mask credential dumping as normal activity.
• Custom and in memory tools: On the other end of the spectrum, attackers may use entirely custom tooling to avoid known signatures. We’ve seen malware authors write their own LSASS dumpers that perform minimal actions to evade detection for instance, only reading specific memory ranges or using direct syscalls to avoid API monitoring. Tools like nanodump emerged to dump LSASS in a stealthy manner by running as a Beacon object file in memory and not touching disk at all. Likewise, some techniques leverage handle duplication e.g., injecting into one process that already has SYSTEM rights to indirectly read LSASS which can confuse security products. Because LSASS dumping techniques are so well known, there’s an ongoing cat and mouse game: attackers constantly tweak their methods to bypass new defenses, from API unhooking to exploiting newly discovered OS weaknesses.
• Why it’s effective: Ultimately, LSASS dumping remains effective because Windows needs to keep credentials accessible in RAM for single sign on and network authentication to work. Even when passwords aren’t stored in clear text, the hashes and Kerberos tickets present in LSASS memory are enough for attackers to reuse. In addition, many organizations inadvertently make this easier by poor privilege hygiene e.g., administrators using their domain accounts on standard workstations. This means an attacker who compromises any user machine might find a domain admin’s credentials in LSASS if that admin had logged in earlier. Attackers bank on these common weaknesses, and unfortunately in many environments the technique succeeds with minimal resistance.
• Stealth and detection challenges: Credential dumping can be hard to detect in real time because reading process memory doesn’t always cause obvious system instability or network traffic. A well crafted LSASS dump using official APIs might not crash the LSASS process or trip immediate alarms, especially if no security tooling monitors that specific behavior. Attackers also often perform dumping quickly and then move on to using the credentials, leaving a short window for detection. Moreover, if they use encrypted or in memory only tools, traditional antivirus might not catch it. All of this puts the onus on behavioral detection and proper controls discussed below to catch the misuse. The effectiveness of LSASS dumping for attackers and the difficulty of completely preventing it without strong measures is exactly why it remains such a popular technique in offender toolkits.

Detection & Monitoring

Detecting LSASS dumping requires watching for a combination of suspicious process behavior and system artifacts. Since accessing LSASS memory is not something that most applications ever need to do, any process doing so should be treated as suspect. Modern Endpoint Detection and Response EDR tools and security telemetry can reveal these patterns:

• Process access indicators: Security monitoring should flag unexpected processes that open lsass.exe with memory-read rights (PROCESS_VM_READ, often seen as GrantedAccess values such as 0x1010 or 0x1410 in Sysmon Event ID 10), as well as full-access masks. Typically, an administrator process needs to request rights like PROCESS_VM_READ or PROCESS_DUP_HANDLE on LSASS to dump it. For example, an unexpected process calling OpenProcess on LSASS with a full-access mask (0x1FFFFF on modern Windows; 0x1F0FFF on legacy systems) is a telltale sign. Microsoft’s detection guidance describes this sequence: an abnormal process opening LSASS, followed by memory dump or file writes, as indicative of credential theft. If you have Sysinternals Sysmon deployed, Event ID 10 Process Access can capture a process attempting to access LSASS, this, combined with Sysmon Event 11 file created for an .dmp file, is a strong signal of LSASS dumping. In Windows Security logs, enabling Audit for handle access can generate Event ID 4656/4663 when a handle to LSASS is requested and used, these events can be filtered for the LSASS process and specific access rights to spot malicious access.
• Unusual process behavior: Even without deep handle inspection, certain process executions are inherently suspicious. For example, if you see rundll32.exe executing comsvcs.dll with a MiniDump function, that’s a red flag of a dump attempt. Likewise, taskmgr.exe spawning a dump of LSASS, especially outside of expected administrative activity, should almost never happen in normal operations. EDR solutions look for these anomalies, often by maintaining a list of known LSASS accessing tools Mimikatz signatures, etc. and by detecting behavioral patterns. For instance, a process that enables SeDebugPrivilege (Event ID 4703, 'A user right was adjusted', logged when Audit Authorization Policy Change is enabled) and then opens LSASS could generate an alert. Event 4672 is different: it is logged at logon when special privileges such as SeDebugPrivilege are assigned to the new logon session. Many EDRs will raise high severity alerts whenever a process tries to read LSASS memory, because in a typical environment, only antivirus or backup software should do so any other process doing this is likely malicious.
• Memory dump files and artifacts: Creation of a dump file e.g., lsass.dmp on disk can be another indicator. Attackers often write dumps to a temp directory or somewhere in C:\Windows\ then exfiltrate it. Monitoring file system events for the creation of files with .dmp extension or large binary files by unusual processes can pay off. Also, if LSASS is dumped improperly, it might crash and a sudden LSASS crash WinInit event error, followed by a system reboot because LSASS termination triggers a restart is a big warning sign. While skilled attackers avoid crashes, an attempted dump could sometimes fail and cause instability.
• Network and subsequent activity: Although dumping LSASS itself is a local action, it’s usually followed by attacker behavior that can be caught. For example, after getting credentials, an attacker might start using those credentials to connect to other machines to look for a spike in NTLM logon events or Kerberos ticket usage from that host. If multiple machines suddenly report the same user logon from the compromised host, that could mean credentials from LSASS are being used to pivot. Monitoring for network level attack patterns like an unusual number of failed logons, possible password guessing using hashes or a normally unprivileged machine performing administrative actions over the network can help tie back to a credential theft incident.
• EDR capabilities: Good EDR solutions have built in rules to detect known dumping behaviors. For example, Microsoft Defender for Endpoint has cloud delivered protections that will alert on patterns like those used in known tools, even if renamed or slightly modified. In fact, in AV-Comparatives’ 2022 LSASS credential-dumping test, as reported by Microsoft, Defender for Endpoint ultimately prevented 15 of 15 test cases with the LSASS ASR rule and PPL turned off. This highlights that up to date EDR can catch most standard techniques. However, one should not rely solely on tools it’s important to enable relevant Windows audit logs, deploy Sysmon for granular events, and aggregate this telemetry into a SIEM where custom detection rules like alerting on any process handle open to LSASS by non whitelisted processes can be implemented. Regular threat hunting for traces of Mimikatz, procdump, or suspicious use of rundll32 can also uncover stealthy attempts that might not have triggered a blocking alert.

In summary, visibility is key: defenders should instrument endpoints to catch the slightest poke at LSASS. A combination of OS level logging and advanced behavioral detection provides the best chance to spot LSASS dumping in progress or after the fact.

Mitigation & Prevention

Protecting against LSASS dumping requires a layered approach, starting with hardening Windows itself and then adding monitoring and response on top. Key mitigation strategies include:

• Enable Credential Guard VBS: Microsoft’s Credential Guard uses virtualization based security to isolate LSASS secrets in a separate secure subsystem. When Credential Guard is enabled, even if an attacker dumps LSASS’s process memory in the normal OS, the critical credentials NTLM hashes, Kerberos TGTs are stored in an isolated VM and cannot be read. This dramatically reduces what an attacker can get for example, Mimikatz on a Credential Guard enabled machine cannot extract domain credentials. Note that Credential Guard is available on Windows 10 Enterprise and above and requires certain hardware features UEFI Secure Boot, CPU virtualization extensions. As of Windows 11 Enterprise edition, with supported hardware, Microsoft even enables Credential Guard by default on new installations. Organizations should take advantage of this, while being aware of limitations some legacy drivers or applications might be incompatible, and not all credential types are protected e.g. Kerberos service tickets are still accessible even under Credential Guard. It’s a strong first layer of defense nonetheless.
• LSA Protection RunAsPPL: This is a Windows feature that runs LSASS as a Protected Process Light, meaning only trusted, code signed processes with special permissions can interact with it. Enabling LSA Protection via a registry setting or group policy in Windows 8.1+ and Server 2012 R2+ prevents most third party programs including typical malware from opening LSASS’s memory or injecting code into it. Essentially, the OS will refuse access to LSASS for anything that isn’t Windows system level. This can break some legitimate tools like certain backup or AV software if they aren’t defined to run with proper privileges, but it significantly hardens the system. It’s recommended to enable this on sensitive systems like domain controllers and admin jump boxes. Windows 11 has gone further to turn this on by default in many cases. Important: LSA Protection is complementary to Credential Guard even if you cannot use VBS, at least use RunAsPPL to raise the barrier for LSASS access. According to Microsoft, enabling LSA Protection will block even suspicious admin level processes from dumping LSASS, whereas the separate Defender ASR rule below can be seen as a behavior based block.
• Defender ASR rule Block LSASS credential stealing: Microsoft Defender includes an Attack Surface Reduction ASR rule specifically to block untrusted processes from opening LSASS. This rule Block credential stealing from the Windows local security authority subsystem can be configured via Endpoint Security or group policy. When enabled, even if an attacker has admin rights and tries to dump LSASS using a tool, the OS via Defender will prevent the memory read and typically log an event. This is a very effective mitigation. Microsoft reported that, in its evaluation, this single rule successfully stopped all the techniques it tested. It’s recommended to enable this ASR rule in block mode for all endpoints that support it. Be mindful to test first audit mode because in rare cases, certain IT tools that legitimately access LSASS, some password recovery tools or backup agents might need exclusion. Also, ensure Defender Tamper Protection is on so attackers cannot easily disable these security settings.
• Limit debug privileges and account exposure: Only highly trusted accounts or security software should have the SeDebugPrivilege that allows attaching to system processes. In practice, this means using the principle of least privilege aggressively. Regular IT users should not log on with admin rights on their workstations, and helpdesk/admin accounts should be split and tiered. Privileged Account Management practices help here: do not reuse local admin passwords, deploy LAPS or a similar solution to have unique, rotated local admin creds. Ensure that domain admins or other Tier 0 accounts never log onto lower tier machines like user workstations they should use dedicated secure admin workstations. By limiting where high value credentials appear, even if LSASS is dumped on a typical machine, it won’t yield the keys to the kingdom. This containment strategy was highlighted by MITRE as a mitigation: don’t put domain accounts in local admin groups broadly, to avoid one dump compromising them everywhere.
• Disable legacy credential caches: Windows had older features that made credential dumping easier, such as the WDigest protocol which by default would keep plaintext passwords in LSASS memory on older systems. Ensure the registry setting UseLogonCredential for WDigest is disabled on modern Windows it is by default, but verified via Group Policy. Also consider limiting or disabling NTLM where possible NTLM hashes are a prime target for reuse attacks, and if your environment can enforce Kerberos or use newer authentication methods, it reduces the value of stolen hashes. This can be complex in practice, but at least disable NTLM for highly sensitive systems or across trust boundaries.
• Network segmentation and lateral movement controls: While not directly stopping LSASS dumping, good segmentation can contain the damage if credentials are stolen. For instance, isolate servers so that a compromised user machine can’t directly reach the domain controller. Use features like Windows Firewall or ACLs to restrict SMB, WinRM, and LDAP traffic only to what’s needed. This way, even if an attacker gets some credentials, they might struggle to use them to move freely. Additionally, enable features like Remote Credential Guard for RDP which prevents the remote machine from gaining your credential material during an RDP session and Restricted Admin mode for RDP which avoids sending reusable creds to the target system. These can limit scenarios where credentials end up on machines unnecessarily.
• Cloud VM considerations: In cloud or virtual environments, remember that hypervisor or management plane compromise can negate OS level protections. For example, an attacker who gains admin access to VMware vCenter can snapshot a VM’s memory and extract LSASS externally. Cloud providers generally don’t expose memory capture to tenants, but an overly privileged cloud admin user could install an agent or use a diagnostics feature to dump memory. Mitigate this by strictly controlling who has cloud subscription or VM administration rights. Use encryption for VM snapshots/backups if possible, and monitor administrative actions in the cloud e.g., alerts for new snapshots or unusual management operations on critical VMs. Essentially, extend your least privilege and monitoring principles to the cloud layer: even if OS controls are strong, a breach of the cloud management layer could allow an attacker to work around them.

In summary, no single mitigation is foolproof, so defense in depth is crucial. Harden the OS Credential Guard, LSA Protection, harden the accounts tiered admin model, least privilege, and deploy active monitoring and response EDRs with ASR rules, rigorous logging. By combining these, you significantly raise the cost and complexity for an attacker attempting LSASS dumping, hopefully enough to deter them or at least detect them before major damage is done.

Related Concepts

LSASS dumping is one technique in a broader landscape of credential theft and lateral movement. It’s helpful to understand how it relates to other tactics and defenses:

• OS Credential Dumping Various: Apart from LSASS memory, attackers may target other sources of credentials on Windows. These include dumping the SAM database local account hashes or extracting the NTDS.dit database from a Domain Controller all domain password hashes akin to a more bulk approach than LSASS. There’s also the DCSync technique where an attacker simulates a domain controller and asks another DC to replicate credentials to them. These related credential theft techniques often go hand in hand, for instance, an attacker might dump LSASS on a member server to get a domain admin hash, then use that access to perform DCSync on the DC.
• Pass the Hash / Pass the Ticket: These are lateral movement methods that usually follow LSASS dumping. In Pass the Hash, an attacker uses an NTLM hash stolen from LSASS or SAM to authenticate to other systems without needing to know the plaintext password. In Pass the Ticket, they use extracted Kerberos tickets or create Golden Tickets if they have the Kerberos signing keys to impersonate users on the network. LSASS dumping provides the raw material hashes, tickets that make these attacks possible. Defenders often treat alerts of LSASS dumping as a prelude to such similar lateral movement methods, and will look for subsequent unusual authentication events across the network. This dump-then-pivot chain is exactly what a Red Team vs Blue Team exercise is designed to stress test.
• Lateral Movement and Privilege Escalation: Beyond using credentials directly, LSASS dumps enable attackers to perform actions like pivoting with PsExec or WMI. For example, after dumping credentials, an attacker might use the stolen admin credentials to run tools remotely like executing a service via PsExec on another host. LSASS dumping is thus a critical link in the kill chain bridging initial compromise to full domain takeover, it provides the means for privilege escalation if higher privilege creds are obtained and lateral movement using those creds to access other machines. It often works in concert with other techniques like service execution, scheduled tasks, or exploitation of trust relationships.
• Detection techniques: On the defensive side, LSASS dumping detection relates to memory forensics and anomaly detection. For example, the presence of certain strings or heuristics in memory like Mimikatz patterns is a concept overlapping with malware detection. Also, LSASS protection ties into Windows internals understanding concepts like Protected Processes, Security Support Providers SSPs, and credentials caching help in grasping why LSASS is vulnerable and how features like Credential Guard change that. Another related concept is monitoring anomalous account behavior if an account suddenly authenticates in unusual ways after an LSASS dump, indicating it’s been compromised.
• Complementary controls: Mitigating LSASS dumping aligns with broader security controls: for instance, enforcing multi factor authentication MFA can limit the usefulness of stolen passwords though hashes and tickets can still bypass MFA in some cases. Privileged Access Workstations PAW are another concept if admins only log into highly secured machines that are well monitored and don’t contain internet facing attack vectors, it’s much harder for attackers to ever dump a domain admin’s creds. In identity security, features like the Protected Users AD group can reduce how long credentials are cached and prevent older auth protocols, indirectly reducing exposure in LSASS. Finally, ongoing user training and vigilance against phishing reduce the chance an attacker gets that initial foothold needed to even attempt an LSASS dump.

By understanding LSASS dumping in context, defenders can better anticipate the next steps an attacker might take and deploy holistic mitigations. It’s a piece of the larger puzzle of Windows enterprise defense, closely intertwined with credential management and network security practices.

FAQs

• What credentials can an attacker obtain from an LSASS dump?

By dumping LSASS memory, an attacker can collect a variety of authentication data. This typically includes NTLM password hashes for any users with sessions on that machine, Kerberos tickets TGTs/TGSs for domain authentication, and potentially plaintext passwords for those sessions if certain conditions are met for example, if WDigest is enabled or if the system is an older Windows version that hasn’t disabled that. LSASS also holds cached credentials for recently logged on accounts and service account passwords often in hashed form. Essentially, any credential material that Windows is using to validate logons or SSO can be present in LSASS’s memory.

• Do you need to be an administrator to dump LSASS?

Yes. Only a process with high privileges, typically NT AUTHORITY\SYSTEM or a user in the Administrators group can open and read the LSASS process memory. That’s why attackers first work to gain admin rights on a machine before attempting to dump credentials. Standard users do not have the necessary permissions. In fact, Windows runs LSASS as a protected process by default only on new installations of Windows 11 version 22H2 or later that are enterprise joined and capable of hypervisor-protected code integrity (HVCI); other Windows 11 22H2 and later devices get only audit mode by default, according to Microsoft's LSA protection guide. Where that protection is on, even an admin may be blocked unless they disable it or have a signing certificate. But in general, any malware or tool capable of LSASS dumping is either running as administrator or has exploited a system level vulnerability to act with those privileges.

• How can I tell if LSASS was dumped on a system?

There are a few telltale signs. First, check for any dump files e.g., .dmp or .tmp files that could be LSASS dumps, they might be left in the Temp folder or a suspicious directory. Next, look at Windows Event Logs and Sysmon logs for suspicious activity: Event ID 4656 with an access mask request on LSASS, Sysmon Event 10 showing a process accessed LSASS’s memory, or Event 4688 showing unusual processes starting like rundll32.exe comsvcs.dll or procdump.exe targeting LSASS. Also, if your security software logs any alerts, many AV/EDR solutions will flag or block Mimikatz and similar tools, that’s a strong indicator. If LSASS unexpectedly crashed and you see a WinInit event about LSASS termination followed by a reboot, that suggests someone tried to tamper with it. Proactively, you should have monitoring in place for these signals because by the time you notice manually, an attacker may have already stolen the data and moved on.

• Will Credential Guard or LSA Protection completely stop LSASS dumping?

They significantly help, but are not absolute in isolation. Credential Guard, for instance, will block access to secret data like NTLM hashes and Kerberos TGTs by isolating it so even if an attacker dumps LSASS, those credentials won’t be present to steal. This thwarts most credential dumping attempts, although an attacker might still retrieve some secondary information machine account hashes or tokens that aren’t protected. LSA Protection RunAsPPL will outright prevent most tools from opening LSASS memory at all, because the OS won’t allow it unless the tool is trusted. Attackers have to either disable those features which is hard without already being kernel/System and will likely be noticed or resort to very advanced methods. In practice, enabling these features stops the common attacks. However, keep in mind that nothing stops an attacker from trying, they might run Mimikatz and just find nothing useful. Also, these features don’t prevent someone with full kernel access or hypervisor access from grabbing credentials, those scenarios are beyond their scope. So, use these protections as a crucial layer, but also have detection for any attempts since an attempt means someone is on your system with admin rights.

• Can antivirus or EDR solutions detect LSASS dumping?

Yes, modern security solutions are quite good at detecting this behavior. Many EDRs have specific rules to detect suspicious handle access to LSASS or known patterns from tools like Mimikatz. For example, Microsoft Defender’s ASR rule can outright block the action of reading LSASS memory. Even without that, Defender and other AV engines often recognize the signatures or heuristics of dumping tools like sequences of Windows API calls used to open and dump processes and will alert or stop them. In AV-Comparatives’ 2022 LSASS credential-dumping test, as reported by Microsoft, Defender for Endpoint ultimately prevented 15 of 15 test cases, and other top EDR products similarly prioritize this detection. However, attackers may use fresh custom tools that aren’t known, so behavior detection the act of a process accessing LSASS is crucial. Ensure your EDR is configured to not just detect but ideally block LSASS access attempts. And keep those tools updated as new attack variants appear, the vendors update their detection logic.

• Is LSASS dumping used by ransomware groups?

Absolutely. Ransomware operators or the initial access brokers working with them almost always employ credential theft to maximize their reach. Once they infiltrate one machine, they dump credentials from LSASS to get admin accounts, then they spread to as many machines as possible, sometimes targeting backups and critical servers before triggering the ransomware. Credentials from LSASS help them disable security tools using admin rights and deploy ransomware widely via tools like Group Policy or management software. In fact, it’s such a common step that many high profile incidents have evidence of Mimikatz or similar in the forensic analysis. Stopping the credential dumping could potentially contain the attack to the initial few machines instead of a domain wide disaster. Therefore, defending against LSASS dumping is a key part of anti ransomware strategy.

• Does dumping LSASS leave any traces or can it be done filelessly?

Some older or naive methods leave obvious traces for example, a large dump file on disk, or crash events. But attackers have evolved to minimize traces. It’s possible to dump LSASS without writing a file, by using techniques that exfiltrate the dump over the network or read it directly into an attacker controlled process and send the contents out. Tools like nanodump and other fileless strategies do exactly this, leaving little on the disk for investigators. That said, even fileless dumping leaves some evidence in memory and possibly in logs the act of reading LSASS still happens. Skilled attackers also often clear event logs or use direct syscalls to avoid security hooks, further reducing evidence. So yes, LSASS can be dumped in a very stealthy manner which is why real time monitoring and memory forensics skills are important. If you suspect a sophisticated intrusion, you might need to inspect memory or use EDR telemetry to catch the subtler signs.

• If an attacker dumps LSASS on a regular user’s PC, can they get domain admin creds from that?

Not usually, unless a domain admin had used that PC. LSASS dumping yields whatever credentials are in that machine’s memory. On a typical user workstation, you’d get that user’s credentials and possibly cached domain creds if that user is domain joined and the machine is offline, etc., but those are the user’s own. To get domain admin credentials, attackers either dump LSASS on a machine where a domain admin has logged on, or they dump on a server like a domain controller which inherently holds a lot of domain credential info. This is why one best practice is that high privilege accounts like domain admins should not log onto untrusted machines: if they do, their credentials can be stolen from that machine’s LSASS. In many attacks, the adversary compromises a low level machine, then moves to an IT admin’s machine, dumps LSASS there to get admin creds, and finally targets a domain controller. So, while an LSASS dump on a user’s PC might not directly give domain admin, it can give VPN passwords, local admin hashes, or other info that helps move upward. Defense wise, strict credential hygiene admins only log into secure machines helps ensure that dumping any given box yields only credentials of that box’s user, not the keys to the whole network.

• What is Mimikatz used for?

Mimikatz extracts Windows authentication secrets, such as NTLM hashes, Kerberos tickets and sometimes plaintext passwords, mostly from LSASS memory. Attackers use it to steal credentials, replay hashes and tickets, and forge Kerberos tickets so they can move from one compromised host to the rest of a domain. Penetration testers and red teams use it, with authorization, to show whether those attacks would work against your controls. MITRE ATT&CK tracks it as software S0002.

• Is Mimikatz malware?

Not by design. MITRE ATT&CK classifies Mimikatz as a tool rather than malware, and its author built it as a proof of concept. It's dual-use: running it on systems you don't own or don't have written permission to test is unauthorized access, and most antivirus and EDR products flag it as a hacking tool. Malware such as NotPetya has embedded modified versions of it.

• Does Credential Guard stop Mimikatz?

It stops Mimikatz from reading the most valuable secrets held by LSASS: Credential Guard isolates NTLM hashes, Kerberos TGTs and stored domain credentials with virtualization-based security, so even an administrator-level process can't extract them. It doesn't protect the SAM database, the Active Directory database or secrets on domain controllers, where Microsoft doesn't recommend enabling it. Layer it with LSA protection, the Defender ASR rule for LSASS, credential hygiene and monitoring for LSASS access.

LSASS dumping is a potent technique in the attacker’s arsenal, enabling a single foothold to evolve into a full network compromise by stealing credentials from memory. We’ve defined what it is, examined how it works, and underscored why it’s so dangerous in today’s threat landscape. It effectively allows attackers to hijack the identities that trust our systems. On the defensive side, the good news is there’s a robust toolbox of mitigations: from locking down LSASS with built in OS protections to watching like a hawk for any process that dares touch it. The key takeaway is vigilance and layered defense. By combining strong architectural measures Credential Guard, least privilege with real time detection and response, security teams can significantly blunt this technique. In an era where credential theft underpins many breaches, investing in protections against LSASS dumping yields security benefits that far outweigh the effort. Keep the guardrails up, monitor relentlessly, and treat your LSASS process as the crown jewels because for attackers, it’s certainly a treasure worth pursuing.

About the Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.