-
-
[原创]VPN客户端访问日志_内部访问出错_2021年4月15日样本分析
-
发表于: 2021-7-15 15:40 4913
-
cs的远控,钓鱼......
2021.04.06
远控程序/钓鱼邮件
file-size,2112512 (bytes)
md5,53C72DBF6E0528433C9E890DC497DFBB
sha1,5F848B2B7E59BFD99AB4FCF956873791B95D46A5
sha256,5573858C4FE763251C116FE85F7F661CA45C5E4A61AE593D6FA88BA1B624AAB8
简单查壳
在exeinfo看出,这个样本是go语言写的,没有加壳的
x64
未涉及
VPN客户端访问日志_内部访问出错_2021年4月15日
样本执行后,在C:\ProgramData\
目录释放了services.exe
文件
从火绒剑记录跟踪的变化发现,样本只执行了两个操作REG_openkey
,REG_getval
抓包分析,发现样本访问地址8.136.207.146
样本执行流程
在分析之前先对样本进行基地址固定
010editor检测固定是否成功
根据壳信息,我们知道该样本是go写的,我们借助IDAGolangHelper
来识别函数名
过滤main
相关的函数,看到了入口函数main_main
函数,函数地址是4DC7A0
首先调用了函数main_DE
,跟进
初步分析,上面这几个函数应该起这样本的反调试作用,我们分别看一下这几个函数
首先,调用了main_checkNic
,我们这里看关键代码
通过汇编代码分析,通过net_Interfaces
获取本地IP地址,然后通过net_HardwareAddr_Strings
获取MAC地址
继续回到main_DE
函数
然后调用了一个main_checkResource
,我们通过看go的源码
这个函数应该是Golang的HTTP Client
的一个参数,用来检测http超时状态的
我们将样本放入微步沙箱中,网络行为发现
发起了一系列的http请求,目前猜测应该就是与这个HTTP Client
有关,我们可以在动态分析的时候调试一下看看是什么情况
回到main_DE
函数,继续分析
这块调用main_detectDBG
函数
调用了syscall_CreateToolhelp32Snapshot
函数进行进程枚举,这块根据经验应该是在查找是否有调试器进程
继续,又调用了syscall_Process32First
函数
下面又调用了Process32Next
,熟悉CreateToolhelp32Snapshot
函数的应该清楚,Process32First
是CreateToolhelp32Snapshot
的一个获取进程的函数,作用就是获取当前运行进程的快照后的第一个进程,Process32Next
就是获取下一个线程
有关CreateToolhelp32Snapshot
用法参考
到这main_DE
就分析完了,总结就是这个函数主要就是反调试检测
继续分析main_H
获取并判断样本执行完的结果,如果为0则执行删除操作,然后继续比较,如果返回的值小于2,则执行解码
如果样本执行完的结果不为0,则执行
看到这,熟悉的函数就来了,这应该就是样本主要程序,用了一系列函数
这块主要,样本本体是一个壳子,而此处的作用就是在C:\\ProgramData
释放真正的样本,释放完之后在删除本体程序
其中io_ioutil_WriteFile
这个函数写了文件,从汇编看看不出什么东西,但是一般readfile之后应该是os_exec,分析的暂时先这么理解,因为在上边文件系统变化时候,我们发现样本释放了services.exe
文件,然后执行了os_exec这个函数,所以我看到这块会有想法,具体我们可以下面动态调试的过程中继续深究
然后下边的根据经验就应该是CS的shellcode
然后我们继续分析函数main_D
这个main_D
应该就是base64
进行解码
然后继续分析main_L
main_L
函数分析就没有意义了,基本就是准备程序运行的环境等等
我们根据上面的分析,分别在write_file
、read_file
、Process32Next
、Process32First
、VirtualAlloc
、CreatePipe
处下断
静态分析知道main_DE
函数地址是4DB6E0
,所以x64dbg直接跳转到4DB6E0
,然后在此下断,运行到此断点,F8单步
单步过程中,没有发现有关获取地址的操作,而是直接跳转到了CreateToolhelp32Snapshot
想了一下,我们应该现在main_main
处下断,肯定是判断我虚拟机里边到网卡以及获取到的IP所以直接跳转到判断调试进程了
我们直接在main_main
函数,函数地址4DC7A0
处下断,然后运行到此断点,F8单步,经过一天调试和研究,发现并没有发现样本去执行main_DE
,而是执行了一个叫做sync Preemp
的参数,通过google,发现他其实是preempt
函数的一个参数
go的源码在参考链接第一个,有时间去分析一下,再来补充
根据大佬分析完的,这个函数应该是起这异步抢占的作用,我第一次执行完,第二次不用在运行前边的程序,直接继续运行,参考链接第二个
由于样本逻辑我们基本弄清楚了,关键操作在shellcode,所以就不纠结这了
因为我们在文件系统变化分析到,该样本释放了一个services.exe
的程序,所以我们就从这着手,直接在write_file
下断,命中之后,在内存中发现
样本在C:\ProgramData\services.exe
释放了一个程序,然后在往下看
发现是我们从静态中的shellcode,然后开始解密shellcode
程序命中了Process32Next
断点,我们转到内存,看到有获取物理地址的操作
继续执行,命中CreateFileW
断点
释放services.exe
继续执行,当断点命中os_exec_Command
,函数地址为4DC320
时,样本开始启动services.exe
到这基本能和我们静态分析的对得上了,所以即使我们调试本体程序也不会有什么结果,所以直接调试services.exe
我们进行下断VirtualAlloc
、CreatePipe
、CreateFileW
、Write_file
等函数下断,但当我们运行到当前程序开始调试时候,程序直接调试结束了,我们猜测这里边可能有反调试,然后我们在FatalExit
函数下断,程序运行
我们发现在退出之前貌似又创建了一个进程启动了services.exe
然后我们在CreateProcessW
下断,然后重新运行程序
当我们运行到CreateProcessInternalW
这个函数的时候调试器的services.exe
又创建了一个进程ID为4068
的services.exe
关于CreateProcessInternalW()
的用法
大概作用就是创建远程线程这么个意思
既然它创建了新的线程,那我们在调试这个services.exe
肯定就调试不出来啥东西了,然后我们直接attach
新的线程
连接目标主机并请求指定地址
发起请求
http://8.136.207.146:8443/kIHa
https://golang.org/src/runtime/preempt.go
https://zhuanlan.zhihu.com/p/216118842
https://s.threatbook.cn/report/file/5573858c4fe763251c116fe85f7f661ca45c5e4a61ae593d6fa88ba1b624aab8/?sign=history&env=win7_sp1_enx64_office2013
https://www.hybrid-analysis.com/sample/423ac0e900132082c1ce0614459ae2074667f6bbc6851e04dc953ac4d67e0b4a/60ecfd13029ee46b041cd2f4
https://doxygen.reactos.org/d9/dd7/dll_2win32_2kernel32_2client_2proc_8c.html#a13a0f94b43874ed5a678909bc39cc1ab
/
/
https:
/
/
docs.microsoft.com
/
en
-
us
/
windows
/
win32
/
api
/
tlhelp32
/
nf
-
tlhelp32
-
createtoolhelp32snapshot
HANDLE CreateToolhelp32Snapshot(
DWORD dwFlags,
DWORD th32ProcessID
);
/
/
https:
/
/
docs.microsoft.com
/
en
-
us
/
windows
/
win32
/
api
/
tlhelp32
/
nf
-
tlhelp32
-
createtoolhelp32snapshot
HANDLE CreateToolhelp32Snapshot(