How do you detect kernel exploit privilege escalation?

Combine surrounding signals, since the exploit itself rarely has a stable signature. On Linux, search kernel logs for oops, BUG and general protection faults, audit init_module and finit_module calls, and alert on root processes started by ordinary users with no sudo, su or setuid parent. On Windows, use Sysmon Event 6 to flag unsigned or known-vulnerable drivers and watch for SYSTEM processes with no explainable lineage. Look for a compile-and-run sequence in temp paths, and treat a crash followed by a root session as high confidence. Patching and driver blocklists remain the strongest control.

Detecting Kernel Exploit Privilege Escalation: Oops Logs, Drivers and Root Transitions

Exploitation of kernel and driver flaws (T1068) gives an attacker the highest privileges in one step. Dirty COW and Dirty Pipe on Linux, and bring-your-own-vulnerable-driver attacks on Windows, are well-known examples. No single signal is reliable, but exploits are unstable and noisy, and they have to end with a process whose identity changed without any normal mechanism. We combine those clues.

Signals at a Glance

Signal	Where	ATT&CK
Kernel oops, BUG, general protection fault or repeated segfaults before a root session	dmesg, journalctl -k, syslog	T1068
init_module or finit_module from an unexpected process	auditd syscall records	T1068
Unsigned or known-vulnerable driver loaded	Sysmon 6, EDR driver events	T1068
Source compiled and executed from /tmp, /dev/shm or a user profile	auditd, EDR	T1068
Root or SYSTEM process with no sudo, su, setuid or service parent	auditd, Sysmon 1, EDR	T1068

Linux Kernel Telemetry

Collect kernel messages centrally and search for crash signatures, then add audit coverage for module loading and for root processes started by ordinary users. The module rules also catch rootkit installation that follows a successful exploit:

# Hunt kernel crash signatures (run on a schedule or ship journald to your SIEM)
journalctl -k --since "-24h" | grep -Ei "oops|general protection|kernel bug|unable to handle|call trace"

# /etc/audit/rules.d/kernel.rules
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kmod
-w /sbin/insmod -p x -k kmod_tools
-w /sbin/modprobe -p x -k kmod_tools
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=-1 -F uid=0 -k root_from_user
# tune/validate: root_from_user also fires for sudo; join against the sudo_exec key to exclude it.

Drivers and Unexplained SYSTEM

On Windows, kernel exploitation increasingly arrives as a driver load: an attacker brings a signed but vulnerable driver and abuses it. Sysmon Event 6 records driver loads with signature status and hashes, so you can alert on drivers that fail validation or match a known-vulnerable list:

index=sysmon EventCode=6
| search SignatureStatus!=Valid OR Signed=false
| lookup vulnerable_drivers_sha256 Hashes OUTPUT driver_name as known_vulnerable
| eval severity=if(isnotnull(known_vulnerable),"high","medium")
| table _time host ImageLoaded Signature SignatureStatus Hashes severity
```tune/validate: the vulnerable driver list can be built from the LOLDrivers project```

Alert on a SYSTEM or root process that appears with no parent chain you can explain. Kernel exploits skip sudo, su, services and setuid execution, so the absence of those is itself the signal.
Treat crash-then-root as a sequence: a kernel oops followed by a new root session from the same user within minutes is far stronger than either event.
Patch cadence is a detection control. Compare kernel and driver versions against known-exploited vulnerability lists and flag hosts that sit in the exposure window.
Enable Microsoft’s vulnerable driver blocklist and HVCI where hardware supports them, since prevention is more reliable than detecting any individual driver.

Vetted sources

Use the LOLDrivers project for vulnerable driver hashes, the SigmaHQ driver-load and Linux module rules, Elastic’s prebuilt rules for kernel module loading, the CISA known-exploited-vulnerabilities catalogue for patch prioritisation, and Atomic Red Team T1068 where applicable. Baseline your own environment — hardware vendors ship legitimate unsigned and out-of-band drivers.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Linux Kernel Telemetry

Drivers and Unexplained SYSTEM

Build Detections That Fire

Privilege Escalation Detection

Detection Hub

PrintNightmare Detection