A little-known feature of the .NET framework allows attackers to execute malicious code inside trusted, Microsoft-signed applications without exploiting a software flaw or dropping a standalone payload. By manipulating configuration files or environment variables, adversaries can quietly redirect how .NET applications initialize, permitting covert code execution under the guise of a legitimate .NET application.
During a live session of the Huntress Tradecraft Tuesday series, threat hunters Casey Smith and John Hammond examined this technique, known as App Domain Manager injection, and demonstrated how it fits squarely into the broader theme of living off the land, where attackers abuse native operating system binaries and trusted applications to execute, persist, or move laterally in a breached network.
The session opened with stories dominating the news headlines, including the targeted Notepad++ supply chain compromise and the ongoing exploitation of SolarWinds Web Help Desk. In both cases, attackers relied heavily on trusted tools and legitimate system features rather than overt malware deployments. That context set the stage for the main discussion: attackers increasingly succeed by bending existing application logic to their will rather than introducing obviously malicious binaries.
According to Smith, a Staff Threat Intelligence Analyst here at Huntress, App Domain Manager injection operates inside the .NET framework’s initialization process. When a .NET application launches, the runtime checks for configuration instructions that define how the application domain should be initialized.
He explained that developers use this mechanism legitimately to control isolation boundaries and startup behavior, but warned that the same feature can be repurposed for malicious purposes. By placing a specially crafted configuration file alongside a target executable, an attacker can instruct the runtime to load an arbitrary assembly before the application’s normal logic executes. The injected code runs under the context of a legitimate, often Microsoft-signed process.
The technique doesn't rely on classic DLL injection patterns such as remote memory manipulation or process handle abuse. Instead, Smith walked through how to manipulate configuration files or environment variables to influence assembly loading behavior. This distinction matters because the execution chain appears natural and the visible process is legitimate.
Smith warned that the technique is significant because it works against any .NET Framework Application, leverages trusted Microsoft-signed binaries, and can be used for local or remote code execution.
He also noted that App Domain Manager injection represents a later-stage technique in an attack chain. If detected, it indicates the attacker already has initial access and significant control.
The demonstration covered three variations. The simplest involved copying a trusted .NET executable into a writable directory, placing a matching .exe.config file next to it, and specifying a malicious assembly to load.
When executed from that directory, the application loads the attacker-controlled DLL before continuing with normal execution. The same technique can be extended to remote loading by pointing the configuration at an HTTP or UNC path and specifying the required public key token.
Smith explained that the runtime will download and execute the remote assembly, creating a mechanism for remote code execution that still operates under the guise of a trusted binary.
A third variation uses environment variables rather than configuration files. According to published Microsoft documentation, an attacker can set APPDOMAIN_MANAGER_ASM and APPDOMAIN_MANAGER_TYPE to globally influence .NET assembly resolution behavior for child processes. Because environment variables propagate to spawned processes, this allows chaining across multiple .NET applications. In practice, this means that once the variables are set, any .NET executable launched in that session may load the attacker’s assembly.
Smith and Hammond noted that the technique has appeared in public reporting, including in red-team assessments from the US government’s cybersecurity agency, CISA, and in industry research. It's been used for lateral movement and execution under trusted processes, particularly in environments where application allow-listing or traditional execution controls are deployed.
Because the initial binary remains signed and legitimate, defenders must rely on behavioral artifacts rather than simple signature-based detection, the researchers explained.
Figure 4: CISA advisory flags this technique in public red-team assessments
From a defensive perspective, Smith and Hammond emphasized that unusual execution paths are a primary signal to investigate, particularly when trusted .NET binaries that normally reside in system directories are launched from writable or unexpected locations.
The researchers suggest that new or modified .exe.config files should also be treated as suspicious, since attackers rely on these configuration changes to redirect how assemblies are loaded, and remote-loading activity can leave artifacts in user profile locations such as the WinInet cache and the .NET Assembly cache under AppData.
To analyze and validate this behavior, Smith said defenders should enable Fusion logging to capture detailed assembly resolution activity and use tools like Process Monitor to observe file access patterns and identify when malicious assemblies are being loaded.
Smith also recommends monitoring environment variable modifications if possible, making it clear that APPDOMAIN_MANAGER-related variables shouldn't typically appear in production environments. If they do, defenders should investigate immediately because this likely indicates that the attacker has progressed well into the intrusion lifecycle.
The broader takeaway aligns with the living-off-the-land theme. Attackers continue to prefer techniques that rely on built-in system components, legitimate development features, and trusted binaries. App Domain Manager injection doesn't exploit a vulnerability; it uses a built-in feature, as designed.
As a result, prevention depends less on patching and more on visibility into configuration changes, execution context, and assembly loading behavior, Smith explained.
For defenders, the early warning lies in understanding that many .NET applications (including third-party software) are susceptible to this technique. Organizations that rely heavily on .NET-based tooling should consider whether their telemetry captures configuration file creation, assembly resolution behavior, and environment variable manipulation. Without that visibility, this technique can operate quietly within otherwise trusted processes.
This Tradecraft Tuesday session reinforced a consistent lesson: attackers often don't need new exploits when existing functionality provides sufficient leverage. Understanding how legitimate systems behave under normal conditions is essential to recognizing when that behavior has been subtly redirected.
Like what you just read? Join us every month for Tradecraft Tuesday, our live webinar where we expose hacker techniques and talk nerdy with live demos. Snag your spot now!
