CLR profiler environment variable set in the registry

Siemphony@siemphonymediumT1574.012unverified

Matches the registry half of AN1319: a value written to one of the CLR profiling environment variables under an `Environment` key, which is how a system-wide or user-wide COR_PROFILER is made persistent. Setting COR_ENABLE_PROFILING to 1 and pointing COR_PROFILER at a CLSID (or, from .NET Framework 4 onward, pointing COR_PROFILER_PATH straight at a DLL on disk) causes the runtime to load that unmanaged DLL into every process that starts the CLR, which is the hijack this technique performs. Only the registry-backed scopes are visible here by definition — a process-scope COR_PROFILER set in memory by the parent that spawns the target never touches the registry and leaves no matching event. The value names are anchored with `endswith` beneath `\Environment\`, which covers the two scopes where `Environment` is a registry *key* and the COR_ name is a value beneath it: the machine-wide `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment`, and the per-user `Environment` key that Sysmon writes as HKU followed by the account SID. The per-service scope is deliberately not covered and cannot be: under a Services key, `Environment` is itself a single REG_MULTI_SZ *value* whose data holds `COR_ENABLE_PROFILING=1` and friends, so `TargetObject` ends at `\Environment` with no COR_ name in it at all, and Sysmon renders multi-string data as binary rather than as readable text in `Details`. Catching that scope needs a separate rule against the value data, not another term here. MITRE names COR_ENABLE_PROFILING, COR_PROFILER and COR_PROFILER_PATH; the bitness-suffixed COR_PROFILER_PATH_32/_64 forms and the CORECLR_ equivalents that .NET Core and .NET 5+ read instead were added here, not taken from the analytic, because a modern host runs the CoreCLR names and a rule listing only the Framework ones would miss it entirely. Vocabulary, scope and prerequisites. The brief maps Security EventID 4657 onto the Sigma `registry_set` category, but that category is Sysmon-shaped: this rule is written in the Sysmon vocabulary, where `TargetObject` carries the full key-plus-value path in one field. Security 4657 splits the same information across `ObjectName` and `ObjectValueName`, so that feed needs a field mapping before this rule can match on it and enabling Audit Registry with a SACL on the Environment keys will not by itself make this rule fire. The analytic's other two halves are out of reach: correlating the registry write with the profiler DLL then loading into a .NET process, within MITRE's `TimeWindow` knob, is a Sysmon EventID 7 record and a cross-event join, and MITRE's `AllowedProfilers` and `ProfilerDllPaths` knobs would have to be applied against the `Details` field, which is left unconstrained here so a profiler DLL in any location is caught. Prerequisite: registry monitoring in a Sysmon configuration is an explicit allowlist of paths, and the Session Manager Environment key and the per-user Environment keys are not in every shipped configuration, so confirm they are in scope before reading an empty result as an absence of this technique. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0479, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceRegistryEvents| where (RegistryKey endswith "\\Environment\\COR_ENABLE_PROFILING" or RegistryKey endswith "\\Environment\\COR_PROFILER" or RegistryKey endswith "\\Environment\\COR_PROFILER_PATH" or RegistryKey endswith "\\Environment\\COR_PROFILER_PATH_32" or RegistryKey endswith "\\Environment\\COR_PROFILER_PATH_64" or RegistryKey endswith "\\Environment\\CORECLR_ENABLE_PROFILING" or RegistryKey endswith "\\Environment\\CORECLR_PROFILER" or RegistryKey endswith "\\Environment\\CORECLR_PROFILER_PATH" or RegistryKey endswith "\\Environment\\CORECLR_PROFILER_PATH_32" or RegistryKey endswith "\\Environment\\CORECLR_PROFILER_PATH_64")

Splunk · SPL

Run this as a search.

index=* (TargetObject="*\\Environment\\COR_ENABLE_PROFILING" OR TargetObject="*\\Environment\\COR_PROFILER" OR TargetObject="*\\Environment\\COR_PROFILER_PATH" OR TargetObject="*\\Environment\\COR_PROFILER_PATH_32" OR TargetObject="*\\Environment\\COR_PROFILER_PATH_64" OR TargetObject="*\\Environment\\CORECLR_ENABLE_PROFILING" OR TargetObject="*\\Environment\\CORECLR_PROFILER" OR TargetObject="*\\Environment\\CORECLR_PROFILER_PATH" OR TargetObject="*\\Environment\\CORECLR_PROFILER_PATH_32" OR TargetObject="*\\Environment\\CORECLR_PROFILER_PATH_64")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(registry.path) LIKE "*\\\\environment\\\\cor_enable_profiling" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\cor_profiler" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\cor_profiler_path" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\cor_profiler_path_32" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\cor_profiler_path_64" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\coreclr_enable_profiling" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\coreclr_profiler" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\coreclr_profiler_path" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\coreclr_profiler_path_32" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\coreclr_profiler_path_64")

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,registry_set,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetObject" type="pcre2">(?i)(\\Environment\\COR_ENABLE_PROFILING$|\\Environment\\COR_PROFILER$|\\Environment\\COR_PROFILER_PATH$|\\Environment\\COR_PROFILER_PATH_32$|\\Environment\\COR_PROFILER_PATH_64$|\\Environment\\CORECLR_ENABLE_PROFILING$|\\Environment\\CORECLR_PROFILER$|\\Environment\\CORECLR_PROFILER_PATH$|\\Environment\\CORECLR_PROFILER_PATH_32$|\\Environment\\CORECLR_PROFILER_PATH_64$)</field>    <description>CLR profiler environment variable set in the registry</description>    <mitre>      <id>T1574.012</id>    </mitre>  </rule></group>

At a glance

Logsource: registry_set / windows
Level: medium
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 29c9f303-2b12-46b8-8a26-19806545969a

ATT&CKT1574.012

T1574.012COR_PROFILER

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

A CLR profiler environment variable written into the registry under an Environment key. Setting COR_ENABLE_PROFILING to 1 and pointing COR_PROFILER at a CLSID — or, from .NET Framework 4 onward, pointing COR_PROFILER_PATH straight at a DLL — makes the runtime load that unmanaged DLL into every process that starts the CLR. Persisting those values in the registry is what turns a one-shot trick into a foothold, and that write is the registry half of AN1319. A process-scope COR_PROFILER set in memory by a parent that spawns the target never touches the registry and is invisible here by definition.

02 · Telemetry you need

Sysmon registry events under the Sigma registry_set category on Windows, taken from the brief. Note the vocabulary carefully: the brief maps Security EventID 4657 onto registry_set, but that category is Sysmon-shaped. Sysmon's TargetObject carries key and value name in one field, while 4657 splits them across ObjectName and ObjectValueName. This rule is written in the Sysmon vocabulary, so enabling Audit Registry and putting a SACL on the Environment keys will not make it fire — that feed needs a field mapping first. Sysmon registry monitoring is also an explicit path allowlist, and these keys are not in every shipped config; confirm they are in scope before reading an empty result as absence.

03 · How the logic works

A single selection, selection_profiler_env, matching TargetObject|endswith against ten strings, all of the form \Environment\<NAME>: COR_ENABLE_PROFILING, COR_PROFILER, COR_PROFILER_PATH and its _32/_64 bitness variants, then the same five with the CORECLR_ prefix. The condition is that block alone. MITRE's analytic names COR_ENABLE_PROFILING, COR_PROFILER and COR_PROFILER_PATH. The bitness-suffixed forms and the whole CORECLR_ family that .NET Core and .NET 5+ read instead were added by the pipeline, not taken from MITRE — a modern host runs the CoreCLR names, and a rule listing only the Framework ones would miss it outright. The \Environment\ anchor deliberately covers the two scopes where Environment is a registry key with the COR_ name as a value beneath it: machine-wide HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, and the per-user Environment key Sysmon renders as HKU plus the account SID. It is hive-agnostic, which is what lets one term serve both — and also means any application settings tree ending in \Environment can match. Two gaps are worth naming. The per-service scope is out of reach: under a Services key, Environment is itself one REG_MULTI_SZ value holding COR_ENABLE_PROFILING=1 as string data, so TargetObject stops at \Environment with no COR_ name in it, and Sysmon renders multi-string data as binary so Details cannot rescue it. Catching that needs a separate rule against value data. Second, the DLL is resolved through SOFTWARE\Classes\CLSID\{...}\InprocServer32; an adversary who registers the COM object locally and sets the variables by GPO leaves only that CLSID write behind, and this selection does not reach it. An empty result is not proof of no COR_PROFILER persistence.

04 · Common false positives

APM agents are the highest-volume source by a wide margin: Dynatrace OneAgent, AppDynamics, New Relic, the Datadog .NET tracer and Elastic APM all use this exact mechanism as their supported install method and set the same values machine-wide. Then developer workstations running Visual Studio's profiler, dotTrace or dotMemory under the interactive user's SID; and build agents where OpenCover or altcover set CORECLR_ENABLE_PROFILING on every pipeline run. That first entry is why level is medium rather than high.

05 · Detection maturity

tier_1: Lowest tier. Machine-derived from DET0479 and never executed against a log line, so there is no measured hit rate, no false-positive baseline and no confirmation the field vocabulary matches your feed. It stays there until run against real Sysmon registry data and tuned on what it actually returns.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Details is unconstrained on purpose, so a profiler DLL in any location is caught — and so an enable and a teardown write of 0 look identical. Apply MITRE's AllowedProfilers and ProfilerDllPaths knobs against Details with your own sanctioned CLSIDs; that is what would justify raising the level. Split machine-scope from user-scope alerting, since HKU writes are almost all developer tooling.

Declared by the author

Application performance monitoring agents, which use this exact mechanism as their supported installation method and set the same values machine-wide at install time. Dynatrace OneAgent, the AppDynamics and New Relic .NET agents, the Datadog .NET tracer and Elastic APM all do this. On an estate rolling an APM agent out, this is the highest-volume source by a wide margin — one or more matches on every server in the wave — and is why the level is medium rather than high; allowlisting the agents' CLSIDs against MITRE's AllowedProfilers knob is what would justify raising it.
Developer workstations running profiling and diagnostic tools that write a user-scope profiler: Visual Studio's performance profiler, JetBrains dotTrace and dotMemory, the Application Insights Profiler and the IIS diagnostics tooling. These fire under the interactive user's own SID whenever a profiling session is configured.
Build agents running .NET code coverage, where OpenCover, altcover and the legacy Coverlet collector set CORECLR_ENABLE_PROFILING and CORECLR_PROFILER for the test run. On a shared agent this repeats on every pipeline execution.
Uninstall and repair of any of the above, which rewrites the same values to clear them. A COR_ENABLE_PROFILING set back to 0 is a normal teardown and matches this rule identically to the enabling write.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1574.012, evaluated against their registry_set events.

Share this rule

/u/siemphony/29c9f303-2b12-46b8-8a26-19806545969a

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

CLR profiler environment variable set in the registry

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it