Lord Of The Ring0 - Part 6 | Conclusion

In the last blog post, we learned about two common hooking methods (IRP Hooking and SSDT Hooking) and two different injection techniques from the kernel to the user mode for both shellcode and DLL (APC and CreateThread) with code snippets and examples from Nidhogg.

While there are couple of methods to perform operations from kernel mode on user mode processes, in this part I will focus on one of the most common methods that allow it with ease - KeStackAttachProcess.One of the first things that are being done, is saving the current IRQL and raising the IRQL to DISPATCH_LEVEL by writing to CR8 register, it is being done to make sure synchronization and that there are no other threads that can interrupt this process. If you are more interested to learn about IRQLs, please refer to this article by Offsec that explains more about the subject.Once the thread is synchronized, now it can use the SavedApcState structure to store the previous APC information such as flags, pointers, lists, etc. Once saving the APC state is done, it is added to the top of the list. Lastly, the Process->Pcb.StackCount.Value is incremented by 8, if the result is multiplications of 8, it will release the lock and then try to do similar process to acquiring the thread lock mentioned above.For the final part, there is a check if KvaShadow is enabled (kernel virtual addresses, explained in detail here that was introduce as a mitigation against side channel attacks such as Meltdown and if so will apply the protection accordingly.

To code the AMSI bypass driver, we will utilize the knowledge accumulated in the previous section to attach to the remote process and modify its memory. For a more complete implementation of patching user mode memory, please look at Nidhogg’s implementation.For the Patch function, we will get a structure named PatchInformation that is defined as so:Now, let's define and go through the Patch function:The definitions for the MemoryAllocator can be found here as I will not go through it to stay focused on the subject. First thing that is being done, is copying the parameter to local variables so they will be accessible after the KeStackAttachProcess function is executed (the reason why they will not be accessible otherwise is due to reasons that explained in the previous section). Afterwards, a call to achieve the EPROCESS structure of the target process is made and if such process exists then the current thread will attach it.Next, the GetFunctionAddress is called to iterate the export table of that module and search for a specific function within it.Once the function address achieved, it now can be patched using the KeWriteProcessMemory function to overwrite it with the given patch.KeWriteProcessMemory is doing several things, first a check is performed on the given source and destination addresses to validate that they are valid addresses. Then, a handle to the process is acquired through ObOpenObjectByPointer using the EPROCESS given as a parameter, later on the protection is changed to PAGE_READWRITE to ensure there are write permissions and finally the data is copied using MmCopyVirtualMemory to copy the data.And for the user mode side:

Interacting with kernel mode memory is different from interacting with user mode memory in some ways, one of them being that there is no need for attaching to different processes to access memory and the main limitation is Kernel Patch Protection (PatchGuard). There are several deep dive articles about PatchGuard (and I also explained a little about it in my talk) so I won't go too deep into it. Generally speaking, PatchGuard is protecting certain critical objects (tables, lists, registers, etc) and scans the device once each certain period of time (this time is randomly generated each boot), if it finds mismatch it will crash the system with error code 0x109 (CRITICAL_STRUCTURE_CORRUPTION) . The full list of protected objects is available in MSDN.ETW-TI is an ETW provider that is created by Microsoft to provide insights on specific operations that happens on the system via specific syscall monitoring. The reason Microsoft created that provider is that back in the days both antimalware and malwares abused the ability to filter syscalls (via SSDT hooking and other methods) for monitoring syscall execution. To give the ability to monitor important syscalls with lower risk to the user, Microsoft created an ETW provider that an authorized antimalware vendor (the vendor need to get a proper signature from Microsoft to register to that provider) can use.

In this section, I will use the previous example of ETW-TI disabling to show the process of finding and creating a signature via IDA Free (it doesn't matter which SRE (software reverse engineering) is used, use whatever you feel more comfortable with :) ). To create the best signature, it is preferable to check against several Windows versions but for the sake of the explanation I will document the process for Windows 11 22H2.So now that we know that EtwThreatIntProvRegHandle is the target handle, we can look at xrefs to it and see if there is any exported function that using it. From searching in xrefs, the only function that is using it (in the searched version) and is exported is KeInsertQueueApc . The reason behind searching an exported function is to find the target objects with as little signatures as possible.Now, we can create a signature using the mov rcx, operation (if the opcodes of the target aren't the first occurrence, the signature will be created using couple of instructions i.e. xor edx, edx; mov rcx, cs:EtwThreatIntProvRegHandle). To see the bytes conveniently in IDA we can change the amount of bytes seen next to the instruction by navigating to Options → General and change the Number of opcode bytes (graph) from 0 to 8.Since now we see hat 48 8B is repeating itself above, we can use theD2 above to create the signature: D2 48 8B and know that the offset to the handle will be in baseAddress + foundIndex + offset(usually this is the calculation but it might shift a little depends on the instructions) where the offset will be 3 in this case, the foundIndex is the index that this signature was found in the function and baseAddress is the address of the function (in this case, KeInsertQueueApc).

Another example for modifying kernel mode memory can be patching kernel callbacks. The kernel callbacks are stored inside different linked lists, one for each callback type. To find the list, usually we will need to go through a process of creating a signature and binary searching the object (NOTE: It is super important to notice that when searching need to make sure the searched address is valid and not searching within discardable page or it might cause a BSOD). However, I want to show the different case of object callbacks (if you want, you can refresh your memory on object callbacks here).In this function, there is no binary searching or any signature, instead the exported Ps*Type is used to enumerate the callbacks. The reason being, that for object callbacks there is no internal list that is being used, instead the callbacks are saved inside a list in the corresponding object type itself in a structure called CallbackList. Conveniently, the TypeLock is available to acquire from the list as well.

I have thought for a long time when and how to end this series. From a small “hello world” driver to one of the drivers with most features and support in all Windows versions since the first release of Windows 10 - this was definitely quite a journey and of course, I cannot forget about this blog series as well.