Detect Mimikatz Credential Dumping in Elastic Common Schema Process Logs

title: Mimikatz Process Execution via Process Name or Command-Line Modules
id: 5a3af970-5587-4827-8af6-b761fdb983c1
status: experimental
description: >
  Detects Mimikatz credential-dumping activity in ECS process events, either
  by the process name mimikatz.exe or by the distinctive sekurlsa and
  privilege::debug module invocations in the command line. sekurlsa::logonpasswords
  reads credentials out of LSASS memory, and privilege::debug is the
  standard precursor that elevates the process token to SeDebugPrivilege so
  that read can happen.
references:
  - https://attack.mitre.org/techniques/T1003/001/
  - https://attack.mitre.org/software/S0002/
author: LogTriage
date: 2026/10/26
logsource:
  category: process_creation
  product: windows
detection:
  selection_process:
    process.name: 'mimikatz.exe'
  selection_cmdline:
    process.command_line|contains:
      - 'sekurlsa::logonpasswords'
      - 'privilege::debug'
  condition: selection_process or selection_cmdline
falsepositives:
  - Authorized red team or penetration test engagement with a known ticket
  - Security product testing or EDR validation labs
level: critical
tags:
  - attack.credential_access
  - attack.t1003.001
  - attack.t1003

What this rule detects

Mimikatz is the reference tool for pulling plaintext passwords, hashes and Kerberos tickets out of LSASS memory on Windows. This rule looks for it in ECS process-creation events by either of two independent signals:

1. process.name: mimikatz.exe — the tool run under its default, unrenamed file name.
2. process.command_line containing sekurlsa::logonpasswords or privilege::debug — the module invocations that do the actual credential theft, regardless of what the binary is called.

Either condition alone is a critical finding. There is no threshold because a single successful execution is enough to compromise every credential cached on the host.

Detection logic

selection_process and selection_cmdline are combined with or rather than and, because an attacker only needs to defeat one of the two signals to evade detection — renaming the binary defeats the first, while running a different module name defeats the second, but defeating both at once is harder, since the tool’s internal module names (sekurlsa, privilege) are what give it its functionality and are not cosmetic.

privilege::debug is listed because it is the standard first step: it elevates the running process to SeDebugPrivilege so it can open a handle to lsass.exe. sekurlsa::logonpasswords is the module that then reads the credentials out of that process’s memory. Seeing either in a command line captured from an ECS-shipped process event is enough to treat the host as compromised.

Validated against a real sample

In ecs_attack.json, a process event on host DESKTOP-VICTIM records:

• process.name: "mimikatz.exe"
• process.command_line: "mimikatz.exe privilege::debug sekurlsa::logonpasswords"
• user.name: "CORP\\jsmith"
• file.path: "C:\\Temp\\mimikatz.exe" with a file.hash.sha256 matching process.hash.sha256

Both selections match this single event: the process name matches selection_process, and the command line matches selection_cmdline on both listed strings. The rule fires.

The benign sample’s only process event is chrome.exe --no-first-run launched by alice on DESKTOP-ALICE — neither the file name nor the command line contains any Mimikatz string, so the rule stays silent.

False positives

The only legitimate source of this alert is intentional: a red team or penetration test running Mimikatz under an authorized engagement, or a security team validating EDR coverage in a lab. Both cases should be traceable to a known host and a ticket. Outside of that, this rule has no benign explanation — there is no routine administrative task that invokes sekurlsa::logonpasswords.