Loading

Suspicious Managed Code Hosting Process

Identifies a suspicious managed code hosting process which could indicate code injection or other form of suspicious code execution.

Rule type: eql
Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.file-*
  • logs-windows.sysmon_operational-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • endgame-*
  • logs-crowdstrike.fdr*

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

Version: 315
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 CLR UsageLog behavior did the alert preserve?
    • Focus: file.path, file.name, event.type, and acting process.name / process.executable.
    • Implication: escalate when the UsageLog host has no stable process/user pattern; lower suspicion only as an initial read when the same path and process recur for the same product, deployment, login-script, COM, or service-host context.
  • Is the managed host the genuine Windows binary rather than a lookalike?
    • Focus: same-process start evidence for host.id and process.entity_id: process.executable, hash, original file name, signer, and trust. $investigate_0
    • Hint: if a source lacks process.entity_id, fall back to process.pid plus host.id in a tight alert-time window to avoid PID reuse. $investigate_3
    • Implication: escalate when the host binary runs from a user-writable path, has a mismatched original file name, or has an unexpected signer; lower suspicion only when identity, signer, path, and the UsageLog host name all point to the same genuine Windows host.
  • Does the launch chain explain why this host loaded managed code?
    • Focus: process.command_line, parent executable/command line, user.id, and session context.
    • Implication: escalate when Office, browsers, archive tools, remote sessions, or user-writable scripts drive mshta, wscript, cscript, wmic, regsvr32, or cmstp; lower suspicion when the same command line, parent, user, and session match a recognized installer, scheduled task, management agent, COM component, or login script.
  • Does this UsageLog path recur with the same process and user pattern?
    • Focus: historical file and process events for the same host.id, comparing file.path, event.type, process/parent executable, and user.id. $investigate_4
    • Implication: escalate when a first create, new process.executable, new parent, new user, or unusual update appears for a process that normally should not host managed code; lower suspicion when prior events show the same path, process identity, parent, and user with no follow-on artifacts.
  • Does the UsageLog artifact or same-process activity expose payload staging?
    • Why: HTA/JS managed-code hosting and repeat UsageLog updates can hide intent in process text, so preserve the UsageLog while using same-process file/process telemetry for the decision.
    • Focus: preserve file.path, then query file and process events for the same host.id and process.entity_id, comparing name, extension, size, and later process.executable reuse of written paths. $investigate_5 $investigate_6
    • Hint: if only process.pid is available, keep the file/process correlation tightly scoped to the alert time and host; empty or multiple PID matches are unresolved, not benign.
    • Implication: escalate when the process writes scriptable or executable content to user-writable paths, creates unusual payload-sized files, or later executes a written artifact; lower suspicion when artifacts stay inside the same recognized product or deployment path with no follow-on execution.
  • If local evidence remains suspicious or unresolved, does the same user or host show related managed-host abuse?
    • Focus: related alerts for user.id and host.id: repeated UsageLog paths, script-host execution, payload staging, injection, or persistence.
    • Hint: same-user alert view: $investigate_1
    • Hint: same-host alert view: $investigate_2
    • Implication: broaden scope only when UsageLog, identity, launch, recurrence, or artifact evidence remains suspicious or incomplete; keep local when the alert is isolated and all supported evidence resolves to one recognized workflow.
  • Escalate for unauthorized managed-code execution through a script host or LOLBin; close only when UsageLog, identity, launch, recurrence, artifact, and related-alert evidence bind to one recognized workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete.
  • Packaging, deployment, login-script, management-agent, product, COM, and service-hosted workflows can legitimately update CLR UsageLogs for wscript.exe, cscript.exe, mshta.exe, wmic.exe, cmstp.exe, svchost.exe, dllhost.exe, or regsvr32.exe. Confirm file.path, process identity, signer or hash history, parent or service/COM launch context, user/session context, artifact behavior, and same-process file/process activity all point to one workflow. If inventories are unavailable, require stable UsageLog path, parent chain, process identity, and user-host pairing across prior alerts before closing as benign.
  • Build exceptions only from the minimum confirmed workflow pattern: file.path, process.executable, process.parent.executable, stable signer or hash, and the relevant host.id or user.id scope. Avoid exceptions on file.name, process name, or host name alone.
  • If confirmed benign, reverse any temporary containment and document the UsageLog path, process identity, launch chain, user/session context, recurrence pattern, and artifact evidence that proved the workflow. Create an exception only after the same pattern recurs consistently across prior alerts.
  • If suspicious but unconfirmed, preserve the UsageLog artifact, process start event, command line, parent chain, same-process file/process timeline, written artifacts, related alerts, and case notes before containment or cleanup.
  • If suspicious but unconfirmed, apply reversible containment tied to the findings, such as heightened monitoring or temporary isolation of the affected host.id when process/file evidence suggests payload execution. Avoid process termination or file deletion until the artifact set is preserved.
  • If confirmed malicious, isolate the endpoint when process identity, launch context, artifact behavior, or related alerts establish unauthorized managed-code execution. Before suspending or terminating the host process, record the recovered process.entity_id, command line, parent chain, UsageLog path, and staged files.
  • Scope related hosts and users for the same UsageLog path, parent process, process identity, and staged artifacts before deleting files or terminating additional processes.
  • Remove only malicious scripts, HTA/JS payloads, assemblies, staged binaries, or persistence artifacts identified during the investigation, then remediate the delivery path or launcher that caused the managed host to load CLR.
  • Post-incident hardening: restrict script-host and LOLBin execution through application control where feasible, keep endpoint file/process telemetry for CLR UsageLog triage, and document the confirmed benign workflow or malicious artifact set for future analysts.
file where host.os.type == "windows" and event.type != "deletion" and
  file.name : ("wscript.exe.log",
               "cscript.exe.log",
               "mshta.exe.log",
               "wmic.exe.log",
               "svchost.exe.log",
               "dllhost.exe.log",
               "cmstp.exe.log",
               "regsvr32.exe.log")

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK