Windows Kernel Exploitation - Driver to SYSTEM
1. Kernel Attack Surface
Windows kernel exploitation targets vulnerabilities in kernel-mode drivers, the Windows kernel itself, or privileged system components. Successful exploitation grants ring 0 access - complete control over the operating system. This advanced guide covers kernel exploitation fundamentals on Windows 11 23H2, from vulnerability discovery through shellcode execution.
2. Vulnerability Classes
- Buffer Overflow: Overrunning fixed-size kernel pool allocations.
- Use-After-Free: Accessing freed kernel objects with attached handles.
- Type Confusion: Treating kernel object as different type than intended.
- Race Conditions: TOCTOU between validation and object use in kernel.
- Integer Overflow: Arithmetic errors leading to undersized allocations.
3. Exploitation Primitives
Code:
Typical kernel exploit flow:
1. Open handle to vulnerable driver (CreateFile).
2. Send crafted IOCTL to trigger vulnerability.
3. Exploit primitive: write-what-where or arbitrary increment.
4. Overwrite process token (TokenStealing) or pipe attributes.
5. Escalate current process to SYSTEM via token replacement.
6. Spawn SYSTEM shell or install persistent backdoor.
7. Clean up - restore modified kernel structures.4. Token Stealing Technique
- Locate SYSTEM process EPROCESS in kernel memory.
- Extract SYSTEM token (offset varies by build).
- Locate current process EPROCESS via PsGetCurrentProcess.
- Overwrite current process token with SYSTEM token value.
- Execute cmd.exe or payload - it runs as SYSTEM.
- Original token can be restored for stealth.
5. Mitigation Bypass
- SMEP: Use ROP chains or NX bit disable instead of direct shellcode jump.
- KASLR: Information leak required to locate kernel base address.
- Driver Signing: Exploit legitimate signed drivers. BYOD technique.
- Windows Defender: Disable ETW and kernel-mode CFG before exploitation.
- VBS: Different attack surface - target hypervisor instead.
Kernel exploitation is the highest risk, highest reward area of hacking. One mistake causes BSOD. Test everything in VMs first.