4、第四阶段（调用dllmain方法，dllmain方法研究）

来到dllmain方法：如下图，进来就判断fdwReason参数是否等于1，这里也就是第一次调用dllmain，cs其实是在做初始化操作，接下来我们跳转过去看看：

来到跳转后的位置：如下图

跟进到这个call里面：如下图，这个call里面对某块数据进行解密还原：循环的次数是0x1000：

还原之后的数据如下,其中红色的部分我们是能看出来端倪的，其中包括c2，ua，URI，CT，以及相关心跳传输内容的传输字段（下面这个是Cookie字段）

所以这里这个fwdReason为1的时候的call，其实就是在初始化，将一些被加密的要用的信息还原出来（这个可能是因为beacon生成的时候会受c2profile的配置影响，总不能修改一个c2profile里面的配置，我们就要大费周章的去beacon里面找对应位置做修改把，所以cs对beacon的修改接口就是对这个资源段的修改）。

回过头来，我们来看看dllmain中fwdReason等于4的时候：

一堆逻辑，这里的逻辑代码就不是位置无关代码了，所以我们这里直接反汇编来分析会更加直观简单些，这里我们直接用ida来打开这个dll文件看下：

找到dllmain函数：

如下图，也就是在8cdf偏移的位置（ida默认基址是10000000）：

直接f5大法：如下图，可以看到其实就是我们分析的对fdwReason进行判断：进行如下逻辑：

上面通过VirtualQuery获取到这个dll的虚拟空间的一系列页面信息，对获取到的buffer（MEMORY_BASIC_INFORMATION 结构），判断其type属性：

type这个属性在msdn上是这么解释的：

所以这里对这个属性做了个判断，为20000的时候释放8000的空间，为40000的时候取消对应dll的映射，笔者这里也不太清除这是要干啥，是检查dll被分配到空间的权限问题吗?

无碍，这个逻辑最后不管这么说，都是去到0x1388这个偏移对应的函数，这个函数就是我们要分析的点，我们简单来看下主要的一些关键位置：

如下是这个偏移函数反汇编后开始的内容：首先获取到和c2通信要用的一些资源和配置，如c2IP、端口、心跳时间，ua等等

最关键的点是，beacon段要定时发送心跳，并接收返回，对返回的内容进行判断处理，然后做出对应的指令。这里其实就是下面这个死循环：其中1A69偏移的这个函数是在和c2建立连接：（里面就是Wininet里面的InternetOpen，InternetSetOption、InternetConnect）

发送心跳请求，如果有就获取响应体内容（通过InternetReadFile获取，cs通信中，如果心跳请求有响应体了，就说明这里在下发任务了）：

然后根据返回内容来执行对应命令：如下图，当某个响应内容的值大于0的时候调用8831这个偏移的函数：

这个函数的实现如下：，其中有个8305的偏移的函数，这个函数就是在处理执行操作的类型，更具类型执行不同的命令：

如下图，可以看到这个cobaltstrike4.0的beacon里面内置了100个任务类型：

根据响应内容来判断调用不同形式命令，常见的什么截图、弹窗、代理等相关命令之类的

switch ( a3 )  
  {  
    case 1:  
      v3 = 1;  
      goto LABEL\_3;  
    case 3:  
      return (void \*)sub\_100021AE(Src);  
    case 4:  
      return (void \*)sub\_10002231(Src, result);  
    case 5:  
      return (void \*)sub\_100021C2(result);  
    case 9:  
      return (void \*)sub\_100043D4(1);  
    case 10:  
      return (void \*)sub\_100026BA((int)result, Src, "wb");  
    case 11:  
      return (void \*)sub\_10003ACE(result, Src);  
    case 12:  
      return (void \*)sub\_10002269(result);  
    case 13:  
      return (void \*)sub\_10009D53(result, Src, 1);  
    case 14:  
      return (void \*)sub\_10006FC6(result, Src);  
    case 15:  
      return (void \*)sub\_100071D2(Src);  
    case 16:  
      return (void \*)sub\_10007214(Src);  
    case 17:  
      return (void \*)sub\_10006F72(result);  
    case 18:  
      return (void \*)sub\_1000477E(Src, 1);  
    case 19:  
      return (void \*)sub\_10003D0C(Src);  
    case 22:  
      return (void \*)sub\_100062FE(Src);  
    case 23:  
      return (void \*)sub\_10006445(Src);  
    case 24:  
      return (void \*)sub\_100062BD(Src);  
    case 27:  
      return (void \*)sub\_1000A2A2(Src);  
    case 28:  
      return (void \*)sub\_1000A16F(Src);  
    case 29:  
      return (void \*)sub\_1000274D(result, Src);  
    case 31:  
      return (void \*)sub\_1000A371(result, Src);  
    case 32:  
      return (void \*)sub\_1000894E(result, Src);  
    case 33:  
      return (void \*)sub\_10008886(Src, result);  
    case 37:  
      return (void \*)sub\_10007714(result);  
    case 38:  
      return (void \*)sub\_1000243C(result, Src);  
    case 39:  
      return (void \*)sub\_100028D4(Src);  
    case 40:  
    case 62:  
      return (void \*)sub\_10005F7A(result, Src);  
    case 41:  
      return (void \*)sub\_100060AA(Src);  
    case 42:  
      return (void \*)sub\_10006112(Src, result);  
    case 43:  
      return (void \*)sub\_100043D4(0);  
    case 44:  
      v4 = 1;  
      goto LABEL\_40;  
    case 45:  
      return (void \*)sub\_100047C9(Src, 1);  
    case 46:  
      return (void \*)sub\_100047C9(Src, 0);  
    case 47:  
      return (void \*)sub\_10002938(Src, result);  
    case 48:  
      return (void \*)sub\_1000589B(result, Src);  
    case 49:  
      return (void \*)sub\_1000A5D8(result, Src);  
    case 50:  
      return (void \*)sub\_10007616(Src, result);  
    case 51:  
      return (void \*)sub\_100076C0(Src, result);  
    case 52:  
      return (void \*)sub\_100029DA(result, Src);  
    case 53:  
      return (void \*)sub\_10003FD1(result, Src);  
    case 54:  
      return (void \*)sub\_10003EAA(Src, result);  
    case 55:  
      return (void \*)sub\_10003DA1(Src, result);  
    case 56:  
      return (void \*)sub\_10003E68(Src, result);  
    case 57:  
      return (void \*)sub\_10002A92(result, Src);  
    case 58:  
      return (void \*)sub\_10002C10(result, Src);  
    case 59:  
      return (void \*)sub\_1000A8BD(Src, result);  
    case 60:  
      return (void \*)sub\_10002FE8(result);  
    case 61:  
      return (void \*)sub\_10003075(Src);  
    case 67:  
      return (void \*)sub\_100026BA((int)result, Src, "ab");  
    case 68:  
      return (void \*)sub\_1000660C((LPCSTR)result);  
    case 69:  
      return (void \*)sub\_10009D53(result, Src, 0);  
    case 70:  
      v5 = 1;  
      goto LABEL\_63;  
    case 71:  
      v6 = 1;  
      goto LABEL\_65;  
    case 72:  
      return (void \*)sub\_10002212(result);  
    case 73:  
      return (void \*)sub\_10003ED3(result, Src);  
    case 74:  
      return (void \*)sub\_10003F53(result, Src);  
    case 75:  
      return (void \*)sub\_10007A4A(Src, result);  
    case 76:  
      return (void \*)sub\_1000233F(result, Src);  
    case 77:  
      return (void \*)sub\_10003154(result, Src);  
    case 78:  
      return (void \*)sub\_100025C9(result, Src);  
    case 79:  
      return (void \*)sub\_1000774D(Src, result);  
    case 80:  
      return (void \*)sub\_1000499E(Src, result);  
    case 81:  
      return (void \*)sub\_100097FC(result, Src);  
    case 82:  
      return (void \*)sub\_1000766B(Src, result);  
    case 83:  
      return (void \*)sub\_10001092(result, Src);  
    case 84:  
      return (void \*)sub\_10001130(Src);  
    case 85:  
      return (void \*)sub\_100011D5(Src);  
    case 86:  
      return (void \*)sub\_1000695C(result, Src);  
    case 87:  
      v5 = 0;  
LABEL\_63:  
      result = (void \*)sub\_10004903(result, Src, 1, v5);  
      break;  
    case 88:  
      v6 = 0;  
LABEL\_65:  
      result = (void \*)sub\_10004903(result, Src, 0, v6);  
      break;  
    case 89:  
      v3 = 0;  
LABEL\_3:  
      result = (void \*)sub\_10004475(result, Src, 1, v3);  
      break;  
    case 90:  
      v4 = 0;  
LABEL\_40:  
      result = (void \*)sub\_10004475(result, Src, 0, v4);  
      break;  
    case 91:  
      result = (void \*)sub\_1000477E(Src, 0);  
      break;  
    case 92:  
      result = (void \*)sub\_10007966(Src, result);  
      break;  
    case 93:  
      result = (void \*)sub\_100046AD(result, Src, 1);  
      break;  
    case 94:  
      result = (void \*)sub\_100046AD(result, Src, 0);  
      break;  
    case 95:  
      result = (void \*)sub\_1000585E(Src, result);  
      break;  
    case 96:  
      result = (void \*)sub\_100045C7(1);  
      break;  
    case 97:  
      result = (void \*)sub\_100045C7(0);  
      break;  
    case 98:  
      result = (void \*)sub\_10004520(1);  
      break;  
    case 99:  
      result = (void \*)sub\_10004520(0);  
      break;  
    default:  
      return result;  
  }

相关

一、上文中用来提炼函数名和模块名生成特征码使用的算法

笔者理解这里之所以要存在这个算法，主要是两个作用：

1、缩短shellcode的长度，有些函数名以及模块名比较长，如果直接写到shellcode里面我们要使用像下面这种位置无关代码，这样就会占比较长位置（shellcode越短越好，因为在一些系统溢出漏洞中对内存空间的大小限制是非常严格的）。

char szMessageBoxA\[\] = { 'M','e', 's', 's', 'a', 'g', 'e', 'B', 'o', 'x', 'A', 0 };

机器码的存储形式是，如下图：

2、对抗静态分析把，如果直接出现一些函数名，模块名在里面，特征太明显了。（但是其实算法后的特定值之后也会被作为静态分析的特征）

二、关于windows在rang3，如何从fs寄存器中拿到模块基址的这个过程

上文这里没有详细写，如果想具体了解，可以参考笔者之前写的文章：

https://forum.butian.net/share/1934

中的shellcode编写部分的内容，如下图，这里面有详细讲：

三、检测思路:

笔者了解到目前已有的对上述shellcode加载过程的检测：

1、流量侧

1、拉取beacon文件的时候，可以检测到发起的请求，这个请求满足算法checksum8（），返回文件很大，20000个字节左右。

2、我们可以去对beacon文件里面的内容做检测，因为这里beacon文件加密方式就是和一个密钥异或，并且密钥也是在beacon里面的，解密出来之后我们就可以看到pe文件的全貌了，这是一种检测思路

3、执行反射加载的dll里面dllmain方法的时候，触发c2客户端逻辑，发起心跳流量和命令执行流量，心跳流量请求的uri（http/https隧道的）、元数据传输字段，主要由生成shellcode的时候对应cs的c2profile文件控制。

4、当是https隧道的时候，因为TLS在建立连接的时候要发送证书，这里可以通过一些cs默认的证书去检测（当然如果更换证书了，这里就检测不了了）；除此之外，笔者之前看了一篇文章，说这个c2server在和beacon利用TLS协议建立连接的时候，c2server端发送的一些内容是有特征的，能检测。

2、主机侧

笔者看github上有个beaconeyes的项目，这个项目检测的是主机内存空间，将进程的内存dump下来，去判断我们上面说的dllmain初始化逻辑里面还原出来的一些数据，通过这些数据的通用形式来匹配。

还有一些查杀技术，比如专门针对shellcode的检测，在r3检测是否存在通过fs获取模块基址的行为；再比如专门对抗检测反射dll加载的查杀技术，对开辟空间进行检查，检测是否存在动态加载dll的过程等

总结

一、过程

简单总结下cs的shellcode的思路：

1、执行shellcode，shellcode会通过fs寄存器获取内存模块加载表，从而从kernel32模块里面获取loadlibrary的地址，来加载wininet这个模块，加载之后从这个模块里面找到一些网络连接要用的函数（如，InternetConnectA，HttpSendRequestA等等），通过调用这些函数，向cobaltstrike的c2 server拉取beacon文件，并执行。

2、执行beacon，对其中部分数据进行解密，还原出来一个pe文件，并执行。

3、执行pe文件头部，通过dos头引导，执行pe文件里面的reflectiveloader函数，reflectiveloader函数里面主要实现：

通过3环fs寄存器那套，找到kernel模块里面我们要用的几个函数（GetProcessAddress、GetModuleHandleA、LoadLibraryA、LoadLibraryExA、VirtualAlloc、VirtualProtect）
通过找到的函数，实现对dll本身的加载（1、将pe从文件格式映射到内存格式；2、修复导入表 3、修复重定位表 4、运行dllmian（初始化））

4、dos引导的最后也是会调用从reflectiveLoader函数里面返回的dllmain函数，dllmain里面实现c2客户端的通信逻辑，发送心跳，执行命令等

对cs的shellcode进行研究分析还是比较有价值的，能为后续我们对免杀技术手段的研究打一个夯实的基础。

Cobaltstrike4.0 —— shellcode分析（三）