Auditing Lsass access using Sysmon is one of the key settings that blueteam are using to detect suspicious instances in an attempt to detect behaviour like Mimikatz. It's also known that a lot of legit programs (including MS native services) are requesting process access handle (including VM_READ) which get very noisy in large scale deployment.
One exception that comes to mind is what if some of the machines in the prod have RunAsPPL enabled ? RunAsPPL normally is designed to prevent OpenProcess from a process with lower signature level to access Lsass. Thus the volume of Sysmon 10 events with TargetImage set to lsass.exe shouldn't be a problem as its limited to what Lsa PPL allow:
If the SourceProcess is not a protected process then the only allowed access rights (from a high/system integrity level) are :
- PROCESS_QUERY_LIMITED_INFORMATION (0x1000)
- PROCESS_SET_LIMITED_INFORMATION (0x2000)
- PROCESS_TERMINATE (0x1)
- PROCESS_SUSPEND_RESUME (0x800)
Excluding QUERY_LIMITED_INFORMATION (suspend/terminate is a bit abnormal for lsass anyway) and should be good enough to limit noise to SourceImage set to a protected processes (with signature level >= PsProtectedSignerLsa) or a usermode process leveraging a kernel mode driver such as ProcessExplorer via PROCEXP512.sys or ProcessHacker via kph.sys and those cases should be limited (no major impact on noise, can excluded with minimal efforts).
To confirm this behavior, created a generic sysmon config to audit all process access to PPL Lsass :
ProcExp leveraging PROCEXP.SYS
As suspected, almost 90% of the volume is related to query_limited_info/set_limited_info, rest is malicious or related to a usermode process that leverage a kernel mode component :
As can be seen above, even protected process with signature level > LsaLight (services.exe) they usually don't request GA > query_limited_info (even if technically they can get full access). This lead us to the idea that if we receive a sysmon event 10 with target image set to lsass and granted access allow to read memory and RunAsPPL is enabled from that machine then there are high chances it's A) PPL Bypass or B) legit usermode process (non protected) leveraging a kernel driver (risky too if not controlled and can be abused via stealing lsass handles), C) Protected Process with signature_protect level >= Lsa_LIGHT (should be limited).
The question that remain is how an analyst can differentiate between a Sysmon event 10 (Process Access) coming from an Lsa protected process or from a normal one ?
An ideal scenario is if Sysmon added an enrichment to Sysmon 10 events (at least if targe image is lsass but can also be useful for auditing PP tampering in general), something like :
A dirty way of doing it, is to create a scheduled task (via GPO) that triggers on a sysmon 10 event with lsass access (custom XML filter), then run a command to query RunAsPPL registry value (I know it can be deleted as a bypass with no effect on PPL but unlikely scenario and can be audited via sysmon 12) and write the results to the event logs (everytime lsass is accessed), then ingest and correlate that event with any process access:
References:
- https://itm4n.github.io/lsass-runasppl/
- https://github.com/RedCursorSecurityConsulting/PPLKiller
- https://docs.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights
- https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection