LSASS object access
A process obtained a handle to LSASS, recorded by Windows object-access auditing (4656 request / 4663 use) rather than by Sysmon.
What it detects
A process obtained a handle to LSASS, recorded by Windows object-access auditing (4656 request / 4663 use) rather than by Sysmon.
This matters because it is the ONLY view of LSASS access most estates have. windows.credential.lsass_access covers the Sysmon 10 path, but Sysmon is an optional download that a large share of environments have never deployed, while a SACL on lsass.exe is configurable with built-in Windows auditing alone. Without this rule, credential dumping on those hosts is invisible no matter how good the Sysmon-based coverage is.
LSASS holds the credential material of every account currently or recently logged on to the machine, so a successful read is a full credential compromise of that host and every account that touched it.
MITRE ATT&CK mapping
- T1003.001OS Credential Dumping: LSASS Memory· Credential Access
False positives and triage
Endpoint protection, EDR sensors, some backup agents and Windows' own error reporting open LSASS legitimately, so a baseline of the tools on the host is needed before this is actionable.
To confirm: ProcessName in the event names the accessing process. A security agent under Program Files is expected; cscript.exe, powershell.exe, rundll32.exe, taskmgr.exe or anything in a user directory is not. Then check AccessMask — 0x10 (VM_READ) and 0x1f/0x1fffff (full) are the interesting ones — and look for a .dmp file created nearby, which is the extracted credential store and should be recovered as evidence before it is deleted.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/windows/lsass_object_access.yaml, licensed under the Apache License 2.0.
id: windows.credential.lsass_object_access
version: 1.0.0
status: stable
severity: critical
confidence: 0.8
platforms: [windows]
mitre_techniques: [T1003.001]
description: |
A process obtained a handle to LSASS, recorded by Windows object-access auditing
(4656 request / 4663 use) rather than by Sysmon.
This matters because it is the ONLY view of LSASS access most estates have.
`windows.credential.lsass_access` covers the Sysmon 10 path, but Sysmon is an
optional download that a large share of environments have never deployed, while a
SACL on lsass.exe is configurable with built-in Windows auditing alone. Without
this rule, credential dumping on those hosts is invisible no matter how good the
Sysmon-based coverage is.
LSASS holds the credential material of every account currently or recently logged
on to the machine, so a successful read is a full credential compromise of that
host and every account that touched it.
match:
native_event_id_any: ['4656', '4663']
raw_message_contains_any:
- 'lsass.exe'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
Endpoint protection, EDR sensors, some backup agents and Windows' own error
reporting open LSASS legitimately, so a baseline of the tools on the host is
needed before this is actionable.
To confirm: `ProcessName` in the event names the accessing process. A security
agent under `Program Files` is expected; `cscript.exe`, `powershell.exe`,
`rundll32.exe`, `taskmgr.exe` or anything in a user directory is not. Then check
`AccessMask` — `0x10` (VM_READ) and `0x1f`/`0x1fffff` (full) are the interesting
ones — and look for a `.dmp` file created nearby, which is the extracted
credential store and should be recovered as evidence before it is deleted.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.