Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1574.014: AppDomainManager

Adversaries may execute their own malicious payloads by hijacking how the .NET `AppDomainManager` loads assemblies. The .NET framework uses the `AppDomainManager` class to create and manage one or more isolated runtime environments (called application domains) inside a process to host the execution of .NET applications. Assemblies (`.exe` or `.dll` binaries compiled to run as .NET code) may be loaded into an application domain as executable code.[1]

Known as "AppDomainManager injection," adversaries may execute arbitrary code by hijacking how .NET applications load assemblies. For example, malware may create a custom application domain inside a target process to load and execute an arbitrary assembly. Alternatively, configuration files (`.config`) or process environment variables that define .NET runtime settings may be tampered with to instruct otherwise benign .NET applications to load a malicious assembly (identified by name) into the target process.[2][3][4]

EnterpriseT1574.014Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

AppDomainManager abuse matters because it turns trusted-looking Windows .NET application execution into a place where malicious .NET assemblies can be loaded. For leaders, the practical risk is not just “malware runs,” but that execution may appear to come from otherwise benign .NET processes, complicating SOC triage, incident scoping, and application-control confidence.

Executive priority

Prioritize this where Windows .NET applications are common, especially on systems where users or processes can modify application configuration files, writable directories, or runtime environment settings. The key business question is whether critical endpoints and servers can prove that .NET application paths, related .config files, and assembly locations are protected and monitored. This is also useful audit evidence for least-privilege file permission controls and incident readiness around execution-flow hijacking.

Technical view

This is a Windows sub-technique of Hijack Execution Flow under stealth and execution. ATT&CK does not provide official detection text, but the relationship to DET0517 indicates a detection strategy exists for AppDomainManager hijacking on Windows. SOC and detection teams should validate visibility into .NET process execution, assembly loading behavior, changes to .NET application configuration files, and process environment variables that influence .NET runtime settings. IR teams should treat unexpected .NET assemblies loaded by benign applications, or recent configuration tampering near affected applications, as important scoping leads.

Likely telemetry

  • Windows process creation and command-line context for .NET applications
  • File creation and modification events for .NET assemblies such as .exe and .dll files
  • File modification events for application .config files
  • Process environment variable evidence where available
  • Loaded module or assembly telemetry for .NET processes

Detection direction

  • Validate whether DET0517-aligned logic or equivalent analytics exist for AppDomainManager hijacking on Windows.
  • Baseline expected .NET applications, their normal configuration files, and expected assembly load locations before alerting on deviations.
  • Tune for recent changes to .config files or assembly files followed by execution of the associated benign .NET application.
  • Correlate suspicious .NET assembly loads with file-write events and permission changes in the same application path.
  • Account for false positives from legitimate software deployment, application updates, development tooling, and administrative configuration changes.

Mitigation priorities

  • Apply M1022: restrict file and directory permissions so unnecessary users, groups, or processes cannot write to sensitive application directories, configuration files, or assembly locations.
  • Review least-privilege access for Windows systems running important .NET applications.
  • Reduce unnecessary write access before relying on detection, because this technique depends on tampering with load behavior or placing malicious assemblies.
  • Use change control and monitoring for .NET application configuration and related runtime files on high-value systems.
  • During incident response, preserve modified configuration files, suspicious assemblies, process evidence, and permission state for root-cause analysis.
Analyst notes and limits

The supplied ATT&CK object links this technique to IMAPLoader software and to the broader Hijack Execution Flow parent technique. That relationship supports prioritizing the behavior as a stealthy execution concern, but local exposure depends on whether the organization runs Windows .NET applications and whether their configuration and assembly paths are writable or poorly monitored.

MITRE did not provide official detection text for this object in the supplied fields. Telemetry and control recommendations are derived from the official description and relationships, especially DET0517 and M1022, and must be validated against the organization’s actual Windows, .NET, endpoint, and file-monitoring coverage. No claim is made that this technique is currently active in the user’s environment.

Official MITRE ATT&CK definition

AppDomainManager

Adversaries may execute their own malicious payloads by hijacking how the .NET `AppDomainManager` loads assemblies. The .NET framework uses the `AppDomainManager` class to create and manage one or more isolated runtime environments (called application domains) inside a process to host the execution of .NET applications. Assemblies (`.exe` or `.dll` binaries compiled to run as .NET code) may be loaded into an application domain as executable code.[1]

Known as "AppDomainManager injection," adversaries may execute arbitrary code by hijacking how .NET applications load assemblies. For example, malware may create a custom application domain inside a target process to load and execute an arbitrary assembly. Alternatively, configuration files (`.config`) or process environment variables that define .NET runtime settings may be tampered with to instruct otherwise benign .NET applications to load a malicious assembly (identified by name) into the target process.[2][3][4]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1574 Hijack Execution Flow This object subtechnique of Hijack Execution Flow.
Associated objects

Groups, software, and campaigns

Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0517: Detection Strategy for Hijack Execution Flow through the AppDomainManager on Windows. Enterprise uses · Malware S1152: IMAPLoader Enterprise mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise subtechnique of · Technique T1574: Hijack Execution Flow Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1022: Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions:

- Remove unnecessary write permissions on sensitive files and directories. - Use file ownership and groups to control access for specific roles.

Example (Windows): Right-click the shared folder → Properties → Security tab → Adjust permissions for NTFS ACLs.

Harden File Shares:

- Disable anonymous access to shared folders. - Enforce NTFS permissions for shared folders on Windows.

Example: Set permissions to restrict write access to critical files, such as system executables (e.g., `/bin` or `/sbin` on Linux). Use tools like `chown` and `chmod` to assign file ownership and limit access.

On Linux, apply: `chmod 750 /etc/sensitive.conf` `chown root:admin /etc/sensitive.conf`

File Integrity Monitoring (FIM):

- Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.

Audit File System Access:

- Enable auditing to track permission changes or unauthorized access attempts. - Use auditd (Linux) or Event Viewer (Windows) to log activities.

Restrict Startup Directories:

- Configure permissions to prevent unauthorized writes to directories like `C:\ProgramData\Microsoft\Windows\Start Menu`.

Example: Restrict write access to critical directories like `/etc/`, `/usr/local/`, and Windows directories such as `C:\Windows\System32`.

- On Windows, use icacls to modify permissions: `icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F` - On Linux, monitor permissions using tools like `lsattr` or `auditd`.

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
179837b87b0a996c...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 179837b87b0a…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Microsoft App Domains

    Microsoft. (2021, September 15). Application domains. Retrieved March 28, 2024.

    Open source URL
  2. [2]
    PenTestLabs AppDomainManagerInject

    Administrator. (2020, May 26). APPDOMAINMANAGER INJECTION AND DETECTION. Retrieved March 28, 2024.

    Open source URL
  3. [3]
    PwC Yellow Liderc

    PwC Threat Intelligence. (2023, October 25). Yellow Liderc ships its scripts and delivers IMAPLoader malware. Retrieved March 29, 2024.

    Open source URL
  4. [4]
    Rapid7 AppDomain Manager Injection

    Spagnola, N. (2023, May 5). AppDomain Manager Injection: New Techniques For Red Teams. Retrieved March 29, 2024.

    Open source URL
  5. [5]
    mitre-attack T1574.014
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use