The kernel is the core component of any modern operating system. It controls hardware access, manages memory and processes, arbitrates CPU usage and executes at the highest privilege level available on the processor, known as ring 0. Everything else running on a machine depends on it. That is why kernel security determines, in practice, the security of everything that runs on top.
This guide explains what the kernel is, walks through the main design models, describes why attackers invest so much effort in reaching it, what kernel exploits and kernel-level rootkits are, how modern EDRs monitor it and what defenses exist today. It also places the problem inside NIS2 and ISO 27001.
The essentials about the kernel in cybersecurity
- The kernel runs in ring 0 with full privileges over hardware, memory and system processes.
- A kernel exploit bypasses by design most controls living in userland, including antivirus and EDR.
- Kernel-level rootkits are the most persistent and hardest to detect way to compromise an endpoint or server.
- Modern EDRs load drivers into the kernel to gain visibility, which provides detection but introduces stability risk.
- NIS2 and ISO 27001 require vulnerability management and operating system hardening, including kernel patches within documented SLAs.
What the kernel is: an accessible explanation
The kernel is the software layer that sits between the hardware and the rest of the programs. When an application opens a file, sends a network packet or allocates memory, it does not talk directly to the disk or the RAM. It asks the kernel to do it on its behalf through system calls, or syscalls. The kernel validates the request, checks permissions and executes the operation against the hardware when appropriate.
Modern processors implement privilege rings. On x86 there are four rings numbered 0 to 3, although common operating systems use only two: ring 0 for the kernel and ring 3 for applications, also known as userland. In ring 0 an instruction can access any physical memory address, reprogram the interrupt controller or run privileged instructions. In ring 3 any attempt to do so triggers an exception that the kernel intercepts.
That separation is what allows a buggy program not to damage the rest of the system. Every time a process needs a protected resource it transitions from ring 3 to ring 0 through a syscall, the kernel runs the operation and returns control to the process. If the kernel itself is compromised, that boundary ceases to exist: the attacker inherits the maximum privileges of the system.
Kernel types
Not every operating system solves the kernel problem in the same way. There are three main families and the choice has clear consequences in attack surface and stability.
Monolithic kernel. All privileged code, drivers included, lives in the same kernel memory space. Linux is the reference example, and BSD follows a similar model. The advantage is performance: calls between subsystems are direct function calls with no context switches. The drawback is surface area: a bug in a network driver can compromise the entire kernel.
Microkernel. Only the strictly essential parts (scheduling, basic memory management, inter-process communication) live in ring 0. The rest, including drivers and file systems, runs in user processes that talk to each other through message passing. QNX is used in critical embedded systems, and seL4 is formally verified mathematically, which makes it particularly relevant in aviation and defense. The cost is design complexity and a performance overhead that has historically slowed general-purpose adoption.
Hybrid kernel. A compromise. It keeps more components in ring 0 than a microkernel but fewer than a monolithic one, and introduces internal layers to isolate parts of the code. Windows NT (the base of Windows 10, 11 and Server) and XNU, the kernel of macOS and iOS based on Mach with BSD components, are the usual exponents. In practice the academic debate of monolithic versus microkernel dilutes itself: what matters for a defender is the exposed surface and the quality of the loaded drivers.
Why the kernel is a critical target for attackers
For an attacker, the kernel is the final destination inside a machine. Whoever controls the kernel controls everything that happens above it. There are three operational reasons why an advanced actor invests time and money in reaching that level.
The first one is total evasion. An EDR, an antivirus or a SIEM agent are userland processes or, in the best case, kernel drivers that rely on the kernel's own structures to decide what to see and what to report. If the attacker is already in ring 0, they can modify those structures, hide processes from the list the EDR sees, intercept the syscalls the agent uses to enumerate connections or simply patch detection functions in memory. The agent's telemetry keeps flowing but no longer reflects reality.
The second one is complete privilege escalation. A kernel exploit turns an unprivileged user, or even a process sandboxed inside a browser, into SYSTEM on Windows or root on Linux. There is no nuance: once code executes in ring 0, the concepts of file permissions, process integrity or UAC isolation no longer apply.
The third one is rootkit persistence. By modifying kernel structures it is possible to hide files, processes, network connections and registry entries from any inventory tool. A well-implemented kernel rootkit can survive reboots and even partial reinstalls if it combines firmware techniques. For the incident response team, the only certainty is that the host's own telemetry is no longer trustworthy.
Famous kernel exploits
Over the years, kernel vulnerabilities have been disclosed that became didactic references because of their impact.
Dirty COW (CVE-2016-5195) was a race condition in the copy-on-write subsystem of the Linux kernel. It allowed a local user to write to read-only files mapped in memory, including /etc/passwd, and obtain root privileges. It affected virtually every Linux distribution for years before public disclosure.
Dirty Pipe (CVE-2022-0847) was conceptually similar but in the pipes subsystem of Linux kernel 5.8 and later. It allowed overwriting memory pages belonging to files the attacker had no permission to modify, again opening local privilege escalation.
PrintNightmare (CVE-2021-34527) was a vulnerability in the Windows Print Spooler service that enabled remote code execution as SYSTEM on domain controllers. Technically it was not a pure ring 0 flaw, but the spooler ran as SYSTEM and the practical impact was equivalent.
The pattern is the same: a sidecar flaw ends up granting full control of the system because the vulnerable code runs with elevated privileges.
Kernel-level rootkits vs userland rootkits
A rootkit is a collection of techniques designed to maintain access to a compromised system and hide that presence. The difference between userland and kernel rootkits is operationally enormous.
A userland rootkit, also called user-mode rootkit, works by modifying libraries, hooking system API functions inside the victim process or replacing binaries. It is relatively easy to detect by comparing the output of legitimate tools against external analysis, because the rootkit only controls what the processes under its influence can see.
A kernel-level rootkit changes the rules. By residing in ring 0, it can manipulate internal operating system structures: the scheduler's active process list, syscall tables, the network or filesystem driver stack. When an EDR asks the kernel which processes are running, the rootkit can return a filtered list. When an administrator lists files in a directory, the rootkit can hide its own. Well-known academic and forensic examples include historical families such as Necurs, TDL/TDSS, Uroburos/Turla and, in the macOS world, documented cases like Triangulation. Detection usually requires offline disk analysis, hash comparison against signed reference binaries and, in many cases, assuming the host as unrecoverable and reinstalling it from scratch.
EDR and kernel monitoring
The EDR industry solved the visibility dilemma the only possible way: loading code into the kernel itself. Tools like Sysmon from Microsoft, Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne Singularity and virtually every commercial EDR install one or more kernel-mode drivers that intercept events of process creation, module loading, registry modification, network connections and file operations.
The advantage is that telemetry is hard to fake from userland. The drawback is that the same driver introduces third-party code in ring 0 with full permissions over the system. A bug in that driver has immediate consequences, as the CrowdStrike incident of July 2024 demonstrated, when a faulty update of the Falcon sensor caused widespread blue screens (BSOD) on Windows machines worldwide and paralyzed entire sectors for hours. The episode reminded the industry that loading code into the kernel is an operational risk decision, not just a defensive one. That is why Microsoft has started pushing architectures like Windows Resilience and userland APIs that allow EDRs to obtain similar visibility without depending on ring 0 drivers.
Kernel-level defenses
Over the past decade, defensive layers have been deployed inside the kernel itself to reduce the impact of an exploit even when it manages to execute.
KASLR (Kernel Address Space Layout Randomization) randomizes the kernel base address in memory on every boot, forcing the attacker to first obtain an information leak to locate structures before exploiting.
SMEP (Supervisor Mode Execution Prevention) and SMAP (Supervisor Mode Access Prevention) are CPU-level mitigations that prevent, respectively, the kernel from executing code located in userland memory pages and from accessing userland data directly without explicit markers. They break classic exploitation patterns where the attacker redirected the kernel's execution flow to its own shellcode in userland.
KPTI (Kernel Page Table Isolation) was introduced in 2018 as a response to Meltdown. It separates kernel and userland page tables to prevent kernel information leaks through side-channel attacks based on speculative execution.
Secure Boot and kernel signing ensure that the bootloader and loaded modules are signed by a trusted authority, which makes loading a malicious driver from a cold boot harder. On Windows, HVCI (Hypervisor-protected Code Integrity) takes the idea further using virtualization to isolate the kernel and validate that only signed code runs.
None of these defenses is absolute. Their value lies in raising the cost of a working exploit, not in making it impossible.
Kernel security on Linux vs Windows vs macOS
On Linux, the model rests on SELinux (default in RHEL, Fedora and derivatives) and AppArmor (Ubuntu, SUSE), which enforce mandatory access control. On top come seccomp to restrict syscalls, eBPF for observability and capability separation.
On Windows, the heart of the defense is PatchGuard (Kernel Patch Protection), which prevents drivers, even signed ones, from modifying critical kernel structures such as the SSDT or the GDT. Microsoft complements this with Driver Signature Enforcement, known vulnerable driver blocklist and Virtualization-based Security (VBS), where Hyper-V acts as a kernel integrity arbiter.
On macOS, kernel extensions (kexts) are deprecated in favor of System Extensions that run in userland. System Integrity Protection (SIP) blocks modifications to critical directories even for root, and Lockdown Mode aggressively restricts attack surfaces for users targeted by advanced actors. iOS takes that model to the extreme: no third-party software runs in the kernel.
How it fits with NIS2 and ISO 27001
NIS2 requires, in article 21, technical measures to manage cybersecurity risks, and explicitly includes vulnerability management. For an essential or important entity, that translates into concrete patching deadlines, control over drivers in production and traceability of deployed kernel versions. An unpatched kernel against an exploitable critical CVE is a direct audit finding.
ISO 27001:2022 carries the same idea into Annex A: A.8.8 (technical vulnerability management), A.8.9 (configuration management) and A.8.31 (separation of environments) require a documented process to detect operating system vulnerabilities and apply them within an SLA. The CIS Benchmarks and STIG guides are common references to evidence kernel hardening.
Frequently asked questions
Is the kernel the same as the operating system?
No. The operating system includes the kernel plus a wide set of userland services: shells, package managers, graphical environment, standard libraries. The kernel is only the privileged core. In Linux it is common to distinguish between Linux (the kernel) and the distribution (Ubuntu, Debian, Red Hat).
Can the kernel be audited?
Yes, with caveats. Open source kernels can be audited line by line. Closed kernels like Windows or XNU are audited through fuzzing, reverse engineering and bug bounties. Cases like seL4 have gone to mathematical formal verification.
What should I do facing a kernel exploit in my infrastructure?
Assume telemetry of the affected host might be false, isolate the machine, capture memory and disk for external forensics, rotate credentials and plan a clean reinstallation.
Is an open source kernel automatically safer?
No. Code availability enables independent review but also eases vulnerability discovery by offensive actors. What makes a real difference is the maturity of the review process and the speed of patching.
Can an EDR cause a BSOD or a kernel panic?
Yes. Any driver in ring 0 can trigger an exception that the kernel cannot handle. The CrowdStrike incident of July 2024 is the most visible public example. Hence the staged rollouts and documented rollback procedures.
Are there firmware-level rootkits below the kernel?
Yes. Implants in UEFI/BIOS, in the Intel Management Engine or in disk and network controller firmware have been documented in real campaigns. Secure Boot, TPM and boot-time firmware verification raise the bar but do not eliminate it.
Related resources
- What is Mimikatz: credential dumping
- What is EDR
- What is a CVE
- MITRE ATT&CK: tactics and techniques
- Types of malware
- What is a backdoor: types and detection
- What is threat hunting
Kernel hardening with Secra
Securing the kernel is not a one-off task but a continuous process that cuts across inventory, patch management, operating system configuration and behavioral monitoring. At Secra we help security teams and executive committees to bring that discipline to the field: we run kernel hardening audits for Linux and Windows aligned with CIS Benchmarks and STIG guides, deliver threat hunting services focused on kernel-level activity (unsigned drivers, anomalous loads, structure tampering) and provide support in post-incident forensics when there is suspicion of a kernel rootkit or compromise of EDR drivers.
If the organization is within the scope of NIS2 or works towards an ISO 27001 with real operational focus, the kernel ends up being an unavoidable audit point. Let us talk before the next critical vulnerability forces improvisation. Contact Secra and we will review the current state of kernel hardening in your organization.
About the author
Secra Solutions team
Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.