« IIS HTTP Logging Disabled Command Execution via ForFiles »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Proxy Execution via Console Window Host

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

Proxy Execution via Console Window Host

edit

Identifies abuse of the Console Window Host (conhost.exe) to execute commands via proxy. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software.

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: Defense Evasion
  • 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: 4

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Proxy Execution via Console Window Host

Possible investigation steps

  • What command did the headless conhost instance proxy?
  • Why: --headless can hide the child window behind conhost, so command intent and child-process evidence outweigh conhost identity alone.
  • Focus: process.command_line for --headless and the proxied family: shell, script host, retrieval, UNC, caret-escaped, batch, or scheduled-task action.
  • Implication: escalate when headless conhost proxies script execution, remote retrieval, scheduled-task changes, or lateral-path commands; lower suspicion only when command, launcher, user, and host match remote-admin console management, deployment automation, or installer/update helper use and later process evidence does not contradict it.
  • Is this the native conhost binary or a masqueraded copy?
  • Focus: process.executable, process.pe.original_file_name, process.hash.sha256, process.code_signature.subject_name, and process.code_signature.trusted; compare the path with C:\Windows\System32\conhost.exe.
  • Implication: escalate when conhost is renamed, unsigned, user-writable, host-new by hash, or signed by an unexpected publisher; native signed identity lowers masquerade concern but not suspicious --headless proxy execution.
  • Which launcher produced headless conhost?
  • Focus: process.parent.executable, process.parent.command_line, and process.parent.entity_id.
  • Implication: escalate when the launcher is Office, a browser, a script host, a temp or user-writable binary, another LOLBin, or a remote-management tool outside its console-management pattern; lower suspicion when the same parent is a stable console, deployment, or update path for the same user.id and host.id.
  • Do the user and session context fit the same admin or deployment use?
  • Focus: user.id, host.id, process.Ext.session_info.logon_type, and process.Ext.authentication_id.
  • Implication: escalate when session type, account, or authentication ID is unusual for that host.id and user cohort or ties to unrelated suspicious processes; lower suspicion when user, host cohort, session type, command, and lineage match the same remote-admin, deployment, or update use.
  • Did headless conhost spawn the command family named in the alert?
  • Focus: child process starts on host.id where process.parent.entity_id matches alert process.entity_id; read process.name, process.executable, and process.command_line. !{investigate{"description":"","label":"Child process starts from the same conhost instance","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"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: if process.entity_id is absent, query the same host.id with alert process.pid in a tight alert-time window; treat matches as weaker because PID reuse is possible.
  • Implication: escalate when conhost spawns shell, script-host, downloader, scheduled-task, or payload-like children; keep scope local only when no child execution appears and earlier evidence fits the same named admin, deployment, or update use.
  • If local evidence is suspicious or unresolved, is this isolated or broader proxy execution?
  • Focus: process-start history for the same host.id and, if needed, user.id; compare process.command_line, process.parent.executable, and child-process patterns.
  • !{investigate{"description":"","label":"Process history on the same host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • !{investigate{"description":"","label":"Process history for the same user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: review related alerts for the same host.id and user.id, especially script execution, downloader, scheduled-task, credential-tool, or other proxy-execution activity.
  • !{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"}}
  • !{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: escalate scope when the same host or user shows repeated headless conhost proxy execution, suspicious launchers, or related script, downloader, scheduled-task, or credential-tool processes; lack of history does not clear suspicious command, lineage, session, or child-process evidence.
  • Escalate on unauthorized headless proxy execution plus suspicious identity, launcher, session, child-process, or repeat-alert corroboration; close only when command, identity, lineage, session, and child-process evidence bind to one named benign use case below; preserve evidence and escalate when evidence is mixed or incomplete.

False positive analysis

  • Remote-administration, console-management, deployment automation, installer, or update agents can launch headless conhost when a named tool uses console helpers. Confirm that native process.executable, stable process.parent.executable, process.parent.code_signature.subject_name, process.parent.code_signature.trusted, parent and child process.command_line, user.id, host.id, process.Ext.session_info.logon_type, and child-process pattern all align with that tool or product path. Tool inventories, change records, or owner confirmation can corroborate telemetry-backed use, but should not replace missing or contradictory process evidence. If command, parent, session, or child evidence diverges, or the first cohort event includes retrieval, UNC, script-host, or scheduled-task behavior outside that path, treat it as unresolved or suspicious.
  • Before creating an exception, verify that native process.executable, parent identity, exact process.command_line, user.id, host.id, and session type recur across prior alerts from this rule. Build the exception from that confirmed workflow pattern; avoid exceptions on process.name, the conhost filename, or --headless alone.

Response and remediation

  • If confirmed benign, reverse temporary containment and record the command intent, native conhost identity, parent lineage, user.id, host.id, session type, and child-process evidence that justified closure. Create an exception only when that same admin, deployment, or update pattern recurs consistently across prior alerts.
  • If suspicious but unconfirmed, preserve the alert, process tree export, command lines, hash and signer details, process.entity_id, process.parent.entity_id, process.Ext.authentication_id, child-process events, and any scripts or task definitions named in the command line before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on the affected user.id, host.id, or parent tool, and avoid process termination until scope is clearer.
  • If confirmed malicious, contain the host or affected account when command intent, launcher lineage, session context, or child-process evidence establishes unauthorized proxy execution. Record the process identifiers, command lines, signer and hash evidence, user and host anchors, and child-process chain before terminating processes, deleting scripts, disabling scheduled tasks, or isolating accounts.
  • Eradicate only the scripts, task definitions, copied tools, or persistence mechanisms identified during the investigation, then remediate the launcher, automation path, or access path that allowed headless conhost to proxy the command.
  • Rotate credentials only when the user and session evidence or adjacent case evidence confirms account misuse, remote abuse, or privileged account compromise; otherwise keep identity action proportional to the confirmed process evidence.
  • After containment, scope other hosts and users for the same process.command_line, process.parent.executable, process.hash.sha256, parent signer, or child-process pattern. Retain the process telemetry and response notes needed to distinguish repeat benign console automation from repeat proxy 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.name : "conhost.exe" and process.args : "--headless" and
  process.command_line : (
    "*powershell*", "*cmd *", "*cmd.exe *", "*script*", "*mshta*", "*curl *", "*curl.exe *", "*^*^*^*",
    "*.bat*", "*.cmd*", "*schtasks*", "*@SSL*", "*http*", "* \\\\*", "*.vbs*", "*.js*", "*mhsta*"
  ) and
  not (
    /* Winget-AutoUpdate via ServiceUI */
    process.parent.executable : "?:\\Program Files\\winget-autoupdate*\\serviceui.exe" or
    /* Winget-AutoUpdate notification via Task Scheduler */
    (
      process.parent.executable : "?:\\Windows\\System32\\svchost.exe" and process.parent.args : "-s" and
      process.parent.args : "Schedule" and process.command_line : "*WAU-Notify.ps1*"
    ) or
    /* Windows OpenSSH console host — SSH-specific detection handled by 8cd49fbc-a35a-4418-8688-133cc3a1e548 */
    process.parent.executable : (
      "?:\\Windows\\System32\\OpenSSH\\sshd.exe",
      "?:\\Windows\\System32\\OpenSSH\\sshd-session.exe",
      "?:\\Program Files\\OpenSSH*\\sshd.exe",
      "?:\\Program Files\\OpenSSH*\\sshd-session.exe"
    )
  )

Framework: MITRE ATT&CKTM

« IIS HTTP Logging Disabled Command Execution via ForFiles »