You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to #576, this request for comment seeks to assess the usability and cost/benefit ratio is implementing a CLR assembly execution harness which would permit us to pull in various post-exp frameworks' executable "modules" written in .NET.
Unlike #576, there are a number of ways to skin this cat including leveraging our own PSH extension which is a CLR runtime of its own. This example uses the native CLR runtime, and i think ideally we would permit users to decide whether to use the runtime from our extension or what's on-host.
The text was updated successfully, but these errors were encountered:
I think the BOF and module cover the use case of leveraging the CLR runtime native to the host. Thanks @zeroSteiner for linking those.
The second part of the consideration is around "what do we do if we want to avoid hooked/tripped tartget-local CLR?" The Python meterpreter extension carries an RDI-compatible runtime under the attacker's control into the target system; and since .NET core is Open Source, it seems to me that a similar approach should be possible to permit execution of .NET code without ever touching the host's DLLs, tripping hooks on loading of the library, etc.
Similar to #576, this request for comment seeks to assess the usability and cost/benefit ratio is implementing a CLR assembly execution harness which would permit us to pull in various post-exp frameworks' executable "modules" written in .NET.
Unlike #576, there are a number of ways to skin this cat including leveraging our own PSH extension which is a CLR runtime of its own. This example uses the native CLR runtime, and i think ideally we would permit users to decide whether to use the runtime from our extension or what's on-host.
The text was updated successfully, but these errors were encountered: