S3cur3Th1sSh1t/Caro-Kann

Does it really bypass EtwTi?

ManualSyscall opened this issue · 2 comments

When the second shellcode calls NtProtectVirtualMemory +X, the EtwTiLogProtectExecVm event appears.
Remote VirtualAlloc + remote WPM are also suspicious and have corresponding EtwTi events.

The main goal here is to bypass the memory scan which is typically triggered after the execute primitive is called (e.G. CreateRemoteThread, QueueApc or other Windows APIs which trigger ETWti events after being called).

It of course doesn't bypass the creation of events in general. But as many EDR vendors try to verify the Payload in the moment it gets executed via process injection with a memory scan - exactly this verification or scan won't find anything in that moment.

And as the re-protection from RW to RX takes place in the (local) remote process, its not that suspicious. This typically doesn't trigger memory scans (as far as I can tell from my testings).

In my slides from the conference talk, there is also more information on what the EDR stil see's and how to get rid of that. But thats mainly the OPSec best practices also mentioned in the README.

Greetings

So no it didn’t bypass ETWti but it bypasses the memory scan. 😉