From ATT&CK Technique to Production Query: Hunting LSASS Memory Dumping

Most MITRE ATT&CK mapping exercises in enterprise SOCs are pure security theater. Teams slap technique IDs onto existing alerts, color a coverage matrix green, and assume they can detect a adversary moving through their domain. The reality is that a single ATT&CK sub-technique can manifest in dozens of distinct execution paths—and if your hunt strategy relies on simple string matching against process creation events, you are missing the vast majority of real-world activity.

To demonstrate how to build an actual, operational threat hunt, we will take T1003.001 (OS Credential Dumping: LSASS Memory) and trace it from raw execution mechanics to validated hunt queries.

Deconstructing T1003.001 Beyond Matrix Heatmaps

Adversaries need local credentials to pivot. Extracting plaintext passwords, NTLM hashes, and Kerberos tickets directly from the Local Security Authority Subsystem Service (lsass.exe) memory space remains one of the fastest paths to domain escalation.

While attackers can drop custom tools like Mimikatz or PSSnapShot, sophisticated operators favor native binaries to reduce disk footprint and bypass basic software restriction policies. The most common living-off-the-land variant invokes the exported MiniDump function within comsvcs.dll via rundll32.exe.

The standard execution syntax looks like this: rundll32.exe C:\windows\system32\comsvcs.dll, MiniDump <LSASS_PID> C:\Windows\Tasks\lsass.dmp full

If your detection logic only looks for the string comsvcs.dll and MiniDump in command lines, any attacker with a basic understanding of Windows internals will trivial bypass you. They can rename comsvcs.dll, execute via ordinal call (#24 instead of MiniDump), or drop a copy of the DLL into a user-writable directory. A resilient hunt strategy must look deeper at the underlying behavior.

Translating Execution Mechanics into a Testable Hypothesis

A threat hunt starts with an explicit, falsifiable statement about adversary behavior that cannot be answered with a simple binary alert.

Flawed Hypothesis: “Adversaries are running comsvcs.dll to dump LSASS.” (Too narrow, relies on brittle indicators.)

Operational Hypothesis: If an adversary attempts to dump LSASS memory without bringing custom binaries, they will execute a native process host (rundll32.exe) that loads comsvcs.dll or invokes export ordinal #24, OR a non-system process will request high-privilege access rights (PROCESS_VM_READ / 0x0010) to the lsass.exe memory space.

This hypothesis establishes two distinct hunting tracks:

1. Command-line behavioral patterns: Catching native execution variants across command-line flags and ordinals.
2. Process access events: Catching handle creation against lsass.exe regardless of what process requested it.

Telemetry Requirements: Process Creation vs. Memory Access

Testing both tracks requires specific log sources. You cannot hunt memory abuse if you are only collecting basic process creation events.

For Track 1 (Command-Line Behavior), you need process creation logs that capture full command arguments:

• Windows Event ID 4688 (with “Include command line in process creation events” enabled via Group Policy)
• Sysmon Event ID 1 (ProcessCreate)
• EDR Process Creation Telemetry (e.g., Microsoft Defender for Endpoint DeviceProcessEvents)

For Track 2 (Direct Memory Handle Acquisition), process creation telemetry is insufficient because an attacker could use an unmonitored or renamed process. You need process access telemetry:

• Sysmon Event ID 10 (ProcessAccess)
• EDR Process Open Events (e.g., MDE DeviceEvents with ActionType == "OpenProcessApiCall")

Ensure your Sysmon configuration explicitly monitors target image lsass.exe for handle requests. Without GrantedAccess filtering, Event ID 10 will swamp your log ingest with benign queries from system services.

Building the Hunt Queries (KQL)

We will write our queries in Kusto Query Language (KQL) for Azure Sentinel or Defender XDR. The same logic translates directly to Splunk SPL or Elastic EQL.

Track 1: Command-Line Variations and Ordinal Evasion

First, let’s query process creation events. We need to catch standard MiniDump strings, ordinal invocations (#24), and instances where pathing is manipulated.

DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName =~ "rundll32.exe" or ProcessCommandLine has "rundll32"
| where (
    // Direct reference to comsvcs or dynamic library loading variants
    ProcessCommandLine has "comsvcs" 
    // Capture ordinal export invocation for MiniDump (#24)
    or ProcessCommandLine has "#24"
    or ProcessCommandLine has "#+24"
)
// Look for flags associated with dumping or path targets
| where ProcessCommandLine has_any ("full", "dump", "lsass", "minidump")
| project TimeGenerated, DeviceName, AccountName, ParentProcessName, ProcessCommandLine, InitiatingProcessFolderPath

Notice that we check for both comsvcs and #24. An attacker running rundll32.exe target.dll, #24 <PID> out.dmp full bypasses every naive detection looking for the string MiniDump.

Track 2: Process Access Telemetry (Sysmon Event ID 10 / MDE)

To catch LSASS access regardless of binary name or command-line syntax, we look at the access mask requested when opening a process handle. To read LSASS memory, the requesting process must obtain PROCESS_VM_READ (0x0010). Attackers frequently request broader rights like PROCESS_ALL_ACCESS (0x1F0FFF) or 0x1410 (PROCESS_VM_READ | PROCESS_QUERY_INFORMATION).

DeviceEvents
| where TimeGenerated > ago(7d)
| where ActionType == "OpenProcessApiCall"
| where TargetProcessFileName =~ "lsass.exe"
// Convert or match GrantedAccess masks containing PROCESS_VM_READ
| extend GrantedAccess = tostring(AdditionalFields.GrantedAccess)
| where GrantedAccess in~ ("0x10", "0x1410", "0x1F0FFF", "0x143A")
// Filter out standard legitimate Windows OS processes
| where NOT (
    FileName in~ ("svchost.exe", "msmpeng.exe", "lsass.exe", "csrss.exe", "mrt.exe")
    and FolderPath startswith @"C:\Windows\System32\"
)
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, FileName, FolderPath, TargetProcessFileName, GrantedAccess

Lab Validation and Triage Logic

Never push a hunt query straight to an alert rule without testing your baseline in a lab and triaging production results.

To validate Track 1 in an isolated domain environment:

1. Open an elevated Command Prompt.
2. Identify the PID of lsass.exe using tasklist /fi "imagename eq lsass.exe".
3. Execute the ordinal variant: rundll32.exe C:\windows\system32\comsvcs.dll, #24 <LSASS_PID> C:\Windows\Tasks\test.dmp full

Run your Track 1 KQL query. If executed properly, it should surface the event immediately.

Baseline Noise and Triage Workflow

When running Track 2 against production data, you will encounter legitimate software that queries LSASS memory:

• Antivirus/EDR agents (e.g., third-party endpoint security products)
• Password policy validation drivers
• System management software (e.g., IT monitoring tools)

Do not blindly add these to a broad exclude list. Validate the code signature of the binary making the request using InitiatingProcessSignerInfo. If an unsigned process originating from C:\Users\Public\ or AppData requests access mask 0x10 against lsass.exe, isolate the host immediately. You are not looking at a false positive—you are looking at credential theft in progress.