Listen to this Post
Introduction
Dumping the memory of the Local Security Authority Subsystem Service (LSASS) remains one of the most effective post‑exploitation techniques for credential harvesting on Windows systems. While security products have become adept at blocking conventional methods such as using `comsvcs.dll` or rundll32, a direct call to `MiniDumpWriteDump` via `dbghelp.dll` can bypass detection entirely—leaving fully patched Windows Server 2022 with up‑to‑date Microsoft Defender completely silent.
Learning Objectives
- Understand how a direct `MiniDumpWriteDump` call evades signature‑based and command‑line detection mechanisms.
- Identify the gaps in Defender’s telemetry, including the absence of expected Event IDs and the non‑deterministic nature of EID 10.
- Learn practical detection strategies, including correlation of Defender exclusion events (EID 5007) and advanced hunting queries.
You Should Know
- The Silent LSASS Dump Technique – Step by Step
The technique described in the LinkedIn post relies on a straightforward Win32 API call that any crash‑dump utility uses. Instead of the well‑monitored path via comsvcs.dll, the attacker calls `MiniDumpWriteDump` directly from dbghelp.dll. This bypasses command‑line detection, does not generate Event ID 1116/1117 (traditionally associated with malware detection), and produces no LSASS‑specific alerts.
Step‑by‑step guide to replicate the behaviour (for authorised testing only):
1. Obtain a handle to the LSASS process.
Running as administrator, open a handle to `lsass.exe` with the necessary access rights (PROCESS_QUERY_INFORMATION, PROCESS_VM_READ).
2. Call `MiniDumpWriteDump` from `dbghelp.dll`.
The call is made directly, not via comsvcs.dll. Example C++ snippet:
include <DbgHelp.h> pragma comment(lib, "DbgHelp.lib") HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, lsassPid); HANDLE hFile = CreateFile(L"lsass.dmp", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); MINIDUMP_TYPE dumpType = MiniDumpWithFullMemory; MiniDumpWriteDump(hProcess, lsassPid, hFile, dumpType, NULL, NULL, NULL);
3. Observe the behaviour.
The dump write slows from seconds to 30–45 minutes, and system load spikes. Despite this, the dump completes and credentials (NT hash, machine credentials, DPAPI) can be extracted.
4. Check for alerts.
No LSASS‑related alerts appear in Defender. The only high‑fidelity signal is a Defender exclusion add → remove within 30 minutes, which generates Event ID 5007.
Linux/Windows commands for analysis (detection side):
- Monitor for `dbghelp.dll` being loaded by an unusual process:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational';ID=7} | Where-Object { $_.Message -match 'dbghelp.dll' } - Check for LSASS handle access via Sysmon Event ID 10:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational';ID=10} | Where-Object { $_.Message -match 'lsass.exe' }
2. Why Microsoft Defender Remains Silent
The post highlights a critical detection gap: Defender observes and interferes with the operation but emits no corresponding security signal. The expected Event ID 10 (LSASS handle access) is non‑deterministic – it fired on run three but not on runs one or two, on the same host with the same binary and the same Defender state.
What triggers and what doesn’t:
- Blocked immediately:
comsvcs.dll, `MiniDump` → alertHackTool:Win32/DumpLsass.H. - Silent: Direct call to `MiniDumpWriteDump` via
dbghelp.dll. - High‑confidence signal (when present): Event ID 10 – but absence of this event is not evidence of absence.
Key finding: The signature keys on `MiniDump` (a `rundll32` alias) but not on `MiniDumpW` (the actual export). Detection is tied to an invocation artifact, not to the capability itself.
- Hunting for the Hidden Execution – Detection Engineering in Practice
Since the technique leaves no direct LSASS alerts, defenders must rely on secondary indicators and behavioural correlations.
Primary detection artefact – Defender exclusion manipulation:
Event ID 5007 (Microsoft-Windows-Windows Defender/Operational) logs configuration changes. The post reports that the highest‑fidelity signal was:
– An exclusion added to Defender.
– The same exclusion removed within 30 minutes.
PowerShell command to hunt for rapid exclusion changes:
$timeWindow = (Get-Date).AddMinutes(-30)
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -FilterXPath "[System[EventID=5007]]" |
Where-Object { $<em>.TimeCreated -ge $timeWindow -and $</em>.Message -match "Exclusions" } |
Select-Object TimeCreated, Message
Correlation with other telemetry:
- Sysmon Event ID 7 (DLL load) for `dbghelp.dll` loaded by an unexpected process.
- Sysmon Event ID 10 (process access) for LSASS, even if it fires only intermittently.
- Process creation events (EID 4688) for tools that could call
MiniDumpWriteDump.
4. Mitigation Strategies – Closing the Gap
Defenders should not rely solely on signature‑based detection. A layered approach is required.
Enable LSA Protection (RunAsPPL):
- This protects LSASS as a protected process, making it harder for user‑mode tools to obtain a handle with sufficient access.
- Check status:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL
- Enable:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f
Implement Credential Guard:
- Virtualisation‑based isolation of LSASS prevents even kernel‑mode read access to the process memory.
- Check status:
Get-WinEvent -LogName Microsoft-Windows-DeviceGuard | Where-Object { $_.Id -eq 1 }
Advanced hunting query in Microsoft 365 Defender / Sentinel:
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "DllLoaded"
| where FileName =~ "dbghelp.dll"
| where InitiatingProcessFileName in ("powershell.exe", "cmd.exe", "rundll32.exe")
| join kind=inner (
DeviceEvents
| where ActionType == "ProcessAccess"
| where TargetProcessName =~ "lsass.exe"
) on DeviceId
- Practical Detection Engineering – Building Your Own Rules
Sigma rule for suspicious `dbghelp.dll` access:
title: Suspicious LSASS Access via DbgHelp.Dll status: experimental logsource: product: windows service: sysmon detection: selection: EventID: 7 ImageLoaded: '\dbghelp.dll' ProcessName: - '\powershell.exe' - '\cmd.exe' - '\rundll32.exe' condition: selection
Correlation with Event ID 5007 (Defender exclusion changes):
- Any exclusion add followed by a removal within a short time window is highly suspicious.
- Playbook: Alert on the pair, then investigate the process that made the change.
- The Future of Credential Access – Predictions and Recommendations
This technique demonstrates a growing trend: attackers will move away from well‑monitored living‑off‑the‑land binaries and instead directly invoke low‑level APIs. The 30‑45 minute write time forces a strategic choice – only privileged jump hosts and quiet windows become viable targets. However, as defensive tooling improves, attackers will likely combine this method with additional obfuscation, such as:
– Unhooking `MiniDumpWriteDump` from a fresh copy of dbghelp.dll.
– Using callbacks to manipulate the dump in memory before writing to disk (as seen in tools like LetMeowIn).
Recommendations for blue teams:
- Do not rely on a single data source. Combine file access, handle access, and configuration change events.
- Treat the absence of Event ID 10 as no evidence of safety – especially when other indicators (e.g., high CPU, slow I/O) are present.
- Include Defender exclusion changes in your core detection pipeline.
- Consider moving from reactive detection to proactive prevention with LSA Protection and Credential Guard.
What Undercode Say
- The quietest dump is the most dangerous. A fully patched Windows Server 2022 with current Defender signatures allowed a complete LSASS dump without a single LSASS‑specific alert. The only tell‑tale sign was a Defender exclusion added and removed within 30 minutes – an artefact of operational behaviour, not technique detection.
-
Detection gaps are not binary. Defender clearly observed and interfered with the dump (the 45‑minute slowdown proves active runtime enforcement), yet it emitted no security signal. This means visibility into enforcement activity is as important as visibility into malicious intent.
-
As defenders, we must hunt for behavioural anomalies, not just known signatures. Event ID 10 is non‑deterministic – it may fire or not, even under identical conditions. Relying on it as a primary LSASS detection source will leave you blind.
-
The future of credential access is in user‑land, not kernel. No PPL bypass, no BYOVD, no kernel tricks – just a standard API call. This is a sign that offensive tradecraft is moving toward leveraging built‑in Windows functionality in ways that security products are not yet instrumented to monitor.
Prediction
In the next 12–18 months, we will see a wave of credential‑dumping tools that directly invoke `MiniDumpWriteDump` (or similar low‑level APIs) combined with in‑memory manipulation to avoid writing a dump file altogether. Defenders will be forced to move beyond traditional file‑based and handle‑based detections. Microsoft will likely respond by enhancing Defender’s telemetry for `dbghelp.dll` access and making Event ID 10 more reliable, but the cat‑and‑mouse game will continue. Organisations that rely solely on out‑of‑the‑box detection will remain vulnerable; those that implement behaviour‑driven hunting and proactive mitigation (LSA Protection, Credential Guard) will stay ahead.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
