某传奇游戏登录器劫持分析
一些乱七八糟的话
某天接到一个样本，说游戏运行之后，在浏览器访问某游戏官方的网站会定向跳转到另一个网站，而且在浏览器搜索该网址关键词也会进行跳转，由于技术比较菜，前前后后看了近一个月，于是就有了这篇文章
有的时候截图中的PID可能不对，还请见谅，因为调这调这程序就跑飞了
基本信息
样本概述
该样本属于供应链劫持，传奇登录器应用下发服务器被入侵，导致软件包被捆绑恶意程序，进行网站劫持。
样本发现日期
2021年7月8号
样本类型
流氓推广，恶意捆绑
样本文件大小
file-size,38185984 (bytes)
样本文件MD5校验值
md5,9621681916E9D27BAE71B84FBBA96015
样本文件SHA1校验值
sha1,78C3E5C75838F9F414072E31E71103BB44F97663
样本文件SHA256校验值
sha256,9F7EE5BECBE18E944195841EAFBB26E213353F7530092D4194E9DD59F8130753
可能受到的威胁的系统
Windows x86
相关漏洞
未涉及
被感染系统及网络症状
文件系统变化
样本主体向服务器获取数据并释放msg_xxxx.jpg、rar_xxxx.exe、rar_xxxx.exe
rar_xxxx.exe程序释放驱动程序
注册表变化
释放的其他程序对注册表的变化没有什么可疑的，驱动对注册表进行了操作
网络症状
网络行为中发现样本的异常
样本执行之后，发起TCP连接
我们启动登录器并配置抓包，发现某个地址被重定向到
https://www.aoskal.com
样本会访问
https://pz.520found.com:86/dll.txt
下载完访问
详细分析
静态分析
由于是游戏登录器，我们区分哪些是游戏行为，哪些是恶意软件行为，哪些是外挂行为，这实际上给我们分析带来很大的难度
我们分析字符串的时候发现有调用wininet.dll,发起网络请求
跟进，看到不仅调了
wininet.dll还调了wsocks32.dll也是提供网络的请求的
我们跟进
sub_49AD2C这个函数，往上分析
我们获取了一段创建任务栏提示
TaskbarCreated，这样的一段字符串，我们推测应该是登录器先创建一个任务栏提示，然后当我们鼠标点击时，触发条件并加载wininet.dll以及wsocks32.dll发起网络请求，事实上我们的样本也的确会在任务栏触发这样的一个请求，
而且会弹出一个框
经过我们多次尝试，当我们点击
是的时候劫持就会发生劫持，点击否的时候不会发生劫持，分析到这的时候，让我想起来技术手段可能是APC注入继续往下分析
调了
kernel32.dll库，大致看了下，有获取进程快照的，有获取进程第一个堆的，有查找进程的，有查找模块的看到这，对于我们上边推测的劫持是由
APC注入导致的肯定又多加了一分概率，但也可能是游戏行为，因为也可能是利用查找进程进程和堆进行一些功能性的判断也说不定然后我们继续分析他调了
kernel32.dll库都干了什么，要实现什么来到反汇编,代码顶部函数名
sub_49F438
查看交叉引用
往上翻，翻到
sub_4BFC98这个函数
这块主要功能就是查找进程然后打开，然后在往上翻，查看交叉引用，到了
sub_4E6B00函数
注意我标记的这几个地方，然后我们看流程图
分析到
sub_4C0AEC这个函数，我们跟进
然后看到这，我们就明白了，上边的流程是干嘛的了，意思就是样本获取进程线程ID，然后去寻某个进程，如果找到了，就执行
sub_4C0AEC这个函数，执行delme.bat，然后start什么什么，然后执行ExitProcess
我们把它引用的所有交叉流程分析了一遍流程都差不多，那就意味这，这三个交叉引用的函数，可能是查了三次不同的进程，具体查了什么我们可以动态去调出来
我们在分析导入函数，在
kernel32.dll中发现了引起我们注意的函数WaitForMultipleObjectsEx以及WaitForSingleObject我们定位到
WaitForSingleObject所在函数，查看其交叉引用
我们随便跟进一个函数，比如说
sub_4120C0这个函数，查看其交叉引用sub_41226C函数如下
作用就是获取线程ID然后执行
sub_4120C0等待线程挂起关闭，然后进入Sleep进行延时查看交叉引用跟进函数
sub_4CC2AC
看到分析出来字符串Set-cookie设置cookie，推测似乎是和网络请求有关
然后继续在往上追到函数sub_4CBD88
很明显是在构造http的请求头
WaitForSingleObject函数调用关系分析完了但是没啥关联性，我们继续看WaitForMultipleObjectsEx，跟进其所在的函数顶部sub_43AF88
这里利用一个循环来处理传过来的消息，传过来什么消息，开头获取了
sub_43AF88的句柄，我们看看这里调里
FindWindowExA
FindWindowExA是Windows API的一个函数，该函数获得一个窗口的句柄，该窗口的类名和窗口名与给定的字符串相匹配。
我们先来看看FindWindowExA 定义，也就是说获取窗口句柄与给定定字符串比对，和谁进行比对，往下看sub_407BE0函数
这里传里一段数据进行tls的解密，并获取线程ID返回传给hWnd
在往上追到sub_43B06C函数
这里边用了一个泵式等待的函数
CoWaitForMultipleHandles，具体用法如下
在分析的时候琢磨好长时间用它干啥，让我想起样本如果很长时间没有人点击
是就会默认按照是的条件运行，或者说我们调试器遇到MessageBox不去管他，程序跑过去一直步过超过等待时间就会自动加载，我推测sub_43AF88就应该起了这样一个作用，至于具体传了什么数据，我们得动态交叉引用，继续往上追
sub_43B17C
没啥好分析的
sub_43B17C再往上就没有引用了，但是我们空格切换汇编代码
IDA把这段代码识别成文本了，但是我们通过偏移地址发现off_43AE44这段数据涉及函数是sub_49E71C，跟进其中call了一个sub_42B40C函数
这里我们看到调用了一个ResumeThread函数，这个函数的意义是恢复函数线程，看到这懂得都懂 /滑稽
我们继续查看交叉引用，往上追
将字符串交给
sub_4BCE68去解密，这里调了LoadLibaryA，去加载dll，
函数
sub_4BCE68执行过程我们在前面分析到，样本运行会弹一个框，所以我们通过查看交叉引用
sub_40FA28为有关MessageBox的最外层的函数，
首先
sub_40FA28会进入sub_40F8A0函数
调用
GetModuleFileName这个参数，去获取当前进程已加载模块的文件路径，进行读取数据，解密数据
这是退出时
sub_4050EC函数最后一个调用，关键就是判断sub_404FCC(); sub_405060();最后执行
sub_40C144函数退出进程，至于后边一堆函数调用就是判断数据以及上边的调用，有没有执行完，执行完调用ExitProcess结束然后，进入一个JZ判断，结果不等于0，获取字符串，在桌面重新生成一个程序，然后返回
如果等于0，然后弹窗显示，
LoadStringA_0的作用根据运行结果推断是加载
这样的一个弹框，打完补丁之后，也会进行一系列的判断，会执行退出
在分析过程中，发现
sub_49234C这个函数也调用了MessageBoxA
调用了关键函数
sub_487054
主要调用GetCurrentThreadId和EnumThreadWindows，目的就是获取线程ID并进行枚举
动态分析
行为分析
样本运行之后会释放msg_xxxx.jpg文件，msg后边的命名是随机的
然后在
C:\Users\jhon\AppData\Local\Temp释放rar_xxxx.exe文件，rar后边的命名也是随机的
rar_xxxx.exe程序进行映像劫持，但是在我的Windows10的机器上并未劫持成功
然后
rar_xxxx.exe，释放并加载驱动程序到C:\Windows\System32\drivers目录下
然后样本执行两次销毁
rar_xxxx.exe程序
对msg_oetjdg.jpg的分析
file看一下是data类型
将它投入ida，看起来是加密的
对释放对驱动程序分析
我们首先看一下子字符串能不能发现什么信息，提取了一些比较关键的信息
/?t=1
[ENDBASE64]
[BASE64]
<
由于我们在
rar_xxxx.exe释放之前停掉了Process Monitor抓取，所以导致rar_xxxx.exe没有抓去到，但好在火绒剑抓取到了，但是pid记录的不太一样
这里边释放了两个程序，一个
rar_gqmpjn.exe,一个是rar_uyditq.exe我们知道这个了，我们再回到调试器，进行单步，在
ZwCreateUserProcess处下断，经过以上推断以及调试基本确定是APC注入导致的劫持，然后我们单步看到主进程创建了一个7984的线程
我们在ResumeThread处下断，样本跑到此处pid为2802，然后我们再已管理员打开一个x32dbg进行进程附加
新的进程pid为
7416然后我们主进程的
x32dbg单步
然后我们通过
Process Monitor发现样本在7416基础上又创建了个线程9128,草，真tm恶心啊
也就是说我们得断在创建
9128线程之前，才能捕获到释放的文件恢复快照之后，在跑到
ResumeThread停下，对3064进行attach
在
Writefile处下断，然后我们单步
我们在单步过程中发现，样本的数据基本都是远程获取，动态解密的，所以就很狗
在
Writefile处停下，获取到释放的文件在
Deletefile处下断，运行停下之后
样本解密释放执行之后会进行自动删除，但是我们从这里看到从百度贴吧获取图片，然后到本地进行重命名，
rar_xxxx.exe会从图片进行解密
恶意代码行为
rar_xxxx.exe从图片进行解密之后，会在释放驱动文件
C:\Windows\System32\drivers\puhsvgvhhu.sys
既然得到了释放的样本我们简单分析一下子，我们把样本单独放在虚拟机运行了一下子，发现
Process Monitor并没有记录太多有用的东西，于是又重新跑了一边程序，Process Monitor没有记录加载驱动的过程，但是火绒剑记录到了
| 时间 | 名称 | 进程号 | 操作 | 路径 | 执行结果 |
|---|---|---|---|---|---|
| 16:53:55:800 | rar_qlessd.exe | 3364 | EXEC_create | C:\Users\mac\AppData\Local\Temp\rar_qlessd.exe | parent_pid:7000 cmdline:‘C:\Users\mac\AppData\Local\Temp\rar_qlessd.exe msg_kucxcf.jpg’ image_base:0x00007FF60A790000 image_size:0x00034000 |
| 16:53:55:815 | conhost.exe | 3364 | FILE_open | C:\Users\mac\AppData\Local\Temp\rar_miirmz.exe | access:0x00000080 alloc_size:0 attrib:0x00000000 share_access:0x00000007 disposition:0x00000001 options:0x00200000 |
| 16:53:55:831 | conhost.exe | 3364 | FILE_open | C:\Users\mac\AppData\Local\Temp\rar_miirmz.exe | access:0x00000080 alloc_size:0 attrib:0x00000000 share_access:0x00000007 disposition:0x00000001 options:0x00200000 |
| 16:53:55:831 | conhost.exe | 3364 | REG_openkey | HKEY_CURRENT_USER\Console\C:_Users_mac_AppData_Local_Temp_rar_miirmz.exe | access:0x02000000 |
| 16:53:55:831 | conhost.exe | 3364 | REG_openkey | HKEY_CURRENT_USER\Console\C:\Users\mac\AppData\Local\Temp\rar_miirmz.exe | access:0x02000000 |
| 16:53:55:831 | conhost.exe | 3364 | FILE_open | C:\Users\mac\AppData\Local\Temp\rar_qlessd.exe | access:0x00000080 alloc_size:0 attrib:0x00000000 share_access:0x00000007 disposition:0x00000001 options:0x00200000 |
| 16:53:55:831 | conhost.exe | 3364 | FILE_open | C:\Users\mac\AppData\Local\Temp\rar_qlessd.exe | access:0x00000080 alloc_size:0 attrib:0x00000000 share_access:0x00000007 disposition:0x00000001 options:0x00200000 |
| 16:53:55:831 | conhost.exe | 3364 | REG_openkey | HKEY_CURRENT_USER\Console\C:_Users_mac_AppData_Local_Temp_rar_qlessd.exe | access:0x02000000 |
| 16:53:55:831 | conhost.exe | 3364 | REG_openkey | HKEY_CURRENT_USER\Console\C:\Users\mac\AppData\Local\Temp\rar_qlessd.exe | access:0x02000000 |
| 16:53:55:893 | rar_miirmz.exe | 3364 | FILE_touch | C:\Windows\System32\drivers\puhsvgvhhu.sys | access:0x00100002 alloc_size:0 attrib:0x00000080 share_access:0x00000000 disposition:0x00000005 options:0x00000060 |
| 16:53:55:893 | rar_miirmz.exe | 3364 | FILE_truncate | C:\Windows\System32\drivers\puhsvgvhhu.sys | eof:0x00000000 |
| 16:53:55:893 | rar_miirmz.exe | 3364 | FILE_write | C:\Windows\System32\drivers\puhsvgvhhu.sys | offset:0x00000000 datalen:0x0007AF30 |
| 16:53:55:893 | rar_miirmz.exe | 3364 | FILE_open | C:\Windows\System32\drivers\puhsvgvhhu.sys | access:0x00120089 alloc_size:0 attrib:0x00000080 share_access:0x00000003 disposition:0x00000001 options:0x00000060 |
| 16:53:55:893 | rar_miirmz.exe | 3364 | FILE_modified | C:\Windows\System32\drivers\puhsvgvhhu.sys | 0x00000000 [操作成功完成。 ] |
| 16:53:55:893 | rar_miirmz.exe | 3364 | BA_extract_pe | C:\Windows\System32\drivers\puhsvgvhhu.sys | 0x00000000 [操作成功完成。 ] |
从上面记录我们注意到，rar_qlessd.exe执行了个命令
rar_qlessd.exe msg_kucxcf.jpg
然后我们把这两个文件，拖入到一个新的机器，在终端执行一下子
可以看到直接就能释放驱动，说明这就是关键地方了，哈哈哈，草到这莫名的开心了一下子
接下来就是分析这两个东西了，我们刚刚分析
msg_kucxcf.jpg里边是data，肯定是rar_qlessd.exe去msg_kucxcf.jpg里边解密我们先分析
rar_qlessd.exe，投入ida之后发现都是乱七八糟的函数，没啥头绪，直接动态调终端管理员方式打开，检测一下子，发现程序是x64的，然后启
x64dbg，进行进程附加
通过调试我们发现，样本会在
NtResumeThread，生成驱动并注入我们查看调用栈
发现调用的是
ntdll.dll的函数，NtCreatefile、ZwClose、NtWritefile这些
IOCs
42.81.34.35