DET0479: Detection Strategy for Hijack Execution Flow using the Windows COR_PROFILER.
This detection strategy is relevant because it points defenders toward a Windows execution-flow hijack pattern involving the .NET COR_PROFILER feature. In...
Analyst context for executives and security teams
This detection strategy is relevant because it points defenders toward a Windows execution-flow hijack pattern involving the .NET COR_PROFILER feature. In business terms, the concern is not the profiling feature itself, but that trusted .NET application execution can be redirected in ways that may blend into normal developer or troubleshooting activity. Leaders should treat this as a coverage-validation item for Windows and .NET-heavy environments rather than assuming standard process monitoring will be sufficient.
Executive priority
Prioritize this where critical business applications, administrative tools, or internally developed services rely on the .NET CLR on Windows. The decision value is to confirm whether SOC, incident response, and compliance evidence can show when COR_PROFILER-related execution behavior is expected versus suspicious. Because the ATT&CK object provides no official detection logic, this should drive a control and telemetry review, not a claim of existing coverage.
Technical view
DET0479 is a detection strategy object for technique T1574.012, COR_PROFILER, which is associated with execution and stealth on Windows. SOC and detection engineering teams should validate visibility into .NET process execution context, environment-variable influence on process startup, profiler DLL loading behavior, and parent-child process patterns around managed applications. Incident responders should be prepared to distinguish legitimate developer/profiling use from unexpected profiler configuration affecting production, administrative, or user-facing processes.
Likely telemetry
- Windows process creation telemetry, including command line and parent process context
- Environment variable visibility where available, especially process-level context relevant to COR_PROFILER behavior
- Module or DLL load telemetry for .NET processes that load the CLR
- Endpoint detection and response events for process start, image load, and suspicious execution-flow changes
- Change records or configuration evidence for legitimate profiling, debugging, or troubleshooting activity
Detection direction
- Start by inventorying where legitimate .NET profiling is used; without this baseline, detections may create avoidable false positives from developer or performance-monitoring workflows.
- Validate whether telemetry can connect a .NET process to profiler-related environment configuration and unmanaged DLL loading, rather than relying only on process names.
- Tune around sensitive execution contexts such as production services, administrative tools, and unusual user workstations, while allowing documented development and troubleshooting use cases.
- Correlate suspicious profiler-related behavior with execution and stealth context from T1574.012, including unexpected process lineage or DLL load locations when such telemetry is available.
- Document blind spots explicitly: the ATT&CK detection strategy object does not provide official detection text, and the strategy platform field is not specified even though the related technique is Windows.
Mitigation priorities
- Establish policy for where .NET profiling is allowed and require documented approval for production or privileged systems.
- Harden endpoint and application execution controls to reduce unauthorized loading of unmanaged profiler DLLs in sensitive Windows environments.
- Restrict who can modify relevant runtime or process-start configuration affecting .NET applications.
- Ensure IR playbooks include review of profiler-related configuration and loaded modules when investigating suspicious .NET process behavior.
- Use the validation results as audit evidence for execution-control monitoring, change governance, and SOC readiness rather than treating the ATT&CK entry as a complete detection specification.
Analyst notes and limits
The supplied object is a detection strategy record with no official description or detection content. The useful context comes from its relationship to ATT&CK technique T1574.012, COR_PROFILER, which describes adversary use of the COR_PROFILER environment variable to hijack execution flow for programs that load the .NET CLR. Recommendations above are therefore framed as validation and control-direction guidance, not as confirmed analytic logic.
Platforms, tactics, and detection text are not specified on the detection strategy object itself. Windows, execution, and stealth context come only from the related technique. Local environment baselines are required to determine whether COR_PROFILER activity is legitimate, suspicious, or irrelevant.
Detection Strategy for Hijack Execution Flow using the Windows COR_PROFILER.
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1574.012 | COR_PROFILER Sub-technique | This object detects COR_PROFILER. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 8db8f5480ad8… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0479Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.