Listen to this Post
Introduction:
The Local Security Authority Subsystem Service (lsass.exe) is a prime target for credential dumping using tools like Mimikatz. Many security teams still write static detection rules – e.g., “alert when any process opens a handle to lsass.exe with PROCESS_ALL_ACCESS” – which generate thousands of false positives from legitimate backup agents, anti‑virus scanners, and system tools. Worse, attackers easily bypass these rules by using indirect memory access, minifilter drivers, or living‑off‑the‑land binaries (LOLBins). To truly defend lsass, you need behaviour‑based analytics, kernel‑call stacks, and integrity monitoring that adapts to modern tradecraft.
Learning Objectives:
- Understand why traditional process‑access rules for lsass.exe fail against real‑world attacks.
- Implement advanced detection techniques using Sysmon, ETW, and Windows Defender Credential Guard.
- Deploy Linux-based memory forensics and cross‑platform EDR telemetry to catch credential dumping across hybrid environments.
You Should Know:
- The False‑Positive Epidemic – Why Your lsass Rule Is Noise
Most detection rules for lsass rely on Event ID 10 (ProcessAccess) in Sysmon or similar alerts for `PROCESS_ALL_ACCESS` or PROCESS_VM_READ. However, hundreds of legitimate processes – from `MsMpEng.exe` (Defender) to `VeeamAgent.exe` – legitimately open lsass handles. Attackers use `OpenProcess` with minimal rights (e.g., PROCESS_QUERY_LIMITED_INFORMATION) or exploit direct system calls (NtReadVirtualMemory) to bypass user‑mode hooks.
Step‑by‑step guide to validate your current rule’s failure:
- Collect Sysmon logs on a test Windows machine:
Install Sysmon with default config .\Sysmon64.exe -accepteula -i Enable ProcessAccess logging (Event ID 10) View live events Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=10} | Format-List -
Simulate a benign lsass access using `tasklist` (a built‑in tool):
tasklist /m /fi "PID eq lsass_pid"
Observe Event ID 10 with `GrantedAccess=0x1010` – no alert triggered by simplistic rules.
3. Simulate a Mimikatz‑style access (requires admin):
Use PowerShell to open lsass (will be logged)
Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;
public class LsassOpener {
[DllImport("kernel32.dll")] public static extern IntPtr OpenProcess(uint dwDesiredAccess, bool bInheritHandle, int dwProcessId);
}
"@
$pid = (Get-Process -Name lsass).Id
[bash]::OpenProcess(0x1F0FFF, $false, $pid)
Now check Sysmon – you’ll see GrantedAccess=0x1F0FFF. But so will your backup software.
Why it fails: Attackers use `PROCESS_QUERY_INFORMATION` (0x0400) plus indirect read via `NtReadVirtualMemory` – a call that never triggers a handle open event. Use ETW for Microsoft‑Windows‑Kernel‑Process to capture `ReadProcessMemory` directly.
- ETW‑Based Detection – Kernel Telemetry That Catches Syscall Bypass
Event Tracing for Windows (ETW) provides kernel‑level `ReadProcessMemory` events, even when no `OpenProcess` handle is visible. Enable the Microsoft‑Windows‑Kernel‑Process provider and subscribe to event ID 50 (Remote Read) to detect actual memory extraction from lsass.
Step‑by‑step guide to deploy ETW monitoring:
- Create a PowerShell script to register the ETW consumer (run as Admin):
Install Nt Kernel Logger session logman create trace "LsassMonitor" -p "{22fb2cd6-0e7b-422b-a0c7-2fad1fd0e716}" 0xffffffffffffffff 0x5 -o c:\logs\lsass.etl -ets logman start "LsassMonitor" -ets Wait for events, then stop: logman stop "LsassMonitor" -ets -
Parse ETL files to detect remote reads on lsass:
Use Get-WinEvent with the ETL file Get-WinEvent -Path c:\logs\lsass.etl -FilterXPath "[System[EventID=50]]" | Where-Object { $_.Properties[bash].Value -like "lsass" }
3. Deploy real‑time via NXLog or custom C:
Sample C ETW consumer code (simplified):
using Microsoft.Diagnostics.Tracing.Session;
var session = new TraceEventSession("LsassWatcher");
session.EnableProvider(new Guid("{22fb2cd6-0e7b-422b-a0c7-2fad1fd0e716}"), TraceEventLevel.Always);
session.Source.Dynamic.AddCallbackForProviderEvent("Microsoft-Windows-Kernel-Process", "ReadProcessMemory", (data) => {
if (data.ProcessName == "lsass") Console.WriteLine($"Remote read from {data.GetUnicodeString("CallingProcessName")}");
});
What this catches: Mimikatz’s sekurlsa::logonpasswords, even when using `MiniDumpWriteDump` or direct syscalls. Combine with Windows Defender Credential Guard to virtualise lsass memory – making any read return only gibberish.
- Linux Memory Forensics – Detecting Similar Attacks on Pluggable Authentication Modules
While Linux lacks an exact lsass equivalent, credential dumping targets /etc/shadow, SSSD caches, or gnome-keyring. Attackers use `ptrace` or process‑VM‑reads on `sshd` or gdm‑password. Static rules like “alert on ptrace of sshd” fail similarly. Use BPF‑based process monitoring and Linux Security Modules (LSM).
Step‑by‑step guide to harden Linux against credential memory scraping:
1. Restrict `ptrace` system‑wide (blocks many debugger‑based dumpers):
Permanently disable ptrace echo "kernel.yama.ptrace_scope = 2" >> /etc/sysctl.d/99-ptrace.conf sysctl -p /etc/sysctl.d/99-ptrace.conf
2. Monitor process‑VM‑read using auditd:
auditctl -a always,exit -F arch=b64 -S process_vm_readv -k cred_dump ausearch -k cred_dump --format raw | aureport -f -i
- Deploy Falco runtime security to alert on suspicious memory access:
Falco rule snippet:
- rule: Read SSH Process Memory desc: Detect process_vm_readv on sshd condition: > evt.type = process_vm_readv and proc.name != "gdb" and fd.name contains "/proc/sshd_pid/mem" output: "Credential dump attempt on sshd (user=%user.name process=%proc.name)" priority: CRITICAL
Training course correlation: Teach SOC analysts to move from “lsass.exe rule” thinking to memory access telemetry – regardless of OS. Recommend SANS FOR528 (Memory Forensics) or eLearnSecurity’s Windows internals course.
4. AI‑Driven Behavioural Baselines – Automating Anomaly Detection
Static rules can’t keep up with obfuscated attackers. Use unsupervised learning on process‑access graphs to model normal relationships – e.g., `backup.exe→lsass` is baseline, `notepad.exe→lsass` is anomaly. Open‑source tools like GRR or Elasticsearch’s pre‑built anomaly detectors can help.
Step‑by‑step guide to implement a simple ML baseline (Python + ELK):
- Collect historical process access data (Sysmon Event ID 10) into Elasticsearch.
- Create a data view of source process, target process, granted access flags.
- Use Elastic’s built‑in “unusual process access” machine learning job:
– Navigate to Machine Learning → Anomaly Detection → Create job.
– Choose “process_access” datafeed.
– Set partition field to `TargetProcessImage` (lsass.exe).
– Detector: `mean` of `count` for each SourceProcessImage.
4. Tune the model – exclude known backup processes as “influencers”.
5. Set alerts for anomaly scores > 70.
Why AI wins: Attackers using `rundll32.exe` or `regsvr32.exe` (LOLBins) to access lsass will appear as low‑frequency, high‑severity anomalies, while daily backup jobs remain baselined.
- Cloud Hardening – Protecting Credentials in Azure and AWS
Modern attackers skip lsass entirely and dump cloud credentials (Azure Refresh Tokens, AWS metadata). However, the same principle applies: don’t write static rules for single processes. Instead, enforce Just‑In‑Time (JIT) access and monitor secure token storage.
Step‑by‑step mitigation for cloud credential scraping:
- On Azure VMs: Enable Azure Disk Encryption and use Azure Policy to require `CredentialGuard` on Windows VMs.
- On AWS EC2:
Block access to IMDSv1 (prone to SSRF) and enforce v2 aws ec2 modify-instance-metadata-options --instance-id i-12345 --http-tokens required --http-endpoint enabled Monitor IMDS access logs in CloudTrail
- API security rule: Never write a rule that alerts on “any GET to /metadata”; instead, alert on anomalous User‑Agent or source IP not matching your ephemeral CI/CD runners.
- Vulnerability Exploitation & Mitigation – Bypassing lsass Protections
Attackers now use PPI (Process‑Protocol‑Injection) or NTFS transactions to dump lsass without memory reads. As a defender, deploy Windows 11’s “Local Security Authority (LSA) Protection” (RunAsPPL).
Step‑by‑step guide to enable lsass as a Protected Process Light:
1. Check current status (as Admin PowerShell):
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL"
2. Enable PPL:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f
3. Reboot – then try to run Mimikatz with sekurlsa::logonpasswords. It will fail with ERROR kuhl_m_sekurlsa_acquireLSA – Handle on memory (0x00000005).
4. But bypass exists – kernel drivers can unset PPL. So add Hypervisor‑protected Code Integrity (HVCI) and memory integrity.
What Undercode Say:
- Static detection rules for lsass.exe are a dead end – they create noise, not security.
- Shift to ETW kernel telemetry, BPF/LSM on Linux, and AI‑driven baselines for real credential dumping visibility.
- Train teams to think in terms of memory access patterns, not process names – and enforce PPL + HVCI as a default.
Analysis (10 lines):
The post highlights a systemic failure in detection engineering: chasing atomic indicators (e.g., “process opens lsass”) while ignoring contextual behaviour. Modern EDRs that rely solely on user‑mode hooks are trivially bypassed via direct syscalls or minifilter drivers. The recommended shift to ETW Provider 50 (ReadProcessMemory) captures the actual attack primitive, regardless of how the handle was obtained. Similarly, on Linux, `process_vm_readv` audit rules provide the same fidelity. AI and behavioural analytics are not magic – they require clean baselines and careful exclusion of legitimate outliers. The most cost‑effective defence remains enabling PPL and Credential Guard, which raise the cost of dumping to requiring a kernel exploit. Organisations should prioritise these configuration changes over writing another 100 lsass‑access rules. Finally, training courses must update their curricula – teaching “alert on Event ID 10” is obsolete; teaching “decode ETW kernel events” is the new minimum.
Prediction:
By 2026, nearly all SIEM rules based on `PROCESS_ALL_ACCESS` to lsass will be deprecated as vendors embed kernel‑call‑stack telemetry by default. Attackers will shift to memory injection into trusted processes (e.g., lsaiso.exe) or leverage GPU‑based DMA attacks to read lsass from physical memory. Defenders will respond with confidential computing (AMD SEV, Intel TDX) that encrypts lsass memory even from the hypervisor. The “stop writing rules for lsass.exe” mantra will evolve into “stop trusting your own kernel – move lsass to a separate TEE (Trusted Execution Environment).”
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Ridgeline Cyber – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
