Sigma Rule for LSASS Credential Access (Event ID 10)

A Sigma rule for LSASS credential access targets the single most valuable move in a Windows intrusion: a process opening lsass.exe to read the credentials in its memory. Sysmon records that open as Event ID 10 (ProcessAccess), and the access rights the caller requested are the tell. This post writes that detection as Sigma, leans on the GrantedAccess mask and CallTrace the way the established SigmaHQ rules do, and is honest about the one place this technique does not convert cleanly — there is no raw process-access table in Microsoft Defender to point it at.

Key Takeaways

• Credential dumping from LSASS (MITRE ATT&CK T1003.001) shows up as Sysmon Event ID 10, which records the source process, the target (lsass.exe), and the access mask requested.
• A Sigma rule for LSASS credential access keys on GrantedAccess values such as 0x1010, 0x1410, and 0x1438 — Sysmon logs the mask as a literal string, so the rule matches it as a string, not as a bitwise test.
• The CallTrace field strengthens the rule by revealing when the access came through dbghelp.dll or dbgcore.dll, the MiniDump path that dumping tools use.
• Process-access events are high volume and noisy by default, so the rule depends on a Sysmon config that includes ProcessAccess with sane filters.
• Unlike the rest of this series, Sysmon Event ID 10 has no direct Microsoft Defender advanced-hunting table; Defender covers the technique through its ASR rule (AsrLsassCredentialTheft) instead.

Environment

• sigma-cli 1.0+ with a backend installed (kusto for Microsoft Sentinel here).
• Sysmon deployed with a configuration that includes ProcessAccess (Event ID 10) with filters — the unfiltered event is extremely noisy and most baseline configs scope it tightly.
• Windows endpoints forwarding the Microsoft-Windows-Sysmon/Operational channel to your SIEM.
• A SIEM workspace to validate the converted query against a known-good baseline before promoting it.

The Problem

Reading credentials out of LSASS memory is the technique that turns a single foothold into domain-wide movement, which is why it is the one defenders most want to catch. The difficulty is that opening a process handle is a completely ordinary operation — antivirus, EDR, diagnostic tools, and Windows itself open lsass.exe constantly. The event volume is enormous, and a malicious open looks structurally identical to a benign one until you read the access rights the caller asked for.

That is the discriminator. To scrape credentials, a tool needs to read LSASS memory, so it requests an access mask that includes PROCESS_VM_READ. Sysmon Event ID 10 records that mask in the GrantedAccess field, alongside the source and target images and a CallTrace showing which DLLs were on the stack. The masks that credential tools request — 0x1010 for the classic Mimikatz read, 0x1410 and 0x1438 for the dump-to-disk path — are a small, well-characterised set. This is the same credential-access tactic behind Kerberoasting detection, approached from memory rather than the ticket service. The technique reference is MITRE ATT&CK T1003.001.

The Solution — Writing a Sigma Rule for LSASS Credential Access

Step 1 — Confirm Sysmon is logging ProcessAccess for LSASS

Event ID 10 is off or heavily filtered in most configs because, unfiltered, it floods the log. The right approach is to include ProcessAccess but scope it to LSASS as the target, which keeps the volume manageable while capturing exactly the opens that matter:

<ProcessAccess onmatch="include">
  <TargetImage condition="image">lsass.exe</TargetImage>
</ProcessAccess>

Even scoped to LSASS, the event fires for legitimate accesses from security tooling, so the rule still has to discriminate by access mask. My Sysmon configuration walkthrough covers the wider config; the snippet above is the ProcessAccess part this rule needs.

Step 2 — Match the credential-access masks on lsass.exe

The rule pins the target to lsass.exe and matches the access masks that credential tools request. A critical detail: Sysmon writes GrantedAccess as a literal hex string, and the conversion is a string comparison — the value must match as logged, not as a bitwise mask:

title: LSASS Credential Access via Sysmon Event ID 10
id: 9f1c7e84-2b6d-4a30-9c52-7e0d3f8a1b46
status: experimental
description: Detects a process opening lsass.exe with access rights used to read or dump its memory
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: SecurityScriptographer
date: 2026-06-04
tags:
  - attack.credential_access
  - attack.t1003.001
logsource:
  product: windows
  category: process_access
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess:
      - '0x1010'
      - '0x1410'
      - '0x1438'
      - '0x143a'
      - '0x1fffff'
  condition: selection
falsepositives:
  - Antivirus and EDR agents legitimately open lsass with high access; exclude by SourceImage
level: high

A real Event ID 10 from the lab: Taskmgr.exe opening lsass.exe with GrantedAccess 0x1fffff — the full PROCESS_ALL_ACCESS mask the rule flags. On a host with LSA protection or Defender's ASR rule enabled, the read right is stripped and this mask never appears — which is the point of running both.

0x1fffff is PROCESS_ALL_ACCESS — overkill for anything legitimate to request against LSASS and worth flagging on its own. The category: process_access log source is the abstract Sigma taxonomy that the pipeline maps onto Sysmon Event ID 10, so the rule stays portable.

Step 3 — Add the CallTrace signal for the dump path

The access mask catches the read; the CallTrace catches how the memory was dumped. Tools that write LSASS to disk go through the MiniDump API in dbghelp.dll or dbgcore.dll, and those DLLs appearing in the call stack of an LSASS open is a strong, specific signal:

  selection_calltrace:
    TargetImage|endswith: '\lsass.exe'
    CallTrace|contains:
      - 'dbghelp.dll'
      - 'dbgcore.dll'
  condition: selection or selection_calltrace

This is the field that catches dump-to-disk tooling even when it requests a less obvious access mask, because the MiniDump call path is hard to avoid if you want a usable dump. It is the same logic of reading the mechanism rather than the label that runs through the whole series, including the SIEM correlation rules that tie these single events into a sequence.

Step 4 — Exclude security tooling by SourceImage, not by weakening the masks

The predictable noise is your own defensive stack — antivirus and EDR open LSASS with high access by design. Exclude them by the process doing the opening, never by removing access masks from the detection:

  filter_security_tools:
    SourceImage|endswith:
      - '\MsMpEng.exe'        # Microsoft Defender Antivirus
      - '\MsSense.exe'        # Defender for Endpoint sensor
  condition: (selection or selection_calltrace) and not filter_security_tools

Pin these exclusions to the full path and, ideally, validate the signer, because SourceImage filename alone is something an attacker can mimic by naming their binary MsMpEng.exe from a different directory. Document each exclusion in the falsepositives field, as with every rule in this series.

Step 5 — Convert it, and mind where it can actually run

Conversion is the same single command the rest of the series uses:

sigma convert -t kusto -p sysmon lsass_access.yml

Here is the honest catch that sets this rule apart. Sysmon Event ID 10 lands in the Sysmon-sourced table when you forward the channel to Sentinel, and the rule runs there fine. But Microsoft Defender XDR has no raw process-access table in advanced hunting — there is no DeviceProcessAccessEvents to convert onto. Defender covers this technique a different way: its attack surface reduction rule for LSASS credential theft surfaces in the DeviceEvents table as ActionType == "AsrLsassCredentialTheft". So in a Defender-only shop, you hunt the ASR detection rather than the raw access:

DeviceEvents
| where ActionType == "AsrLsassCredentialTheft"
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, FolderPath

The two are not equivalent — the Sysmon rule sees every qualifying open, while the ASR event fires only when the ASR rule is enabled and triggers. If LSASS credential access matters to you, the Sysmon path gives the broader visibility, which is the whole reason to forward Sysmon in the first place.

The Sigma rule from this post is available in my defensive-toolkit repository on GitHub.

Frequently Asked Questions

Why does my LSASS Sigma rule match the GrantedAccess as a string?

Because Sysmon logs GrantedAccess as a literal hex string and the detection performs a string comparison, not a bitwise operation. The mask must match exactly as logged — 0x1010 matches 0x1010. This is why the rule enumerates the specific masks credential tools request rather than testing for a bit.

Can I detect LSASS credential dumping in Microsoft Defender?

Yes, but not through a raw process-access table — Defender XDR has none. Defender detects it through its attack surface reduction rule for LSASS credential theft, which appears in DeviceEvents as ActionType == "AsrLsassCredentialTheft". That covers the technique but only when the ASR rule is enabled and triggers, which is narrower than Sysmon Event ID 10.

Won't this rule fire on antivirus and EDR constantly?

It will, because security tools open LSASS with high access by design. Exclude them by SourceImage — Defender's MsMpEng.exe and MsSense.exe, plus whatever else runs in your environment — and validate the signer where you can, so an attacker cannot evade the rule simply by renaming a binary.

What makes 0x1010 and 0x1438 the masks to watch?

They include PROCESS_VM_READ, the right needed to read another process's memory. 0x1010 is the classic Mimikatz read of LSASS, while 0x1410 and 0x1438 appear on the dump-to-disk path used by ProcDump and Task Manager. They are the small set of masks that map to reading or dumping LSASS memory.

Conclusion

LSASS credential access is the highest-value technique to catch and one of the noisiest events to catch it in, which forces the detection to read the access mask and the call trace rather than the bare fact of a process open. Sysmon Event ID 10 hands you the source, the target, the GrantedAccess mask, and the CallTrace together, and writing the logic as Sigma keeps it portable across SIEMs.

The limitation worth stating plainly is conversion coverage. This is the one rule in the series with no clean Microsoft Defender advanced-hunting target — the raw process-access event simply is not exposed as a table, and Defender's ASR-based detection is narrower than what Sysmon sees. On the Sysmon-native path the rule does exactly what the others do: match the mechanism, exclude by the calling process, and document every exclusion.

Related Posts

• Detecting Kerberoasting with Windows Event ID 4769 — the other half of credential access, approached from the ticket service.
• Sysmon Configuration for Windows Security Monitoring — how to enable the ProcessAccess events this rule depends on.
• From Logs to Threats: SIEM Correlation Rules for Real Attacks — tying an LSASS access to the activity around it.

Authoritative reference: MITRE ATT&CK T1003.001 — OS Credential Dumping: LSASS Memory and the SigmaHQ rule repository.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.