so.cl

This is the second part of the blog I wrote 3 days back on proxying DLL loads to hide suspicious stack traces leading to a user allocated RX region. I won’t be going in depth on how stack works, because I already covered that in the previous blog which can be accessed from the above link. We previously saw that we can manipulate the call and jmp instructions to request windows callbacks into calling LoadLibrary API call. However, stack tracing detections go far beyond just hunting DLL loads. When you inject a reflective DLL into local or remote process, you have to call API calls such as VirtualAllocEx/VirtualProtectEx which indirectly calls NtAllocateVirtualMemory/NtProtectVirtualMemory. However, when you check the call stack of the legitimate API calls, you will notice that WINAPIs like VirtualAlloc/VirtualProtect are mostly called by non-windows DLL functions. Majority of windows DLLs will call NtAllocateVirtualMemory/NtProtectVirtualMemory directly. Below is a quick example of the callstack for NtProtectVirtualMemory when you call RtlAllocateHeap. Hiding In PlainSight - Indirect Syscall is Dead! Long Live Custom Call Stacks