红队开发基础-基础免杀（三）

2022-07-18

字数统计: 2.3k字 | 阅读时长≈ 8分

暂无简介

红队开发基础-基础免杀(三)

引言

本文是《红队开发基础-基础免杀》系列的第三篇文章，主要介绍了“删除ntdll中的钩子”、“伪造线程调用栈”、“beacon的内存加密这几种手段”，达到了bypass edr的效果。

删除ntdll.dll中的钩子

实现原理

此技术在《红队队开发基础-基础免杀(二)》中提到的syscall工具ParallelSyscalls中有提及。

该技术最初于《EDR Parallel-asis through Analysis》这篇文章中被提出。

Windows10之后的版本增加了windows parallel加载的特性，简单点说就是win10之前的系统dll加载都是同步加载的，windows10以后引入异步加载。

在加载所有dll之前系统会做一些列判断，判断是采用同步还是异步加载。

在这过程种，windows会保存NtOpenFile(), NtCreateSection(), ZwQueryAttributeFile(), ZwOpenSection(), ZwMapViewOfFile()这几个函数的存根,保存位置在ntdll的.text节中。

这样就是说，这几个函数就算被hook，我们也可以获取到syscall number。并且有了这个函数，我们可以重新把内存种的ntdll换成干净的ntdll，实现了unhook的操作。

其中获取到纯净的ntdll有两种方式，如图:

具体实现

参考工具RefleXXion

该工具有exe和dll的形式可以直接编译dll进行使用。利用RefleXXion的dll可以解除对ntdll.32的hook。

下面的例子是对Sleep函数进行了hook，因为sleep函数在Kernel32.dll中，要对dll源码进行改动。

首先调用InitSyscallsFromLdrpThunkSignature函数，函数名顾名思义就说获取到syscall存根。

这段代码似曾相识，和《红队队开发基础-基础免杀(二)》中的从dll搜索是从ntdll.dll中搜索出syscall的系统调用号几乎一样:

使用BuildSyscallStub工厂函数生成不同函数的syscall内联汇编代码:

强制转换成函数指针以备调用

接下来要替换掉内存中ntdll.dll的函数，该工具使用两种技术，说的两种技术其实主要是ntdll.dll获取的位置不同，技术一从\??\C:\Windows\System32\ntdll.dll读取，技术二从\KnownDlls\ntdll.dll读取。

技术一

使用NtCreateSection和NtMapViewOfSection api：

首先通过本地文件创建内存session：

ntStatus = RxNtCreateSection(&hSection, STANDARD_RIGHTS_REQUIRED | SECTION_MAP_READ | SECTION_QUERY, 
NULL, NULL, PAGE_READONLY, SEC_IMAGE, hFile);

之后映射到当前进程的内存中：

ntStatus = RxNtMapViewOfSection(hSection, NtCurrentProcess(), &pCleanNtdll, NULL, NULL, NULL, &sztViewSize, 1, 0, PAGE_READONLY);

可以看到dll被载入了内存，明显是MZ头为PE文件。之后搜索当前进程中已经加载的ntdll.dll：

解析已有的dll的pe结构，找到.text段：

进行替换：

这样就解除了对ntdll.dll中函数的hook。

技术二

主要是用NtOpenSection和NtMapViewOfSection实现，dll获取方式不同对应使用的api就不同，这里技术二和技术一原理差不多，这里不做过多分析。

解决问题

编译dll直接调用，发现没有成功。

找调试dll的方式，只要将dll项目的debug选项调成加载该dll的exe就可以实现dll的远程调试：

发现RtlInitUnicodeString调用返回了false，这个函数是ntdll.dll里的，这里改动有问题：

这里返回的hHookedNtdll变量有两个作用，一是获取到RtlInitUnicodeString函数，二是要作为下面等待被替换的dll名称。

这里作用一应该是ntdll.dll，而作用二应该是kernel32.dll。进行一系列修改：

又报错，一样的问题，这里的pCleanNtll应该是ntdll的副本，这里是kernel32.dll的副本了：

改为从ntdll获取这个api。

没有被hook之前，sleep函数的内存为：

hook后产生变化:

加载dll后恢复：

可以看到hook已经被解除，sleep函数被正常调用:

伪造线程调用堆栈

下面介绍的两种技术都是配套cs进行使用的：

基础知识

Cobalt Strike默认对命令有60s的等待时间，我们可以通过sleep x命令修改这个时间。通过sleep实现了beacon的通讯间隔控制。beacon中调用系统sleep进行休眠,teamserver实现一种消息队列,将命令存储在消息队列中。当beacon连接teamserver时读取命令并执行。

常规的cs在sleep休眠时，线程返回地址会指向驻留在内存中的shellcode。通过检查可疑进程中线程的返回地址，我们的implant shellcode很容易被发现。

实现原理

在ThreadStackSpoofer项目的readme中有这样一张图:

笔者理解是EDR/工具获取调用栈是通过某一时刻的栈的状态获生成一个链状的图，在某个时间损坏中间的某个环节可以导致链状图不完整伪造调用图。

笔者没找到ThreadStackSpoofer作者的效果图是哪个工具生成的，这里直接贴ThreadStackSpoofer README中的图，经过hook的调用栈应该像下面的图:

没有经过hook的调用栈：

代码实现

在主线程中HOOK SLEEP函数，跳转到Mysleep函数。

通过创建进程的方式启动beacon，将Mysleep函数原本返回值的位置改为0:

这样就可以简单的扰乱程序的调用栈了。

beacon的内存加密

基本原理

主要是根据ShellcodeFluctuation

该项目是基于threadstackspoofer项目的加强版，在sleep函数执行的时候在对shellcode内存的修改属性且解密。可以一定程度上绕过edr的内存扫描。原理就是beacon线程在执行sleep函数的时候，会自动将自己的内存加密并修改属性为不可执行，再执行正常的sleep函数。执行成功后恢复shellcode并使之可以执行，等待下一次连接重复上述操作。在sleep函数真正执行的过程中，shellcode为不可执行属性可以绕过edr的检查。