Loading

Bypass UAC via Event Viewer

Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass UAC to stealthily execute code with elevated permissions.

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-*

Rule Severity: high
Risk Score: 73
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

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

Version: 323
Rule authors:

  • Elastic

Rule license: Elastic License v2

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

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

  • What did Event Viewer launch in the alert?

    • Focus: alert time, host/user scope, process.parent.executable, process.executable, process.command_line, and integrity level.
    • Implication: escalate when eventvwr.exe launches an unexpected high-integrity child or script/LOLBIN command instead of the normal console or error-reporting helper; lower suspicion only when path normalization proves helper behavior or fields match controlled UAC testing.

  • Does the child payload identity and command line fit helper behavior or payload execution?

    • Focus: process.executable, process.hash.sha256, process.code_signature.subject_name, process.code_signature.trusted, and process.command_line.
    • Hint: use process.pe.original_file_name when path, filename, or signer conflicts suggest masquerading.
    • Implication: escalate when the child is unsigned, rare, user-writable, signer-mismatched, or runs PowerShell, cmd.exe, rundll32.exe, mshta.exe, wscript.exe, regsvr32.exe, remote retrieval, encoded content, or admin-path writes; lower suspicion only when identity, signer, hash history, and command intent fit controlled testing or helper behavior.

  • What started Event Viewer, and did the session fit an interactive admin task?

    • Focus: recover the Event Viewer start using host.id + process.parent.entity_id, then review executable, command line, and logon type. $investigate_0
    • Hint: if process.parent.entity_id is absent, use host.id + process.parent.pid in a tight @timestamp window; PID-only recovery is weaker. Inspect process.Ext.ancestry only when direct lineage is incomplete.
    • Implication: escalate when Office, browser, archive, scripting, RMM, or remote/noninteractive activity launched Event Viewer; lower suspicion only when launcher and session also support controlled testing or helper behavior. Routine Event Viewer use should open Microsoft Management Console, not an arbitrary child.

  • Is there corroborating current-user mscfile hijack evidence when process evidence stays suspicious?

    • Focus: if registry telemetry exists, review current-user mscfile shell-open command content, creator/deleter process, and timing; HKCU may render as HKEY_USERS<user SID>\Software\Classes\mscfile\shell\open\command.
    • Hint: use this as corroboration, not as a prerequisite for escalation. Missing registry telemetry is unresolved, not benign; absence of the key after the alert can mean cleanup.
    • Implication: escalate or raise confidence when the value points to the alert child, a script interpreter, a temp/user path, or was created or removed around the alert; lower suspicion only when artifact evidence fits the same confirmed test or helper behavior already supported by process evidence.

  • What did the elevated child do next?

    • Focus: child process events where process.parent.entity_id matches process.entity_id; review executable, command line, and integrity level. $investigate_1
    • Hint: prefer entity-ID matches; if only PID matches are available, keep them tightly anchored to @timestamp.
    • Implication: escalate when the elevated child spawns shells, discovery, credential tools, droppers, installers, persistence helpers, or network-capable tooling; do not close on absent follow-on children when the original command, lineage, or mscfile evidence remains suspicious.

  • Does the same Event Viewer payload pattern recur beyond this host?

    • Range: run only when local process, command, artifact, or lineage evidence remains suspicious or unresolved.
    • Focus: process.hash.sha256, stable command-line fragments, and process.executable, scoped by host and user.
      • $investigate_2
      • $investigate_3
    • Implication: broaden when the same payload or Event Viewer child pattern appears for unrelated hosts or users; keep locally scoped when recurrence is limited to the same confirmed test cohort and no contradictory local evidence remains.

  • Based on the evidence gathered, what disposition is supported?

    • Escalate on strong local abuse signals across child behavior, payload identity, command intent, launcher/session, mscfile artifacts, follow-on children, or scope; close only when process evidence and recovery prove helper normalization or controlled testing; preserve evidence and escalate when registry corroboration is unavailable or evidence is mixed.
  • This behavior is an operational anti-pattern. Realistic benign paths are controlled UAC testing or a sensor/path-normalization miss for expected Microsoft Management Console (mmc.exe) or Windows Error Reporting (WerFault.exe) child activity. Confirm identity, launcher/session context, command line, and any recovered mscfile artifact support the same benign explanation; if any dimension contradicts it, do not close as benign.
  • Build exceptions from the minimum confirmed pattern: stable child hash or signer, exact Event Viewer parent-child relationship, bounded user.id and host.id, and test or normalization evidence. Avoid exceptions on process.parent.name, process.name, or user.name alone.
  • If confirmed benign, document the exact evidence that resolved the alert, reverse temporary containment, and keep any exception scoped to the confirmed child identity, parent-child pattern, and host/user cohort.
  • If suspicious but unconfirmed, preserve the alert, process event exports, Event Viewer parent and child entity IDs, command lines, hashes/signers, recovered mscfile value/history, child process tree, and process-scoped file or network indicators when available.
  • After preservation, apply reversible containment tied to the findings, such as endpoint isolation for non-critical hosts or temporary egress restrictions for confirmed suspicious destinations. Weigh host criticality before isolation.
  • If confirmed malicious, preserve the confirmed hashes/domains/destinations and elevated child process details, then isolate the host as needed, block confirmed malicious indicators, and suspend or terminate malicious processes only after recording their evidence.
  • Eradicate only the artifacts found during triage: remove malicious payloads, restore the current-user mscfile handler to the expected mmc.exe behavior or remove the malicious override, clean related persistence, and remediate the entry vector that launched Event Viewer.
  • Reset credentials or disable accounts only when process/session evidence shows credential exposure, explicit misuse, or attacker use of the affected user.id.
  • After eradication, reduce repeat exposure by reviewing local administrator membership, using the highest feasible UAC prompt level, and patching affected Windows builds.
process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : "eventvwr.exe" and
  not process.executable : (
        "?:\\Windows\\SysWOW64\\mmc.exe",
        "?:\\Windows\\System32\\mmc.exe",
        "?:\\Windows\\SysWOW64\\WerFault.exe",
        "?:\\Windows\\System32\\WerFault.exe",

        /* Crowdstrike specific exclusion as it uses NT Object paths */
        "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\mmc.exe",
        "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\WerFault.exe"
  )

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK