Skip to content

Attack Surfaces

Driver Type → Attack Surface → Vuln Class → Primitive → Case Study

Once a target driver is identified, the next question is: how does user-mode code reach it? Windows kernel drivers expose multiple attack surfaces depending on their type and the IRP/callback interfaces they implement. The attack surface determines what data an attacker controls and what code path the input traverses.

FIG_003 — User-Kernel Boundary USER MODE DeviceIoControl CreateFile WSASend NtAlpcSend RegSetValueEx MapViewOfFile SYSCALL BOUNDARY KERNEL MODE IOCTL Dispatch IRP_MJ_DEVICE_CONTROL FS IRP Dispatch IRP_MJ_CREATE/READ NDIS / TDI Packet handlers ALPC Port Message dispatch Registry CB CmRegisterCallback Shared Memory MDL / Section obj PnP & Power (IRP_MJ_PNP) WMI / ETW (IRP_MJ_SYSTEM) WDF / KMDF Framework

User-mode APIs cross the syscall boundary into kernel handler dispatch. Each path represents a distinct attack surface.

Categories

Surface Description Key Drivers
IOCTL Handlers Device I/O control dispatch appid.sys, ks.sys, csc.sys
Filesystem IRPs File system and minifilter operations cldflt.sys, ntfs.sys, fastfat.sys
NDIS / Network Network packet and OID handling tcpip.sys
PnP & Power Plug and Play and power transitions All PnP drivers
WDF / KMDF WDF-managed driver framework KMDF drivers
Registry Callbacks Registry filtering callbacks Minifilter/security drivers
ALPC Advanced Local Procedure Call System services
Shared Memory Kernel-user shared memory regions mskssrv.sys, ksthunk.sys
WMI / ETW WMI and ETW interfaces Instrumented drivers

Attack Surface vs. Driver Type

IOCTL FS IRP Network Shared Mem Registry CB ALPC
File System
Minifilter
Log / Transaction
Network Stack
Kernel Streaming
Win32k
Core Kernel
Security / Policy
Storage / Caching
Next in the pipeline: Vulnerability Classes → What goes wrong when attacker-controlled data reaches kernel code?