« Interactive Logon by an Unusual Process Privilege Escalation via Named Pipe Impersonation »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.24

Potential Escalation via Vulnerable MSI Repair

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

Potential Escalation via Vulnerable MSI Repair

edit

Identifies when a browser process navigates to the Microsoft Help page followed by spawning an elevated process. This may indicate a successful exploitation for privilege escalation abusing a vulnerable Windows Installer repair setup.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • endgame-*
  • logs-endpoint.events.process-*
  • logs-windows.sysmon_operational-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-m365_defender.event-*

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: Privilege Escalation
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Microsoft Defender XDR
  • Resources: Investigation Guide

Version: 207

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Escalation via Vulnerable MSI Repair

Possible investigation steps

  • What did the elevated browser parent launch?
  • Why: MSI repair abuse can expose a SYSTEM browser through a help-link redirect; a non-browser child marks the privilege-escalation boundary.
  • Focus: process.parent.command_line, process.name, process.executable, process.command_line, and process.Ext.token.integrity_level_name.
  • Implication: escalate when a Microsoft Help-tied browser launches a SYSTEM or high-integrity shell, script host, installer, admin utility, file manager, or user-writable binary; lower concern only when the command line shows a browser-internal role, path and signer match the parent browser family, and no non-browser child appears in the alert window.
  • Does the lineage fit an MSI repair-to-help-link path?
  • Focus: process.parent.entity_id, process.parent.pid, surrounding process.name, and process.command_line.
  • Implication: escalate when ancestry or surrounding starts show MSI repair, installer custom actions, console activity, or an unexpected SYSTEM browser before the child; lower concern when the chain stays inside browser self-maintenance without repair, console, or custom-action ancestry.
  • Hint: recover the parent browser event first. If parentage is incomplete, inspect process.Ext.ancestry; if entity IDs are absent, use host.id, process.parent.pid, and a tight alert window. !{investigate{"description":"","label":"SYSTEM browser parent process event","providers":[[{"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.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Is the child process identity expected for the host and signer?
  • Focus: process.executable, process.pe.original_file_name, process.code_signature.subject_name, process.code_signature.trusted, and process.Ext.relative_file_creation_time.
  • Implication: escalate when the child runs from a user-writable or temporary path, has a mismatched original file name, lacks a trusted signer, or was recently created; lower concern only when signer, path, age, and browser parent context all fit the same recognized component.
  • What follow-on process activity came from the same SYSTEM browser or spawned child?
  • Focus: same-host starts from the browser process.parent.entity_id or child process.entity_id: process.name, process.command_line, and process.Ext.token.integrity_level_name.
  • Implication: escalate when the browser or child launches shells, scripts, persistence or administration tools, additional installers, or chained SYSTEM processes; keep scope local when activity stops at browser helpers with no privileged child chain.
  • Hint: prefer host.id plus parent or child process.entity_id; use host.id, process.pid, and a tight window only when entity IDs are absent.
  • !{investigate{"description":"","label":"Process starts from the SYSTEM browser parent","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.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • !{investigate{"description":"","label":"Process starts from the launched child","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.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}}
  • Does the user and session context support interactive exploitation?
  • Focus: user.id, user.name, user.domain, process.Ext.authentication_id, and process.Ext.session_info.logon_type.
  • Implication: escalate when a low-privileged or unexpected interactive session is tied to the SYSTEM browser-to-child chain; a pre-existing user browser usually breaks the SYSTEM child path, so a SYSTEM or high-integrity child tied to an interactive session is severity-changing. Lower concern only when process evidence maps to controlled repair validation or browser-helper behavior.
  • Does process telemetry show the same SYSTEM-browser-to-tool pattern beyond this process instance?
  • Focus: same process.parent.command_line redirect fragment, suspicious process.name or process.executable, user.id, and host.id across recent starts.
  • Implication: broaden when recent starts show the same non-browser child pattern across unrelated hosts or users; keep response scoped when telemetry shows only this browser parent, child command line, and no repeated non-browser descendants.
  • Hint: run this pivot only if child intent, lineage, or session context remains suspicious or unresolved. !{investigate{"description":"","label":"Recent process starts with the same child executable","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":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Based on the evidence gathered, what disposition is supported?
  • Escalate on SYSTEM or high-integrity browser-to-tool execution, MSI repair lineage, suspicious child identity, interactive session linkage, or repeated scope; close only for same-browser helper behavior with no non-browser descendants or an authorized test whose process facts exactly match scope. Preserve evidence and escalate when child intent, lineage, or session context is mixed or incomplete.

False positive analysis

  • Browser helper, renderer, GPU, updater, or crash subprocesses can trigger after a SYSTEM browser opens a Microsoft Help link. Confirm a browser-internal role, same browser family, installed-browser path and signer, and no shell, installer, file manager, or admin tool from the same parent.
  • Authorized MSI repair security validation is benign only when @timestamp, host.id, user.id, the SYSTEM browser parent command line, and child command line match the exact exercise; outside records may corroborate but not replace process facts.
  • Build exceptions from the minimum confirmed workflow: browser family and signer, exact redirect parent context, expected child executable or command pattern, host.id, and tightly scoped test or managed-repair cohort. Avoid exceptions on user.domain, browser name, or redirect URL alone.

Response and remediation

  • If confirmed benign, document the process evidence that proved the browser-helper or validation workflow, reverse any temporary containment, and create only the narrow exception described above if the same workflow recurs.
  • If suspicious but unconfirmed, preserve the alert and Timeline/export records for the browser parent, child, ancestor chain, host, and user. Record command lines, process.entity_id, process.parent.entity_id, host.id, user.id, and any visible MSI package or vulnerable-application names before containment or process termination.
  • Apply reversible containment first when findings remain suspicious: isolate the host if its business role allows, or restrict the affected account/session while preserving endpoint telemetry. Do not terminate the child process until its command line, parentage, and spawned descendants are recorded.
  • If confirmed malicious, contain the host and affected account based on the process lineage and session evidence, then terminate the malicious child and descendants after recording their identifiers. Remove only the payloads, repair artifacts, or configuration changes identified during the investigation.
  • Patch Windows Installer and the vulnerable application package involved in the repair path, verify that the affected OS has the relevant vendor security update for CVE-2024-38014, and repackage or disable repair flows that let low-privileged users reach elevated custom actions, console windows, or help-link execution.
  • Document the final evidence set, repair path, affected hosts, and any missing telemetry that limited certainty so future alerts can distinguish browser helper noise, authorized validation, and repeated exploitation.

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 event.type == "start" and host.os.type == "windows" and
 user.domain : ("NT AUTHORITY", "AUTORITE NT", "AUTORIDADE NT") and
 process.parent.name : ("chrome.exe", "msedge.exe", "brave.exe", "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe",
                        "opera.exe", "iexplore", "firefox.exe", "waterfox.exe", "iexplore.exe", "tor.exe", "safari.exe") and
 process.parent.command_line : "*go.microsoft.com*"

Framework: MITRE ATT&CKTM

« Interactive Logon by an Unusual Process Privilege Escalation via Named Pipe Impersonation »