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
andjmp
instructions to request windows callbacks into callingLoadLibrary
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 asVirtualAllocEx
/VirtualProtectEx
which indirectly callsNtAllocateVirtualMemory
/NtProtectVirtualMemory
. However, when you check the call stack of the legitimate API calls, you will notice that WINAPIs likeVirtualAlloc
/VirtualProtect
are mostly called by non-windows DLL functions. Majority of windows DLLs will callNtAllocateVirtualMemory
/NtProtectVirtualMemory
directly. Below is a quick example of the callstack forNtProtectVirtualMemory
when you callRtlAllocateHeap
. Hiding In PlainSight - Indirect Syscall is Dead! Long Live Custom Call Stacks
so.cl
Indirect Syscall is Dead! Long Live Custom Call Stacks
Rascals are always sociable, and the chief sign that a man has any nobility in his character is the little pleasure he takes in others company. Arthur Schopenhauer
Indirect Syscall is Dead! Long Live Custom Call Stacks