VPN客户端访问日志_内部访问出错_2021年4月15日样本分析
基本信息
样本概述
cs的远控，钓鱼…
样本发现日期
2021.04.06
样本类型
远控程序/钓鱼邮件
样本文件大小/被感染文件变化长度
file-size,2112512 (bytes)
样本文件MD5校验值
md5,53C72DBF6E0528433C9E890DC497DFBB
样本文件SHA1校验值
sha1,5F848B2B7E59BFD99AB4FCF956873791B95D46A5
样本文件SHA256校验值
sha256,5573858C4FE763251C116FE85F7F661CA45C5E4A61AE593D6FA88BA1B624AAB8
壳信息
简单查壳
在exeinfo看出，这个样本是go语言写的，没有加壳的
可能受到的威胁的系统
x64
相关漏洞
未涉及
已知检测名称
VPN客户端访问日志_内部访问出错_2021年4月15日
被感染系统及网络症状
文件系统变化
注册表变化
从火绒剑记录跟踪的变化发现，样本只执行了两个操作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用法参考
// https://docs.microsoft.com/en-us/windows/win32/api/tlhelp32/nf-tlhelp32-createtoolhelp32snapshot
HANDLE CreateToolhelp32Snapshot(
DWORD dwFlags,
DWORD th32ProcessID
);
到这main_DE就分析完了，总结就是这个函数主要就是反调试检测
继续分析main_H
获取并判断样本执行完的结果，如果为0则执行删除操作，然后继续比较，如果返回的值小于2，则执行解码
如果样本执行完的结果不为0，则执行
看到这，熟悉的函数就来了，这应该就是样本主要程序,用了一系列函数
| functions | descrition |
|---|---|
| os_exec_LookPath | 获取当前文件执行的路径 |
| path_filepath_abs | 获取完整路径 |
| io_ioutil_ReadFile | 读取文件 |
| io_ioutil_WriteFile | 写文件 |
| time_Sleep | 睡眠延时定时任务 |
这块主要，样本本体是一个壳子，而此处的作用就是在C:\\ProgramData释放真正的样本，释放完之后在删除本体程序
其中io_ioutil_WriteFile这个函数写了文件，从汇编看看不出什么东西，但是一般readfile之后应该是os_exec，分析的暂时先这么理解，因为在上边文件系统变化时候，我们发现样本释放了services.exe文件，然后执行了os_exec这个函数，所以我看到这块会有想法，具体我们可以下面动态调试的过程中继续深究
然后下边的根据经验就应该是CS的shellcode
VT9WEv0mzmWAJ/ah0Yl7mU/T1fRsynYD7iweZBPKUS2c47hEHVL2mAp0trGW6N/+G9zTgDxZvlvdz8rgPQ3fGnVBiuhgHFts+BNxwBs3++l5dNa2ehN8e4rVwpcl3rtaY3tzb0FgdxgavHGoV63zmOTiIHL+KOHldgfklnSc14cqUIjdDmuN07pfYbxyPK5ub9cDwXo35gaBTmtEpmi04UuaEezx8bU/2cADisff7a7yUxBR0IsBWNNRG4yZdt2dYpTHhVqFVvqDgtDA3gOFx/mymLLPMG/e3E0PhXLZw8XeQcS928/oMW+iADfEP7U5c9jrDK6+XWm69EFDkP3q2ls24reeE+H2HwL/u8drqm3uv/RTVgk5QwNQv+60dJnRbFJGe5NxauNNopmiKmYWorNd8CFhryYUuc5qFTq9YpBFOWAIbEahyR2ocHe3/HnfPjSjDEK55ePaflTOgsCORRNOp6WDyJ721nu0ySzBVSHKwG2O8wZArhXa/SJAGI/dJOhjwU0qeeyiSJd9ZT7YdRCUEWAeYNqF14+edIBOo0HOwIwkEDTHsTne5usfOEmPzzw5wTqjQxUvEzWddNsH6XbLBONe+sl9Y9XfGP6cy69Qc1JBHwlVUBL+xvevAEgvpfDKQPAfIyhtcbpBihUH5ZtdyHDdT/cyK12Aj62gTl+KbVhnUxOgF+A2paPh8z3Ay9k2uJRTS7p5NJlEY3+cRp1W7VsI/k4J7hVWdD2sBPkzx+OltrVQaN9xiKB52ykY1pgYoDQctQBReWZpAq/4id0qjkBCbl3EIUIU+ZU/2Ao804yb9gCfB72GcWaivFG1pQ00AYqrMG6DaZHrbEkOxrrERW4Rev3hP22r7hNQs2935CrHK+YaacI89WHH6mbveJIVNd+qlJlsvf7Jc8wFUArDe/lFVs8VBQy7OoZNxToWYh0COZyieWZkVL/dTBA2K03FUsos5SE+COzsxkdin7rCKzjYSxt6F/9eSZ1ngbCLeUh50sL9ir/IoBWsZtpOTd07BkZHiPgwDH22icaNr8kvxFJAiq+phVnnFJD5D4yR7IPArjg8J9zlw9poQLKc5XIIio51e3D9i+8hgvUwYxqYFkA+sbqTixgMWdReKI6QQwcw2Cjhqxu71VeFETWNcSfAoY7YhVsh2CFP+cdm31C8XaeZauS0pZiyXrkjaiouAYh4PWraQ4Lny+Y=
然后我们继续分析函数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断点
000000000083FE10 000000C00013A480 L"C:\\ProgramData\\services.exe"
释放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()的用法
//https://doxygen.reactos.org/d9/dd7/dll_2win32_2kernel32_2client_2proc_8c.html#a13a0f94b43874ed5a678909bc39cc1ab
CreateProcessInternalW()
BOOL WINAPI CreateProcessInternalW ( IN HANDLE hUserToken,
IN LPCWSTR lpApplicationName,
IN LPWSTR lpCommandLine,
IN LPSECURITY_ATTRIBUTES lpProcessAttributes,
IN LPSECURITY_ATTRIBUTES lpThreadAttributes,
IN BOOL bInheritHandles,
IN DWORD dwCreationFlags,
IN LPVOID lpEnvironment,
IN LPCWSTR lpCurrentDirectory,
IN LPSTARTUPINFOW lpStartupInfo,
IN LPPROCESS_INFORMATION lpProcessInformation,
OUT PHANDLE hNewToken
)
大概作用就是创建远程线程这么个意思
既然它创建了新的线程，那我们在调试这个services.exe肯定就调试不出来啥东西了，然后我们直接attach新的线程
连接目标主机并请求指定地址
发起请求
相关服务器信息分析
http://8.136.207.146:8443/kIHa
参考链接
https://s.threatbook.cn/report/file/5573858c4fe763251c116fe85f7f661ca45c5e4a61ae593d6fa88ba1b624aab8