EPP/EDR API Hooking

In the age of EPP / EDR systems, Red Teamer have to reinvent themselves again and again. One reason for this is, for example, the API hooking technique used by EPP / EDR manufacturers. In this article we want to go into what is meant by API hooking. So we will answer the following questions:

• What is API hooking?
• How does API hooking work in detail?
• How can API hooking be proven?
• Before we go into API hooking, we have to clarify a few other terms:

Before we go into API hooking, we have to clarify a few other terms:

• What is user mode and kernel mode in Windows OS?
• What are Win32 API Calls?
• What are native API calls?
• What are the Kernel32.DLL, the ntdll.dll and the ntoskernel.exe?
• What are system calls aka syscalls?

User mode vs kernel mode

Earlier operating systems were operated in real mode, which means that there was no memory isolation or other protective mechanisms against defective or faulty programs in RAM. In other words, if an application was faulty and was executed, the operating system crashed completely.

This has changed with newer processors and operating systems because they support a protected mode. Protected mode offers prevention options for the previously described system crash problem. For example, system crashes can be prevented by the mutual isolation of running programs using virtual memory and privilege levels (rings). There are a total of four privilege levels (rings) whereby only two levels are used under Windows. Ring 3 forms the equivalent to user mode and ring 0 is equivalent to kernel mode.

User applications such as excel, word etc. are operated in user mode and OS code such as system services and device drivers are operated in kernel mode. It applies to all applications in user mode that they have no possibility of direct direct code execution in kernel mode. Before an application can perform a privileged system operation in user mode, the processor must first switch to ring 0 so that an execution flow transfer can take place in kernel mode. The separation of user mode and kernel mode can be seen in the following figure.

Win32 APIs und Native APIs

In order to understand how the execution flow transfer from user mode to kernel mode works, the terms Win32 API and Native API must be clarified. Win32 APIs are functions, which e.g. can be used by developers in user mode. However, requests through Win32 APIs cannot be processed directly in the kernel, for this the processor must first switch to ring 0.

So a transition from Win32 APIs to Native APIs is required, which happens through the ntdll.dll. The ntdll contains the native APIs for the respective Win32 APIs

At first you might think that the Kernel32.dll should be closer to the kernel compared to the ntdll, but this is refuted by the figure above. The Win32 APIs which can be loaded via the Kernel32.dll can be found in the MSDN. It is a little more difficult with the native APIs, because there is no official documentation for this from Microsoft, but part of it can be found here.

The ntdll with access to the native API calls is the lowest level that can be accessed in user mode and forms the link between user mode and kernel mode with the associated functions (syscalls).

If you are a little concerned with the topic of shell code injection, process injection, you often have to do with the Win32 API CreateThread or CreateRemoteThread. These API calls are user mode API calls that can be used via Kernel32.dll. However, as already mentioned, applications in user mode that use Win32 APIs cannot directly execute code in the kernel. For the Win32 API Call CreateThread, a transition to the associated Native API Call NtCreateThread by the ntdll is required.

Another example to illustrate user mode and kernel mode. In order for a file to be written to the disc in Notepad, the Operation System needs access to the filesystem and device drivers. These are privileged operations for which the application itself (in this case notepad) has no authorization. A transition of the Win32 API WriteFile to the Native API NtWriteFile by the ntdll is required.

The figure below shows the transition from WriteFile to NtWriteFile of a file storage process under Notepad. The dashed lines (blue and red) form the code execution flow transition (transition) from user-mode to kernel-mode via the function contained in the native API, also called syscall.

A closer look reveals that the two different NtWriteFile functions occur. Once through the ntdll and once through the ntoskrnl. The reason for this is that the ntdll is responsible for the export of the Native API NtWriteFile and the Native APIs are implemented by the ntdll in the ntoskrnl. For now, it can be said that the ntdll contains the Native API, which in turn is called the function (syscall), which is required for the transition from user mode to kernel mode.

Syscall

But what does a function (syscall) of a native API look like exactly or how can a syscall be represented visually. For this we use Microsoft's WinDBG and load the previously opened Process notepad. When notepad is loaded, we start in WinDBG with the following command:

x ntdll!NtWriteFile

With this command we specify in WinDBG "to examine (x) the NtCreateFile symbol" in the loaded ntdll module from notepad (more information on what one understands symbols can be found here). After execution we see the following output in WinDBG.

0:003> x ntdll!NtWriteFile


00007ff8`279cae80 ntdll!NtWriteFile (NtWriteFile)

The output provides the memory address from the Native API Call NtWriteFile. So that we can also access the functions (syscall) of NtWriteFile, we use the following command in WinDBG:

u 00007ff8`279cae80

With this command we tell WinDBG that we want to perform an unassemble (u) of the instructions starting at the specific memory range. In short, we get the syscall which is contained in the Native API NtWriteFile and is required for the transition from user mode to kernel mode. After execution we get the following output.

The following can be seen in the illustration. In the first step, the NtWriteFile function from the ntdll is responsible for setting up the relevant functions call arguments in the stack (mov r10, rcx). As soon as this is done, the function must move its relevant system call number into the eax register (mov eax, 8). eax is the register that uses the syscall instruction for each syscall. In this case the system call number for NtWriteFile is 0x08.

Each syscall has its own specific syscall number, which can differ from OS version to OS version. A great list of current Windows x86-64 system calls can be found here thanks to j00ru from Google Project Zero.

After the syscall number has been moved to the eax register, the syscall instruction is called. This is the time at which the CPU switches to kernel mode (ring 0) and carries out the specific privileged operation. The kernel uses the dispatch table (SSDT) to determine the correct native API call based on the respective syscall number (0x08), copies the function arguments from the user-mode stack to the kernel mode stack and executes the kernel version of the native API call ( ZwWriteFile). After the kernel routine has been executed, the user mode is switched back to.

API-Hooking

What is API hooking?

API hooking is a technique that is often used by EPP / EDR manufacturers for the interception of function calls and code flow redirection. The EPP / EDR thus acts as a kind of proxy at the process level and uses the API hook to assess whether the syscall is considered harmful or not.

What is the technical function of API hooking?

Code flow redirection is carried out by setting jmp instructions in the respective function call by the EPP / EDR dll. In other words, a remote Win32 API call is examined by the EPP / EDR dll and evaluated whether it is harmful or not. This redirection is sometimes called detour / trampoline.

IMPORTANT: However, not all APIs are hooked by the EPP / EDR dll. Usually only those APIs that have been misused over and over again in the context of malware, for example:

• CreateRemoteThread
• NtQueueApcThread

Furthermore, one should know that, according to Microsoft, at least officially all API hooks take place in user mode, since an API hooking in kernel mode is "not" possible through the use of Patchguard.

When does the API hook happen?

If a process is started, such as notepad.exe or cmd.exe, certain libraries / DLLs are loaded as modules in the respective user process address space. Important, each started application loads the respective libraries / DLLs separately, but virtually the lowest common denominator is always the ntdll. The API hook does not happen in the ntdll that is on the disk, but always only in the loaded ntdll of the respective application.

Source:

https://outflank.nl/blog/2019/06/19/red-team-tactics-combining-direct-system-calls-and-srdi-to-bypass-av-edr/

https://0x00sec.org/t/userland-api-monitoring-and-code-injection-detection/5565#inline-hooking

https://0x00sec.org/t/defeating-userland-hooks-ft-bitdefender/12496

https://jhalon.github.io/utilizing-syscalls-in-csharp-1/