Sysmon Event ID 10: Process Access and LSASS Dumping

Sysmon Event ID 10 (ProcessAccess) is logged when one process opens a handle to another process. It matters because tools that steal credentials have to open lsass.exe first, and this event records who asked, who they asked about, and what access they requested.

If you only learn one use for it, learn this one: a strange process opening LSASS with memory-read rights is how credential dumping looks on the endpoint. This post covers the fields, the access masks, a Splunk and a KQL search, and the false positives that will fill your queue if you skip tuning.

This is one post in a series. For the whole list of IDs, see the Sysmon Event IDs cheat sheet.

What Sysmon Event ID 10 logs

Microsoft describes the event as reporting "when a process opens another process, an operation that's often followed by information queries or reading and writing the address space of the target process." Note the wording: it logs the open, not the read. The fields you will use most:

• SourceImage: the full path of the process doing the opening. This is the suspect. Is it a known tool, or something running from C:\Users\Public or a temp folder?
• TargetImage: the process being opened. lsass.exe is the one to watch, because it holds credential material in memory.
• GrantedAccess: a hex bitmask of the rights the source was given. It tells you whether the source could read memory or only ask basic questions. More on this below.
• CallTrace: the call stack at the time of the access, as a list of modules and offsets. Unusual entries such as UNKNOWN(...) can point at injected or unbacked code, but it takes practice to read and is noisy.
• SourceProcessGUID and TargetProcessGUID: unique IDs for each process. Use them to pivot to Event ID 1 and to tie events together, because PIDs get reused.
• SourceProcessId, TargetProcessId, SourceThreadId: the PIDs and the thread that made the call.
• UtcTime and RuleName: when it happened, and the name of the config rule that matched, if your config names rules.

Newer Sysmon versions also add SourceUser and TargetUser. If your events lack them, you are on an older schema. Run sysmon -s to print the schema your version uses.

What you get depends entirely on your Sysmon configuration. Microsoft warns that enabling this event can create "significant amounts of logging" and says it should generally be used with filters that remove expected accesses. Community configs such as SwiftOnSecurity's sysmon-config and Olaf Hartong's sysmon-modular ship their own ProcessAccess rules, so check what your config actually collects before you trust a quiet dashboard.

Reading GrantedAccess

GrantedAccess is a bitmask built from Windows process access rights. A few of the bits are worth knowing:

• 0x0010 is PROCESS_VM_READ: the right to read the target's memory.
• 0x0400 is PROCESS_QUERY_INFORMATION.
• 0x1000 is PROCESS_QUERY_LIMITED_INFORMATION.
• 0x1FFFFF is PROCESS_ALL_ACCESS on modern Windows.

Add the bits together and you get the values you will see in logs. 0x1010 is 0x1000 plus 0x0010: limited query plus memory read. 0x1410 is 0x1000, 0x0400 and 0x0010: both query rights plus memory read.

Values commonly seen in public LSASS-dumping detections include 0x1010, 0x1410 and 0x1FFFFF. Treat that as a starting list, not a complete one. Tools vary, attackers can request different rights, and legitimate software requests many of the same values. The thing to look for is the memory read bit (0x0010) or full access against LSASS from a source you do not recognise. A source that only has 0x1000 can ask about the process but cannot read its memory.

What it catches

Credential dumping from LSASS (T1003.001)

This is the classic. Tools like Mimikatz open lsass.exe and read memory to pull out credentials. A trimmed event might look like this:

EventCode:       10
SourceImage:     C:\Users\Public\update.exe
TargetImage:     C:\Windows\System32\lsass.exe
GrantedAccess:   0x1410
CallTrace:       C:\Windows\SYSTEM32\ntdll.dll+9d4c4|C:\Windows\System32\KERNELBASE.dll+2c13e|UNKNOWN(00007FF6A1B2C3D4)

A binary in a public folder opening LSASS with memory-read rights is worth escalating on its own. The UNKNOWN(...) frame at the end of the trace fits code running outside a normal loaded module, though by itself it is a hint rather than proof.

Dumping LSASS with a built-in or signed tool

Attackers also use trusted binaries so the source looks boring. A common method is writing a memory dump of LSASS to disk, for example with Task Manager, ProcDump or comsvcs.dll run through rundll32.exe. Here the SourceImage may be rundll32.exe or procdump.exe. The source being "legit" does not help you. Ask instead why this host, this user and this parent process are dumping LSASS at all. This also maps to T1003.001.

Other process-handle abuse

LSASS is not the only target. Process injection techniques open a handle to the victim process before they write to it, and that open shows up as Event ID 10 with write-related rights. This is more advanced and much noisier than the LSASS case, so start with LSASS and expand once you have tuned it.

Searching for it

Both searches assume Sysmon is forwarded to your SIEM and the event is not filtered out at the source. Your config decides whether the events exist at all.

Splunk. This assumes data in sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" with the Splunk Add-on for Sysmon extracting the fields.

sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 TargetImage="*\\lsass.exe"
| search GrantedAccess IN ("0x1010","0x1410","0x1fffff")
| stats count values(GrantedAccess) as access min(_time) as first_seen by host SourceImage
| sort - count

This lists which processes opened LSASS with those access values, per host. Case in GrantedAccess can vary between data sources, so check how yours looks (0x1FFFFF or 0x1fffff) before you rely on it. Rare SourceImage values on a host are the interesting ones. More query patterns are in our SPL cheat sheet.

KQL. This assumes Microsoft Sentinel with Sysmon forwarded into the Event table. The fields live inside EventData, so this pulls them out with a simple regex.

Event
| where Source == "Microsoft-Windows-Sysmon" and EventID == 10
| extend SourceImage = extract(@'Name="SourceImage">([^<]*)<', 1, EventData)
| extend TargetImage = extract(@'Name="TargetImage">([^<]*)<', 1, EventData)
| extend GrantedAccess = extract(@'Name="GrantedAccess">([^<]*)<', 1, EventData)
| where TargetImage endswith @"\lsass.exe"
| where GrantedAccess in~ ("0x1010", "0x1410", "0x1fffff")
| summarize Count = count(), FirstSeen = min(TimeGenerated) by Computer, SourceImage, GrantedAccess
| order by Count desc

The same idea: who opened LSASS, with what rights, on which machine. If your ingestion already parses EventData into columns, drop the extract lines and use those. More patterns are in the KQL cheat sheet.

False positives

LSASS gets opened a lot on a healthy Windows box. Expect:

• Antivirus and EDR agents. Security products open LSASS to protect it and inspect it. These often run from a fixed install path under Program Files.
• Windows system processes. Components such as csrss.exe, wininit.exe, svchost.exe and services.exe interact with LSASS as part of normal operation.
• Monitoring and management tools. Performance counters, backup agents and diagnostic utilities open processes to query state.

How to tell the difference:

• Baseline first. Run the search for a week and list the SourceImage values per host. The same few paths will account for most of the volume. Exclude those by full path, not just file name, since a file name is easy to copy.
• Check the path and signer. C:\Windows\System32\svchost.exe is expected. C:\Users\Public\svchost.exe is not. Pivot to Event ID 1 for the hash and parent.
• Look at the access rights. A tool that only needs to know the process exists should not ask for memory read.
• Look at the context. A new source on a server at 3 a.m., right after a suspicious logon, is a different story from a known agent at install time.

Excluding by path in your Sysmon config is how you control the volume Microsoft warns about. Do it carefully, because an exclusion is also a blind spot an attacker can hide in.

How it fits with other Sysmon events

Event ID 10 tells you who touched LSASS. The other IDs tell you the rest of the story:

• Event ID 1 (process creation): look up the SourceProcessGUID to see the command line, parent and hash of the process that did the access.
• Event ID 11 (file create): if a dump was written to disk, look for a .dmp file created by the same process around the same time.
• Event ID 3 (network connection): did the source process, or the next one, talk to the outside afterwards? That could be exfiltration or lateral movement with the stolen credentials.
• Event ID 8 (CreateRemoteThread): thread creation in another process often follows the open step for injection.

For the wider picture across Windows logs, see the Windows event log IDs guide.

FAQs

What is Sysmon Event ID 10?

It is the ProcessAccess event. Sysmon logs it when one process opens a handle to another, recording the source, the target and the access rights requested.

Is Event ID 10 enabled by default?

Do not count on it. It is controlled by the ProcessAccess rules in your Sysmon configuration, and Microsoft recommends filters because it can be very noisy. Check your config.

What does GrantedAccess 0x1010 mean?

It is 0x1000 (PROCESS_QUERY_LIMITED_INFORMATION) plus 0x0010 (PROCESS_VM_READ). The source can read the target's memory. Against LSASS from an unknown process, that deserves a look.

Does Event ID 10 prove credentials were stolen?

No. It shows a process opened LSASS with certain rights. It does not show what was read. Combine it with process creation, file creation and logon activity before you call it.

TL;DR

Sysmon Event ID 10 logs one process opening another. Watch TargetImage for lsass.exe, then check SourceImage and GrantedAccess for memory-read rights such as 0x1010, 0x1410 or 0x1FFFFF. Baseline your AV, EDR and system processes, exclude them by full path, and investigate the rest. Pair it with Event IDs 1 and 11 to confirm what happened.

How EpicDetect Can Help

Reading about Sysmon events only gets you so far. Adventures drops you into a story-driven SOC investigation where endpoint evidence like this is how you crack the case. Season Zero is free.

Want the fuller picture? The EpicDetect Atlas maps out what to learn next, from SOC fundamentals to detection engineering.