Detection of LSASS Memory Access by Non-System Processes
This brief provides a detection approach for identifying unauthorized access to the Local Security Authority Subsystem Service (LSASS) memory, a common technique used by attackers to harvest credentials.
Triage facts
Revision 1- Applicability
- Windows
- Evidence
- Unknown
- Severity
- Medium
- Action
- Elevated
- Freshness
- Revision 1Oct 20, 12:16 UTC
- Detection
- 1 rule
- Source quality
- A1Likely
Accessing the memory of the Local Security Authority Subsystem Service (LSASS) is a primary technique used by threat actors to perform credential dumping, allowing for the extraction of plaintext passwords, Kerberos tickets, and NTLM hashes. While legitimate security software and system services frequently interact with LSASS, malicious tools such as Mimikatz and custom credential stealers often attempt to open handles to the process with specific access masks to read its memory space. This detection focuses on Windows Security event logs (IDs 4656 and 4663) to identify when non-system, non-trusted processes request handle access to 'lsass.exe' using high-privilege access masks. Defenders should monitor for these events to differentiate between standard administrative activity or security product operations and potentially malicious credential harvesting attempts.
Attack Chain
- Attacker gains initial access to the Windows host through a phishing campaign or exploit.
- Attacker executes an unauthorized process or script under a non-system user context.
- Attacker identifies the process ID (PID) of 'lsass.exe' via system enumeration.
- Attacker attempts to open a handle to 'lsass.exe' using Windows APIs (e.g., OpenProcess).
- The attacker requests specific access masks (e.g., 0x1f0fff) intended for memory reading.
- The Windows Security subsystem generates Event ID 4656 or 4663 due to Object Access Auditing policies.
- If successful, the attacker dumps LSASS process memory to disk or extracts credentials into the tool's buffer.
- Attacker exfiltrates the harvested credentials for lateral movement or domain privilege escalation.
Impact
Successful exploitation of LSASS memory access enables an attacker to obtain cleartext credentials or cryptographic material. This typically results in full domain compromise, as the attacker can impersonate highly privileged users, move laterally through the network, and maintain persistence. This behavior is commonly observed in the post-exploitation phases of ransomware attacks, APT-led espionage, and targeted data breaches.
Recommendation
- Deploy the provided Sigma rule to your SIEM to monitor for unauthorized access attempts to LSASS.
- Ensure "Audit Object Access" and "Audit Handle Manipulation" are enabled via Group Policy to generate Event IDs 4656 and 4663.
- Use the filter list in the Sigma rule to baseline and exclude known-good security products and system processes operating in your specific environment.
- Investigate any triggered events involving processes not located in protected paths (e.g., 'C:\Program Files').
Immediate actions
Enable Windows Object Access Auditing for LSASS process
Threat Hunt
Identify processes with handles to lsass.exe that are not signed by known security vendors
Data: Sysmon Event ID 10
Detection coverage 1
Detect LSASS Memory Access by Non-System Process
mediumDetects potentially malicious processes attempting to access LSASS memory using handle access masks commonly associated with credential dumping tools like Mimikatz.
Detection queries are available on the platform. Get full rules →