Month: April 2017

A Simple API Monitor

This is a simple Windbg script to monitor common Win32 API calls and display the strings, IPs, Ports, Registry keys passed to the APIs. The Win32 API is huge and I have used common APIs used by programs and malware. I coded this for fun 🙂

[code]
Usage: ApiMon.wds run; g;
[/code]

You can remove APIs as you wish to minimize the output or you can add any API you desire. For example
[code]
bp DLLName!APIName @"$$>a<${$arg0} APIName FileNamePtr

bp kernelbase!CreateFileA @"$$>a<${$arg0} CreateFileA 1";
[/code]

This is a sample output that uses CreateProcess API.

This is from running netcat.

Download: https://github.com/OsandaMalith/ApiMon
(more…)

Executing Shellcode Directly

I found this post by Alex Ionescu pretty interesting. I recreated the poc and wrote position independent shellcode. It’s more like executing shellcode directly by the windows loader.

One could develop complete malware by dynamically locating the base address of kernel32.dll and once you locate the functions LoadLibraryA and GetProcAddress, you can load any library in the system and find the exported symbols, in which you have complete access to the win32 API.

You don’t need to specifically write position independent code using assembly. You can directly code in C/C++ and extract the opcodes.

For example using the ‘InMemoryOrderModuleList’ LDR_DATA_TABLE_ENTRY located in the PEB->LDR we can get the base address of kernel32.dll. Usually kernel32.dll can be found in the third LDR_MODULE in the double linked list. If you have done shellcoding under Windows these things should be familiar.
(more…)

Windows Kernel Exploitation: Stack Overflow

Introduction

This post is on exploiting a stack based buffer overflow in the HackSysExtremeVulnerableDriver.
There’s lot of background theory required to understand types of Windows drivers, developing drivers, debugging drivers, etc. I will only focus on developing the exploit while explaining some internal structures briefly. I would assume you have experience with assembly, C, debugging in the userland.
This driver is a kernel driver. A driver is typically used to get our code into the kernel. An unhandled exception will cause the famous BSOD. I will be using Windows 7 32-bit for this since it doesn’t support SMEP (Supervisor Mode Execution Prevention) or SMAP (Supervisor Mode Access Prevention). In simple words, I would say that when SMEP is enabled the CPU will generate a fault whenever the ring0 tries to execute code from a page marked with the user bit. Basically, due to this being not enabled, we can map our shellcode to steal the ‘System’ token. Check the Shellcode Analysis part for the analysis. Exploiting this vulnerability on a 64-bit system is different.
You can use the OSR Driver Loader to load the driver into the system.
If you want to debug the machine itself using windbg you can use VirtualKD or LiveKD

You can add a new serial connection using VirtualBox or VMware, so you can debug the guest system via windbg. I will be using a serial connection from VMware.
For kernel data structures refer to this. I have used it mostly to refer the structures.
After you have registered the driver you should see this in ‘msinfo32’.

If you check the loaded modules in the ‘System’ process you should see our kernel driver ‘HEVD.sys’.


(more…)