skylarinst-winc(10.199.1.19_80).exe样本分析
本帖最后由 HexChristmas 于 2021-6-18 14:19 编辑# 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`
这块调用了一个windowsapi`LoadLibraryA`加载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_GetConsoleMode`h和`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/zmn5tp
https://s.threatbook.cn/report/file/70917aad216c48af027a87395dff4c831a34923cb94448d3c86b5dcfc79568c5/?sign=history&env=win7_sp1_enx64_office2013 cs的golang shellcode？ 对，分析的比较菜，刚开始接触go的样本，后续还有哈哈，大佬见笑 给力，给力点，真不错。
页:
[1]