A Fool's Game

 In response to a valid caveat pointed out by  Chetan  ( here and here ) in regards to TamperingSyscall 's, he previously pointed out that some EDRs may check the origin of various problematic NT API function calls; if they originated from an unbacked RX (Read/Executable) region, the function call would be marked as malicious and potentially killed. Thus this short blog post will look to detail how it is possible to use an "indirect syscall" (if that is the correct terminology).  In the previous posts, we detail the basic application and usage of TamperingSyscalls. When making function calls in Windows using the Win32 API, more often than not, they will eventually call a function in ntdll.dll. As such, kernel32.VirtualAlloc will call kernelbase.VirtualAlloc, which in turn calls ntdll.NtAllocateVirtualMemory. In TamperingSyscalls, we call ntdll.NtAllocateVirtualMemory directly, a possible IoC.  It is pretty effortless to have the function call originate from the Win32 coun

In my previous blog post, I presented a project composed of two techniques that facilitated us to subvert EDR hooks and spoof arguments trivially. Now I will look to cover some of the details of "argument spoofing" and its potential. If you are interested in following along, I recommend grabbing a copy of the  TamperingSyscalls  project.   It is common knowledge that EDRs inject a DLL into an application to install hooks into commonly abused (malicious) functions. If you are interested in a complete list of hooks from various vendors, I recommend checking out the  EDRs  repository by Mr Un1k0d3r.    Looking at one of the functions, 'NtAllocateVirtualMemory', this function is hooked by the majority of userland DLL will often hook this function to facilitate introspection into the arguments passed to it. Thus allowing it to build a picture of what the application may be doing; if it is determined to be malicious, the EDR may terminate the process. In this manner, the ED

TamperingSyscalls  a proof of concept of 2 various techniques I have discovered and published a the code for . I will look to briefly describe these techniques. The former is a syscall retrieval technique I originally discovered in June 2022 while stepping through a user-land application under a debugger in the presence of an EDR. I observed that the EDR would provide us with the correct SSN for that function in the RAX register (as it should). Thus if we set a hardware break-point before the syscall instruction, we could retrieve the SSN and use it for direct syscalls. I wrote a proof of concept for this but never bothered to utilize it as direct syscalls never did interest me. EDRs must hook before or on the instruction that reveals the SSN (system service number). They almost always will return after determining if the nature of the call is malicious or not. They achieve this by inspecting the arguments in the registers and the stack. If the parameters passed to the function are det