One Day SecOne Day Sec

Use AppDomainManager to maintain persistence

Onedaysec
5 min read
0 views
docx image 1770015587359 0 7914e6df70

0x00 Introduction

---

A technique learned from Casey Smith @subTee: For .Net programs, modifying the AppDomainManager can hijack the startup process of .Net applications.

If the startup process of common system .Net programs like powershell.exe is hijacked and a payload is added to them, a passive backdoor trigger mechanism can be achieved.

Reference link:

http://subt0x10.blogspot.com/2017/06/attacking-clr-appdomainmanager-injection.html

0x01 Overview

---

This article will cover the following topics:

  • Hijacking self-developed .Net programs
  • Hijacking the system .Net program powershell_ise.exe
  • An exploitation idea targeting Visual Studio

0x02 Related Concepts

---

CLR:

The full name is Common Language Runtime, which is a runtime environment that can be used by multiple programming languages.

CLR is the main execution engine of the .NET Framework, and one of its functions is to monitor the operation of programs:

  • Programs running under the supervision of CLR are considered 'managed' code.
  • Applications or components that run directly on bare metal, not under CLR, are considered 'unmanaged' code.

For programs under the supervision of CLR, the initialization process of program startup can be referred to in the following link:

http://mattwarren.org/2017/02/07/The-68-things-the-CLR-does-before-executing-a-single-line-of-your-code/

Noteworthy points:

If a position that can be exploited can be found in the initialization process of program startup, loading our own code before the program starts, then we can 'abuse' the functionality of CLR to achieve hijacking of the program.

In an ideal scenario:

If the program that can be hijacked is a commonly used system program that starts automatically with the system, then this method can serve as a persistent backdoor.

The following introduces the backdoor idea shared by Casey Smith@subTee: AppDomainManager

0x03 Hijacking Self-Developed .Net Programs

---

Note:

Code referenced from: http://subt0x10.blogspot.com/2017/06/attacking-clr-appdomainmanager-injection.html

1. Write an example program

Using Visual Studio, select the C# development environment, create a new console application, project name: program, code as follows:

using System;

public class Program
{
public static void Main()
{
Console.WriteLine("Inside the App");
}
}

Compile to generate program.exe

Program execution as shown in the figure below

1. Write an example program — technical illustration 1

2. Write payload Dll

Select the C# development environment, create a new class library, project name: DomainManager, code as follows:

using System;

namespace DomainManager
{
public class InjectedDomainManager : AppDomainManager
{
public override void InitializeNewDomain(AppDomainSetup appDomainInfo)
{
base.InitializeNewDomain(appDomainInfo);
Console.WriteLine("Blah From AppMgr");
}
}
}

Compile to generate DomainManager.dll

3. Set AppDomainManager to hijack program startup

Place DomainManager.dll in the same directory

Method 1:

Set environment variables via cmd:

set APPDOMAIN_MANAGER_ASM=DomainManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

set APPDOMAIN_MANAGER_TYPE=DomainManager.InjectedDomainManager

Execute program.exe and observe that DomainManager.dll runs before program.exe by checking the echo

Hijack successfully implemented, complete operation as shown in the figure below

3. Set AppDomainManager to hijack program startup — technical illustration 2

Note:

Pay attention to compare the execution order

Setting environment variables via cmd only affects the current cmd session and is not universal

Method 2:

More universal method: Configure config file

Create program.exe.config with the following content:








value="DomainManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />

Note:

Config file naming format: exe+.config

Successfully achieved hijacking, complete operation as shown in the figure below

3. Set AppDomainManager to hijack program startup — technical illustration 3

0x04 Hijacking system .Net program powershell_ise.exe

---

Next, we need to find exploitable system .Net programs and attempt to implement a persistent backdoor.

Here, powershell_ise.exe is selected for demonstration.

Note:

powershell_ise.exe: Full name Windows PowerShell Integrated Scripting Environment

Graphical interface, primarily used for writing and debugging PowerShell scripts.

The operation interface is shown in the figure below.

0x04 Hijacking system .Net program powershell_ise.exe — technical illustration 4

For demonstration purposes, we need to modify the project DomainManager to make it display a pop-up window when running.

1. Add Reference

Right-click on the project - Add Reference, select System.Windows.Forms.

As shown in the figure below.

1. Add Reference — technical illustration 5

The code modification is as follows:

using System;
using System.Windows.Forms;
namespace DomainManager
{
public class InjectedDomainManager : AppDomainManager
{
public override void InitializeNewDomain(AppDomainSetup appDomainInfo)
{
base.InitializeNewDomain(appDomainInfo);
Console.WriteLine("Blah From AppMgr");
MessageBox.Show("1");
}
}
}

Recompile to generate DomainManager.dll

2. Testing

Hijacking program.exe successful, as shown in the figure below

2. Testing — technical illustration 6

Hijacking powershell_ise.exe:

(1) Test test directory

Copy powershell_ise.exe to c:\test

Create a new powershell_ise.exe.config file in the same directory. The config file can be appropriately simplified, with the simplified content as follows:










Start powershell_ise.exe in the c:\test directory

Successfully hijacked powershell_ise.exe

(2) Test the default directory of powershell_ise.exe

The path is as follows:

C:\Windows\System32\WindowsPowerShell\v1.0

Requires administrator privileges to create hijack files DomainManager.dll and powershell_ise.exe.config in the default directory

Compile any PowerShell script, default launch of powershell_ise.exe, successfully hijacked

Complete operation as shown in the figure below

2. Testing — technical illustration 7

0x05 An exploitation approach targeting Visual Studio

---

For Visual Studio C# projects, the file App.config exists by default in the project directory, with the following content:






If modified to add hijacking functionality, the default config file generated in the bin directory will also be updated accordingly during program compilation.

App.config modifications are as follows:










After compiling the program, the config file in the bin directory is also modified, as shown in the figure below

0x05 An exploitation approach targeting Visual Studio — technical illustration 8

If DomainManager.dll is also placed in the bin directory, it will be hijacked when the program starts, as shown in the figure below

0x05 An exploitation approach targeting Visual Studio — technical illustration 9

0x06 Summary

---

This article introduces a passive backdoor triggering mechanism implemented by modifying AppDomainManager, analyzes the exploitation approach. From a defender's perspective, it is only necessary to pay attention to the config files in the same directory as .Net programs.

Related Questions & Answers

What are the two methods to set the AppDomainManager for hijacking a .NET program?

The two methods are: (1) Setting environment variables via `set APPDOMAIN_MANAGER_ASM` and `set APPDOMAIN_MANAGER_TYPE` in cmd, which affects only the current session. (2) Creating a configuration file named `<executable>.config` (e.g., `program.exe.config`) with the appropriate `appDomainManagerAssembly` and `appDomainManagerType` values. The config file method is more universal and persistent, as it does not depend on environment variables. Both methods are covered in [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence).

How can defenders detect AppDomainManager hijacking attempts on .NET programs?

Defenders should monitor for unusual `.config` files (e.g., `program.exe.config` or `powershell_ise.exe.config`) in the same directories as .NET executables, especially system paths or common application directories. These config files often contain `appDomainManagerAssembly` and `appDomainManagerType` entries. Additionally, watch for unexpected DLL loading during the startup of managed applications. The article [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence) emphasizes that the primary detection point is the config file in the executable's directory.

What is the exploitation approach targeting Visual Studio using AppDomainManager?

Visual Studio C# projects include a default `App.config` file. By modifying this config to add `appDomainManagerAssembly` and `appDomainManagerType` elements, the corresponding `bin` directory config file will be updated during compilation. If a malicious `DomainManager.dll` is also placed in the `bin` folder, every time the compiled program starts, the payload executes. This allows attackers to backdoor development environments or any .NET projects built with Visual Studio. For more details, see [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence).

How can an attacker hijack a system .NET program like powershell_ise.exe using AppDomainManager?

An attacker can hijack `powershell_ise.exe` by placing a malicious `AppDomainManager` DLL (e.g., `DomainManager.dll`) and a config file (`powershell_ise.exe.config`) in the same directory as the executable. The config file specifies the assembly and type of the custom `AppDomainManager`. For system paths like `C:\Windows\System32\WindowsPowerShell\v1.0`, administrator privileges are required. Once configured, every launch of `powershell_ise.exe` will execute the attacker's payload before the main application runs. This technique is demonstrated in [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence).

What is the AppDomainManager hijacking technique for maintaining persistence in .NET applications?

The AppDomainManager hijacking technique leverages the CLR initialization process to load a custom DLL before a .NET application starts. By setting environment variables (`APPDOMAIN_MANAGER_ASM` and `APPDOMAIN_MANAGER_TYPE`) or using a config file (e.g., `program.exe.config`), attackers can force any managed .NET executable to run a malicious `AppDomainManager` class. This provides a passive backdoor that triggers every time the hijacked program runs, as detailed in [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence). The technique is similar to other CLR-based persistence methods like [Use CLR to maintain persistence](/news/use-clr-to-maintain-persistence).

Continue Reading