« Suspicious JavaScript Execution via Deno Conhost Spawned By Suspicious Parent Process »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.24

Suspicious Cmd Execution via WMI

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Suspicious Cmd Execution via WMI

edit

Identifies suspicious command execution (cmd) via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement.

Rule type: eql

Rule indices:

  • endgame-*
  • logs-crowdstrike.fdr*
  • logs-endpoint.events.process-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-system.security*
  • logs-windows.forwarded*
  • logs-windows.sysmon_operational-*
  • winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Execution
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Windows Security Event Logs
  • Data Source: Microsoft Defender XDR
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Crowdstrike
  • Resources: Investigation Guide

Version: 322

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Suspicious Cmd Execution via WMI

Possible investigation steps

  • Does the alert-local command line match the Impacket-style WMI output-capture shape?
  • Focus: process.command_line for quiet execution, stdout/stderr redirection, temp or loopback admin-share output paths, __* names, and "-encodehex".
  • Implication: escalate when WMI-brokered output capture writes to temp or loopback admin-share paths; lower concern only when the same exact capture shape recurs for one recognized RMM, SCCM, backup, or helpdesk workflow on this host.id.
  • Are "cmd.exe" and "WmiPrvSE.exe" the expected binaries in the expected launch context?
  • Focus: process.executable, process.code_signature.subject_name, process.code_signature.trusted, process.parent.executable, and process.parent.command_line.
  • Implication: escalate when either binary is unsigned, renamed, path-abnormal, or WMI broker context does not fit a management service; Microsoft-signed binaries reduce masquerade concern but do not clear output capture.
  • What operation does the captured command perform?
  • Focus: process.command_line for nested interpreters, discovery commands, copy/archive tools, service or scheduled-task verbs, and defense-evasion tokens.
  • Implication: escalate when the command stages execution, changes services or tasks, performs discovery at scale, invokes secondary interpreters or LOLBins, copies payloads, or hides output; lower concern for one bounded diagnostic or inventory command.
  • Does the user, host, and any session metadata fit controlled WMI administration?
  • Focus: user.id, user.domain, host.id, process.Ext.session_info.logon_type, and process.Ext.session_info.authentication_package.
  • Hint: when process.Ext.authentication_id or session details exist, pivot to same-host Windows Security 4624/4648 and match logon/session ID to recover source workstation, source IP, and account context. Missing authentication telemetry is unresolved, not benign.
  • Hint: if session metadata is absent, decide from recurring user.id, host.id, parent executable, command line, child lineage, and related-alert pattern; missing session metadata is unresolved, not benign.
  • Implication: escalate when a standard user, unusual domain context, network/service session, or unexpected NTLM context drives WMI command execution on this host; lower concern when the same account, host, and parent-command pattern recur as controlled administration.
  • Did the WMI-launched command become a launcher for follow-on execution?
  • Focus: child process events from process.entity_id, reading child process.name, process.executable, and process.command_line. !{investigate{"description":"","label":"Child processes from WMI launched via Cmd.exe","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: if process.entity_id is missing, use host.id plus alert process.pid as child process.parent.pid in a tight alert window; treat this as weaker than entity-linked lineage.
  • Implication: escalate when child processes include secondary interpreters, "rundll32.exe", "regsvr32.exe", "schtasks.exe", "sc.exe", copy tools, archivers, or other LOLBins; keep scope narrower when the cmd instance exits after one bounded command and no suspicious child appears.
  • If local process evidence stays suspicious or unresolved, do related alerts show the same user or host in lateral-movement activity?
  • Focus: same-user.id alerts that reuse WMI output-capture fragments, WMI parentage, SMB, WinRM, service-install, scheduled-task, or matching command-line patterns. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: if the user view is quiet or ambiguous, compare same-host.id alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Implication: broaden scope when the same user, host, or command pattern appears in adjacent remote-execution alerts; keep the case local when related alerts are absent and the local process evidence already explains the activity.
  • Escalate when output capture combines with suspicious identity, command intent, session, child, or related-alert evidence; close only when exact command shape, parent, user/host scope, child lineage, and recurrence bind to one recognized workflow on this host.id; preserve evidence and escalate when answers conflict or remain incomplete.

False positive analysis

  • Remote-management, software distribution, backup, and helpdesk workflows can run "cmd.exe" through WMI and capture output to temp or loopback admin-share paths. Confirm only when parent executable, command line, user.id, host.id, process-side session context, and child behavior align with one workflow. Inventories, change records, and owner confirmation can corroborate but not replace telemetry; without them, require recurrence of the same anchors across prior alerts from this rule.
  • Bounded diagnostic WMI commands can be legitimate when an admin account runs one inventory or support command and the tree ends there. Do not close on Microsoft-signed "cmd.exe" or "WmiPrvSE.exe" alone; require exact output-capture shape, account, host scope, and no suspicious child processes to match the recognized workflow.
  • Build exceptions from the minimum confirmed pattern: stable process.parent.executable, specific output-capture command shape, user.id, and host.id. Avoid exceptions on process.name, "cmd.exe", "WmiPrvSE.exe", or temp-path fragments alone.

Response and remediation

  • If confirmed benign, reverse any temporary containment and document the command, WMI broker path, account, host, session context, child-process result, and recurrence evidence that validated the workflow. Create an exception only for that same recurring pattern.
  • If suspicious but unconfirmed, export the alert, process tree, command line, parent context, child-process lineage, temp/admin-share output path fragments, and related-alert results before containment. Apply reversible containment first, such as heightened monitoring or temporary WMI restriction for the affected account or host where business impact permits; isolate the host only if child execution, destructive command intent, or related alerts suggest active compromise.
  • If confirmed malicious, isolate the host when its role can tolerate isolation, or terminate the alerting "cmd.exe" and malicious child processes only after preserving their command lines and entity IDs. Disable or rotate the affected credentials when user/session evidence or related alerts show account misuse.
  • After containment, remove only the temp outputs, staged payloads, services, scheduled tasks, or WMI persistence changes identified during the investigation, then verify no related alerts remain for the same user.id, host.id, or process.command_line pattern.
  • Post-incident hardening: restrict remote WMI to recognized admin hosts and accounts, reduce local administrator exposure, and retain process telemetry that distinguishes this output-capture pattern from adjacent WinRM or SMB service-based remote execution.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
process where host.os.type == "windows" and event.type == "start" and
 process.parent.name : "WmiPrvSE.exe" and process.name : "cmd.exe" and process.args : "/c" and process.args:"/Q" and
 process.args : "2>&1" and process.args: "1>"  and
 process.args : ("C:\\windows\\temp\\*.txt", "\\Windows\\Temp\\*", "-encodehex", "\\\\127.0.0.1\\C$\\Windows\\Temp\\*", "\\\\127.0.0.1\\ADMIN$\\__*.*")

Framework: MITRE ATT&CKTM

« Suspicious JavaScript Execution via Deno Conhost Spawned By Suspicious Parent Process »