SharpExecute : Advanced Techniques For Stealth .NET Execution And CLR Manipulation

Executing .NET Files from an Unmanaged Process with Manual CLR Loading.

Manually loading the CLR in an unmanaged process and using hardware breakpoints can reveal when the CLR calls NtTraceEvent through the managed thread pool.

To evade detection, this tool offers two approaches:

• Patchless execution by hooking NtTraceEvent AmsiScan and thread-pooling functions using hardware breakpoints.
• Patching the target function via an APC (Asynchronous Procedure Call).

The CLR utilizes thread pooling to optimize the execution of .NET applications. Some calls to NtTraceEvent are made via the thread pool. To evade these calls, it is necessary to either control the thread pool or patch the function’s implementation.

It is also very important to hook NtCreateThreadEx because some assemblies, such as SharpUp, use multithreading. New threads created by these assemblies can generate telemetry via NtTraceEvent.

Patchless Method

Set Hardware Breakpoints (HWBP) on the Following Functions:

• AmsiScanBuffer : Redirect the instruction pointer (rip) to the return instruction, and set the rax register to AMSI_RESULT_CLEAN.
• NtTraceEvent : Redirect rip to the return instruction, and set the rax register to STATUS_SUCCESS.
• NtCreateThreadEx : When the assembly creates a thread, the hook intercepts the function call and runs it via an indirect syscall. Once the thread is created, the HWBP is placed on the new thread, and rip is redirected to the return instruction.
• NtCreateWorkerFactory : Modify the start address of the worker factory to a controlled function to place an HWBP on threads created by the worker factory. After setting the HWBP, jump back to the legitimate start address.
• RtlQueueWorkItem : Modify the start address of the thread pool to a controlled function to place an HWBP on threads created by the worker factory. After setting the HWBP, jump back to the legitimate start address.

Warning: Be aware that NtTraceEvent is sometimes called outside controlled threads due to the limitation of HWBP (only 4 addresses can be set).

During long assembly executions (e.g., running Seatbelt with -group=all), you may encounter 1 or 2 uncontrolled events.

NtTraceEvent Leak	Nbr of Call
Seatbelt -group=all	+/- 2
Seatbelt -group=misc	1
SharpUp audit	0
Rubeus triage	0

NB : If you’re daring, you could parse all threads in the process for each HWBP hit to check whether the HWBP is present, reducing the risk of NtTraceEvent leaks.

However, I did not implement this method because I believe making numerous calls to CreateToolhelpSnapshot/OpenProcess is riskier than allowing a few NtTraceEvent leaks.

Another possibility is to add a watchdog that checks every X ms if a new thread is present, and then adds an HWBP to it.

Some assemblies may encounter issues with HWBP hooking (but not with patching) for unknown reasons.

For more information click here.