HTTP 200 OK
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept
{
"id": 352,
"key": "evasion-using-direct-syscalls",
"unprotect_id": "U0521",
"name": "Evasion using direct Syscalls",
"description": "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.\r\n\r\nEndpoint 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.\r\n\r\nThis 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.\r\n\r\n## Unique Aspects of This Technique\r\nThe 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.\r\n\r\nAnother 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`.\r\n\r\n## Operational Mechanism\r\nThe 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.",
"resources": "https://medium.com/@merasor07/av-edr-evasion-using-direct-system-calls-user-mode-vs-kernel-mode-fad2fdfed01a\r\nhttps://github.com/ghostpepper108/Evasion",
"creation_date": "2023-05-18T23:39:48.016000Z",
"tags": "Kernel32.dll, VirtualAlloc, VirtualProtect, CreateThread, Call stack, Ntdll.dll, Syscall, NtProtectVirtualMemory, EDRs/AVs, Hook onto ntdll.dll, Direct syscalls, Assembly, Heap variable",
"modification_date": "2024-01-14T23:57:50.362000Z",
"category": [
2
],
"rules": [
150
],
"attachments": [],
"featured_api": [
419
],
"contributors": [
11,
27,
32
]
}
