Log Dejargonizer

Sysmon · Event 10

Sysmon Event 10: One process opened another

A process requested access to another process's memory. Almost all of it is ordinary system behaviour, but this is the event that catches credential dumping — something opening lsass.exe with read access is one of the highest-value detections in Windows.

Also written as Sysmon 10Sysmon Event ID 10ProcessAccessSysmon process access lsass

What it means for you

On a personal computer

Only present if you installed Sysmon. It records programs inspecting each other, which is normal Windows behaviour and not something to interpret on a personal machine.

For an analyst

Filter to TargetImage lsass.exe in the configuration, then examine GrantedAccess. Access masks containing memory-read rights are the signal. Expect legitimate hits from antivirus, EDR, and some backup tooling — build the exclusion list from your own environment rather than from a generic one, and exclude by full path and signature rather than by process name.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Process accessed:
  RuleName: -
  UtcTime: 2026-08-28 09:15:31.204
  SourceProcessGUID: {a1b2c3d4-0000-0000-0000-00000000abcd}
  SourceProcessId: 7412
  SourceThreadId: 8120
  SourceImage: C:\Users\jbrooks\AppData\Local\Temp\dbg.exe
  TargetProcessGUID: {a1b2c3d4-0000-0000-0000-00000000dcba}
  TargetProcessId: 812
  TargetImage: C:\Windows\System32\lsass.exe
  GrantedAccess: 0x1010
  CallTrace: C:\Windows\SYSTEM32\ntdll.dll+9d234|UNKNOWN(00000210F1C20000)

The fields that decide it

Everything else in the log line is context.

SourceImage
The process doing the opening. This is what you are trying to identify.
TargetImage
The process being opened.
  • C:\Windows\System32\lsass.exeHolds cached credentials. The single most important value this field takes.
  • A security product's processSomething inspecting your defences, which is worth understanding.
GrantedAccess
The access rights granted, as a hexadecimal mask. This is what separates a real detection from noise.
  • 0x1010Read process memory and query information. The classic credential-dumping mask.
  • 0x1410Another common dumping mask, adding VM read rights.
  • 0x1fffffAll possible access. Broad and worth reading whatever the source.
  • 0x1000Query limited information only. Very common and almost always benign.
  • 0x400Query information. Ordinary system behaviour.
CallTrace
The call stack of the access. Entries pointing at unbacked memory rather than a named module suggest injected code, which is a strong signal on its own.
SourceProcessGUID
Join on this to pull the full command line of the accessing process.

Ordinary reasons this happens

Most of the time it is one of these.

  • Antivirus and EDR products inspecting processes, which is most of the volume against lsass.
  • Windows components querying process information for ordinary bookkeeping.
  • Task Manager, Process Explorer, and other diagnostic tools.
  • Backup and monitoring agents enumerating processes.
  • Debuggers on developer machines.

When it is not ordinary

Credential dumping from LSASS memory.

What gives it awayTargetImage lsass.exe with a GrantedAccess mask that includes memory-read rights, from a process that is not a known security product.

ATT&CK T1003.001

Injected code performing the access.

What gives it awayA CallTrace containing unbacked memory regions rather than named modules, regardless of what the source process claims to be.

ATT&CK T1055

Security tooling being inspected before being disabled.

What gives it awayRepeated access to antivirus or EDR processes from an unexpected source.

ATT&CK T1562.001

A legitimate signed tool abused for dumping.

What gives it awayAccess to lsass from a signed Microsoft utility that has no business reading process memory — the tool is real, the use is not.

ATT&CK T1003.001

What to do next

  1. Filter to lsass.exe as the target first. Everything else is usually noise.
  2. Read GrantedAccess. Masks without memory-read rights are almost always benign.
  3. Check whether the source process is a known security product, and verify it by full path rather than by name.
  4. Read the CallTrace for unbacked memory regions, which indicate injected code.
  5. Join on ProcessGuid to see the source process's command line and parent.
  6. Check whether the same source appears on other machines. A security agent will be everywhere; a dumping tool will not.

Queries to run

kql The core credential-dumping detection. Build the exclusion list from your own security tooling, matched on full path. 
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 10 | where TargetImage endswith 'lsass.exe' | where GrantedAccess in ('0x1010','0x1410','0x143a','0x1fffff') | project TimeGenerated, Computer, SourceImage, GrantedAccess, CallTrace
kql Access from unbacked memory. A strong signal regardless of what the source process appears to be. 
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 10 | where TargetImage endswith 'lsass.exe' | where CallTrace has 'UNKNOWN' | project TimeGenerated, Computer, SourceImage, GrantedAccess, CallTrace
sigma Portable starting point. The exclusions matter more than the rule — tune them to your own agents. 
detection:
  selection:
    EventID: 10
    TargetImage|endswith: '\\lsass.exe'
    GrantedAccess:
      - '0x1010'
      - '0x1410'
      - '0x143a'
  condition: selection
splunk Rarest sources first, which separates your security agents from everything else. 
index=sysmon EventCode=10 TargetImage="*\\lsass.exe" | stats count by SourceImage GrantedAccess host | sort count asc

Common questions

What does GrantedAccess 0x1010 mean in Sysmon Event 10?

It is an access mask combining permission to read another process's memory with permission to query its information. When the target is lsass.exe, that combination is what credential-dumping tools request, which is why it is the value most detection rules key on.

Why does my antivirus trigger Sysmon Event 10 against lsass?

Because inspecting process memory is part of how endpoint security products work — they legitimately need the same access a dumping tool does. Build an exclusion list from the security software actually deployed in your environment, matched on full path and signature rather than process name, since name matching is trivially bypassed.

How do I detect credential dumping with Sysmon?

Filter Event 10 to TargetImage lsass.exe, then look at GrantedAccess for masks including memory-read rights, and at CallTrace for unbacked memory regions. The CallTrace check is the more durable of the two — access masks can be varied, but code running from unbacked memory is hard to disguise.

Should I enable Sysmon Event 10 for all processes?

No. Unfiltered, it is one of the highest-volume events Sysmon produces and most of it is meaningless. Configure it to record access to lsass.exe and to your security tooling, and leave everything else out.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026