文章总结： 文档梳理Windows内存攻防技术演进，包括VAD扫描RWX特征、APIHook及TI-ETW检测、利用CET校验调用栈完整性等。指出传统手段误报高且依赖特征码的痛点。作者展望下一代检测将采用语义分析，通过将Shellcode转为HLIL并结合Transformer模型摆脱特征依赖，文末推广了其基于大模型的病毒云鉴定平台。
综合评分： 68
文章分类： 免杀,终端安全,恶意软件,软文广告,二进制安全

现代windows内存攻防简介(2026年)

原创

为了安全鸭

冲鸭安全

2026年1月13日 09:00
北京

简介

又过一年了兄弟们，是时候更新冲鸭安全和key08了。主要是1月太忙了，一直忙着新产品，一直没空更新公众号和博客，趁着现在有空赶紧更新一波。

shellcode

安全软件对抗中,常用shellcode作为规避杀毒软件文件查杀的办法,因为shellcode可以内存执行,可以随时抹掉,并且容易变形.
一段经典的shellcode loader如下:

    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

代码如下:

MEMORY_BASIC_INFORMATION mbi = { 0 };

        SIZE_T address = 0;
&nbsp; &nbsp; &nbsp; &nbsp; while (VirtualQueryEx(hProcess.get(), reinterpret_cast<LPCVOID>(address), &mbi, sizeof(mbi)) == sizeof(mbi))
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // 排除模块映像段
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (mbi.Type != MEM_IMAGE)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // 检查是否可执行
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; DWORD protect = mbi.AllocationProtect;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bool checkExecuteFlag =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (protect & PAGE_EXECUTE) ||
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (protect & PAGE_EXECUTE_READ) ||
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (protect & PAGE_EXECUTE_READWRITE) ||
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (protect & PAGE_EXECUTE_WRITECOPY);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (checkExecuteFlag)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .....
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (!memoryAvEngin->ScanProcessBlocks(memoryStreamPtr, false, callback)) {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; printf("ScanProcessBlock error");
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .....
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // 跳到下一个内存区域
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; address = reinterpret_cast<SIZE_T>(mbi.BaseAddress) + mbi.RegionSize;
&nbsp; &nbsp; &nbsp; &nbsp; }

由于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
SleepDuck：通用堆栈欺骗检测POC,检测SleepMask
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]在线样本分析平台,下一代文件云鉴定
大模型的病毒木马文件云鉴定平台(粉丝内测)

剩下的就是训练一个transformer分类器就行.
本系统已经有部分应用,不过目前接的是大模型,还没接transformer分类器,可以先用着,目前开放体验(还没开放shellcode/elf的检测,只开放了PE的):
基于大模型的病毒木马文件云鉴定
目前对于PE的效果非常好,同时其实平台也支持ELF和SHELLCODE,但是我现在暂时没开放,还需要调试这两个
比如VT 1报毒的木马:

常规ghost:

c#:

混淆:

重要的是,核心引擎只有6M,6M还是因为我带了一个libcurl

所以下一步,完全可以携带到客户端,做shellcode分析/病毒分析等.

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：冲鸭安全 为了安全鸭《现代windows内存攻防简介(2026年)》