AppDomainManager (T1574.014) is a Windows technique in the stealth and execution tactics. The adversary hijacks how the .NET AppDomainManager loads assemblies to run arbitrary code.
How attackers use it
The .NET framework uses the AppDomainManager class to create and manage isolated runtime environments, called application domains, inside a process. Assemblies (.exe or .dll files compiled to run as .NET code) load into an application domain as executable code.
MITRE calls the abuse AppDomainManager injection. Malware may create a custom application domain inside a target process to load and run an assembly of its choosing. Alternatively, configuration files (.config) or process environment variables that define .NET runtime settings may be tampered with so that an otherwise harmless .NET application loads a malicious assembly, identified by name, into its process.
How to detect it
MITRE's analytic describes unauthorized manipulation of AppDomainManager behavior:
- New application domains created inside trusted processes
- Assemblies loaded through non-standard configuration files
- Registry or environment variable changes that redirect AppDomainManager to a malicious assembly
- Tampered config files, and new .NET host processes such as w3wp.exe or powershell.exe with modified runtime parameters
- Module loads of unusual or unsigned .NET DLLs
File integrity monitoring on .config files next to .NET applications is a cheap way to catch the config variant.
How to reduce the risk
MITRE lists one mitigation: restrict file and directory permissions. Install .NET applications and related software in write-protected locations, and set directory access controls to prevent file writes to the search paths for .NET applications, both in the folders where they run and in the standard resource folders.
Check your own environment
- Which .NET applications live in folders that standard users can write to?
- Do you watch for changes to .config files beside executables?
- Do you collect module load events for .NET host processes?
Quick check
What are two ways to make a benign .NET app load an unwanted assembly?
Tamper with its configuration (.config) file, or with the process environment variables that define .NET runtime settings.
