Reading a Sysmon event 10 against LSASS

Credential theft from memory starts with one step: opening a handle to lsass.exe with enough rights to read it. Sysmon records that step as event 10 (ProcessAccess) — and records the dozens of legitimate programs that open LSASS every hour too. The event is only useful if you can read its fields quickly.

Symptom

A Sysmon configuration that logs process access to lsass.exe produces a constant stream of event 10, and the first instinct is to filter it until it is quiet, or to turn it off.

Cause

Many things have a legitimate reason to touch LSASS: the antivirus or EDR agent, Windows components, management and inventory agents, Task Manager when someone opens the details view. Each of them requests specific access rights, and that is the part to read before deciding what is noise.

The four fields that matter

Field	What it tells you
SourceImage	which program opened the handle, with its full path
GrantedAccess	which rights the handle has, as a hex access mask
CallTrace	the chain of DLLs on the call stack that led to the open
SourceUser	which account the source process runs as (newer Sysmon versions)

GrantedAccess is a bit mask of standard process access rights. The bits worth knowing by heart:

Bit	Right	Why it matters
0x0010	PROCESS_VM_READ	reading the process’s memory — what credential dumping needs
0x0400	PROCESS_QUERY_INFORMATION	detailed process information
0x1000	PROCESS_QUERY_LIMITED_INFORMATION	basic information only; very common and mostly harmless
0x1FFFFF	PROCESS_ALL_ACCESS	everything

So 0x1000 on its own is a program asking “what is this process?”. 0x1010 or 0x1410 add memory read. The distinction alone moves most events into “look closer” or “probably fine” without any allowlist.

CallTrace shows how the open happened. Two patterns stand out: dbghelp.dll or dbgcore.dll in the trace, which is how memory dumps are written (MiniDumpWriteDump), and frames listed as UNKNOWN(…), which means code running from memory that is not backed by a file on disk.

SourceImage with its path: a security product’s binary in C:\Program Files\… is a different statement from the same file name in a user’s Downloads folder or in C:\Windows\Temp.

Fix

Instead of excluding source programs wholesale, read the events in this order:

1. Separate by GrantedAccess: query-only masks versus anything that includes 0x0010.
2. For the memory-read group, look at SourceImage paths and signatures. Your security products and a short list of known agents explain most of it.
3. Look at CallTrace for dump libraries and unbacked code in whatever is left.

And reduce the attack surface at the same time: with LSA protection (RunAsPPL) enabled, LSASS runs as a protected process, and ordinary processes can no longer open it with memory-read rights at all. Check driver and plug-in compatibility in a pilot group first; some older security and smart-card software breaks.

Takeaway

Event 10 is noisy by count and quiet by content. Read the access mask before the process name, and the call trace before you filter anything. The Sysmon baseline explains why process access is worth its volume when it is scoped to LSASS.