• LSASS holds the credential material for every logged-on user on a system, making it the single highest-value target on any compromised endpoint.
• Attackers don't need Mimikatz to get there; a signed, built-in Windows DLL can dump LSASS memory just as effectively.
• The dump itself may look unremarkable, but what gives it away is which process asking to touch LSASS, and how.

The process nobody expects to touch LSASS

A process reaches into lsass.exe and reads its memory. Nothing crashes. No malware signature fires. The binary doing the reaching is signed by Microsoft and sitting exactly where it's supposed to be in System32. Is this a crash-reporting tool doing its job, or is this the moment every credential on that box just walked out the door?

The Local Security Authority Subsystem Service (LSASS) holds the credential material for every user who's logged onto that system. Domain passwords, Kerberos tickets, NTLM hashes, and other authentication data live in its memory while a session is active. If an attacker can read that memory, they don't need to guess a password or crack a hash. They can just take what's already sitting there. 

That’s why this technique remains one of the most consistently used post-exploitation moves in the entire ATT&CK framework, from ransomware crews to nation-state operators.

Most people picture Mimikatz when they think about LSASS dumping: a purpose-built credential theft tool actively flagged by nearly every AV and EDR product on the market. But attackers have already moved on. The technique worth understanding this week doesn't need Mimikatz at all.

The legitimate case 

• Target: A process related to an actual reported problem, rather than LSASS specifically, unless there's a documented, unusual reason to examine it 
• Creating context: Initiated by a recognized diagnostic tool or an administrator working on an an open ticket
• Output: It produces a file that gets handled through normal IT workflows, reviewed, attached to a case, or discarded

The malicious case 

The exact same Windows component (same exported function) can be invoked very differently when an attacker is after credentials.   

• Command line: rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <LSASS_PID> lsass.dmp full, specifically targeting the LSASS process ID
• Parent process: This command rarely originates from a normal admin session. It shows up spawned from PowerShell, a script host, or a process chain that traces back to initial access activity
• Output file: Lands somewhere it shouldn't like a temp directory or a user profile path rather than a location tied to any legitimate diagnostic workflow
• Context: No supporting ticket, crash report, or other reason for LSASS to be dumped right at that moment 

Attackers favor this method precisely because rundll32.exe and comsvcs.dll are both signed, both expected to exist, and neither one is inherently suspicious on its own. It's the same LOLBin logic that’s shown up in our previous walkthroughs: a trusted binary doing something it wasn't primarily built for, in a way that requires context to catch.

There’s also another variant worth knowing. Some attackers skip the direct dump entirely and abuse Windows Error Reporting instead. By manipulating the Image File Execution Options registry key tied to lsass.exe, they can trigger WerFault.exe to produce the memory dump for them through the silent process exit mechanism, avoiding the use of a dumping tool altogether. Same outcome, just different path in.

Where the signal comes together

Manually, this investigation means correlating crossproc events against lsass.exe, filtering for OPEN_PROCESS_HANDLE or PROCESS_API_CALL actions with the specific DesiredAccess rights required to read process memory, such as NtReadVirtualMemory. Followed by chasing down the parent process and command line for anything that touched it. That's a real, learnable threat-hunting skill. It can also mean spending a fair amount of time pulling events together by hand before the picture becomes clear. 

Threat Tracer surfaces that chain directly. Instead of manually correlating a cross-process event to a separate process-creation event and hoping they line up, analysts can see which process requested access to LSASS, what rights it asked for, and what spawned it in the first place. The work shifts from reconstructing a sequence from raw event logs to deciding whether the sequence belongs. 

What to look for in Threat Tracer

Start with the process requesting access to LSASS and trace its parent. 

A quick posture check

Before you close out, consider these questions about your own environment.

1. Would you notice if rundll32.exe requested memory access to lsass.exe on an endpoint right now, or would that blend into normal diagnostic noise for you?
2. Do you know what the legitimate crash-dump and diagnostic tooling actually looks like in your environment, well enough to rule it out quickly?
3. If Credential Guard isn't enabled across your fleet, do you know which systems are still exposed to direct LSASS memory reads?

Out of the three, the third may carry the most weight. Where Credential Guard is deployed, LSASS secrets are isolated in a protected container that this attack technique can't reach. Knowing where that protection is and isn't deployed is itself a posture decision, not just a detection one.

Next up, we'll look at another ATT&CK technique using the same approach: what's normal, what's not, and what can help you make that distinction faster.

To see how Symantec CBX helps analysts spend less time stitching together events, reach out for a 1:1 demo.

You might also enjoy