[2026]现代windows内存攻防简介(2026年) huoji 2026 2026-01-13 218 次浏览 0 次点赞 ## 简介 又过一年了兄弟们，是时候更新冲鸭安全和key08了。主要是1月太忙了，一直忙着新产品，一直没空更新公众号和博客，乘着现在有空赶紧更新一波。 <!--more--> ## shellcode 安全软件对抗中,常用shellcode作为规避杀毒软件文件查杀的办法,因为shellcode可以内存执行,可以随时抹掉,并且容易变形. 一段经典的shellcode loader如下: ```cpp char* shellcode = (char*)VirtualAlloc( NULL, shellcode_size, MEM_COMMIT, PAGE_EXECUTE_READWRITE); CopyMemory(shellcode, buf, shellcode_size); //CreateThread函数，创建线程 hThread = CreateThread( NULL, // 安全描述符 NULL, // 栈的大小 (LPTHREAD_START_ROUTINE)shellcode, // 函数 NULL, // 参数 NULL, // 线程标志 &dwThreadId // 若成功，接收新创建的线程的线程ID DWORD变量的地址。 ); ``` > 如果你对"他发生了什么"感兴趣自己问chatgpt的VAD/PTE吧,这里我们不废话介绍原理了. ## 一般检测 现代的杀毒软件/或者EDR,对于这分配内存,一般会扫一下VAD里面的rwx  代码如下: ```cpp MEMORY_BASIC_INFORMATION mbi = { 0 }; SIZE_T address = 0; while (VirtualQueryEx(hProcess.get(), reinterpret_cast<LPCVOID>(address), &mbi, sizeof(mbi)) == sizeof(mbi)) { // 排除模块映像段 if (mbi.Type != MEM_IMAGE) { // 检查是否可执行 DWORD protect = mbi.AllocationProtect; bool checkExecuteFlag = (protect & PAGE_EXECUTE) || (protect & PAGE_EXECUTE_READ) || (protect & PAGE_EXECUTE_READWRITE) || (protect & PAGE_EXECUTE_WRITECOPY); if (checkExecuteFlag) { ..... if (!memoryAvEngin->ScanProcessBlocks(memoryStreamPtr, false, callback)) { printf("ScanProcessBlock error"); } ..... } } // 跳到下一个内存区域 address = reinterpret_cast<SIZE_T>(mbi.BaseAddress) + mbi.RegionSize; } ``` 由于VirtualAlloc分配的内存是RWX属性并且不是MEM_IMAGE,所以会被扫出来后匹配特征码。 ### 缺陷 实际上，与大家想的不同，安全软件通常不会直接报RWX为病毒(不过部分垃圾EDR会这样做)。这个原因是 实际环境中，**基本每个电脑都会或多或少的有几个RWX内存，jit，广告软件，部分加壳软件居多。**所以杀毒软件不会看到就报，他一定匹配特征码，并且做匹配: 比如ES的yara为例子: https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_CobaltStrike.yar  他不能看到就直接告警，会出现严重问题。必须依赖特征码，并且还有一个致命问题: 依赖进程有RWX的内存，否则就扫不到了。 **总结一个痛点是，必须要能扫到RWX内存，并且必须要匹配特征.** 所以,这种其实后来演变到所谓的"自研C2"/“二开CS”/"SleepMask"。为什么他们能工作的重要原因是,自研/二开的马，没有被拉黑特征，而Sleepmask等一派的东西，他们在休眠的时候是把RWX内存去掉了X属性甚至是混淆了shellcode，导致上面的遍历VAD的代码失效了 ## 升级检测 在前面的一般检测遇到瓶颈后，安全厂商发明了新的办法，为了解决前面的所谓的匹配不到RWX的问题,可以用更激进的手段.这边有几种手段: ### SleepMask: 检测所谓的RWX切换 部分厂商,比如ES通过TI-ETW检测virtualprotect的切换RWX内存，这样就检测了所谓的SleepMask因为这玩意会切换内存，这挺草台的说实在的，但是能用就不深入说了 ### 不依赖特征: 检测shellcode API调用 为了更好的时机去检测,部分厂商使用API HOOK,去挂钩某些SYSCALL或者某些关键API，挂钩后，检测调用是否来自Shellcode,如果是直接拦截或者阻止,而且不止API调用,也能通过TIETW拿到某些来自shellcode的call从而检测. > 对这块感兴趣的我强烈建议你购买一份冲鸭安全的EPP开发教程,此事在EPP开发里面有提到 ### 缺陷 这几个检测手段的缺陷同样有问题,有几个问题: 1. 盲目检测误报大 -生产环境几乎不能用,比如某些严格点策略的组织连x神游戏都打不开,打开直接被拦截. 2. 为了消除误报,依然使用特征码 -虽然解决了SleepMask导致获取不到shellcode的问题,但是为了减少误报,依然会用特征码尝试对shellcode进行匹配,否则是没办法上生产环境的,依然会被自研C2绕过 3. 各种花式syscall直接调用，ntdll unhook，调用栈欺骗绕过API的钩子  ## 继续升级检测 大部分厂商在前面两个阶段就停止对抗了,毕竟用户电脑不是战场,而且手段越多误报越多,不方便运维.但是 **部分好一点的厂商为了解决以上的手段,继续加码,对抗到底:** 首先,使用CET技术或者其他调用栈完整性校验技术,去检测异常调用栈,这里分两种,常见是软件类的,不太常见的是硬件类的.先说硬件类型的: CET技术:  Intel Processor Trace技术:  软件类型的: [2025]SleepDuck-通用堆栈欺骗检测POC,检测SleepMask https://key08.com/index.php/2025/07/13/2716.html TI-ETW结合调用栈:  天守EDR的动态指令追踪技术:  结合虚拟执行,检测调用栈完整性:  此类软/硬技术结合** 就保证了获取的调用栈是真实可靠的,而不是被欺骗的.**并且无法通过摘钩进行绕过.反而摘钩/栈欺骗会导致被检测. ### 缺陷 此类技术,有严重的缺陷,基于硬件的需要硬件达标,暂且不提 基于软件的技术,只能EDR来处理数据,EPP是处理不了这些数据的,处理了也会卡本机系统,因此只能在EDR上使用此类技术,成本没有办法降低.**因此实际做到这一层的很少,实践中也遇到的非常少,总的来说因为成本太大,此类操作不太符合目前的安全市场行情** ## 下一代展望 这里多扯几句，如果我还在干安全的话,并且让我来设计下一代怎么检测shellcode内存加载的操作的话,我会先思考两个问题,我们需要解决什么问题? 我们需要怎么做才能彻底解决他? 当前所有的检测主要有几个痛点: 1. 检测成本太高 2. 无论什么手段,为了防止误报,依然无法离开基于特征码的检测 3. 其实整篇文章我故意忽略了一个细节,**那如果我们不放到RWX内存呢,会怎么样?**答案是全部拉闸,如果你了解外挂就会知道,外挂喜欢找代码洞把shellcode塞到文件段里面,这样就扫不到了.除非更进一步做CRC内存->文件完整性校验,那样成本更高了. 所以,要是让我来搞,我一定会选择语义检测，在如今全是LLMs的时代,我们不能再抱着传统不放手. 这是有可能的,我们完全可以这样做: 1. 把shellcode/调用堆栈/等代码变成HLIL,类似于IDA的伪代码一样 2. 把HLIL送到transformer-base的二分类器里面,就跟以前古早时期那种什么AI检测说的话是不是恶意的话一样.剩下的等结果就行,整个过程非常快,因为不是大模型,是小小模型. 这样会解决如下问题: 1. 基于语义的分析,**即便是不用AI,也能用规则驱动检测**,比如检测PEB直接寻找的shellcode,比如检测shellcode里面的内容到底是在干什么,是混淆还是什么 2. 能检测出不放到RWX段的shellcodes,因为他不需要关心是不是RWX,输入应该是调用栈的各个地址就能开始检测,并且由于没有特征匹配的环节,所以他的速度非常非常的快. ## 扩展阅读(广告) **我提到的语义分析目前真的不是什么技术难题,shellcode2hlil的引擎已经有了: ** [2025]在线样本分析平台,下一代文件云鉴定 https://key08.com/index.php/2025/12/23/3009.html 剩下的就是训练一个transformer分类器就行. 本系统已经有部分应用,不过目前接的是大模型,还没接transformer分类器,可以先用着,目前开放体验(还没开放shellcode/elf的检测,只开放了PE的): https://vt.key08.com/ 目前对于PE的效果非常好,同时其实平台也支持ELF和SHELLCODE,但是我现在暂时没开放,还需要调试这两个 比如VT 1报毒的木马:   常规ghost:  c#:  混淆:  重要的是,核心引擎只有6M,6M还是因为我带了一个libcurl  所以下一步,完全可以携带到客户端,做shellcode分析/病毒分析等.  本文由 huoji 创作，采用 知识共享署名 3.0，可自由转载、引用，但需署名作者且注明文章出处。 点赞 0
还不快抢沙发