.NET for post-exploitation is here to stay. It has been bundled with most C2 frameworks, common tools have been ported, AMSI has been added (then bypassed) and new and clever ways have been found to launch unmanaged code. The process of loading a .NET assembly however appears to be pretty consistent.
We know that tools like Cobalt Strike's
execute-assembly have greatly increased the accessibility of loading a .NET assembly from memory, with most attackers using this in one way or another during an engagement to launch Github goodies. And due to this trend, Blue Team are of course becoming adept at hunting for in-memory artifacts left behind. But as attackers we still find ourselves in situations where the current methods of launching .NET code within a process are similar, regardless of the target being a managed or unmanaged process. For example, if we are looking to inject managed code into a process, the path we typically take is the same even if the target is already a .NET process with the CLR loaded:
This has bugged me for ages, so I spent a few nights looking at potential ways that I could change up the signature. My aim was simple... to try and find a way to invoke .NET methods directly within a .NET process without having to purposefully inject shellcode or an rDLL into unmanaged space, just to grab an interface to the CLR to then load a .NET assembly.
This post will look at one potential of doing this, by harnessing debugging frameworks exposed by Windows we can see just what it takes to invoke arbitrary .NET code within a target process using debugging API's.
Read the full article @
https://blog.xpnsec.com/debugging-into-net/
