Batch, attach and patch: using windbg’s local kernel debugger to execute code in windows kernel

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:

  1. Dumping files embedded into the batch file: a couple of methods for embedding and dumping binary files into the batch file.
  2. Executing the batch file as administrator: here a method to show the UAC prompt from the batch file (without using powershell, vbs…)
  3. Enabling local kernel debugging: how to enable local kernel debugging from the batch.
  4. 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).
  5. 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.

Continue reading

Debugging programs with multiple processes with windbg’s kernel mode debugger

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,…

Continue reading