AppDomain Hijacking (MITRE ATT&CK T1574.014) is a defence-evasion and persistence technique that exploits how the .NET Common Language Runtime (CLR) handles application configuration files. It’s quiet, it abuses a legitimate runtime feature, and it loads attacker code inside the address space of a trusted, signed process — making it a favourite for threat actors who need to stay undetected post-initial-access.
In May 2026, Check Point Research documented Nimbus Manticore (UNC1549 / Smoke Sandstorm, an IRGC-affiliated Iranian APT) adopting AppDomain Hijacking as a primary execution technique in campaigns targeting aviation, telecommunications, and defence organisations across the US and Europe. If you’re not yet hunting for this, you should be.
How it works
When a .NET executable starts, the CLR searches for a configuration file matching the pattern <executable_name>.exe.config in the same directory as the binary. If that file exists, the CLR reads it before the application initialises. An attacker who can write to that directory plants a config file containing two key XML elements:
<runtime>
<appDomainManagerType value="MaliciousAppDomainManager" />
<appDomainManagerAssembly value="MaliciousLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</runtime>When the legitimate application loads, the CLR instantiates the attacker-specified class from the attacker-specified assembly as the AppDomainManager — before Main() runs. The malicious code executes in the context of the legitimate process, inheriting its identity, integrity level, and signed certificate. No UAC prompt. No shell spawned by an unexpected parent. No obvious anomaly at the process level.
No registry modifications are required. No environment variables need to be set. The only artefact on disk is a config file that looks structurally identical to legitimate application config files.
Why threat actors use it
Traditional DLL sideloading drops an unsigned DLL next to a signed binary. Many EDR products flag unsigned DLLs loaded by signed processes, particularly when the DLL path is non-standard. AppDomain Hijacking routes around this: the loaded assembly can be strongly-named, or can be fetched from a remote source at runtime (the CLR supports loading from UNC paths and, in some configurations, HTTP URLs). The technique is also non-destructive — the legitimate application continues to function normally after the injected code runs, reducing the chance that a user or monitoring system notices something wrong.
Nimbus Manticore specifically adopted AppDomain Hijacking as a step up from DLL sideloading because endpoint detection coverage for DLL sideloading has improved substantially. The move to AppDomain Hijacking in 2026 reflects a pattern common in nation-state tradecraft: when defenders build detections for one technique, adversaries shift to a less-detected alternative in the same capability space.
Detection artifacts
File system — the primary signal
The most actionable detection is monitoring for creation or modification of .exe.config files in directories containing .NET executables. Sysmon Event ID 11 (FileCreate) is your friend here. The signal is low-volume in most environments because legitimate applications rarely write to their own installation directories.
Focus on:
- Config file creation in
%ProgramFiles%,%ProgramFiles(x86)%,%LocalAppData%\Programs - Any
.exe.configfile written by a process other than a legitimate installer (check parent process) - Config files with
<appDomainManagerType>or<appDomainManagerAssembly>elements
Process/ETW — the deeper signal
The .NET ETW provider (Microsoft-Windows-DotNETRuntime) logs assembly loads at runtime. Event ID 152 (AssemblyLoad) will show the malicious assembly being loaded into the legitimate process. The distinguishing indicator is an AppDomainManager assembly that doesn’t match the application’s known dependency set.
Enable .NET ETW logging in your SIEM or EDR. It’s verbose, so filter on: assemblies loaded early in process lifetime (before main application assemblies), assemblies loaded from unexpected paths, and assembly load failures (attackers sometimes get paths wrong and the CLR logs the attempt).
Network
If the AppDomainManager assembly is fetched remotely (UNC or HTTP), you’ll see an outbound network connection from a .NET application process to an unusual destination, often shortly after process start. Correlate Sysmon network events (Event ID 3) with file-backed assembly loads from remote paths.
Sigma rule: config file with AppDomainManager elements
title: Suspicious AppDomainManager Config File Written
id: 4e9f7c2a-8b31-4d5e-a0f6-2c3d7e8f9a01
status: experimental
description: Detects creation of .exe.config files containing AppDomainManager settings,
a technique used in T1574.014 AppDomain Hijacking.
references:
- https://attack.mitre.org/techniques/T1574/014/
- https://research.checkpoint.com/2026/fast-and-furious-nimbus-manticore-operations-during-the-iranian-conflict/
author: SOC Analyst Hub
date: 2026-05-25
tags:
- attack.persistence
- attack.defense_evasion
- attack.t1574.014
logsource:
product: windows
category: file_event
detection:
selection:
TargetFilename|endswith: '.exe.config'
TargetFilename|contains:
- '\Program Files\'
- '\Program Files (x86)\'
- '\AppData\Local\Programs\'
filter_installers:
Image|contains:
- '\msiexec.exe'
- '\setup.exe'
- '\install.exe'
- '\Update.exe'
condition: selection and not filter_installers
falsepositives:
- Legitimate application installers writing config files
- Developer tooling updating application configuration
level: mediumKQL (Microsoft Sentinel): AppDomainManager assembly load anomaly
// Detect .NET assembly loads from non-standard paths in trusted process context
DeviceEvents
| where ActionType == "DotNetAssemblyLoad"
| extend AssemblyPath = extractjson("$.AssemblyPath", AdditionalFields, typeof(string))
| where AssemblyPath !startswith "C:\\Windows\\"
and AssemblyPath !startswith "C:\\Program Files\\"
and AssemblyPath !startswith "C:\\Program Files (x86)\\"
and isnotempty(AssemblyPath)
| join kind=inner (
DeviceProcessEvents
| where FileName endswith ".exe"
| project DeviceId, ProcessId, FileName, FolderPath, Timestamp
) on $left.DeviceId == $right.DeviceId and $left.InitiatingProcessId == $right.ProcessId
| where FileName in~ ("outlook.exe", "word.exe", "excel.exe", "powershell.exe", "msbuild.exe", "csc.exe")
| project Timestamp, DeviceName, FileName, AssemblyPath, InitiatingProcessCommandLineHunting for Nimbus Manticore patterns
In the May 2026 campaigns, Nimbus Manticore deployed config files in conjunction with trojanised SQL Developer and other legitimate software installers. Hunt for:
.exe.configfiles created within 30 seconds of a new executable being dropped in the same directory- Config files where the
appDomainManagerAssemblyvalue points to a path outside the application directory - .NET processes making outbound HTTPS connections to newly registered or low-reputation domains within the first 10 seconds of startup
These heuristics won’t fire in clean environments. If they fire, investigate immediately — the false positive rate is very low.
Mitigations
AppDomain Hijacking depends on write access to the application directory. Applying least-privilege filesystem permissions — standard users should not have write access to %ProgramFiles% — removes most of the attack surface. For high-value targets running .NET applications in user-writable directories (which is common for user-installed tools), consider deploying AppLocker or WDAC rules that restrict which assemblies can be loaded as AppDomainManagers.