What Is LSASS Dumping? How Attackers Steal Windows 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.

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.

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 of the most 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.

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 any process that tries to open a handle to lsass.exe with full access rights. Typically, an administrator process needs to request rights like PROCESS_VM_READ or PROCESS_DUP_HANDLE on LSASS to dump it. For example, an attacker calling OpenProcess on LSASS with the 0x1F0FFF access mask full access is a tell tale 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 suddenly acquiring debug privileges Event 4672 for SeDebugPrivilege enablement and then interacting with LSASS could generate an alert. 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 an industry test, Defender’s default configuration even with LSASS ASR rules turned off detected or blocked 15 out of 15 simulated LSASS dump attempts across various methods. 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 this single rule, when tested, successfully stopped all known user mode LSASS dump techniques in their evaluation. 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.
• 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, modern Windows also marks LSASS as a protected process by default on newer systems, so even an admin may be blocked unless they disable protections 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 independent tests, Microsoft Defender scored 100% in detecting/preventing various LSASS dump techniques, 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.

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 for Fortune 500 companies, 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.