Windows Event ID 10 — Process Access

MITRE ATT&CK

Why It Matters

LSASS (Local Security Authority Subsystem Service) stores credential material in its memory — NTLM hashes, Kerberos tickets, and optionally WDigest plaintext passwords. Any tool that dumps this memory must open a handle to lsass.exe with specific access rights. Sysmon 10 captures that handle open at the moment it happens, before the dump completes. The GrantedAccess mask is a near-perfect fingerprint of the tool: 0x1010 is Mimikatz, 0x1410 is ProcDump/Task Manager. No other legitimate process needs these access masks on LSASS.

Key Fields

Investigation Tips

1. 1.Alert on TargetImage = lsass.exe with GrantedAccess = 0x1010 or 0x1410 from any process that is not a known security product (Defender, CrowdStrike sensor, etc.). These two access masks cover the vast majority of LSASS dump tools and have near-zero legitimate use.
2. 2.Check CallTrace for unbacked memory — entries like '0x00007ff...' that don't resolve to a named DLL indicate shellcode or a reflectively-injected DLL opening the LSASS handle. This separates tool-based attacks from attacker tradecraft using injected code.
3. 3.Correlate Sysmon 10 with Sysmon 1 (process create) for the SourceImage — was the accessing process recently created from a suspicious parent? A 4688 or Sysmon 1 event showing rundll32 spawned by cmd.exe spawned by powershell.exe followed by Sysmon 10 against lsass.exe is a complete attack chain.
4. 4.GrantedAccess = 0x1fffff (full process access) against lsass.exe is rare from legitimate software and indicates a tool requesting maximum access — often comsvcs.dll MiniDump or a custom dumper. Alert on this value specifically.
5. 5.Look for Sysmon 10 against processes other than lsass.exe — credential dumping can target winlogon.exe, services.exe, or any process holding sensitive tokens. GrantedAccess 0x1010 against any privileged system process is worth investigating.

Related Event IDs

Frequently Asked Questions

Why is lsass.exe always the target of credential dumping attacks?

LSASS (Local Security Authority Subsystem Service) is the Windows process responsible for authentication — it holds the credential material needed to validate logins without requiring users to re-enter passwords for every resource. This means it keeps NTLM hashes, Kerberos tickets (TGTs and TGSs), and — when WDigest authentication is enabled or forced — plaintext passwords in its working memory. An attacker with local administrator access who dumps LSASS memory gets all credentials for every user who has logged into that machine since last reboot, including domain admins if they've authenticated there. This makes LSASS the single highest-value target in the post-exploitation phase.

What does the GrantedAccess field tell me about which tool was used?

GrantedAccess is a bitmask of the access rights granted when OpenProcess() was called. The most common values and their tool associations: 0x1010 (PROCESS_VM_READ | PROCESS_QUERY_INFORMATION) = Mimikatz sekurlsa::logonpasswords; 0x1410 adds PROCESS_DUP_HANDLE = ProcDump -ma lsass.exe and Windows Task Manager create dump; 0x1fffff = PROCESS_ALL_ACCESS = comsvcs.dll MiniDump via rundll32 or a custom BYOVD tool requesting maximum access. Security products like Defender access LSASS with different, lower masks for scanning purposes — typically 0x1400 or similar. Alert on 0x1010, 0x1410, and 0x1fffff specifically when the SourceImage is not a known security product.

Can RunAsPPL protect lsass.exe from Sysmon 10 detections?

RunAsPPL (Protected Process Light) prevents standard processes from opening high-access handles to lsass.exe — tools like Mimikatz will fail with access denied, and Sysmon 10 will still fire but the GrantedAccess will reflect a downgraded or failed request. However, RunAsPPL does not stop kernel-mode attackers: BYOVD (Bring Your Own Vulnerable Driver) attacks load a signed-but-vulnerable driver that can open handles to protected processes from kernel mode, bypassing PPL entirely. Sysmon 10 will show these accesses from the driver's kernel thread. Credential Guard is stronger — it moves credential material into a Hyper-V protected enclave where even kernel-mode code cannot read it, making LSASS dumps return no usable credential data regardless of access level.

What is CallTrace and how do I use it to detect injected code?

CallTrace is the call stack at the moment OpenProcess() is called — a pipe-delimited list of return addresses in the DLLs that led to the API call. Legitimate accesses show recognizable DLL paths: C:\Windows\System32\ntdll.dll, C:\Windows\System32\kernel32.dll, etc. Injected shellcode or reflectively-loaded DLLs appear as unbacked memory regions — addresses that don't map to any named DLL on disk, shown as raw hex addresses without a module name, or addresses within a DLL's memory range but outside its legitimate code section. Any CallTrace entry that cannot be resolved to a known, signed Windows DLL is suspicious and indicates the OpenProcess call originated from injected code rather than a legitimate tool.