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/zmn5tp
https://s.threatbook.cn/report/file/70917aad216c48af027a87395dff4c831a34923cb94448d3c86b5dcfc79568c5/?sign=history&env=win7_sp1_enx64_office2013
发表于 2021-6-16 21:32
发表于 2021-6-29 16:24
|
发表于 2021-6-30 13:38
