The Ultimate Guide to Detecting LSASS Dumping with KQL (Sentinel Threat Hunting)
If an attacker breaches your environment, their next immediate goal is lateral movement. To do that, they need credentials—and there is no better place to find them than the Local Security Authority Subsystem Service (LSASS). Understanding LSASS dumping KQL can help detect and investigate these kinds of credential theft attacks.
As a SOC analyst and content creator here at Secure Cyber Mart, I spend a significant amount of time analyzing logs and building detections. Whether you are actively hunting threats in a production SIEM or just building out your home lab while studying for your Sec+ or CCNA, understanding how to detect LSASS access is a mandatory skill. If you want to master threat hunting, it’s essential that you learn how to use KQL for detecting malicious dumping of LSASS.
Here is exactly how attackers target this process and the KQL queries you need to catch them in Microsoft Sentinel.
How Attackers Target LSASS (The Mechanics)
When a user logs into a Windows machine, the system generates and stores a variety of credential materials (like NTLM hashes or Kerberos tickets) inside the LSASS process memory. This is by design—it facilitates single sign-on (SSO) so you aren’t prompted for a password every time you access a network share. Therefore, KQL detection for LSASS dumping becomes crucial in incident response workflows.
Attackers know this. By using tools like Mimikatz, Procdump, or even the built-in Windows Task Manager, they can extract (or “dump”) this memory space to a file and parse it offline for plaintext passwords and hashes.
When these tools access the LSASS process, Windows generates specific telemetry. The two most critical event IDs to monitor are:
- Security Event ID 4656: A handle to an object was requested (often seen when a tool requests read access to process memory).
- Sysmon Event ID 10: Process accessed (provides deep visibility into the exact access mask used).
Essential KQL Queries for LSASS Detection
The key to writing effective KQL for LSASS dumping isn’t just looking for the word “lsass”—it’s looking for the specific access masks attackers use to read the memory. For those seeking to really strengthen defenses, constructing KQL queries targeting LSASS dumping activity will improve detection rates.
Here is a primary query to detect suspicious process access. This serves as a practical use of a LSASS dumping KQL detection method.
Expert Tip: Notice that this query uses
TimeGeneratedinstead ofTimestamp. I see many analysts making the mistake of filtering by timestamp. Always useTimeGenerated. It ensures you are querying based on when the log actually arrived in your workspace, preventing massive blind spots caused by log ingestion delays.
Snippet di codice
SecurityEvent
| where TimeGenerated >= ago(7d)
| where EventID == 4656
| where ObjectName endswith "lsass.exe"
| where SubjectLogonId != "0x3e7" // Exclude the SYSTEM account to reduce noise
| extend AccessMask = tostring(AccessMask)
// 0x1010 and 0x1438 are common access masks requested by dumping tools
| where AccessMask in ("0x1010", "0x1438", "0x1fffff", "0x1410")
| project TimeGenerated, Computer, SubjectUserName, ProcessName, AccessMask
| sort by TimeGenerated desc
Hunting with Sysmon Event ID 10
If you have Sysmon deployed (which you highly should), the telemetry is even cleaner. This query looks for a process requesting specific read rights to LSASS. Remember, correlating Sysmon telemetry with KQL can elevate your odds for quickly identifying LSASS dumping efforts.
Snippet di codice
Event
| where TimeGenerated >= ago(7d)
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 10
| extend TargetImage = tostring(EventData.TargetImage)
| extend SourceImage = tostring(EventData.SourceImage)
| extend GrantedAccess = tostring(EventData.GrantedAccess)
| where TargetImage endswith "lsass.exe"
| where GrantedAccess in ("0x1010", "0x1438", "0x1fffff", "0x1410")
| project TimeGenerated, Computer, SourceImage, TargetImage, GrantedAccess
| sort by TimeGenerated desc
Tuning Your Alerts to Reduce False Positives
If you deploy the queries above in a large enterprise environment, you are going to see noise. The reality is that legitimate admin tools, Antivirus scanners, and Endpoint Detection and Response (EDR) agents frequently touch LSASS. While tuning these rules, KQL can distinguish between common LSASS access and actual dumping attempts.
To stop alert fatigue, you must tune the query to whitelist known-good behavior. Do this by excluding the specific binary paths or digital signatures of your security software. Consider the specific KQL logic you use for differentiating normal from malicious LSASS dumping events.
Snippet di codice
// Add this line to your queries above to filter out known good EDR tools
| where ProcessName !in ("C:\\Program Files\\YourEDR\\agent.exe", "C:\\Windows\\System32\\taskhostw.exe")
Note: Never just whitelist the file name (e.g., svchost.exe). Attackers frequently rename their tools to bypass simple string-matching alerts. Always whitelist the full path or validate the file signature.
Next Steps and Home Lab Practice
You can’t learn threat hunting just by reading. You have to run the attacks yourself and watch the logs generate. For your next test, consider scripting LSASS dumping scenarios and developing accompanying KQL detections.
If you want to practice executing Mimikatz and catching it with Sentinel, I highly recommend setting up a local hypervisor. [Insert your affiliate link here: “Here is the mini-PC I use for my Secure Cyber Mart home lab…” or “Check out this highly-rated book on KQL…”]
Deploy these queries, tune out the noise, and secure your environment. In summary, combining hands-on practice with LSASS dumping activity and sharpening your KQL skills is the best way forward for defenders today.
