Potential Privilege Escalation via InstallerFileTakeOver

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

Potential Privilege Escalation via InstallerFileTakeOver

Identifies a potential exploitation of InstallerTakeOver (CVE-2021-41379) default PoC execution. Successful exploitation allows an unprivileged user to escalate privileges to SYSTEM.

Rule type: eql

Rule indices:

logs-endpoint.events.process-*

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:

https://github.com/klinix5/InstallerFileTakeOver

Tags:

Domain: Endpoint
OS: Windows
Use Case: Threat Detection
Tactic: Privilege Escalation
Resources: Investigation Guide
Use Case: Vulnerability
Data Source: Elastic Defend

Version: 116

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Privilege Escalation via InstallerFileTakeOver

Possible investigation steps

Which alert path fired: a suspect service binary or a service-spawned child?
Focus: alert-local process.name, process.executable, process.command_line, process.parent.executable, and process.Ext.token.integrity_level_name.
Implication: escalate when SYSTEM "elevation_service.exe" runs outside "%ProgramFiles% or %ProgramFiles(x86)%\Microsoft\Edge\Application
Implication: escalate when SYSTEM "elevation_service.exe" runs outside "%ProgramFiles% or %ProgramFiles(x86)%\Microsoft\Edge\Application\<version>\elevation_service.exe" or starts "cmd.exe", "powershell.exe", or "rundll32.exe"; lower suspicion only for a genuine Edge service start with no shell child.
lt;version>\elevation_service.exe" or starts "cmd.exe", "powershell.exe", or "rundll32.exe"; lower suspicion only for a genuine Edge service start with no shell child.
Is the elevation service binary genuine Microsoft content?
Focus: compare service process.executable, process.pe.original_file_name, process.hash.sha256, process.code_signature.subject_name, and process.code_signature.trusted; for child alerts, recover the parent service start on host.id with process.parent.entity_id and compare those fields there.
Hint: if a child alert lacks parent hash or signer details, recover the parent service process start with entity or PID fallback. !{investigate{"description":"","label":"Parent elevation service process start","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"}],[{"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.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
Implication: escalate when original filename is not "elevation_service.exe", signer is not Microsoft, trust fails, or the same hash appears from a user-writable path; lower suspicion only when path, filename, signer, trust, and hash history fit the expected Microsoft Edge service.
Does lineage show Windows Installer takeover rather than normal Edge servicing?
Focus: process.parent.executable, process.parent.command_line, process.parent.code_signature.subject_name, process.parent.code_signature.trusted, and broader process lineage when needed.
Implication: escalate when an MSI, temp, or user-session chain leads to the SYSTEM service or shell; lower suspicion when Microsoft-signed Edge installer or updater lineage starts the genuine service with servicing arguments and no shell.
Do recovered file events show service overwrite or PoC staging artifacts?
Focus: if file telemetry exists, open host-scoped file events, then filter to the recovered service or child process.entity_id; if entity IDs are absent, use host.id plus service process.pid or process.parent.pid and the alert window. Review file.path, file.Ext.original.path, and writing process.executable. !{investigate{"description":"","label":"File events on this host near the alert","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
Range: start 30 minutes before the alert because MSI administrative-install staging can precede service execution.
Implication: escalate when the Edge service path is overwritten or PoC artifacts such as the "microsoft plz" temp folder, temp MSI, or "elevation_service.exe" file creation cluster around the alert; treat those names as corroborators, not required evidence. Missing file telemetry is unresolved, not benign.
Hint: modified variants may omit PoC names; keep this centered on service replacement and MSI staging when names differ.
What did the SYSTEM service or spawned child do next?
Focus: descendant process starts on the same host.id from process.entity_id or process.parent.entity_id, especially process.name, process.command_line, and process.Ext.token.integrity_level_name. !{investigate{"description":"","label":"Child process starts from the alert process","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.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"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
Implication: escalate when SYSTEM context launches credential-access, persistence, payload staging, or remote-execution tooling; keep scope near the privilege-escalation event only when the service or shell produces no follow-on SYSTEM activity.
If local findings remain suspicious or unresolved, do related alerts show broader exploitation?
Focus: related alerts for the same host.id in the last 48 hours, especially service tampering, suspicious MSI, credential access, or follow-on execution. !{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"}}
Hint: compare user.id only when it identifies a non-SYSTEM actor; otherwise keep broadened review host-scoped and use lineage to avoid over-attributing the operator. !{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"}}
Implication: broaden response when the same host or user shows privilege-escalation or post-exploitation alerts; quiet related-alert review does not close unresolved local evidence.
Escalate on identity mismatch, MSI/user lineage, service overwrite, SYSTEM shell, or follow-on activity; close only when all evidence fits genuine Microsoft Edge service identity with no shell behavior or verified validation/detonation; preserve artifacts and escalate when evidence is mixed or telemetry is missing.

False positive analysis

Authorized exploit validation, red-team work, detection-content testing, malware research, or incident-response detonation can trigger this rule on lab or disposable analysis hosts. Confirm process.hash.sha256, service process.executable, parent process.parent.executable, child process.command_line, recovered temp-artifact pattern, and bounded host.id cohort match the same test kit or analysis-host cohort. If change, test, or sandbox records are unavailable, require the same telemetry pattern across prior alerts from this rule before closing as benign.
Before creating an exception, keep process.hash.sha256, process.executable, process.parent.executable, child process.command_line, host.id, and the recovered temp-artifact pattern stable across prior alerts from this rule. Avoid exceptions on process.name, process.parent.name, or "elevation_service.exe" alone because those values overlap real service abuse.

Response and remediation

If confirmed benign, reverse temporary containment and record the validation or analysis workflow that matched the alert, including the stable process.hash.sha256, service process.executable, parent process.parent.executable, child process.command_line, recovered artifact pattern, and bounded host.id cohort. Create an exception only after the same pattern recurs across prior alerts from this rule.
If suspicious but unconfirmed, preserve the case export, process tree with service and child entity IDs, service binary and hash identity, spawned-shell command line, and recovered service-overwrite or temp-artifact timeline before containment or cleanup. Apply reversible containment first, such as heightened monitoring or host isolation when the asset role permits it; terminate the spawned shell only after capture, and escalate to isolation if follow-on SYSTEM activity or spread appears.
If confirmed malicious, use the preserved identity, lineage, artifact, and follow-on evidence to isolate the endpoint or escalate to the team that can contain it. Before replacing or deleting files, collect the overwritten service binary, temp MSI or recovered PoC artifacts, and spawned-shell timeline. Review related hosts and users for the same hash or service-path pattern, then restore the genuine Edge elevation service binary and remove only attacker payloads, persistence, or configuration changes identified during scoping.
Post-incident hardening: verify Windows Installer and Edge components are patched, restrict unnecessary MSI administrative-install paths where possible, retain process and file telemetry long enough to reconstruct service replacement, and record the service-path, temp-artifact, and child-shell pattern for future response.

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

process where host.os.type == "windows" and event.type == "start" and
    process.Ext.token.integrity_level_name : "System" and
    (
      (process.name : "elevation_service.exe" and
       not process.pe.original_file_name == "elevation_service.exe") or

      (process.name : "elevation_service.exe" and
       not process.code_signature.trusted == true) or

      (process.parent.name : "elevation_service.exe" and
       process.name : ("rundll32.exe", "cmd.exe", "powershell.exe"))
    ) and
    not
    (
      process.name : "elevation_service.exe" and process.code_signature.trusted == true and
      process.pe.original_file_name == null
    )

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
Technique:
- Name: Exploitation for Privilege Escalation
- ID: T1068
- Reference URL: https://attack.mitre.org/techniques/T1068/
Technique:
- Name: Hijack Execution Flow
- ID: T1574
- Reference URL: https://attack.mitre.org/techniques/T1574/
Tactic:
- Name: Defense Evasion
- ID: TA0005
- Reference URL: https://attack.mitre.org/tactics/TA0005/
Technique:
- Name: Masquerading
- ID: T1036
- Reference URL: https://attack.mitre.org/techniques/T1036/
Sub-technique:
- Name: Match Legitimate Resource Name or Location
- ID: T1036.005
- Reference URL: https://attack.mitre.org/techniques/T1036/005/

« Group Policy Abuse for Privilege Addition Service Creation via Local Kerberos Authentication »