SKILL: Modern Kernel Exploit Mitigations

Metadata

• Skill Name: security-mitigations
• Folder: offensive-mitigations
• Source: https://github.com/SnailSploit/offensive-checklist/blob/main/mitigations.md

Description

Security mitigation reference and bypass catalog: ASLR, DEP/NX, RELRO, stack canaries, CFI, sandboxing, seccomp. Covers both detection of enabled mitigations and known bypass techniques. Use when assessing target hardening or planning exploit mitigation bypasses.

Trigger Phrases

Use this skill when the conversation involves any of: mitigations, ASLR bypass, DEP bypass, NX bypass, RELRO, stack canary bypass, CFI bypass, sandbox bypass, seccomp bypass, mitigation detection, checksec

Instructions for Claude

When this skill is active:

1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. Suggest next steps based on findings

---

Full Methodology

Modern Kernel Exploit Mitigations

Memory-safety & Isolation

Kernel Address Space Layout Randomization (KASLR)

• Randomizes memory addresses where the kernel and its components are loaded.
• Makes it difficult for attackers to predict kernel code and data locations.

Bypass Techniques

• Information Leaks: Exploiting vulnerabilities (e.g., uninitialized memory, side-channels) to leak kernel pointers and calculate the base address.
• Side-Channel Attacks: Using timing, cache, or other microarchitectural side channels to infer memory layout.
  • Prefetch Cache Timing: Measures access speed across the kASLR range (0xfffff80000000000 to 0xfffff80800000000, ~0x8000 iterations with 0x100000 alignment). The fastest access indicates a cached address, revealing the actual kernel base. Uses rdtscp for timing, mfence for memory barriers, and prefetchnta/prefetcht2 for cache manipulation.
• Targeting Non-Randomized Regions: Exploiting data or code segments that are not fully randomized.
• Brute-Force: Feasible in environments with limited entropy (e.g., some 32-bit systems or specific configurations).
• Intel LAM: Linear Address Masking support exists on recent kernels/CPUs but may be disabled by default. Verify with kernel config, boot params, and CPU flags on your target.

Kernel Page Table Isolation (KPTI)

• Linux:
  • Separates user-space and kernel-space page tables.
  • Mitigates the Meltdown vulnerability by preventing user-space access to kernel memory.

Bypass Techniques

• Side-Channel Attacks: Exploiting microarchitectural side channels (e.g., TLB timing, cache attacks) that leak information across the isolation boundary.
• Hardware Vulnerabilities: Exploiting CPU vulnerabilities (e.g., L1TF, MDS) that can bypass page table separation.
• Implementation Flaws: Bugs in the KPTI implementation itself.

Practitioner

• Linux: check status via /sys/devices/system/cpu/vulnerabilities/* and dmesg | grep -i kpti.
• Windows: verify meltdown/KVA shadowing with Get-SpeculationControlSettings PowerShell script from Microsoft.

Supervisor Mode Access Prevention (SMAP)

• Linux:
  • Hardware feature preventing unintended kernel access to user-space memory.
  • Protects against attacks exploiting improper memory accesses.

Bypass Techniques

• ROP/JOP Gadgets: Finding instruction sequences (gadgets) within kernel code that disable SMAP temporarily (e.g., via stac instruction) before accessing user memory.
• Data-Only Attacks: Attacks that achieve their goal without directly accessing user-space data from the kernel inappropriately.
• Kernel Information Leaks: Combining with KASLR bypasses to find suitable gadgets.

Practitioner

• Linux: confirm with grep smap /proc/cpuinfo and cat /proc/cpuinfo | grep 'smep\|smap'.
• Check CR4 at runtime with rdmsr/wrmsr tools or lscpu -e on supported systems.

Supervisor Mode Execution Protection (SMEP)

• Linux/Windows:
  • Hardware feature preventing execution of user-space code when in supervisor mode.
  • Located in bit 20 of the CR4 control register.
  • Blocks certain privilege escalation attacks that rely on executing shellcode in user-mode memory.

Bypass Techniques

• ROP/JOP Chains: Constructing code reuse chains entirely from existing kernel code, avoiding execution of user-space code.
• Data-Only Attacks: Exploiting vulnerabilities without needing to execute shellcode (e.g., overwriting kernel data structures).
• Disabling SMEP: Finding gadgets or techniques to modify the CR4 control register to disable SMEP.
• Type Confusion Exploits: Using type confusion vulnerabilities to gain control flow and build ROP chains for SMEP bypass.
• Page Table Manipulation: Modifying page table entries (PTEs) to change user pages to supervisor pages, making user-space code executable in kernel context.
• Write-What-Where Primitives: Using arbitrary write vulnerabilities to modify CR4 register or page table structures.

Practitioner

• Linux: grep smep /proc/cpuinfo; verify effective state via dmesg | grep -i smep.
• Windows: SMEP is enforced when Memory Integrity/HVCI is enabled on modern systems.

Kernel Data Protection (KDP)

• Windows:
  • Marks certain kernel memory regions as read-only.
  • Prevents unauthorized modification of critical kernel data structures.

Practitioner

• Check with Get-CimInstance -ClassName Win32_DeviceGuard and System Information → Device Guard properties for KDP/HVCI/VBS.

Memory Integrity (Core Isolation)

• Windows:
  • Uses virtualization and HVCI to prevent malicious code alteration.
  • Guards against code injection or execution in kernel mode.

Practitioner

• Enable/verify: Windows Security → Device Security → Core isolation details.
• PowerShell: Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity | Select-Object Enabled.

Read-Only Data Sections (RODATA)

• Linux:
  • Marks specific kernel memory regions as read-only.
  • Prevents modification of critical data structures and code.

Hardened Usercopy

• Linux:
  • Adds boundary checks to memory copy operations between user and kernel space.
  • Prevents buffer overflows and memory corruption during copy operations.

Memory Tagging Extension (MTE)

• Linux (ARM):
  • Hardware-assisted memory safety feature to detect memory corruption bugs.
  • Mitigates use-after-free and buffer overflows at a hardware level.
  • Adopted as a production security feature in Android 16 (March 2025) with both asynchronous and synchronous detection modes available for apps.

How MTE Works

• 4-bit Tags: Each 16-byte memory allocation receives a random 4-bit tag (values 0-15)
• Pointer Tagging: Upper bits of pointers store the allocation tag
• Tag Checking: Hardware validates pointer tag matches memory tag on every dereference
• Fault on Mismatch: Invalid access triggers SIGSEGV (sync mode) or logs asynchronously (async mode)

Bypass Techniques

• Tag Collision (Probabilistic): With only 4-bit tags (16 possible values), collision probability is high
  • Increase entropy with larger allocation pools; Android 16 uses tag rotation heuristics.
• Untagged Memory Regions: Not all memory is MTE-protected
  • Enable MTE on stack via prctl(PR_MTE_TCF_SYNC, PR_TAGGED_ADDR_ENABLE).
• Asynchronous Mode Exploitation: Android's async mode delays fault reporting for performance
  • Use synchronous mode (MTE_mode=sync) for security-critical apps.
• Integer Overflow in Tag Calculation: MTE tags are derived from allocation size; overflow can corrupt tags
• Kernel-Space Bypass: MTE only protects userspace by default
  • Kernel allocations (kmalloc, vmalloc) don't use MTE (Android 16, Linux 6.8)
  • Kernel exploit primitives (KASLR leak, arbitrary write) unaffected
  • Syscall buffer handling may not validate tags
• JIT Code Execution: JIT-compiled code can bypass MTE checks

; Assembly gadget to create untagged pointer
mov x0, xzr          ; Zero out tag bits
orr x0, x0, #0x1000  ; Set address without tag
ldr x1, [x0]         ; Load from untagged pointer (no MTE check)

Exploitation Workflow:

1. Leak a tagged pointer
2. Strip tag bits (mask upper 8 bits)
3. Use untagged pointer for memory operations
4. MTE doesn't validate untagged accesses in some contexts

Practitioner

• Android: enable per‑app via Developer Options or adb shell setprop persist.device_config.runtime_native_boot.mte_mode sync (device‑specific).
• Linux: compile with CONFIG_ARM64_MTE and use prctl(PR_SET_TAGGED_ADDR_CTRL, ...) from user space.
• Verify MTE status: cat /proc/cpuinfo | grep mte and check HWCAP2_MTE in getauxval(AT_HWCAP2)
• Android 16+ apps: opt-in via manifest <application android:memtagMode="sync">

Intel Linear Address Masking (LAM)

Intel allows software to use upper address bits for metadata, similar to ARM's Top Byte Ignore (TBI).

How LAM Works

• LAM57: Uses bits 62:57 (6 bits) for tags in 5-level paging
• LAM48: Uses bits 62:48 (15 bits) for tags in 4-level paging
• Hardware Masking: CPU ignores tagged bits during address translation
• Use Cases: Memory tagging, capability systems, garbage collection metadata
• Vulnerability Classes:

1. Pointer Forge: Attackers can craft tagged pointers without validation
2. Info Leak Bypass: Some sanitizers only check canonical addresses; LAM-tagged pointers pass checks
3. Address Confusion: Software assuming canonical addresses may mishandle LAM pointers

Memory Sealing

• Linux:
  • mseal() permanently seals selected VMAs so permissions/mappings can no longer change—even by the owner (verify kernel version and libc support on your target).
  • Adopted by projects such as Chrome/glibc/BPF tool‑chains to seal JIT pages, locking down GOT/PLT and eBPF JIT regions (version‑specific; verify).

Bypass Techniques

• Time‑of‑use Window: Exploits must succeed before sealing.
• Data‑only Abuse: Still possible if the mapping remains writable.
• Kernel Flaws: Bugs in the mseal() path could bypass a seal.

Practitioner

• Verify mseal availability via grep -R sys_mseal /proc/kallsyms or kernel symbols.
• Userland: prctl(PR_MSEAL, ...) (glibc 2.41+ headers), check errno for ENOSYS on older kernels.

Privileged Access Never (PAN)

• Linux (ARM):
  • Hardware feature preventing direct kernel access to user-space memory.
  • Similar concept to SMAP on x86, prevents certain data leakage/corruption bugs.

Kernel DMA Protection

• Windows:
  • Uses IOMMU/VT-d to protect against malicious peripherals performing DMA attacks.
  • Prevents unauthorized memory access via hardware devices.

Pluton Security Processor

• Windows:
  • Microsoft Pluton is increasingly deployed with newer platforms, replacing or augmenting discrete TPM 2.0 and hardware‑binding BitLocker keys, Secure Boot, and HVCI policies. Check OEM/SKU documentation for Copilot+ requirements.

Practitioner

• Check Pluton state in Device Manager → Security devices, or tpm.msc shows Pluton‑backed TPM if present.

Memory Protection Keys (MPK)

• Linux:
  • Provides per-page memory permissions using hardware keys.
  • Allows fine-grained control over memory access rights.

Bypass Techniques

• PKRU Register Manipulation: Using gadgets to modify the Protection Key Rights Register.
• Unprotected Memory: Targeting memory regions not protected by MPK.
• Implementation Bugs: Exploiting flaws in the MPK implementation.
• Side-Channel Attacks: Using side channels to infer protected memory contents.

Protection Keys for Supervisor (PKS)

• Linux/Intel:
  • Extends PKU to supervisor pages; the kernel flips page permissions via wrmsr PKS_MSC* without TLB flushes (Sapphire‑Rapids+).
  • Landed upstream in Linux 6.12.

Bypass Techniques

• ROP/JOP WRMSR Gadgets that flip PKS bits.
• Unprotected Regions outside a PKS domain.
• CPU Errata undermining isolation.

Practitioner

• Linux: enable with CONFIG_X86_PKS; verify via dmesg | grep -i pks and /proc/cpuinfo flags.

Zero-Page Memory Allocation

• Linux/Windows:
  • Ensures memory pages are zeroed before allocation.
  • Prevents leakage of residual data.

Zero-Page Mapping Removal

• Linux:
  • Removes zero page mapping to prevent NULL pointer dereference exploits.
  • Enhances memory safety.

Init-On-Alloc and Init-On-Free and Init-Stack-All-Zero

• Linux:
  • Automatically zeroes memory when allocated or freed.
  • Prevents use-after-free and information leakage.

TPM Bus Encryption

• Linux:
  • Recent kernels add support for stronger TPM transports over SPI/I²C on some platforms. Feature availability and defaults vary; verify in dmesg and driver configs for your device.

Practitioner

• Verify with dmesg | grep -i tpm and kernel config CONFIG_TCG_TIS_SPI/_I2C options; firmware must expose supported transports.

Memory Safety Initiatives

Rust in the Linux Kernel

• First‑class Rust support landed in Linux 6.1 (December 2022) and was declared production‑ready with Linux 6.6 (October 2023).
• In‑tree Rust drivers (e.g., NVMe, DRM simple‑display, Wi‑Fi) have so far exhibited zero memory‑safety bugs under continuous fuzzing, demonstrating the practical security benefit of memory‑safe languages.
• Ongoing work aims to extend Rust usage into networking, Android GKI modules, and scheduler subsystems, further shrinking the kernel's attack surface.

Safer Windows Drivers with C++20 and Rust

• Starting in Windows 11 23H2, the Windows Driver Framework (WDF) officially supports both modern C++20 and a Rust projection (windows‑drivers‑rs) that wrap KMDF/WDF APIs with lifetime‑safe abstractions.
• Hardware vendors can now obtain WHQL signatures for C++20 or Rust kernels drivers, eliminating common lifetime and IRQL‑misuse bugs without sacrificing performance.

CHERI / Morello (Experimental Capability Hardware)

• Arm's Morello evaluation platform (2022‑2025) runs a CHERI‑enabled Linux kernel that enforces pointer capabilities in user and kernel space, providing hardware‑enforced spatial and temporal memory safety.
• Although experimental, CHERI demonstrates a plausible post‑2025 path toward fundamentally safer C/C++ code with architectural support.

memfd_secret (userland secret memory)

• Linux:
  • memfd_secret (Linux 5.14+) provides user‑mode pages hidden from other processes and the kernel direct mappings
  • Useful for protecting keys and ROP staging from accidental exposure; verify support via kernel config and memfd_secret(2)

Virtualization-Based Security Enhancements

Virtualization-Based Security (VBS)

• Windows:
  • Creates an isolated, secure memory region using hardware virtualization.
  • Protects sensitive system components and data from malware and exploits.

Bypass Techniques

• Hypervisor Vulnerabilities: Exploiting bugs in the underlying hypervisor (Hyper-V) to escape the VBS container.
• Misconfiguration: Weaknesses in VBS configuration or deployment.
• Physical Access: Hardware-level attacks (e.g., DMA attacks if not mitigated by Kernel DMA Protection).
• Compromised Signed Components: Exploiting vulnerabilities in trusted components running within VBS.

Practitioner

• Confirm VBS/HVCI: Core isolation settings or PowerShell Get-CimInstance -ClassName Win32_DeviceGuard (look for VirtualizationBasedSecurityStatus and SecurityServicesConfigured).

AMD Secure Encrypted Virtualization – Secure Nested Paging (SEV‑SNP)

• Linux guest support since 6.11; provides full memory encryption + integrity with an SVSM.
• Shipping today in major cloud "confidential VM" SKUs.

Intel Trust Domain Extensions (TDX)

• Guest driver landed in 6.11; host enablement queued for 6.16.
• Protects guest memory against a compromised hypervisor.

Practitioner

• Cloud: verify TDX/SEV‑SNP instance type (Azure DCasv5/ECasv5, GCP C3, AWS C7g variants); attest via platform‑specific tools (e.g., az confcom attestation).

Arm Confidential Compute Architecture (CCA) Realms

• Realm VM support merged in 6.13 for Arm v9 CPUs, giving encrypted, isolated guest environments.

Hypervisor-Enforced Code Integrity (HVCI)

• Windows:
  • Uses VBS to enforce code integrity checks on kernel-mode drivers and binaries.
  • Ensures only signed and verified code can execute in kernel mode.

Bypass Techniques

• Signed Malicious Drivers: Obtaining signing certificates (stolen or illicitly acquired) to sign malicious code.
• Exploiting Allowed Drivers: Finding vulnerabilities in legitimate, signed drivers already running on the system ("Bring Your Own Vulnerable Driver" - BYOVD).
• Hypervisor Vulnerabilities: Exploiting the underlying hypervisor (see VBS bypasses).
• Configuration Issues: Weaknesses in Code Integrity policies.

Mode Based Execution Control (MBEC)

• Windows:
  • Ensures driver code can only be executed in kernel mode.
  • Available in hardware and software (emulated) forms.
  • Prevents user-mode execution of kernel code.

Kernel Mode Code Integrity (KMCI)

• Windows:
  • Ensures kernel pages can only become executable with proper signing.
  • Enforces driver signing enforcement and vulnerable driver blocklists.
  • Implements software SMEP (Supervisor Mode Execution Prevention).
  • DriverSiPolicy.p7b now refreshes weekly via Windows Update and MEM Configuration Manager, accelerating the BYOVD blocklist cadence.

User Mode Code Integrity (UMCI)

• Windows:
  • Ensures user mode pages can only become executable with proper signing.
  • CI validates the signaturees of EXE and DLL before allowing them to load.
  • Enforces protected processes and protected process light signature requirements
  • Enforces /INTEGRITYCHECK for FIPS 140-2 modules
  • Exposed to consumers as Smart App Control and businesses as App Control for Business.
  • Part of the Device Guard technology stack.

Windows Defender System Guard

• Windows:
  • Monitors system integrity during boot and runtime.
  • Protects against rootkits and bootkits by verifying system integrity.

Windows Defender Application Guard

• Windows:
  • Runs untrusted content in isolated containers.
  • Protects the host from potentially malicious websites and documents.

Credential Guard

• Windows:
  • Uses VBS to isolate and protect credentials.
  • Prevents attacks like Pass-the-Hash or Pass-the-Ticket.

Device Guard

• Windows:
  • Combines WDAC and virtualization-based security to lock down devices.
  • Ensures only trusted applications can run.

OS Loader and Hotpatching Changes (Windows 11 24H2+)

• Recent Windows versions (24H2 and later) introduced changes that impact classic process injection techniques like Process Hollowing (RunPE).
• Status: Client Hotpatching availability and cadence depend on SKU/servicing channel. Validate GA status in current Microsoft documentation.
• Windows Server 2025 requires an Azure Arc subscription for hotpatch servicing.

Impact on Process Hollowing (MEM_PRIVATE Payloads)

• Root Cause 1 (Error 0xC0000141): Native Hotpatching support added a new function RtlpInsertOrRemoveScpCfgFunctionTable during process initialization (LdrpInitializeProcess -> LdrpProcessMappedModule). This function calls ZwQueryVirtualMemory with a new MemoryImageExtensionInformation class, which only works on MEM_IMAGE memory regions.
  • Classic Process Hollowing stores the payload in MEM_PRIVATE memory (either by unmapping the original PE or allocating a new region).
  • The ZwQueryVirtualMemory call fails with STATUS_INVALID_ADDRESS for the MEM_PRIVATE payload region, causing process loading to terminate.
• Root Cause 2 (Error 0xC00004AC, Memory Integrity Enabled): If Memory Integrity (HVCI) is enabled, another check occurs later in the loading process.
  • LdrpQueryCurrentPatch is called on the payload's memory region.
  • This leads to a call to NtManageHotPatch, which fails with STATUS_CONFLICTING_ADDRESSES for the MEM_PRIVATE payload.
  • This error also terminates the process loading.

Solutions and Bypasses

1. Use Alternative Techniques (Recommended): Employ methods that map the payload as MEM_IMAGE, which are unaffected by these specific checks.
   • Examples: Process Doppelganging, Process Ghosting, Process Herpaderping, Transacted Hollowing, Ghostly Hollowing, Herpaderply Hollowing, Process Overwriting.
   • These techniques generally interact more naturally with the loader and newer OS features.
2. Patch NTDLL (If sticking to Classic RunPE):
   • For 0xC0000141: Hook ZwQueryVirtualMemory.
     • Check if the OS is Win11 24H2+ (64-bit).
     • If the MemoryInformationClass is MemoryImageExtensionInformation AND the query targets the base address of the MEM_PRIVATE payload:
       • Return a benign error like STATUS_NOT_SUPPORTED instead of calling the original function.
     • Otherwise, call the original ZwQueryVirtualMemory.
     • Implementation Example
   • For 0xC00004AC (Memory Integrity): Hook NtManageHotPatch.
     • Patch the function to immediately return a benign error like STATUS_NOT_SUPPORTED.
     • Apply this patch early in the process creation, for both 32-bit and 64-bit.
     • Ensure FlushInstructionCache is called if patching after the function might have been cached.
     • 32-bit Example
     • 64-bit Example

Control Flow Integrity and Execution Protections

Data Execution Prevention (DEP)

• Windows/Linux:
  • Marks certain memory regions as non-executable.
  • Prevents execution of code from data pages, mitigating buffer overflow attacks.

Bypass Techniques

• Return-oriented Programming (ROP): Using existing code fragments to create attack chains without injecting code.
• ret2libc: Jump directly to code in libc.
• ret2data: Place shellcode in the data section.
• ret2strcpy: Place shellcode on the stack and use strcpy to move it somewhere executable.
• ret2gets: Read from stdin to gain control.
• VirtualProtect/VirtualAlloc: Call these functions to change memory permissions.
• JIT Spraying: Leverage Just-In-Time compilation to get executable memory.

Practitioner

• use !vprot rip or !vpro rsp to check for protections inside WinDbg
• .scriptload G:\Projects\narly.js; !nmod also helps you to see which modules have DEP protection
• Data Execution Prevention settings inside Windows Exploit Guard can be used to force DEP protection on an executable
• pivot with VirtualProtect / NtProtectVirtualMemory (or pre‑ACG RWX section) from a ROP/JOP chain.
• Modern Windows 10/11 enforce CET (Shadow Stack) and XFG (Cross‑Function Guard), which break classic ROP; successful chains must first disable CET (for example with SetProcessMitigationPolicy) or switch to JOP/SCS gadgets.
• an example would be pop rcx; retn; pop rcx; retn; mov [rcx], rax; pop rbp; retn;
• we can use IAT to identify and call WriteProcessMemory which can be used to circumvent DEP protection through NtProtectVirtualMemory API
• Ropper 2.0 or Rizin‑ropper — both support CET/XFG‑aware gadget filtering.

Control Flow Integrity (CFI)