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

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没有检测出来壳,
1
我们尝试切换扫描器,可以看出是go的样本go版本1.15.7
7
我们使用exeinfo检测是go的
2

可能受到的威胁的系统

Windows

相关漏洞

未涉及

已知检测名称

skylarinst-winc(10.199.1.19_80).exe

被感染系统及网络症状

文件系统变化

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

注册表变化

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

网络症状

当样本执行的时候会访问149.248.18.93
5
我们这里使用

详细分析/功能介绍

首先进行简单的字符串分析
我们通过字符串看出,该样本应该是从mac上构建的
3
构建的GOBUILDID
4
这些东西好像并没有什么用

静态分析

我们使用IDAGOLANGHelper插件,对ida分析出来的函数进行重命名
8
首先分析_rt0_amd64
27
直接分析重点runtime_osinit,因为根据go的启动顺序,runtime会在main之前启动,他这里调用了一个函数runtime_loadOptionalSyscalls
28
这块调用了一个windowsapiLoadLibraryA加载dll文件,然后调用runtime_windowsFindfunc函数,调用GetProcAddress获取程序地址,
29
调用runtime_windowsLoadSystemLib函数,调用api获取当前程序的路径
30 31
再往下,调用runtime_initWine实现wine沙箱检测
32
这就是我们之前将样本投递到微步中为什么显示反检测技术的原因
33
调用了一系列的api,比如SetConsoleCtrlHandler,GetSystemInfo,SetProcessPriorityBoost等等
入口函数main_main,首先是个jbe跳转,为了平衡栈,会有个小于等于跳转,进行个字符串转字节的转换,然后在进行十六进制的解码
9
有个ja高于的跳转,这里分析跳转的作用应该是判断动态堆栈的大小,去申请或者回收堆栈,
10
跟进函数发现部分ida没有分析出来
11
如果低于,调用runtime_newobject这个函数
12
通过runtime_morestack_noctxtruntime_mallocgc去申请函数运行所需要的大小,直到满足条件
13
调用了一个标准库,然后jz非空判断,如果为空则执行报错处理,如果不为空就继续执行loc_4A90C9,这块有个不高于的跳转,高于就执行loc_4A918F,应该也是维持堆栈平衡
14
如果小于等于就继续执行,去申请函数运行所需要的堆栈大小,直到满足条件为止,调用标准库与底层交互,然后异常判断,调用syscall_Syscall这个函数,这个函数应该是样本主要功能的入口,
15
这里我们看到,调用了一个runtime_cgocall这样的函数,这是一个go操作c的库
16
这一整块都是go调用c过程,包括gcc编译,回调,栈处理,所以不分析了
然后再往下,就是call了一个runtime_unlockOSThread,
17
这个函数主要起到解锁线程的作用,我通过看go的官方文档发现,go操作c然后解锁线程等一系列操作比较平常,我们分析到这,发现结束了,没有发现样本主要程序,根据上边的分析,应该是先解密,然后go操作c去生成什么东西,然后其他的包在调用生成的文件进行其他操作,我们继续分析其他入口函数
我们将ida中的函数列表按照字母顺序排序
18
根据我们之前对于goruntime的研究,我们继续分析main_init这个函数,
19
上来jbe跳转平衡栈,然后调用syscall_MustLoadDLL加载dll文件,具体加载什么dll文件估计得动态才能知道,我们简单跟一下这个函数
20
这边syscall_LoadDLL这个函数
21
48 89 8C 24 90 00 00 00以上应该是传入什么数据然后转换成UTF-16,通过runtime_mapaccess1_faststr读取数据,再往下有个jz跳转,如果为0就直接跳转syscall_loadlibrary,不为0继续执行上边的运算,然后跳转到syscall_loadsystemlibrarysyscall_loadlibrarysyscall_loadsystemlibrary作用应该是一致的只不过syscall_loadsystemlibrary多了一些异常处理,我们这里继续跟一下syscall_loadlibrary
22
我们这里看到调用了一个windows的api是LoadLibraryW我们一会可以尝试在此下断看看他具体加载了什么dll文件,再往下分析就是各种内存回收机制
我们继续分析main_main,可以看到这个字符串就是cs的shellcode,在VirtualAlloc下断进行调试
43
我们继续分析os_init,我们发现这个函数没有交叉引用,我们根据以上猜测,该函数应该是在main_main之前启动,
23
前边是一些异常处理包括,文件打开,权限异常等等,然后我们继续分析
25
我看们看到syscall_GetConsoleModeh和syscall_GetFileType,联想到我们在文件系统变化,火绒剑有监测到该样本有exec_create的动作,执行的参数parent_pid:5-36 cmdline不谋而合,所以这块就应该是释放文件的过程
然后我们继续分析os_init_0
26
这块看到,与上边的不谋而合,更加确定了我们的猜测

动态分析

加载kernel32.dll为样本程序运行提供环境
35
加载winmm.dll
36
加载ws2_32.dll,用于样本联网提供socket服务
37
获取wine版本,反沙箱的一种机制
加载winnet.dll,符合cs的beacon的加载执行过程
40
连接C2
41 42

相关服务器信息分析

149.248.18.93

参考链接



服务器资源由ZeptoVM赞助

Partners Wiki IRC