Intercepting all System Calls by Hooking KiFastSystemCall

Usually I don’t post things like this, but because KiFastSystemCall hooking only works on x86 systems and doesn’t work on Windows 8 or above, it no longer has much use in malware. There are also multiple public implementations for this method, just not very elegant, which I hope to correct.

If you haven’t read my previous article about this topic, or need a refresher, you can find it here.

Performing a System Call

KiFastSystemCall has a very strange calling convention (if you can call it that). Each native function (Ex: NtCreateFile) corresponds to a function with the same name in the SSDT. In order to make the transition from user mode to kernel mode, the instruction “sysenter” is used.
I don’t want to go into great detail on how the sysenter instruction actually enters kernel mode, as that would take up the entire page, but I’ll explain the basics:
  • The SSDT is an array of addresses for each native function.
  • The number you see being moved into the eax register is known as its ordinal, and is the position within the SSDT where that functions address is located. 
  • When the sysenter instruction is executed the kernel reads the ordinal from eax and uses it to call the corresponding function in the SSDT, before returning execution to usemode.
Something important to note is that the native function simply calls KiFastSystemCall and doesn’t even set up a stack frame, meaning the address of the first parameter can only be accessed using [esp+8], so we can’t just hook KiFastSystemCall with a C function, as this matches no standard calling convention (which is what makes the method so tricky to implement).

Dispatching Calls

Since the last article I’ve improved on the dispatching method, which now has two purposes: 
  1. Determining which native function made the call to KiFastSystemCall, so we can properly handle it.
  2. Setting up the stack in such a way that we can access the parameters using plain C.
Dispatching
Normally we’d hook each individual function we want to intercept with a single handler (proxy), but all native functions call KiFastSystemCall, so we need to think differently. 
As I explained earlier, the SSDT is an array of addresses and the ordinal (which is in eax when KiFastSystemCall is invoked), corresponds to the position of that function’s address within the SSDT. Using this knowledge we can do the same: We create an array of addresses for the the proxy functions and use the ordinal to locate the correct handler using the ordinal in eax. For our SSDT each entry will be 8 bytes, so the handler needs to be placed at our_ssdt[2*ordinal] (in order to get the ordinal for a native function we just read 4 bytes starting at the 2nd byte of the function). 
You’re probably wondering why each entry for our SSDT is 8 bytes, instead of 4; this is because in order to set up the stack before calling the proxy, we need to know how many parameters were passed to KiFastSystemCall (we store the proxy address as the first 4 bytes and the number of parameter as the rest).
Preparing the Stack
When KiFastSystemCall is invoked, there are two return addresses between the stack pointer and the function parameters (the return from KiFastSystemCall to the native function and the return from the native function). In order to call the proxy function we will get the number of parameter for the function from our_ssdt[2*ordinal+4] and push them to the stack again, in stdcall format (the proxy function is responsible for removing them from the stack). The last thing that is pushed to the stack before we call the proxy is the eax register (the ordinal), we will need this later if we wish to call the original, non hooked, version of KiFastSystemCall.

The Code

FstHook – This is my own C library which allows a program to easily hook any number of native function using a single hook on KiFastSystemCall.
Everything is pretty well commented and self explanatory, but if you have any questions feel free to email me on [email protected]
Uncategorized
9
Why Open Source Ransomware is Such a Problem

A while back 2sec4u posted a poll asking if people considered open source ransomware helpful to detection and prevention, with 46% voting yes. Although the poll wasn’t limited to people working in the antimalware industry, 46% is scarily high. Trying to prove a point, help me out Twitter. Is open source ransomware helping …

Uncategorized
1
Mapping Mirai: A Botnet Case Study

Mirai is a piece of malware designed to hijack busybox systems (commonly used on IoT devices) in order to perform DDoS attacks, it’s also the bot used in the 620 Gbps DDoS attack on Brian Kreb’s blog and the 1.1 Tbps attack on OVH a few days later. Although Mirai isn’t even close to …

Uncategorized
1
Dridex Returns to the UK With Updated TTPs

With the exception of a few unconfirmed reports of Dridex targeting Baltic countries (which doesn’t make much sense economically), infection campaigns have ceased since mid August when Dridex briefly resumed spreading to propagate multiple new botnets aimed at Switzerland. This morning a friend of mine, Liam, reported receiving a malicious email which unusually didn’t …