目录
- 导语:EDR对抗进入"显微手术"时代
- EDR架构原理:三层检测体系
- 2026年绕过技术体系全景
- 四大EDR产品检测盲点分析
- PoC原理详解:六大核心绕过技术
- 绕过技术对比矩阵
- 防御建议:从被动检测到主动免疫
- 个人技术观点
- 参考来源
- 网络安全免责声明
导语:EDR对抗进入"显微手术"时代
2026年的终端安全战场,EDR已经不再是简单的"高级杀毒软件"。以CrowdStrike Falcon、SentinelOne Singularity、Microsoft Defender for Endpoint(MDE)和Palo Alto Cortex XDR为代表的下一代EDR产品,构建了一套从用户态到内核态、从静态特征到行为模型的多层检测体系。它们通过DLL注入hook关键API、注册内核回调监控进程/线程生命周期、订阅ETW(Event Tracing for Windows)获取系统遥测,并依托云端AI行为分析引擎进行异常判定。
然而,攻防对抗的本质是"成本与收益"的博弈。攻击者发现,完全绕过EDR的检测并非必须——只需要在关键注入环节制造"时间差"或"空间差",使EDR的检测信号与恶意行为失配,即可达成目标。2024年公开的HookChain研究[1]展示了通过IAT Hooking结合动态SSN解析和间接Syscall,可在不修改应用源码的情况下完全绕过基于ntdll.dll的监控机制。2025-2026年,SindriKit[2]、Ekko sleep obfuscation、硬件断点清除hook等技术进一步将对抗推向内核边缘。
本文将从架构原理出发,逐层拆解六大类绕过技术的实现逻辑,并结合四大EDR的架构特点分析其具体盲点。
EDR架构原理:三层检测体系
要理解绕过技术,必须先理解EDR的"感官系统"。现代EDR的检测体系可抽象为三层:用户态hook层、内核态回调/遥测层、云端行为分析层。
1. 用户态Hook(Userland API Hooking)
用户态hook是EDR最前线的检测机制。EDR驱动(Kernel Driver)将自身的Sensor DLL注入到每个用户态进程中,该DLL通过修改ntdll.dll中关键Native API函数的前几个字节(通常是jmp指令),将执行流重定向到EDR的分析代码中。
典型被hook的函数包括:
NtAllocateVirtualMemory/NtProtectVirtualMemory—— 监控RWX内存分配NtWriteVirtualMemory—— 监控进程内存写入(注入行为)NtCreateThreadEx/NtQueueApcThread—— 监控远程线程创建NtMapViewOfSection—— 监控共享内存映射
当进程调用这些API时,EDR可检查参数(如目标进程句柄、内存保护属性、写入内容特征等),若判定为可疑行为则生成遥测数据或立即阻断。
** Hook的实现方式**:
| Hook类型 | 原理 | 典型实现 |
|---|---|---|
| Inline Hook | 修改函数前5-20字节为jmp | 最普遍 |
| IAT Hook | 修改导入地址表指针 | 易于绕过 |
| SSDT Hook | 修改系统服务描述符表 | 已较少使用(PatchGuard) |
2. 内核态回调与ETW(Kernel Callbacks / ETW Telemetry)
用户态hook存在天然的绕过可能(攻击者可以直接发Syscall),因此现代EDR将关键检测能力下沉到内核态。
内核回调机制:
Windows内核提供了一系列回调注册接口,EDR驱动通过它们订阅系统事件:
PsSetCreateProcessNotifyRoutine(Ex)—— 进程创建通知PsSetCreateThreadNotifyRoutine(Ex)—— 线程创建通知PsSetLoadImageNotifyRoutine—— 映像加载通知ObRegisterCallbacks—— 对象句柄操作通知- Minifilter驱动 —— 文件系统操作监控
这些回调由内核在关键事件发生时直接调用,位于Ring 0,用户态程序理论上无法直接篡改。但研究表明,通过BYOVD(Bring Your Own Vulnerable Driver)或已签名的第三方驱动漏洞,攻击者可以获得内核级内存读写能力,进而清零回调例程地址、注销回调或patch回调代码[3][4]。
ETW遥测:
ETW是Windows内置的高性能事件追踪框架。EDR广泛订阅以下Provider:
Microsoft-Windows-Kernel-Process—— 进程/线程生命周期事件Microsoft-Windows-Kernel-Audit-API-Calls—— 关键API审计调用Microsoft-Windows-Threat-Intelligence—— 威胁情报专用通道
ETW事件在内核态生成,通过高性能缓冲区传递到用户态消费者。由于ETW Provider本身运行在用户态的ntdll.dll中(如EtwEventWrite),这成为后续ETW Patch技术的攻击面。
3. 行为分析引擎(Behavioral Analytics / AI Detection)
遥测数据最终会汇集到EDR的本地Agent Service或云端分析引擎。现代EDR(尤其是CrowdStrike和SentinelOne)大量采用以下技术:
- IOA(Indicators of Attack):基于攻击链行为的规则引擎,而非静态IoC
- 无监督机器学习:识别偏离基线的异常行为
- 跨进程关联分析:将看似无害的单点操作串联成攻击链
- 内存扫描:定期扫描进程内存中的已知shellcode特征
行为分析层虽然强大,但其前提是"获得足够多且真实的遥测数据"。如果底层hook或ETW被抑制,上层分析将失去输入源——这正是"遥测欺骗"类技术的核心思路。
2026年绕过技术体系全景
基于公开研究,当前Windows EDR绕过技术可分为六大类,形成一个从"用户态欺骗"到"内核态压制"的连续谱:
┌─────────────────────────────────────────────────────────────┐
│ EDR Bypass Taxonomy 2026 │
├─────────────────────────────────────────────────────────────┤
│ 用户态层 │ Direct Syscall → Indirect Syscall + SSN解析 │
│ │ → IAT Hooking (HookChain) → DLL Unhooking │
├─────────────────────────────────────────────────────────────┤
│ 内存操作层 │ Process Hollowing → Process Doppelgänging │
│ │ → Process Herpaderping → Module Stomping │
├─────────────────────────────────────────────────────────────┤
│ 遥测抑制层 │ ETW Patching → AMSI Bypass → Hardware BP │
│ │ Hook Removal │
├─────────────────────────────────────────────────────────────┤
│ 休眠对抗层 │ Sleep Obfuscation (Ekko/Foliage) │
├─────────────────────────────────────────────────────────────┤
│ 内核压制层 │ Kernel Callback Removal (BYOVD) │
└─────────────────────────────────────────────────────────────┘
四大EDR产品检测盲点分析
CrowdStrike Falcon
架构特点:
- 轻量级agent,大量依赖云端AI分析(Threat Graph)
- 用户态hook + 内核回调 + ETW三重遥测
- 以IOA(攻击指标)为核心检测逻辑,强调跨进程行为链关联
已知盲点与绕过路径:
-
遥测断链:CrowdStrike的云端AI虽然强大,但如果本地agent的ETW或hook被抑制,云端无法获得足够数据生成IOA。2025年的研究表明,通过
EtwEventWritepatch可在不触发内核态防护的情况下使关键遥测沉默[5]。 -
用户态hook绕过:CrowdStrike的hook集中在
ntdll.dll。通过Indirect Syscall或HookChain技术[1:1],可完全绕过其用户态监控,而Falcon的内核回调在纯内存操作(不创建新进程/线程)场景下检测粒度不足。 -
Sleep检测盲区:Falcon对beacon休眠期间的内存扫描依赖特定触发条件。使用Ekko等sleep obfuscation技术将可执行内存加密/换页,可规避内存特征扫描。
SentinelOne Singularity
架构特点:
- 强调"自主响应"(Autonomous Response),agent本地决策能力强
- 对内核访问做了限制,"kernel access is limited to provide visibility and anti-tampering measures only"[6]
- 用户态行为监控 + 内存分析引擎(Storyline)
已知盲点与绕过路径:
-
Storyline依赖用户态遥测:SentinelOne的Storyline技术通过关联进程行为构建攻击叙事。如果攻击者使用硬件断点清除hook[7]而非patch内存,可在不触发内存完整性告警的情况下恢复原始
ntdll函数流,使Storyline失去关键事件节点。 -
模块加载信任盲区:Module Stomping技术利用SentinelOne对已签名、合法DLL的初始加载信任——在加载完成后覆盖其
.text段,此时EDR仍认为该模块是"干净的"。 -
Ranger轻量性:SentinelOne Agent号称轻量,但也意味着其内核回调覆盖不如CrowdStrike全面。针对纯用户态内存注入(不触发进程/线程创建回调),存在一定盲区。
Microsoft Defender for Endpoint(MDE)
架构特点:
- 深度集成Windows系统,可访问独有的内核接口和 Defender 驱动
- ASR(Attack Surface Reduction)规则提供强力预防性控制
- 内存完整性(HVCI)和Credential Guard作为系统级防护
已知盲点与绕过路径:
-
ASR规则绕过:MDE的ASR规则依赖特定触发条件。通过Process Herpaderping[8]修改磁盘上的文件内容后再映射执行,可在不触发"Block executable files from running unless they meet a prevalence, age, or trusted list criterion"规则的情况下启动恶意代码。
-
HVCI下的内存操作:HVCI(Hypervisor-protected Code Integrity)确实阻止了非签名驱动的加载和内核patch,但在用户态层面,Direct Syscall + Indirect Syscall组合仍然有效,因为HVCI不拦截用户态到内核态的合法syscall路径。
-
ETW原生依赖:MDE对ETW的依赖程度高于其他EDR。通过patch
EtwEventWrite为ret或xor rax, rax; ret[9],可导致MDE的部分检测通道直接沉默。
Palo Alto Cortex XDR
架构特点:
- XDR强调跨端点、网络、云的统一分析
- 检测逻辑高度依赖行为分析代理(Behavioral Analytics Agent)
- 相比其他三家,在内核态驱动层面的公开研究较少
已知盲点与绕过路径:
-
线程级遥测延迟:公开材料指出,CrowdStrike Falcon Insight XDR存在"无法按事件发送线程级进程数据"的局限,Cortex XDR同样面临线程级遥测粒度与性能的平衡问题[10]。攻击者可通过短生命周期线程(瞬时注入后立即自销毁)减少被捕获的概率。
-
跨平台统一agent的兼容性成本:Cortex XDR作为跨平台产品,其Windows agent需要在兼容性与深度监控之间取舍。对Windows特有机制(如NTFS Transaction、Section Object)的监控粒度可能不如原生Windows EDR。
-
DLL Hook集中度高:与其他EDR类似,Cortex XDR的用户态hook集中在
ntdll.dll和kernel32.dll。HookChain[1:2]技术通过重定向kernel32.dll→kernelbase.dll的执行流,使其hook失效。
PoC原理详解:六大核心绕过技术
技术一:Syscall直接调用(Direct Syscall)
核心原理:绕过用户态hook的最直接方法——不经过被hook的ntdll.dll导出函数,而是自己构造syscall指令。
实现思路:
- 从
ntdll.dll的.text段中提取目标函数的syscall stub(包含mov r10, rcx、mov eax, SSN、syscall、ret的指令序列) - 将提取的stub复制到自身内存中
- 直接调用该stub,参数通过RCX、RDX、R8、R9等寄存器传递(遵循Windows x64调用约定)
关键API:NtAllocateVirtualMemory、NtWriteVirtualMemory、NtCreateThreadEx
检测难点:由于直接执行了与合法ntdll完全相同的syscall指令序列,单纯基于调用来源的检测难以区分。
EDR应对:部分EDR开始监控"非ntdll内存区域内的syscall指令",或检测内存中是否存在从ntdll复制而来的stub。这催生了Indirect Syscall。
技术二:间接Syscall + Syscall桩(Indirect Syscall / Halo's Gate)
核心原理:不自己生成syscall指令,而是跳转到ntdll.dll中真实函数体内、EDR hook之后的地址执行。这样既绕过了hook,又不会因"非法位置的syscall指令"被检测。
实现思路:
- 读取
ntdll.dll中目标函数的原始字节 - 若函数被hook(前几个字节是
jmp),向上/向下遍历相邻函数的stub,通过已知相邻函数的SSN推算目标函数SSN(Halo's Gate技术) - 计算
ntdll中该函数stub内syscall指令的确切地址(hook之后的位置) - 使用
jmp或call跳转到该地址,完成"间接syscall"
Sleep Obfuscation关联:现代C2(如Havoc[11])将Indirect Syscall与sleep obfuscation结合。当beacon进入休眠时,通过VEH(Vectored Exception Handler)或APC(Asynchronous Procedure Call)触发内存加密/解密,使EDR的内存扫描无法发现明文shellcode。
关键API:NtDelayExecution + 自定义Timer + VEH处理异常
技术三:Process Doppelgänging / Process Herpaderping
这两种技术都利用Windows文件系统与进程创建机制的时间差,实现"无文件"或"文件内容欺骗"的进程注入。
Process Doppelgänging(Windows 7+):
- 使用
NtCreateTransaction创建一个NTFS Transaction - 在该Transaction中创建一个新的文件映射(Section),写入恶意PE
- 回滚Transaction,使磁盘上不留恶意文件痕迹
- 使用
NtCreateProcessEx从已创建的Section启动进程 - 进程启动时,EDR看到的文件内容已经因回滚而"消失"
Process Herpaderping(Windows 10+改进):
- 在磁盘上创建一个合法文件并获取句柄
- 使用该句柄创建Section(此时文件内容合法)
- 在进程创建前,通过同一句柄将文件内容覆盖为恶意代码
- EDR在进程创建时读取磁盘文件进行扫描,看到的是恶意内容
- 但内核在创建进程时使用的是之前创建的Section(合法内容),导致EDR的扫描结果与实际执行内容不一致
关键API:NtCreateTransaction、NtCreateSection、NtCreateProcessEx、NtWriteFile
技术四:Module Stomping / DLL Unhooking
Module Stomping(模块踩踏/幻影):
- 向目标进程加载一个合法的、已签名的DLL(如
kernel32.dll或comctl32.dll) - EDR会记录该DLL的加载事件,并可能进行完整性校验
- 等待加载完成后,使用
NtProtectVirtualMemory将该DLL的.text段改为RWX - 将shellcode写入
.text段,覆盖原始函数代码 - 创建远程线程,执行被覆盖的DLL内存区域
- EDR看到的模块列表中,该区域仍然显示为"合法DLL"
DLL Unhooking(DLL脱钩):
与Module Stomping的"覆盖合法模块"不同,DLL Unhooking的目的是恢复被EDR hook的ntdll函数原始字节。
- 从磁盘读取原始的
ntdll.dll文件(或从已知干净的内存区域复制) - 对比内存中
ntdll函数与被hook的字节差异 - 使用
NtProtectVirtualMemory将ntdll对应页面改为可写 - 将原始字节写回,恢复函数前序指令
- 恢复内存保护属性
硬件断点清除hook(Hardware Breakpoint Hook Removal):
这是DLL Unhooking的进化版。为了不修改ntdll内存(避免触发EDR的内存完整性检测),攻击者使用CPU调试寄存器(DR0-DR3)在AmsiScanBuffer或hook函数上设置硬件断点,配合VEH在断点触发时动态修改执行流,实现"无内存patch"的hook绕过[7:1]。
技术五:ETW Patching / AMSI Bypass
ETW Patching:
ETW Provider的写入函数EtwEventWrite位于ntdll.dll中。由于它最终是用户态函数,因此可以被patch:
- 定位
ntdll!EtwEventWrite - 修改其前几个字节为
ret(0xC3)或xor rax, rax; ret(0x48 0x33 0xC0 0xC3) - 此后该进程内所有ETW事件写入立即返回,不产生任何遥测
影响:严重。EDR高度依赖ETW获取系统级遥测,patch后相当于"致盲"EDR的部分感知能力。
AMSI Bypass:
AMSI(Anti-Malware Scan Interface)是Windows的恶意软件扫描接口,被PowerShell、.NET、Office等调用。常见绕过方式:
- Patch
AmsiScanBuffer:将amsi.dll中的AmsiScanBuffer函数patch为始终返回AMSI_RESULT_CLEAN - Patch
AmsiInitialize:使AMSI初始化失败 - Hardware Breakpoint法:在
AmsiScanBuffer上设置硬件断点,通过VEH在调用时修改返回值[7:2] - Patchless AMSI Bypass:通过修改
AmsiContext结构体中的扫描函数指针,而非patch代码本身,规避基于代码完整性的检测[5:1]
关键API:EtwEventWrite、AmsiScanBuffer、AmsiInitialize
技术六:Sleep Obfuscation(内存加密休眠)
C2 beacon在休眠期间内存中的shellcode是静止的,EDR可能在此期间进行内存扫描。Sleep Obfuscation通过在休眠前加密/混淆内存中的敏感区域,醒来后再解密,实现"扫描时不可见"。
Ekko技术:
- 使用
NtCreateTimer/SetThreadpoolTimer创建定时器 - 在休眠前,将 beacon 内存区域加密,并将解密代码注册为APC或VEH处理器
- 当定时器到期时,通过APC/VEH触发解密,恢复执行上下文
- 部分实现还会在此期间将内存属性改为不可执行(
PAGE_NOACCESS),进一步规避内存扫描
关键API:NtCreateTimer、NtQueueApcThread、RtlEncryptMemory、VEH注册
绕过技术对比矩阵
| 技术名称 | 核心原理 | 运行层级 | 检测难度 | 主要影响EDR | 稳定性 | 代表性工具/项目 |
|---|---|---|---|---|---|---|
| Direct Syscall | 自行构造syscall指令,跳过ntdll hook | 用户态 | 中等 | 所有依赖ntdll hook的EDR | 高 | SysWhispers3, Halo's Gate |
| Indirect Syscall | 跳转到ntdll中hook之后的地址执行 | 用户态 | 高 | 所有依赖ntdll hook的EDR | 高 | Hell's Gate, HookChain[1:3] |
| Process Doppelgänging | 利用NTFS Transaction回滚实现无文件执行 | 内核态接口 | 高 | MDE, Cortex XDR | 中 | Transacted Hollowing |
| Process Herpaderping | 进程创建前后修改文件内容造成扫描不一致 | 内核态接口 | 高 | CrowdStrike, MDE | 中 | Herpaderping PoC |
| Module Stomping | 加载合法DLL后覆盖其.text段 | 用户态 | 高 | SentinelOne, Cortex XDR | 高 | 各类C2植入器 |
| DLL Unhooking | 恢复被EDR修改的ntdll原始字节 | 用户态 | 中等 | 所有用户态hook型EDR | 高 | EDRSandBlast[4:1] |
| Hardware BP Hook Removal | 使用DR寄存器设置硬件断点,动态修改执行流 | 用户态 | 极高 | CrowdStrike, SentinelOne | 中 | Chimera[12] |
| ETW Patching | Patch EtwEventWrite使其直接返回 |
用户态 | 中等 | MDE(依赖最重)、Falcon | 高 | SharpSploit |
| AMSI Bypass | Patch AmsiScanBuffer或劫持其上下文 |
用户态 | 低-中等 | MDE, 所有AMSI集成产品 | 高 | AMSI.fail |
| Sleep Obfuscation | 休眠期间加密/隐藏内存中的shellcode | 用户态 | 高 | Falcon, SentinelOne | 中 | Ekko, Foliage |
| Kernel Callback Removal | 通过内核驱动移除EDR注册的内核回调 | 内核态 | 极高 | 所有EDR | 低(易BSOD) | EDRSandBlast, RealBlindingEDR[3:1] |
防御建议:从被动检测到主动免疫
1. EDR自身加固方向
用户态Hook加固:
- Canary Hook:在hook函数前后插入检测用"金丝雀"指令,若发现指令被恢复则触发告警
- 多位置Hook:不仅hook
ntdll函数入口,还在kernel32、kernelbase等上层DLL中设置冗余hook - HookChain防护:监控IAT(Import Address Table)的异常修改,检测执行流是否被重定向到非预期模块[1:4]
内存完整性保护:
- 对关键系统DLL(
ntdll、kernel32、amsi)的.text段启用写保护监控 - 检测
NtProtectVirtualMemory将内存属性改为RWX的行为,尤其是针对已加载模块的操作 - 定期校验内存中关键DLL的哈希,与磁盘原始版本对比
2. 行为分析补充
跨层关联:不要仅依赖单一层面的遥测。例如:
- 当检测到Direct Syscall时,结合ETW的
KERNEL_AUDIT_API_SETCONTEXTTHREAD事件进行交叉验证 - 当发现
EtwEventWrite被patch时,即使当前没有其他告警,也应将该进程标记为高风险
异常行为建模:
- 监控进程中是否存在非
ntdll区域的syscall指令执行 - 监控调试寄存器(DR0-DR3)的异常使用——正常业务程序极少使用硬件断点
- 监控VEH(Vectored Exception Handler)的频繁注册/注销,这可能是Sleep Obfuscation或硬件断点攻击的信号
进程创建增强检测:
- 对Process Doppelgänging/Herpaderping,监控
NtCreateTransaction与NtCreateSection的组合调用 - 在进程创建完成点(而非创建前)重新扫描映像文件,避免时间差攻击
3. 内核态与系统级防护
BYOVD防护:
- 严格管控驱动签名策略,仅允许已知、可信的驱动加载
- 启用Microsoft的 vulnerable driver blocklist(微软维护的已知漏洞驱动黑名单)
- 使用HVCI(Hypervisor-protected Code Integrity)阻止未签名驱动加载
内核回调完整性:
- 定期枚举
PspCreateProcessNotifyRoutine、PspCreateThreadNotifyRoutine等回调数组 - 监控
ObRegisterCallbacks的注册与注销操作 - 对内核回调例程的代码段进行完整性校验
ETW增强:
- 不依赖单一ETW Provider,多源交叉验证
- 在ETW消费者层增加心跳检测——若预期应收到的事件长时间缺失,触发"遥测沉默"告警
个人技术观点
2026年的EDR绕过技术已经形成了完整的工程化体系。从最早的简单DLL Unhooking,发展到如今的HookChain、硬件断点、内核回调移除,攻击者的技术栈正在向"更底层、更隐蔽、更难以区分正常行为"的方向演进。
几个值得关注的趋势:
-
用户态hook的末日:单纯依赖
ntdllinline hook的EDR架构已经难以应对Indirect Syscall和HookChain。未来的EDR必须向内核态和硬件辅助虚拟化(Intel VT-x/AMD-V)下沉,或采用AI驱动的行为基线模型。 -
遥测完整性比遥测丰富度更重要:拥有1000个ETW Provider但无法保证其数据不被篡改,不如拥有100个但具备完整性校验的Provider。EDR厂商需要将"防篡改"作为与"检测"同等重要的设计目标。
-
Sleep Obfuscation将成为标配:随着EDR内存扫描的普及,C2的休眠期已不再安全。Ekko、Foliage等技术会被集成到所有主流C2框架中,EDR必须发展"休眠期持续监控"能力——例如通过定时器触发的轻量内存指纹扫描。
-
BYOVD仍是最大威胁:内核回调移除技术的核心前提是获得内核写能力。在Windows生态中,有签名的漏洞驱动是获得这一能力的"捷径"。微软的驱动黑名单策略虽好,但存在更新滞后性。企业应结合自身环境建立驱动白名单,而非仅依赖黑名单。
-
攻防不对称性在缩小,但并未逆转:EDR的检测逻辑正在从"签名+规则"转向"行为+AI",这在理论上可以检测到未知绕过技术。但攻击者同样在使用AI辅助生成绕过代码(如自动化SSN解析、自动化call stack spoofing)。未来的胜负手可能在于"谁能在更短的时间内完成从检测到绕过、或从绕过到检测的迭代"。
参考来源
网络安全免责声明
本文所述技术仅供网络安全研究、授权渗透测试及防御加固参考之用。文中涉及的所有技术细节、API调用原理及绕过思路均基于已公开发表的学术研究、安全博客和行业报告整理而成,不涉及任何完整的攻击利用代码或可用于实际入侵的工具分发。
严禁将本文内容用于以下行为:
- 未经授权访问计算机信息系统
- 破坏计算机信息系统功能或数据
- 制作、传播恶意程序
- 对他人网络或系统进行任何形式的渗透测试(未获得书面授权)
读者应遵守《中华人民共和国网络安全法》及相关法律法规,仅在合法授权范围内开展安全研究和测试活动。因违反法律法规或滥用本文信息所造成的任何后果,由行为人自行承担全部法律责任,与本文作者及发布平台无关。
安全研究的价值在于提升防御能力。建议企业安全团队基于本文思路,定期对自身EDR部署进行红队评估,发现检测盲区并及时加固,而非将技术用于非法目的。
本文最后更新:2026年7月14日
Helvio Carvalho Junior. "HookChain: A new perspective for Bypassing EDR Solutions." arXiv:2404.16856v1, 2024. https://arxiv.org/pdf/2404.16856v1 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
femtosec.io. "SindriKit: Decoupling Syscalls to Evade EDR Telemetry." 2026. https://www.femtosec.io/threat-intelligence/sindrikit-edr-evasion-stack-spoofing ↩︎
thedailytechfeed.com. "RealBlindingEDR: A Tool That Disables Antivirus and EDR Systems via Kernel Callbacks." 2025. https://thedailytechfeed.com/realblindingedr-a-tool-that-disables-antivirus-and-edr-systems-via-kernel-callbacks/ ↩︎ ↩︎
notes.qazeer.io. "EDRSandBlast: EDR bypass with arbitrary kernel memory read/write." https://notes.qazeer.io/red-team-specifics/edr_bypass_with_edrsandblast ↩︎ ↩︎
CrowdStrike Blog. "CrowdStrike Researchers Investigate the Threat of Patchless AMSI Bypass Attacks." https://www.crowdstrike.com/en-us/blog/crowdstrike-investigates-threat-of-patchless-amsi-bypass-attacks/ ↩︎ ↩︎
SentinelOne. "CrowdStrike vs SentinelOne." https://www.sentinelone.com/vs/crowdstrike/ ↩︎
0xdbgman.github.io. "Security Controls: Modern EDR & Windows Protection Bypass." https://0xdbgman.github.io/posts/sec-controls-the-art-of-breaking-through/ ↩︎ ↩︎ ↩︎
securitylab.lat. "Evasión del EDR y técnicas anti-forenses." https://securitylab.lat/blog/personal/XiaomiFanES/359118.php ↩︎
hackersmanifest.com. "EDR Bypass Techniques." 2026. https://hackersmanifest.com/internal-pentest/09f-edr-bypass/ ↩︎
Palo Alto Networks. "Cortex XDRとCrowdStrikeの比較." https://www.paloaltonetworks.jp/cortex/xdrvscrowdstrike ↩︎
redsecuretech.co.uk. "Havoc C2: Sleep Obfuscation & Return Address Spoofing Guide." 2026. https://www.redsecuretech.co.uk/blog/post/havoc-c2-sleep-obfuscation-return-address-spoofing-guide/1164 ↩︎
0xsr.com. "Building Chimera: An EDR Evasion Framework from Scratch." February 2026. https://0xsr.com/blog/edr-evasion ↩︎
浙公网安备 33010602011771号