Evasion using direct Syscalls
Created the Thursday 18 May 2023. Updated 2 weeks, 5 days ago.
In the Windows operating system, conventional malware frequently utilizes strategies involving the invocation of specific functions from the kernel32.dll library, such as
CreateThread. A closer inspection of the call stack reveals that the functions employed from kernel32.dll eventually trigger corresponding functions within the ntdll.dll library. This is facilitated by the ntdll.dll library, which serves as the gateway to the Windows kernel, executing this transition via system calls (syscalls). Hence, any function invoked from kernel32.dll will subsequently prompt one or more associated functions within ntdll.dll. To illustrate, the
VirtualProtect function from kernel32.dll corresponds to the
NtProtectVirtualMemory function in ntdll.dll.
Endpoint Detection and Response (EDR) and Antivirus (AV) systems generally hook onto the ntdll.dll, but only for a handful of crucial functions often exploited by malware. These systems actively monitor potentially exploitable behavior.
Unique Aspects of This Technique
The distinctiveness of this technique lies in its ability to invoke direct syscalls using assembly without calling upon any kernel32 or ntdll functions. It also bypasses the implementation of createthread by directly jumping to a custom heap variable, altering its protection, and finally returning for a clean exit - all without the need to allocate memory, change protection, and copy the payload to the new memory location.
Another intriguing aspect is the flexibility in naming the extern functions. These functions need not necessarily be called
VirtualAlloc. They can have any arbitrary name of your choice, which enhances the complexity of analysis, particularly when disassembled. For instance, it could be named
myCustomDontProtect, or even something obscure like
The main function initiates by setting up markers using inline assembly and then calls an extern function to unprotect the heap variable location containing the executable payload (in this instance, 'calc'). This extern function is converted into assembly code that triggers the syscall. Subsequently, the main function conserves the registers and prompts payload execution via another extern function. This function, in turn, translates to a "jmp" instruction that directs execution to the heap location, executing the payload. The payload contains instructions to return via another "jmp" instruction. The return location is preserved in the R15 register using inline assembly in the main function. Post return to the main function, the registers are restored, and the program gracefully terminates.
The resources provided below are associated links that will give you even more detailed information and research on current evasion technique. It is important to note that, while these resources may be helpful, it is important to exercise caution when following external links. As always, be careful when clicking on links from unknown sources, as they may lead to malicious content.