claude-red is a curated library of offensive security skills designed for the Claude skills system. Each skill is a structured SKILL.md file that primes Claude with expert-level methodology for a spec
Install
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add SnailSploit/Claude-Red --skill offensive-mitigations -a cursor -y
claude-red is a curated library of offensive security skills designed for the Claude skills system. Each skill is a structured SKILL.md file that primes Claude with expert-level methodology for a specific attack surface — from SQLi to shellcode, EDR evasion to exploit development.
Questions
How do I install Claude-Red?
Download Skills/exploit-dev/offensive-mitigations/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does Claude-Red live?
The publisher keeps it at https://github.com/SnailSploit/Claude-Red.
Which agents can use Claude-Red?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
claude-red is a curated library of offensive security skills designed for the Claude skills system. Each skill is a structured SKILL.md file that primes Claude with expert-level methodology for a specific attack surface — from SQLi to shellcode, EDR evasion to exploit development.
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:
Load and apply the full methodology below as your operational checklist
Follow steps in order unless the user specifies otherwise
For each technique, consider applicability to the current target/context
Track which checklist items have been completed
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.
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:
Leak a tagged pointer
Strip tag bits (mask upper 8 bits)
Use untagged pointer for memory operations
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:
Pointer Forge: Attackers can craft tagged pointers without validation
Info Leak Bypass: Some sanitizers only check canonical addresses; LAM-tagged pointers pass checks
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.
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).
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.
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
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.
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.
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.0or Rizin‑ropper — both support CET/XFG‑aware gadget filtering.
Small Allocations: Using allocations smaller than the probe size to avoid triggering protection.
Alternative Memory Regions: Targeting other memory regions not protected by stack clash detection.
Implementation Gaps: Exploiting edge cases in the probing logic.
Hardware‑Enforced Stack Protection
Windows:
Utilizes Intel CET (specifically the Shadow Stack feature, referred to as Kernel Mode Hardware-enforced Stack Protection or KCET) and AMD Shadow Stack features.
Requires Hypervisor-Enforced Code Integrity (HVCI) / Virtualization-Based Security (VBS) to be enabled.
Provides a hardware-backed shadow stack to protect return addresses against ROP/JOP attacks.
Applies to kernel-mode stacks, including those associated with user-mode threads executing in kernel mode (e.g., during system calls).
Hardware-Enforced Stack Protection is enabled by default on compatible hardware with Windows 11, version 24H2, when VBS/HVCI is active. The IMAGE_GUARD_SHADOW_STACK PE flag indicates compatibility and is increasingly adopted for key binaries, with Windows components widely enabling it.
Bypass Techniques
Increased Difficulty with HVCI: When combined with Hypervisor-Enforced Code Integrity (HVCI), bypassing hardware-enforced shadow stacks becomes significantly more challenging. HVCI leverages virtualization (Hyper-V) to protect the shadow stack's integrity via the Secure Kernel (VTL1). The Secure Kernel manages the shadow stack pointer (VMX_GUEST_SSP in the VMCS for VTL0) through hypercalls, preventing even kernel-mode code (VTL0) from directly tampering with it.
Return Address Protection: The hardware compares the return address on the main stack with the one stored on the protected shadow stack before executing a RET instruction. Mismatches typically cause a fault (system crash for KCET), mitigating standard ROP/JOP attacks that rely on overwriting the return address on the main stack.
Secure Kernel Validation: The Secure Kernel is involved in validating and restoring shadow stack context (e.g., during exception handling via functions like nt!KeKernelShadowStackRestoreContext and secure system calls like securekernel!SkmmNtKernelShadowStackAssist), adding another layer of integrity checking.
Potential (Difficult) Vectors: Bypasses would likely require exploiting vulnerabilities in the hypervisor (Hyper-V) or the Secure Kernel itself, finding flaws in the hardware CET implementation, or developing sophisticated data-only attacks that achieve control without corrupting the stack's return addresses. These are considerably harder than bypassing software-based or unprotected hardware stack protections.
Limited Scope: Like other CFI mechanisms, attacks targeting non-control data or logic bugs may still be possible if they don't violate the protected control flow.
Pointer Authentication (ARM64)
Linux/iOS:
Uses cryptographic signatures to protect pointers.
Mitigates attacks like Return-Oriented Programming (ROP).
Bypass Techniques
Unprotected Assembly Code: Assembly code often lacks PAC protection.
Raw Function Pointers: Recovery handlers and other mechanisms that use raw pointers.
Signing Gadgets: Using existing code that signs pointers.
Switch Case Branches: Unprotected indirect branches in switch case implementations.
Thread State Manipulation: Incorrect handling of thread state during context switches.
Intel Control‑flow Enforcement Technology (CET)
Hardware feature providing protections against control-flow hijacking.
Includes Shadow Stack and Indirect Branch Tracking.
Enabled by default starting with Windows 11 build 26100 (Win11 24H2+). Any stack pivot or ret without a valid shadow‑stack token raises STATUS_STACK_BUFFER_OVERRUN (0xC0000409).
Detect CET: Read the IMAGE_DLLCHARACTERISTICS_GUARD_CF flag in the PE header or PEB→LdrDataTableEntry.GuardFlags.
Windows: Get-ProcessMitigation -System shows UserShadowStack and UserCetEnabled.
Linux: check cet_ss in /proc/cpuinfo and prctl(PR_SET_SHADOW_STACK_STATUS, ...).
Bypass tips for CET in shellcode:
Align the shellcode entry to a valid call target and emit ENDBR64/SETSSP before the first ret.
Use ROP‑less staging (queued APC, NtContinue, or NtTestAlert) so the kernel performs the first return.
Intel Indirect Branch Tracking (IBT)
Linux/Windows:
Part of Intel CET that enforces legitimate indirect branch targets.
Requires ENDBR32 or ENDBR64 instructions at valid indirect call/jump destinations.
Prevents JOP (Jump-Oriented Programming) attacks by validating branch targets.
Available on Tiger Lake+ CPUs, enabled via CET_IBT bit in MSR.
Bypass Techniques
ENDBR Gadgets: Finding existing code sequences that start with valid ENDBR32/64 instructions.
ENDBR Spraying: Injecting or finding multiple ENDBR instructions to create gadget chains.
Unprotected Modules: Targeting libraries or code not compiled with IBT support.
Legacy Code Paths: Exploiting code paths that bypass IBT checks (e.g., signal handlers, exception contexts).
Hardware Quirks: Exploiting CPU-specific implementation differences or errata.
Practitioner
Check IBT status: cat /proc/cpuinfo | grep cet_ibt (Linux) or inspect cr4.cet bit
Compile with IBT: -fcf-protection=branch (GCC) or -mcet flag
Binary analysis: Look for ENDBR64 (0xF3 0x0F 0x1E 0xFA) or ENDBR32 (0xF3 0x0F 0x1E 0xFB) instructions
Shadow Call Stack (SCS)
Linux:
Compiler-based CFI mechanism using a shadow stack to protect return addresses.
Helps prevent ROP attacks.
Ensures only signed and verified code can execute in kernel mode.
Blocks RWX pages and unsigned kernel callbacks when Memory Integrity is ON (default on 2024‑hardware).
Common allocation pattern for executable memory: PAGE_READWRITE → write payload → NtProtectVirtualMemory → PAGE_EXECUTE_READ.
WoW64 heaven‑gate patches to WOW64CFG are rejected by HVCI; favour direct 64‑bit syscalls (e.g., via wow64log).
Bypass Techniques
Data‑only Attacks (no return‑address writes).
Hypervisor/Kernel Bugs that corrupt GCS state.
Guarded Control Stack (GCS)
Linux/ARM64:
Hardware user‑space shadow stack on Armv9‑A CPUs, merged in Linux 6.13 and on by default in modern Android.
From Android 16, GCS (shadow stack) plus Privileged Access Never (PAN) are mandatory for all Play‑targetSdk 34+ apps running on Armv9 Realms hardware, providing dual hardware + software enforcement.
Bypass Techniques
Data‑only Attacks (no return‑address writes).
Hypervisor/Kernel Bugs that corrupt GCS state.
FineIBT
Linux:
Enhanced CFI mechanism for indirect branch targets.
Provides finer-grained control flow protection than basic CFI.
The initial implementation was vulnerable to Branch History Injection (BHI). Hardened FineIBT with serialising INT3 fences landed upstream in Linux 6.14
Arbitrary Code Guard (ACG)
Windows:
Prevents processes from allocating or modifying memory to be executable.
Mitigates attacks relying on dynamic code generation or modification.
Protects the integrity of exception handler chains on the stack.
Prevents exploits that overwrite exception handlers to gain control flow.
Bypass Techniques
Modules Without SafeSEH: A single module without protection breaks the chain.
ROP Chains: Building ROP chains that don't rely on exception handlers.
Alternative Attack Vectors: Targeting other vulnerable components not protected by SEHOP.
Unprotected Exception Handlers: Finding handlers that are still vulnerable.
Exploit Address Table Filtering (EAF & EAF+)
Windows:
Blocks access to Export Address Tables of critical DLLs like kernel32.dll and ntdll.dll.
EAF+ allows specifying modules not permitted to access the EAT, particularly targeting UAF bugs.
Uses hardware breakpoints to filter access attempts.
Bypass Techniques
Alternative Discovery Methods: Using different techniques to locate functions.
Unprotected Modules: Targeting modules not covered by EAF protection.
Import Address Filtering (IAF)
Windows:
Ensures all functions listed in a DLL's IAT exist within the image's load address range.
Prevents IAT overwrite attacks.
Virtual Table Guard
Windows:
Ensures virtual function table pointers point to valid guard pages.
Terminates execution if invalid vptrs are detected.
Protects against C++ virtual function table overwrites.
MemGC
Windows:
Replacement for MemProtect technology.
Specifically targets mitigation of use-after-free exploitation.
Kernel Text Read-only Region (KTRR)
iOS:
Prevents modification of the iOS kernel at runtime.
Implements hardware-enforced read-only memory for kernel code.
KTRR‑v2 & FastPAC (iOS 18, A18/A19)
Hardware‑enforced cache‑colouring prevents pointer‑authentication re‑spray, complementing traditional KTRR for stricter kernel integrity.
Intel Memory Protection Extensions (MPX)
[!NOTE]
Support was removed from Linux 5.6 (April 2020) and GCC 9.1; no mainstream OS or compiler ships MPX today.
Heap Protections
Heap Cookies
Windows:
Places a 1-byte value in the metadata of heap chunks.
Detects heap metadata corruption before exploitation.
AMSI Heap Scanning (Jan 2025)
Windows:
AMSI (Antimalware Scan Interface) scans newly committed writable heap pages before they are flipped to PAGE_EXECUTE_READ or PAGE_EXECUTE_WRITECOPY.
Safer allocation pattern to avoid AMSI heap scanning: Reserve memory with PAGE_NOACCESS, decrypt/deobfuscate payload in‑place, then change protection to PAGE_EXECUTE_READ.
The classic "patch the AMSI ASCII tag in amsi.dll" trick no longer works reliably; consider patching the COM VTable entry for IAmsiStream::QueryInterface or using a proxy‑DLL hook instead.
Low Fragmentation Heap (LFH)
Windows:
First 32-bit of metadata gets XORed with canary to ensure integrity.
Allocates blocks in predetermined size ranges by organizing blocks into buckets.
Reduces heap predictability and exploitation potential.
Safe Unlink
Windows/Linux:
Checks integrity of pointers before freeing memory chunks.
Prevents unlink exploitation in heap management.
Bypass Techniques
Heap Overflow: Using malloc maleficarum techniques.
Chunk-on-Lookaside Overwrite: Targeting specific heap management structures.
Heap and Stack Protections
Windows:
Implements guard pages and heap allocation randomization.
Detects and prevents buffer overflows and stack smashing.
Randomization Techniques
Address Space Layout Randomization (ASLR)
Linux & Windows:
Randomizes memory addresses used by executables and libraries.
Makes it harder for attackers to predict target addresses.
Bypass Techniques
Information Leaks: Exploiting vulnerabilities to leak addresses of loaded modules.
ROP with PLT/GOT: Using the Procedure Linkage Table to leak addresses and calculate base addresses.
Low Entropy: Exploiting systems with limited randomization bits.
Heap Spraying: Filling memory with copies of shellcode to increase hit probability.
Local Privilege Escalation: Using local exploits to bypass protection.
Partial Overwrite: Overwriting only part of an address to maintain alignment.
Statically Linked Code: Targeting code that doesn't use ASLR.
Practitioner
you probably first need an information leak to identify the correct memory address and then use it to circumvent ASLR and DEP
format string bugs also helps trigger an information leak, so you can use them alongside ropchains to bypass ASLR and DEP
information leaks are often happen through logical errors or memory corruption bugs
Position Independent Executables (PIE)
Linux/Windows:
Compiles executables as position-independent code, enabling ASLR for the main executable.
Without PIE, the main executable loads at a fixed base address, providing attackers a reliable target.
Essential for full ASLR coverage across all memory regions.
Bypass Techniques
Information Leaks: Same techniques as ASLR bypass - leak addresses to calculate base.
Partial Overwrites: Overwriting only the lower bytes of addresses to maintain relative offsets.
Non-PIE Dependencies: Targeting linked libraries that aren't position-independent.
GOT/PLT Attacks: Exploiting Global Offset Table entries before they're resolved.
Practitioner
Check PIE status: file /path/to/binary or readelf -h /path/to/binary | grep Type
Compile with PIE: -fPIE -pie (GCC) or -fPIC -shared for libraries
Detect at runtime: /proc/PID/maps shows randomized executable base addresses
checksec: checksec --file=/path/to/binary shows PIE status
ASCII Armored Address Space
Windows:
Loads all shared libraries in addresses starting with 0x00.
Prevents string manipulation exploits that terminate at null bytes.
Bypass Techniques
Partial Injection: Still possible to inject one null byte.
Main Executable Attacks: Main executable is not moved, so attackers can target it instead.
Function Granular KASLR (FGKASLR)
Linux:
Randomizes kernel functions at a finer granularity.
Enhances address space randomization effectiveness.
Kernel Stack Randomization
Linux:
Randomizes the kernel stack base address per process.
Makes stack-based attacks more challenging.
Mandatory ASLR (MASLR)
Windows:
Forces the rebasing of modules even when they were compiled without ASLR support.
Enhances protection against code reuse attacks.
Bottom-Up ASLR (BASLR)
Windows:
Works alongside MASLR to randomize allocation patterns.
Blocks 64KB allocations from requested base address up to a randomly selected number.
Repeats randomization each time the process restarts.
Side-Channel Attack Mitigations
Speculative Execution Mitigations
Linux/Windows:
Addresses vulnerabilities like Spectre and Meltdown.
Includes microcode updates and patches to prevent speculative execution attacks.
Recent Spectre Mitigations
IBPB (Indirect Branch Prediction Barrier):
Intel/AMD feature that flushes indirect branch predictors.
Container security scanning: Tools like docker-bench-security, kube-bench
Lockdown Mode
Linux:
Restricts access to kernel features that could allow code execution.
Enhances security, especially with Secure Boot enabled.
Linux 6.14 extends lockdown to cover kexec‑file pinning and loads the built‑in module blocklists earlier, further closing BYOVD avenues.
Executable‑policy Securebits
Linux 6.14: Introduces SECBIT_EXEC_RESTRICT_FILE and SECBIT_EXEC_DENY_INTERACTIVE securebits together with the AT_EXECVE_CHECK flag, allowing interpreters to delegate final execution‑permission checks to the kernel and tightening script/loader abuse paths.
NTSYNC Driver Hardening
Linux 6.14: The new ntsync driver offers an io_uring‑based fast‑path that removes classic futex primitives from reachable attack surface, reducing user→kernel synchronization abuse.
Landlock LSM
Linux:
Unprivileged sandboxing framework allowing processes to restrict their own access rights.
Reduces the impact of compromised user-space applications.
AppContainer and User Account Control (UAC)
Windows:
AppContainer: Application isolation for modern apps.
UAC: Limits application privileges, prompting for elevation when necessary.
PatchGuard (KPP)
Windows:
Protects the kernel from modifications of critical structures and registers.
Periodically checks for unauthorized modifications to kernel structures.
Used for secure boot, disk encryption, and credentials.
Secure Boot
Windows/Linux:
Ensures only trusted, signed software loads during boot.
Prevents boot-level malware from starting before the OS.
UEFI Firmware Security
Windows/Linux:
Provides a secure pre-OS environment.
Supports Secure Boot and firmware integrity checking.
Diagrams
Modern Security Architecture
flowchart TB
System["System Security"]
subgraph "Memory Protection"
KASLR["Kernel ASLR"]
KPTI["Kernel Page Table Isolation"]
SMAP["Supervisor Mode Access Prevention"]
SMEP["Supervisor Mode Execution Prevention"]
KDP["Kernel Data Protection"]
RODATA["Read-Only Data Sections"]
end
subgraph "Virtualization Security"
VBS["Virtualization-Based Security"]
HVCI["Hypervisor-Enforced Code Integrity"]
MBEC["Mode-Based Execution Control"]
KMCI["Kernel Mode Code Integrity"]
end
subgraph "Control Flow Protection"
CFG["Control Flow Guard"]
CET["Control-Flow Enforcement Technology"]
KCFG["Kernel Control Flow Guard"]
end
System --> KASLR
System --> KPTI
System --> SMAP
System --> SMEP
System --> KDP
System --> RODATA
System --> VBS
System --> HVCI
System --> MBEC
System --> KMCI
System --> CFG
System --> CET
System --> KCFG
Download Skills/exploit-dev/offensive-mitigations/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does Claude-Red live?
The publisher keeps it at https://github.com/SnailSploit/Claude-Red.
Which agents can use Claude-Red?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.