Catching LSASS credential dumps that use ProcDump and Task Manager

The version of credential theft that keeps me busy isn’t the one with mimikatz on disk. It’s the one where the operator never brings a tool your AV has a signature for, because they don’t need to. They dump the memory of lsass.exe, the process that holds cached credentials and Kerberos material, using something Windows already trusts, and they crack the dump on their own hardware later. Two of the most common signed helpers for that are Sysinternals ProcDump and Task Manager itself.

If your detection for this is a rule matching on procdump.exe, you’ve built something an attacker walks around by renaming the file. The durable signal is a layer down, in the handle the dumping process opens against LSASS.

Why the name is the wrong thing to watch

ProcDump with -ma writes a full memory dump of a target process. Point it at LSASS and you have every secret in that process’s memory, ready to feed to a cracker. Task Manager does the same thing through its “Create dump file” right-click, which calls MiniDumpWriteDump under the hood. Both are legitimately signed by Microsoft, so signature-based blocking does nothing, and both can be renamed, so a rule keyed on the image name is a speed bump, not a wall.

What neither of them can avoid is asking the kernel for a handle to LSASS with enough access to read its memory. That request is the detection.

The handle is the catch: Sysmon EID 10

Sysmon Event ID 10, ProcessAccess, fires when one process opens a handle to another, and it records the source image, the target image, and the granted-access mask. Scope it to a target of lsass.exe and you’re watching the one action credential dumping cannot skip.

The access mask is where the signal lives. A process that intends to read LSASS memory for a dump asks for rights like PROCESS_VM_READ and PROCESS_QUERY_INFORMATION, which show up in masks such as 0x1410 and 0x1010. Task Manager tends to ask for something broader, often 0x1fffff (full access), because it’s a general-purpose tool. So the first-pass rule is: EID 10, TargetImage ending in lsass.exe, GrantedAccess in that dump-capable set, SourceImage that is not one of your known security products.

That last clause matters, because the false positives here are real and worth knowing before you page anyone. Your EDR opens LSASS constantly. A couple of Windows components do. Some backup and crash-reporting agents do. You tune those out by SourceImage, once, and after that the rule sits quiet until something you didn’t authorize reaches for the process. On the estate where I run this, MDE on Win11 23H2 with Sysmon 15, the tuned version fired three times in a quarter and every one was worth looking at.

Backstops for when EID 10 isn’t enough

The handle rule is the core, but I don’t run it alone, because a careful operator can sometimes get access through a route that mutes it. Two cheap backstops:

• The dump file landing (EID 11). A memory dump has to go somewhere. Sysmon FileCreate for a .dmp written into a temp path, a user profile, or any staging directory is a strong corroborating signal, especially when it follows an EID 10 against LSASS by seconds. The size gives it away too; an LSASS dump is tens of megabytes, not a crash stub.
• The living-off-the-land variant. rundll32 comsvcs.dll MiniDump <pid> out.dmp full dumps LSASS with no third-party binary at all. That one you catch on the EID 1 command line (the comsvcs.dll MiniDump string is not something legitimate workflows produce) as well as the same EID 10 handle. It’s a good reminder that the tool inventory is endless and the behavior is small.

Microsoft’s guidance on protecting the process, and the reason handle requests are the right altitude to watch, is in the LSA protection documentation. The technique itself is T1003.001 in ATT&CK, and the whole Sysmon config question of what to collect around LSASS is something I went into separately in the Sysmon baseline.

What I’d actually deploy

Start with the handle rule scoped to LSASS, tuned to your real list of security products, because that single detection covers ProcDump, Task Manager, and most of the tooling nobody has written yet. Add the .dmp file-create rule as corroboration so a single dump attempt lights up two independent signals. Add the comsvcs.dll MiniDump command-line rule because it’s free and it closes the no-binary route. And run Protected Process Light on LSASS where your hardware supports it, so that even a granted handle can’t read the memory, which turns a lot of these attempts into a failed access you still get to see.

The theme, same as always, is that the attacker gets to change the tool and you don’t get to chase every name. Watch the thing that doesn’t change. Here, that’s a handle to LSASS with read access from a process that has no business holding one.