DET0517: Detection Strategy for Hijack Execution Flow through the AppDomainManager on Windows.
DET0517 is a detection strategy object for spotting execution-flow hijacking through .NET AppDomainManager behavior on Windows, as related to ATT&CK techni...
Analyst context for executives and security teams
DET0517 is a detection strategy object for spotting execution-flow hijacking through .NET AppDomainManager behavior on Windows, as related to ATT&CK technique T1574.014. The business significance is that this behavior can let malicious code run inside or alongside expected .NET application execution paths, creating risk that normal-looking application activity masks unauthorized execution. Because the official strategy currently provides no detection text, teams should treat it as a coverage validation prompt rather than a ready-made analytic.
Executive priority
Security leaders should ask whether Windows/.NET execution paths are monitored well enough to support incident decisions when trusted application behavior is abused. Priority should go to confirming telemetry coverage, response playbooks, and control evidence around execution and stealth behaviors, especially for systems where .NET applications support business-critical operations. This is relevant to managed detection quality, incident response readiness, and audit defensibility because lack of visibility into application loading behavior can create uncertainty during investigations.
Technical view
The supplied relationship ties this detection strategy to T1574.014 AppDomainManager, with related tactics of execution and stealth and related platform Windows. SOC and detection engineering teams should validate whether they can observe suspicious .NET application domain or assembly-loading behavior, process execution context, configuration or environment changes that affect .NET loading, and file activity involving .NET assemblies. Because the official detection field is not provided, any analytic must be locally derived, tested against legitimate .NET application behavior, and tuned to avoid over-alerting on normal application hosting or enterprise software patterns.
Likely telemetry
- Windows process creation and parent-child process context
- Command-line and process metadata for .NET applications where available
- File creation, modification, and load evidence for .NET assemblies such as .exe and .dll files
- Host-based telemetry showing module or assembly load behavior where available
- Configuration, registry, or environment-change telemetry relevant to .NET application execution paths
Detection direction
- Inventory where Windows systems run .NET applications and confirm those hosts produce sufficient process, file, and load telemetry for investigation.
- Develop or validate detections around unexpected .NET assembly loading or execution-flow changes, using local baselines for legitimate business applications.
- Correlate execution indicators with stealth context from the related ATT&CK technique rather than relying on a single event type.
- Tune for common false positives from legitimate .NET application hosting, software deployment, developer tools, and enterprise management agents.
- Assess whether managed detection or SOC workflows can reconstruct what code executed, from where, and under which process identity during a suspected event.
Mitigation priorities
- Prioritize visibility first: ensure Windows endpoint logging and EDR coverage can support investigation of .NET execution behavior.
- Harden application execution paths using least privilege, change control, and approved software deployment practices.
- Restrict unauthorized modification of application directories, configuration locations, and other locations that influence .NET execution where operationally feasible.
- Include this behavior in incident response exercises for Windows application compromise scenarios.
- Use vulnerability and configuration management to identify high-value Windows systems running critical .NET workloads that need stronger monitoring and control evidence.
Analyst notes and limits
This take is based on the DET0517 detection strategy object and its relationship to T1574.014 AppDomainManager. The ATT&CK object itself does not include an official description, detection logic, platforms, or tactics; Windows, execution, and stealth context come from the related technique relationship. Treat this as a defensive planning and validation guide, not a complete detection specification.
The supplied official fields are sparse. No active exploitation, attribution, impact level, data source list, or guaranteed analytic coverage is provided. Local environment knowledge is required to determine normal .NET behavior, feasible telemetry, alert thresholds, and response priority.
Detection Strategy for Hijack Execution Flow through the AppDomainManager on Windows.
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.014 | AppDomainManager Sub-technique | This object detects AppDomainManager. |
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 | b1251ddd5b34… |
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 DET0517Open 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.