skylarinst-winc(10.199.1.19_80).exe样本分析

样本概述

和大佬交流一下，由于刚接触go的样本，分析的有些偏，本篇文章主要以分析go样本的执行流程为主。

样本首次微步提交是2021-04-02，有的大佬已经分析过了，我仅是抱着学习的态度分析，该样本伪装成360天擎企业版程序的远控，go语言写的

样本发现日期

resources-stamp,0x6063CC52 (Wed Mar 31 09:11:46 2021)

样本类型

远控木马

样本文件大小/被感染文件变化长度

file-size,1693696 (bytes)

样本文件MD5校验值

md5,C54EB668CF76A37BF28F95C173770ADF

样本文件SHA1校验值

sha1,6D9113E72546CDDDE04E7E5C94D8846649627674

样本文件SHA256校验值

sha256,70917AAD216C48AF027A87395DFF4C831A34923CB94448D3C86B5DCFC79568C5

壳信息

使用die没有检测出来壳，

我们尝试切换扫描器，可以看出是go的样本go版本1.15.7

我们使用exeinfo检测是go的

可能受到的威胁的系统

Windows

相关漏洞

未涉及

已知检测名称

skylarinst-winc(10.199.1.19_80).exe

文件系统变化

该样本没有创建或者删除什么文件

注册表变化

这里我们看到，注册表基本没有变化

网络症状

当样本执行的时候会访问149.248.18.93

我们这里使用

详细分析/功能介绍

首先进行简单的字符串分析

我们通过字符串看出，该样本应该是从mac上构建的

构建的GOBUILDID

这些东西好像并没有什么用

静态分析

我们使用IDAGOLANGHelper插件，对ida分析出来的函数进行重命名

首先分析_rt0_amd64

直接分析重点runtime_osinit,因为根据go的启动顺序，runtime会在main之前启动，他这里调用了一个函数runtime_loadOptionalSyscalls

这块调用了一个windowsapiLoadLibraryA加载dll文件,然后调用runtime_windowsFindfunc函数，调用GetProcAddress获取程序地址，

调用runtime_windowsLoadSystemLib函数，调用api获取当前程序的路径

再往下，调用runtime_initWine实现wine沙箱检测

这就是我们之前将样本投递到微步中为什么显示反检测技术的原因

调用了一系列的api,比如

SetConsoleCtrlHandler,GetSystemInfo,SetProcessPriorityBoost等等

入口函数main_main,首先是个jbe跳转，为了平衡栈，会有个小于等于跳转，进行个字符串转字节的转换，然后在进行十六进制的解码

有个ja高于的跳转，这里分析跳转的作用应该是判断动态堆栈的大小，去申请或者回收堆栈，

跟进函数发现部分ida没有分析出来

如果低于，调用runtime_newobject这个函数

通过runtime_morestack_noctxt和runtime_mallocgc去申请函数运行所需要的大小，直到满足条件  

调用了一个标准库，然后jz非空判断，如果为空则执行报错处理，如果不为空就继续执行loc_4A90C9,这块有个不高于的跳转，高于就执行loc_4A918F，应该也是维持堆栈平衡

如果小于等于就继续执行，去申请函数运行所需要的堆栈大小，直到满足条件为止，调用标准库与底层交互，然后异常判断，调用syscall_Syscall这个函数，这个函数应该是样本主要功能的入口，

这里我们看到，调用了一个runtime_cgocall这样的函数，这是一个go操作c的库

这一整块都是go调用c过程，包括gcc编译，回调，栈处理，所以不分析了然后再往下，就是call了一个runtime_unlockOSThread,

这个函数主要起到解锁线程的作用，我通过看go的官方文档发现，go操作c然后解锁线程等一系列操作比较平常，我们分析到这，发现结束了，没有发现样本主要程序，根据上边的分析，应该是先解密，然后go操作c去生成什么东西，然后其他的包在调用生成的文件进行其他操作，我们继续分析其他入口函数

我们将ida中的函数列表按照字母顺序排序

根据我们之前对于goruntime的研究，我们继续分析main_init这个函数，

上来jbe跳转平衡栈,然后调用syscall_MustLoadDLL加载dll文件，具体加载什么dll文件估计得动态才能知道，我们简单跟一下这个函数

这边syscall_LoadDLL这个函数

48 89 8C 24 90 00 00 00以上应该是传入什么数据然后转换成UTF-16，通过runtime_mapaccess1_faststr读取数据,再往下有个jz跳转，如果为0就直接跳转syscall_loadlibrary，不为0继续执行上边的运算，然后跳转到syscall_loadsystemlibrary，syscall_loadlibrary和syscall_loadsystemlibrary作用应该是一致的只不过syscall_loadsystemlibrary多了一些异常处理，我们这里继续跟一下syscall_loadlibrary

我们这里看到调用了一个windows的api是LoadLibraryW我们一会可以尝试在此下断看看他具体加载了什么dll文件，再往下分析就是各种内存回收机制,分析到这我们继续分析main_main，可以看到这个字符串就是cs的shellcode，在VirtualAlloc下断进行调试

我们继续分析os_init，我们发现这个函数没有交叉引用，我们根据以上猜测，该函数应该是在main_main之前启动，

前边是一些异常处理包括，文件打开，权限异常等等，然后我们继续分析

我看们看到syscall_GetConsoleModeh和syscall_GetFileType，联想到我们在文件系统变化，火绒剑有监测到该样本有exec_create的动作，执行的参数parent_pid:5-36 cmdline不谋而合，所以这块就应该是释放文件的过程

然后我们继续分析os_init_0

这块看到，与上边的不谋而合，更加确定了我们的猜测

动态分析

加载kernel32.dll为样本程序运行提供环境

加载winmm.dll

加载ws2_32.dll，用于样本联网提供socket服务

获取wine版本，反沙箱的一种机制

加载winnet.dll，符合cs的beacon的加载执行过程

连接C2

相关服务器信息分析

149.248.18.93

参考链接

https://www.yuque.com/p1ut0/qtmgyx/zmn5tphttps://s.threatbook.cn/report/file/70917aad216c48af027a87395dff4c831a34923cb94448d3c86b5dcfc79568c5/?sign=history&env=win7_sp1_enx64_office2013