InlineExecute-Assembly: perform in process .NET assembly execution
InlineExecute-Assembly
InlineExecute-Assembly is a proof of concept Beacon Object File (BOF) that allows security professionals to perform in process .NET assembly execution as an alternative to Cobalt Strikes traditional fork and run the execute-assembly module. InlineExecute-Assembly will execute any assembly with the entry point of Main(string[] args) or Main(). This should allow you to run the most released tooling without any prior modification needed.
The BOF will automatically determine which Common Language Runtime (CLR) is needed to be loaded into the process for your assembly (v2.0.50727 or v4.0.30319) prior to execution and in most cases, should exist gracefully if any issues arise. The BOF also supports several flags which allow the operator to dictate several behaivors prior to .NET execution which includes, disabling AMSI via in memory patching, disabling and restoring ETW via in memory patching, customization of the CLR App Domain name to be created, whether to create and direct console output of your assembly to a named pipe or mailslot and allows the operator to switch the default entry point of Main(string[] args) to Main(). More details on usage, use cases, and possible detections can be found below and here.
Lastly, the advantage of executing our .NET assemblies in the same process as our beacon implant is that we avoid the default behavior of Cobalt Strike’s execute-assembly module which creates a new process to then load/inject the CLR/.NET assembly. However, other opsec considerations still exist, for example, does the process we are executing within normally load the CLR, or does the .NET assembly we are executing have any known signatures? Therefore, the disadvantage is that if something does get detected and killed, for example by AMSI, your beacon is also killed.
