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

Lab01-01 Analysis

In my leisure time I like reading the book Practical Malware Analysis and I thought of sharing my analysis in the practical sections. You can find detailed answers in the book as well.

  • Lab01-01.dll – https://virustotal.com/en/file/f50e42c8dfaab649bde0398867e930b86c2a599e8db83b8260393082268f2dba/analysis/
  • Lab01-01.exe https://virustotal.com/en/file/58898bd42c5bd3bf9b1389f0eee5b39cd59180e8370eb9ea838a0b327bd6fe47/analysis/

Lab01-01.dll Analysis

If we have a look at the “Lab01-01.dll” file’s imports we can see that it uses network functions from “ws2_32.dll”. We can suspect that this file is responsible for network communications to the attacker.
imports-of-dll

But if we have a look at the exports section we see nothing, which is strange.
no-exports-dll
(more…)

Patching Windows Media Player

I’m writing this post on the request of @rudr4_sarkar. This is a very simple patch in which you can open multiple instances of wmplayer. It basically uses the ‘CreateMutexW’ API to create a mutex object with the string “Local\Microsoft_WMP_70_CheckForOtherInstanceMutex”.

screenshot_2

The pseudo code would be something like this
[code language=”c”]
HANDLE hMutex = CreateMutex(NULL, FALSE, L"Local\Microsoft_WMP_70_CheckForOtherInstanceMutex");
if (GetLastError() == ERROR_ALREADY_EXISTS) {

}
[/code]
You just need to patch the ‘JNZ’ to a ‘JMP’ instruction, that will always jump to the good boy 🙂

disass (more…)

Random CrackMe

This is an interesting crackme I found randomly. You can download it from here: http://www.mediafire.com/file/5r3a3uqsg1pbp4v/CrackMe1.zip

The algorithm uses the PID of the application for the serial key calculation. It also uses the ‘GetComputerName’ and ‘GetUserName’ win32 APIs in generating the serial key. The length of both results are used for the loops and each ascii value is added. These results are used in the final calculation in the serial key.
This graph is from the OllyGraph plugin.

View post on imgur.com


(more…)

Data Packing

I was doing some random experiments using assembly and C. This is a simple example in packing 2 numbers inside a register in assembly. Let’s assume

\(al < 2^{5}\)
\(bl < 2^{3}\)

We want to store these 2 values inside the dl register. The dl register is of 8 bits, so 5 + 3 = 8 bits

Packing

Unpacking

(more…)