Listen to this Post
Introduction:
Microsoft Defender for Endpoint (EDR) often tags Mimikatz execution attempts as “informational” severity, leading SOC teams to dismiss a clear indicator of post‑compromise activity. When an attacker lands on a host, fails to dump LSASS credentials, but still triggers an alert, that “low” severity signal actually reveals established access, credential access attempts, and active privilege escalation – three kill‑chain phases that demand immediate incident response.
Learning Objectives:
- Analyze why Defender EDR classifies certain Mimikatz events as informational and how adversaries exploit this classification gap.
- Build custom detection rules and hunting queries for credential dumping attempts that evade default alerting.
- Execute hands‑on Linux/Windows commands to simulate, detect, and block LSASS memory access in both on‑prem and cloud environments.
You Should Know:
- Understanding the “Informational” Severity Trap in Defender EDR
Defender EDR assigns severity based on observed impact rather than intent. If Mimikatz runs but fails to extract credentials (e.g., due to PPL protection or disabled debug privilege), the alert is labeled informational. Yet the very presence of Mimikatz on disk or in memory confirms: an attacker has code execution, is enumerating security contexts, and is one bypass away from domain admin.
Step‑by‑step guide to verify your current detection posture:
- Check if Mimikatz execution appears as Informational in your SIEM:
// Kusto Query Language for Microsoft 365 Defender DeviceProcessEvents | where FileName in~ ("mimikatz.exe", "mimikatz") or ProcessCommandLine contains "sekurlsa::logonpasswords" | project Timestamp, DeviceName, ActionType, InitiatingProcessAccountName, Severity, AdditionalFields - Simulate a low‑impact Mimikatz run on a test endpoint (authorized only):
– Download Mimikatz from a trusted test source or compile from GitHub.
– Execute `privilege::debug` – if debug fails, Mimikatz will still log but not dump secrets.
3. Observe alert in Defender portal: note the “Informational” tag and lack of automatic remediation.
- Building a Custom Detection Rule for Failed Credential Dumping
Default rules fire on successful LSASS dump. To catch attempts, you must monitor for specific API calls or process access patterns that fail. Use Sysmon or EDR advanced hunting to detect `PROCESS_ACCESS` requests to LSASS with PROCESS_VM_READ.
Step‑by‑step guide for creating a custom rule (Windows via Sysmon + Sigma):
- Install Sysmon with configuration that logs LSASS access:
<RuleGroup name="" groupRelation="or"> <ProcessAccess onmatch="include"> <TargetImage condition="end with">lsass.exe</TargetImage> <AccessMask condition="is">0x1410</AccessMask> <!-- Read access --> <CallTrace condition="contains">mimikatz|unknown|outlook</CallTrace> </ProcessAccess> </RuleGroup>
2. Deploy via PowerShell:
.\Sysmon64.exe -accepteula -i sysmon_config.xml
3. Convert to Sigma rule for SIEM (simplified detection):
title: Failed LSASS Access Attempt by Unusual Process condition: (TargetImage|contains: 'lsass.exe' and AccessMask: '0x1410')
- Credential Dumping Mitigation: Enabling LSASS PPL and Credential Guard
Blocking Mimikatz entirely is unrealistic; instead, raise the cost by protecting LSASS from read access. Windows Defender Credential Guard isolates LSASS in a virtualized container, while PPL (Protected Process Light) prevents arbitrary code injection.
Windows hardening commands (run as administrator):
Enable Credential Guard via Registry reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LsaCfgFlags /t REG_DWORD /d 1 /f Enable PPL reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1 /f Reboot required shutdown /r /t 0
Linux equivalent: restricting /proc/mem access to prevent similar attacks (e.g., against SSSD):
Restrict ptrace access to prevent memory scraping of authentication caches sudo sysctl -w kernel.yama.ptrace_scope=2 echo "kernel.yama.ptrace_scope=2" | sudo tee -a /etc/sysctl.conf
- Hunting for Mimikatz Indicators Without Relying on Severity
Use process lineage and command‑line arguments to detect Mimikatz regardless of its execution result. Attackers rename binaries or use reflective loading – hunt for unique argument patterns.
KQL advanced hunting query for renamed Mimikatz:
DeviceProcessEvents | where ProcessCommandLine contains "sekurlsa" or ProcessCommandLine contains "logonpasswords" or ProcessCommandLine contains "crypto::" | project Timestamp, DeviceName, FileName, ProcessCommandLine, AccountName | order by Timestamp desc
Linux detection of credential access tools (e.g., mimipenguin, LaZagne):
Auditd rule to monitor access to /etc/shadow and /etc/passwd auditctl -w /etc/shadow -p wa -k cred_access auditctl -w /etc/passwd -p wa -k cred_access Check for suspicious processes reading /proc/mem for SSSD caches sudo ausearch -k cred_access --format interpreted
- Building an Automated Playbook for “Informational” Mimikatz Alerts
Most SOCs ignore low‑severity alerts. Instead, create a playbook that auto‑escalates any Mimikatz reference, regardless of severity, by linking it to preceding suspicious activity (e.g., WMI execution, PsExec, or service creation).
Step‑by‑step playbook logic (SOAR‑ready):
- Trigger: Any process referencing
sekurlsa,logonpasswords, or `mimikatz` in command line, even if severity is Informational or Low. - Enrichment: Pull parent process tree from last 10 minutes. Check if parent process is
cmd.exe,powershell.exe, or `wmic.exe` spawned from network service. - Isolation: Automatically isolate the host from network (using Defender’s machine isolation API).
4. Response:
Collect memory dump of suspicious process .\Procdump.exe -ma <PID> C:\Dumps\suspicious.dmp Capture network connections netstat -ano > C:\Dumps\netconn.txt
5. Notification: Create a “priority informational” ticket routing to Tier‑2 SOC analysts.
- Cloud Hardening: Detecting Mimikatz in Azure VMs and AWS EC2
In cloud environments, attackers pivot from compromised VMs to steal cloud tokens. Defender EDR for cloud workloads produces the same informational alerts, but you must correlate with cloud metadata endpoints.
Linux command to detect unauthorized IMDSv2 access (potential credential theft):
Monitor for curl/wget to 169.254.169.254 sudo auditctl -a always,exit -F arch=b64 -S connect -F a1=0x69 -k imds_access View alerts sudo ausearch -k imds_access --format raw
Azure hardening: Disable IMDS on non‑admin VMs via Azure Policy
{
"if": {
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
"then": {
"effect": "deny",
"details": {
"existenceCondition": {
"field": "tags.IMDSDisabled",
"equals": "true"
}
}
}
}
- Testing Your Detections: Simulating Mimikatz Without Breaking Your EDR
Use atomic red team tests to validate that your custom rules fire on both successful and failed Mimikatz runs. This ensures “informational” alerts no longer go unnoticed.
PowerShell command to attempt LSASS access via MiniDumpWriteDump (will likely fail without SeDebugPrivilege, but still logs):
Invoke-AtomicTest for Mimikatz (Atomics folder) Invoke-AtomicTest T1003.001 -TestNames "Dump LSASS via comsvcs.dll"
Linux simulation of SSSD memory dump attempt (fails without root, but leaves traces):
Attempt to read SSSD memory from /proc cat /proc//maps | grep "sssd" || echo "No sssd memory accessible" Equivalent detection: monitor for process opening sssd's memory map sudo strace -p $(pgrep sssd) -e openat,read 2>&1 | tee /var/log/sssd_hunt.log
What Undercode Say:
- Key Takeaway 1: “Informational” severity in EDR is not a synonym for “safe to ignore.” It often indicates that an attacker failed at a specific tactic but already succeeded at gaining execution and reconnaissance.
- Key Takeaway 2: Default detection rules prioritize noise reduction over true positive capture. SOCs must build custom logic that triggers on attempted credential access, using Sysmon, process lineage, and command‑line arguments.
- Key Takeaway 3: Mitigation without detection is blind. Enabling LSASS PPL and Credential Guard stops most Mimikatz variants, but attackers will move to reflection or LSASS‑less techniques – you still need hunting for secondary indicators like unusual process access requests.
The discussion threads from LinkedIn experts Akash Upadhyay and Jappreet Bath highlight a painful reality: many SOCs still treat alerts like restaurant menus – informational items are skipped. Yet as Ryan Sharpnack jokingly noted about watching The Menu, sometimes the most unassuming items contain the real plot twist. Your EDR’s informational Mimikatz alert is that hidden course – it proves a host is already serving unwanted guests. Build playbooks, automate enrichment, and train analysts to treat any credential access tool reference as a red table flag.
Prediction:
Within 18 months, EDR vendors will phase out “informational” severity for credential dumping attempts, replacing it with a “TTP Observed – No Payload” category that auto‑triggers containment when coupled with any lateral movement precursor. However, until then, SOCs running Defender alone will see a surge in silent breaches where Mimikatz fails but Cobalt Strike or Sliver succeed – forcing teams to adopt custom detection engineering as a baseline competency, not a luxury. The organizations that rewrite their low‑severity playbooks today will be the ones explaining the breach to everyone else tomorrow.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Inode Soc – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
