CLR profiler environment variable set in the registry

1title: CLR profiler environment variable set in the registry2id: 29c9f303-2b12-46b8-8a26-19806545969a3status: experimental4description: |5  Matches the registry half of AN1319: a value written to one of the CLR6  profiling environment variables under an `Environment` key, which is how a7  system-wide or user-wide COR_PROFILER is made persistent. Setting8  COR_ENABLE_PROFILING to 1 and pointing COR_PROFILER at a CLSID (or, from9  .NET Framework 4 onward, pointing COR_PROFILER_PATH straight at a DLL on10  disk) causes the runtime to load that unmanaged DLL into every process that11  starts the CLR, which is the hijack this technique performs. Only the12  registry-backed scopes are visible here by definition — a process-scope13  COR_PROFILER set in memory by the parent that spawns the target never touches14  the registry and leaves no matching event. The value names are anchored with15  `endswith` beneath `\Environment\`, which covers the two scopes where16  `Environment` is a registry *key* and the COR_ name is a value beneath it:17  the machine-wide18  `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment`, and the19  per-user `Environment` key that Sysmon writes as HKU followed by the account20  SID. The per-service scope is deliberately not covered and cannot be: under a21  Services key, `Environment` is itself a single REG_MULTI_SZ *value* whose data22  holds `COR_ENABLE_PROFILING=1` and friends, so `TargetObject` ends at23  `\Environment` with no COR_ name in it at all, and Sysmon renders multi-string24  data as binary rather than as readable text in `Details`. Catching that scope25  needs a separate rule against the value data, not another term here. MITRE26  names COR_ENABLE_PROFILING, COR_PROFILER and COR_PROFILER_PATH; the27  bitness-suffixed COR_PROFILER_PATH_32/_64 forms and the CORECLR_ equivalents28  that .NET Core and .NET 5+ read instead were added here, not taken from the29  analytic, because a modern host runs the CoreCLR names and a rule listing30  only the Framework ones would miss it entirely.31  Vocabulary, scope and prerequisites. The brief maps Security EventID 465732  onto the Sigma `registry_set` category, but that category is Sysmon-shaped:33  this rule is written in the Sysmon vocabulary, where `TargetObject` carries34  the full key-plus-value path in one field. Security 4657 splits the same35  information across `ObjectName` and `ObjectValueName`, so that feed needs a36  field mapping before this rule can match on it and enabling Audit Registry37  with a SACL on the Environment keys will not by itself make this rule fire.38  The analytic's other two halves are out of reach: correlating the registry39  write with the profiler DLL then loading into a .NET process, within MITRE's40  `TimeWindow` knob, is a Sysmon EventID 7 record and a cross-event join, and41  MITRE's `AllowedProfilers` and `ProfilerDllPaths` knobs would have to be42  applied against the `Details` field, which is left unconstrained here so a43  profiler DLL in any location is caught. Prerequisite: registry monitoring in44  a Sysmon configuration is an explicit allowlist of paths, and the Session45  Manager Environment key and the per-user Environment keys are not in every46  shipped configuration, so confirm they are in scope before reading an empty47  result as an absence of this technique.48  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.49references:50  - https://attack.mitre.org/techniques/T1574/01251  - https://attack.mitre.org/detectionstrategies/DET047952author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)53date: 2026-08-1754tags:55  - attack.defense-evasion56  - attack.execution57  - attack.t1574.01258logsource:59  category: registry_set60  product: windows61detection:62  selection_profiler_env:63    TargetObject|endswith:64      - '\Environment\COR_ENABLE_PROFILING'65      - '\Environment\COR_PROFILER'66      - '\Environment\COR_PROFILER_PATH'67      - '\Environment\COR_PROFILER_PATH_32'68      - '\Environment\COR_PROFILER_PATH_64'69      - '\Environment\CORECLR_ENABLE_PROFILING'70      - '\Environment\CORECLR_PROFILER'71      - '\Environment\CORECLR_PROFILER_PATH'72      - '\Environment\CORECLR_PROFILER_PATH_32'73      - '\Environment\CORECLR_PROFILER_PATH_64'74  condition: selection_profiler_env75falsepositives:76  - "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."77  - "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."78  - "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."79  - "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."80level: medium