Evasion using direct Syscalls

Created the Thursday 18 May 2023. Updated 10 months ago.

In the Windows operating system, conventional malware frequently utilizes strategies involving the invocation of specific functions from the kernel32.dll library, such as VirtualAlloc, VirtualProtect, and 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.

This technique can also be used for sandbox evasion. Some sandboxes log only higher-level WinAPI or NT API calls, but do not monitor or hook syscalls (or sysenters). Sandboxes that are missing these events will not see these calls. To combat this technique, ensure your sandboxes are able to log/hook syscalls and kernel function calls.

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 VirtualProtect or 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 rYTBbmNPTDoscUV.

Operational Mechanism

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.



Code Snippets

Detection Rules

Contributors

Additional Resources

External Links

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.


Sleeping Alien

Subscribe to our Newsletter

Don't miss out on the latest and greatest updates from us! Subscribe to our newsletter and be the first to know about exciting content and future updates.