Persistence via WMI Standard Registry Provider

edit

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

Persistence via WMI Standard Registry Provider

edit

Identifies use of the Windows Management Instrumentation StdRegProv (registry provider) to modify commonly abused registry locations for persistence.

Rule type: eql

Rule indices:

logs-endpoint.events.registry-*
endgame-*

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: Persistence
Data Source: Elastic Endgame
Data Source: Elastic Defend
Resources: Investigation Guide

Version: 114

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Persistence via WMI Standard Registry Provider

Possible investigation steps

Which StdRegProv-backed persistence value changed, and what will it run?
Why: StdRegProv can set logon and service ASEPs through "WmiPrvSe.exe" without a child process from the requester; registry value data is the payload clue.
Focus: registry.path, registry.value, registry.data.type, and registry.data.strings.
Implication: escalate when machine-wide Run/RunOnce, Winlogon shell, policy script, "ServiceDLL", or "ImagePath" values launch user-writable, share-hosted, script-host, shell-replacement, or unusual service content; lower suspicion only when the exact value and data match a recognized WMI-based deployment, configuration, or test workflow.
Who is the logical requester behind the WMI provider host?
Why: process.executable usually identifies the provider host; effective process fields can identify the StdRegProv requester.
Focus: Effective_process.executable, Effective_process.name, Effective_process.entity_id, process.executable, and process.entity_id.
Hint: do not clear on the Microsoft-signed provider host alone; attacker and admin tooling can both route registry writes through "WmiPrvSe.exe".
Implication: escalate when the requester is blank with suspicious value data, or is a script host, user-writable binary, Office/browser descendant, or unexpected remote administration tool; lower suspicion when requester path and name match the management or deployment component that owns the value.
Does the launch and session context fit the expected WMI workflow?
Focus: process.command_line, process.parent.executable, process.parent.command_line, process.Ext.session_info.logon_type, and user.id.
Implication: escalate when WMI registry writes occur under an unexpected user, service, remote, or parent context; lower suspicion when parent chain, session type, and user scope match the same recognized management or validation workflow.
Did the payload referenced by the modified value execute?
Focus: same-host process starts after @timestamp where process.command_line matches the payload from registry.data.strings. !{investigate{"description":"","label":"Process starts matching the modified registry payload","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
Hint: empty results do not prove non-execution; quoting, environment expansion, or arguments may require manual parsing.
Implication: escalate when the payload launches after the WMI-backed registry change, especially from user-writable, share-hosted, service, shell, or script paths; keep unresolved when value data cannot be matched directly.
Did the same requester cluster additional persistence changes on this host?
Why: clustered ASEP writes separate one managed configuration change from service-plus-logon fallback persistence.
Focus: same-host registry changes by Effective_process.entity_id, or process.entity_id when the effective requester is blank, reviewing registry.path, registry.value, and registry.data.strings. !{investigate{"description":"","label":"Registry changes by the same effective requester","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"Effective_process.entity_id","queryType":"phrase","value":"{{Effective_process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
Implication: escalate when the same requester changes multiple ASEPs, service values, shell values, or policy scripts in one timeline; lower suspicion when activity is limited to one exact value with data matching the recognized workflow.
If local evidence remains suspicious or unresolved, does the requester or host recur in recent alerts?
Focus: recent alerts for Effective_process.executable. !{investigate{"description":"","label":"Alerts involving the same effective requester path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"Effective_process.executable","queryType":"phrase","value":"{{Effective_process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
Hint: run the host alert view only after the registry target, requester, session, or same-host registry cluster remains suspicious or unresolved. !{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 requester path or host shows repeated WMI abuse, persistence changes, or related execution alerts; keep local when recurrence is absent and local evidence supports a recognized workflow.
Escalate for unrecognized or blank requester with suspicious value data, unexpected remote/service context, clustered ASEP changes, execution, or alert recurrence; close only when modified ASEP, value data, requester, process/session context, cluster, and recurrence evidence bind one recognized management or test workflow with no contradictory registry data; preserve evidence and escalate if mixed or incomplete.

False positive analysis

Configuration managers, endpoint-management agents, installers, and hardening baselines can use StdRegProv to set Run keys, policy scripts, or service values. Confirm Effective_process.executable, Effective_process.name, parent context, registry path/value/data, and host or user scope converge on the same workflow. Use change records, owner confirmation, or tool inventory when available; otherwise require the same requester path, modified ASEP, and registry data pattern to recur across prior alerts from this rule on the same managed host cohort.
Authorized security testing or detection validation can write persistence values through StdRegProv. Confirm the expected requester, exact value, value data, parsed payload path, test scope, and engagement records when available. Without records, require recurrence only on known test assets and no appearance on unrelated production hosts. Do not exception on process.name, "WmiPrvSe.exe", or a broad ASEP family alone.

Response and remediation

If confirmed benign:
Reverse temporary containment and document the requester identity, exact registry value and data, host or user scope, and the recurrence or records that proved the management or test workflow. Build exceptions from that minimum pattern, not from "WmiPrvSe.exe", process.name, or a broad registry key alone.
If suspicious but unconfirmed:
Preserve the alert event, exact registry value and data, effective requester identifiers, parsed payload path from the value data, and same-requester registry timeline before changing host state.
Apply reversible containment tied to the evidence, such as disabling the exact Run, policy, shell, or service value, blocking the requester path, or increasing monitoring on the affected host. Use host isolation only when host criticality allows it and the registry or requester evidence shows active persistence risk.
If confirmed malicious:
Isolate the host after preserving the registry evidence, requester identifiers, parsed payload paths, and same-requester registry changes that established malicious activity; contain the affected account only when process or session evidence supports account misuse.
Terminate the requester process only after recording the relevant entity or PID, then remove the malicious Run key, shell value, policy script, "ServiceDLL", or "ImagePath" change, restore the ASEP to known-good state, and remove only the payloads identified from the investigation.
Review other hosts for the same requester path or registry pattern before deleting artifacts that may be needed for scoping.
Post-incident hardening:
Restrict unnecessary WMI and remote administration access, monitor WMI-hosted writes to high-value ASEPs, keep endpoint process and registry telemetry enabled, and document any visibility gaps surfaced during triage.

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

Rule query

edit

registry where host.os.type == "windows" and event.type == "change" and
 registry.data.strings != null and process.name : "WmiPrvSe.exe" and
 registry.path : (
                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Command Processor\\Autorun",
                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
                  "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
                  "HKLM\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*",
                  "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*",
                  "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*",
                  "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*",
                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*",
                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*",
                  "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\ServiceDLL",
                  "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\ImagePath",
                  "HKEY_USERS\\*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*",
                  "HKEY_USERS\\*\\Environment\\UserInitMprLogonScript",
                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load",
                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell",
                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Shell",
                  "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logoff\\Script",
                  "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logon\\Script",
                  "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Shutdown\\Script",
                  "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Startup\\Script",
                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Ctf\\LangBarAddin\\*\\FilePath",
                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Exec",
                  "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Script",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Command Processor\\Autorun",
                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
                  "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
                  "\\REGISTRY\\MACHINE\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*",
                  "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*",
                  "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*",
                  "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*",
                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*",
                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*",
                  "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Services\\*\\ServiceDLL",
                  "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Services\\*\\ImagePath",
                  "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*",
                  "\\REGISTRY\\USER\\*\\Environment\\UserInitMprLogonScript",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Shell",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logoff\\Script",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logon\\Script",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Shutdown\\Script",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Startup\\Script",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Ctf\\LangBarAddin\\*\\FilePath",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Exec",
                  "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Script"
                  )

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Persistence
- ID: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
Technique:
- Name: Create or Modify System Process
- ID: T1543
- Reference URL: https://attack.mitre.org/techniques/T1543/
Sub-technique:
- Name: Windows Service
- ID: T1543.003
- Reference URL: https://attack.mitre.org/techniques/T1543/003/
Technique:
- Name: Boot or Logon Autostart Execution
- ID: T1547
- Reference URL: https://attack.mitre.org/techniques/T1547/
Sub-technique:
- Name: Registry Run Keys / Startup Folder
- ID: T1547.001
- Reference URL: https://attack.mitre.org/techniques/T1547/001/
Sub-technique:
- Name: Winlogon Helper DLL
- ID: T1547.004
- Reference URL: https://attack.mitre.org/techniques/T1547/004/
Tactic:
- Name: Execution
- ID: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: Windows Management Instrumentation
- ID: T1047
- Reference URL: https://attack.mitre.org/techniques/T1047/

« Persistence via Update Orchestrator Service Hijack Web Shell Detection: Script Process Child of Common Web Processes »