In this article i’d like to share a windbg script that will let us to load a shellcode from a file to kernel memory and create a kernel thread to execute it. I have not played a lot with the script yet, if you find some bug please tell me.
In this article I am going to describe a way to execute code in windows kernel by using windbg local kernel debugging. It’s not a vulnerability, I am going to use only windbg’s legal functionality, and I am going to use only a batch file (not powershell, or vbs, an old style batch only) and some Microsoft’s signed executables (some of them that are already in the system and windbg, that we will be dumped from the batch file).
With this method it is not necessary to launch executables at user mode (only Microsoft signed executables) or load signed drivers. PatchGuard and other protections don’t stop us. We put our code directly into kernel memory space and we hook some point to get a thread executing it. As we will demonstrate, a malware consisting of a simple batch file would be able to jump to kernel, enabling local kernel debugging and using windbg to get its code being executed in kernel.
The article has five parts:
- Dumping files embedded into the batch file: a couple of methods for embedding and dumping binary files into the batch file.
- Executing the batch file as administrator: here a method to show the UAC prompt from the batch file (without using powershell, vbs…)
- Enabling local kernel debugging: how to enable local kernel debugging from the batch.
- Patch kernel memory with windbg to inject and execute our code in kernel mode: a way to patch kernel memory and execute our code in kernel by using windbg local kernel debugging from the batch file).
- Finally, we will put all these things together to make a proof-of-concept batch file that will target a windows 8.1 x64 machine, and we will do some tests.
It’s common to reverse malware (or any type of software) that creates multiple processes or loads drivers, and it is useful to be able to debug the new created processes or loaded drivers from entry point.
To break at the entry point of the processes you can modify CreateProcess parameters to create child processes suspended (to attach debugger later), or introduce 0xCC at entrypoint on disk of the PE file that is going to be launched, or use plugins for debuggers to attach to child processes… There are lot of methods. From kernel mode you can set conditions that break into the debugger: sxe ld ntdll.dll, sxe cpr, etc… For breaking at a driver entry point you can use: bu <drivername>!DriverEntry (though, i don’t know why, sometimes it doesn’t work for me).
I will talk here about a couple of ways to do this from windbg kernel mode debugger, without needing to restart computer to enable exceptions that break into debugger, or modifying PEs in disk,…
The last days my computer started to crash suddenly, with bug check 0x51 (REGISTRY_ERROR). It was totally random, so i decided to analyze the crash. I decided to write an article about this because, in spite of the fact that it doesn’t seem a security problem, i learnt some interesting things about windows registry.