Hiding in Plain Sight with App Domain Manager Injection

What it is

App Domain Manager injection, as detailed by Huntress threat hunters Casey Smith and John Hammond (Tradecraft Tuesday series). It executes attacker code inside a trusted, Microsoft-signed .NET process by redirecting the runtime's application-domain initialization — no software flaw, no standalone payload dropped. It's a later-stage, living-off-the-land technique: detecting it implies the attacker already has initial access and meaningful control.

How it works

When a .NET Framework application launches, the runtime checks configuration for how the app domain should initialize. The page describes three variations:

• Local config: copy a trusted .NET executable into a writable directory, drop a matching .exe.config beside it naming a malicious assembly. Run from that directory and the attacker DLL loads before normal logic.
• Remote loading: point the config at an HTTP or UNC path and supply the required public key token; the runtime downloads and executes the remote assembly under the trusted binary's guise.
• Environment variables: set APPDOMAIN_MANAGER_ASM and APPDOMAIN_MANAGER_TYPE (per Microsoft docs) to influence assembly resolution globally. Because env vars propagate to child processes, any .NET executable launched in that session may load the attacker's assembly — enabling chaining across multiple apps.

It does not use classic DLL injection (remote memory manipulation, process handle abuse), so the execution chain looks natural.

Preconditions / Affected

Works against any .NET Framework application. Attacker needs a writable directory (for the config-file variants) or the ability to set environment variables. Requires prior access — this is not initial compromise. Notably effective where application allow-listing or execution controls are deployed, since the initial binary stays signed and legitimate.

What to do

Signature-based detection won't work; rely on behavioral artifacts.

• Investigate unusual execution paths — trusted .NET binaries that normally live in system directories being launched from writable or unexpected locations.
• Treat new or modified .exe.config files as suspicious.
• Look for remote-loading artifacts in user profile locations: the WinInet cache and the .NET Assembly cache under AppData.
• Enable Fusion logging to capture detailed assembly resolution activity.
• Use Process Monitor to observe file access and spot malicious assemblies being loaded.
• Monitor environment variable modifications where possible.

Caveats

The page notes the technique has appeared in public reporting including CISA red-team assessments and industry research, used for lateral movement and execution under trusted processes. The fetched text is truncated mid-sentence on the environment-variable monitoring recommendation, so any further guidance beyond that point is not captured here.