Detecting credential dumping via LSASS access patterns

Most LSASS-dumping detections start and end with "block/alert on access to lsass.exe," which either misses tools that don't trip the obvious flags or buries you in AV/EDR self-noise. LSASS (Local Security Authority Subsystem Service) holds credential material in memory — NTLM hashes, Kerberos tickets, and in some configurations cached plaintext — which makes it one of the highest-value single targets on a Windows host. Almost every credential-access technique that doesn't rely on disk artifacts eventually routes through a handle to that process.

Why "access denied" isn't the bar

Early detection logic treated any OpenProcess call against LSASS as suspicious. That breaks immediately in production: antivirus engines, EDR agents, backup software, and Windows Error Reporting all legitimately touch LSASS constantly. A rule that fires on the mere existence of a handle will drown a SOC in noise within hours of going live, and get disabled by the second week.

Sysmon Event ID 10 (ProcessAccess) records more than that, though — specifically a GrantedAccess field that reflects the actual access rights the requesting process asked for and received. A process that requested PROCESS_VM_READ and PROCESS_QUERY_INFORMATION together (commonly appearing as 0x1010 or 0x1410) is asking for exactly the capability set a memory scraper needs. A process that only asked for PROCESS_QUERY_LIMITED_INFORMATION is not, and should be filtered out before it ever reaches an analyst.

detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess:
      - '0x1010'
      - '0x1410'
      - '0x1438'
      - '0x143a'
      - '0x1fffff'
  filter_known_good:
    SourceImage|endswith:
      - '\werfault.exe'
      - '\MsMpEng.exe'
      - '\MsSense.exe'
      - '\SenseIR.exe'
  condition: selection and not filter_known_good
      

The access-mask filter does most of the false-positive reduction on its own. The source-image allowlist should be built and maintained from your own AV/EDR/backup agent inventory, not copied wholesale from a blog post — the binaries that legitimately need LSASS access vary by environment and by vendor version.

The comsvcs.dll technique deserves its own rule

A meaningful share of real-world LSASS dumping doesn't use a dedicated tool at all. rundll32.exe can invoke the MiniDump export inside the built-in comsvcs.dll to write a full process dump to disk, using nothing but binaries that already ship with Windows. That makes it attractive precisely because a naive "known bad tool" detection list will never catch it — there's no Mimikatz.exe to fingerprint.

detection:
  selection:
    Image|endswith: '\rundll32.exe'
    CommandLine|contains:
      - 'comsvcs.dll'
      - 'MiniDump'
  condition: selection
      

This one is narrow enough to run with a much lower bar than the access-mask rule above, since there's essentially no legitimate reason for an interactive or scripted process to invoke MiniDump against LSASS through rundll32.

Testing it before you trust it

A detection you haven't tested against the technique it claims to catch is a hypothesis, not a control. Atomic Red Team ships tests for both the generic LSASS-access pattern and the comsvcs.dll variant; run them against a host with the rule deployed, confirm the alert fires, and just as importantly, confirm it doesn't fire on a clean baseline image running your standard AV/EDR/backup stack for 24–48 hours before you call it production-ready.

Track the false-positive rate after deployment the same way you would any other detection — if the source-image allowlist needs updating every time you patch your EDR agent, that's a maintenance cost worth documenting up front, not discovering during an on-call rotation.