Suspicious Managed Code Hosting Process

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

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*

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:

http://web.archive.org/web/20230329154538/https://blog.menasec.net/2019/07/interesting-difr-traces-of-net-clr.html

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

Investigation guide

edit

Triage and analysis

Investigating Suspicious Managed Code Hosting Process

Possible investigation steps

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{"description":"","label":"Process events for the same 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.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
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{"description":"","label":"Process events for the same PID","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.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
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{"description":"","label":"File events for the same UsageLog path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}}
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{"description":"","label":"File events for the same process or PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Child process events for the managed 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"},{"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"}}
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{"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"}}
Hint: same-host alert view: !{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"}}
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.

False positive analysis

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.

Response and remediation

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.

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

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^TM

Tactic:
- Name: Defense Evasion
- ID: TA0005
- Reference URL: https://attack.mitre.org/tactics/TA0005/
Technique:
- Name: Process Injection
- ID: T1055
- Reference URL: https://attack.mitre.org/techniques/T1055/
Technique:
- Name: System Binary Proxy Execution
- ID: T1218
- Reference URL: https://attack.mitre.org/techniques/T1218/
Sub-technique:
- Name: CMSTP
- ID: T1218.003
- Reference URL: https://attack.mitre.org/techniques/T1218/003/
Sub-technique:
- Name: Mshta
- ID: T1218.005
- Reference URL: https://attack.mitre.org/techniques/T1218/005/
Sub-technique:
- Name: Regsvr32
- ID: T1218.010
- Reference URL: https://attack.mitre.org/techniques/T1218/010/
Technique:
- Name: Reflective Code Loading
- ID: T1620
- Reference URL: https://attack.mitre.org/techniques/T1620/
Tactic:
- Name: Execution
- ID: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: Windows Management Instrumentation
- ID: T1047
- Reference URL: https://attack.mitre.org/techniques/T1047/

« Suspicious Execution from a Mounted Device Suspicious Process Access via Direct System Call »