某传奇游戏登录器劫持分析
一些乱七八糟的话
某天接到一个样本,说游戏运行之后,在浏览器访问某游戏官方的网站会定向跳转到另一个网站,而且在浏览器搜索该网址关键词也会进行跳转,由于技术比较菜,前前后后看了近一个月,于是就有了这篇文章
有的时候截图中的PID可能不对,还请见谅,因为调这调这程序就跑飞了
基本信息
样本概述
该样本属于供应链劫持,传奇登录器应用下发服务器被入侵,导致软件包被捆绑恶意程序,进行网站劫持。
补充:在后续分析过程中,发现利用方式不像是应用下发服务器被入侵,导致软件包被捆绑恶意程序
,样本最外层是一层upx的壳,想来是用来压缩的,里边是vmp的壳,因为最开始没有一股脑的去拖vmp,因为拖vmp还是很麻烦的,选择的直接调试,所以该样本还有一种可能就是私服开发者有意而为之
样本发现日期
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]
<![CDATA[
<description>
<item>
/?a=1&t=1&s1=%u&s2=%d&s3=%d
\SystemRoot\System32\
/?t=2&c=
mo.cn
hk.cn
tw.cn
xj.cn
nx.cn
qh.cn
gs.cn
sn.cn
xz.cn
yn.cn
gz.cn
sc.cn
hi.cn
gx.cn
gd.cn
hn.cn
hb.cn
ha.cn
sd.cn
jx.cn
fj.cn
ah.cn
zj.cn
js.cn
hl.cn
jl.cn
ln.cn
nm.cn
sx.cn
he.cn
cq.cn
tj.cn
sh.cn
bj.cn
ac.cn
net.ru
com.ru
edu.cn
gov.cn
org.cn
cn.com
net.cn
com.cn
其中发现了,样本用的签名
151222010803Z
161222010803Z0l1
Henan1
Jiaozuo1
feifan7892@gmail.com
Zhang Zhengqi0
拿到这么一些信息,真实与否不做验证
这里边对以上的关键信息进行分析,放入ida看了一下子,没啥头绪,对驱动程序分析少,后续研究驱动程序再来补充。
动态调试
动态调了几次,然后就跑飞了,并未发现样本主进程有释放文件的迹象,然后我们打开Process Hacker
以及Process Monitor
监控一下子
由于我们在
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
相关链接
https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-cowaitformultiplehandles
https://www.hybrid-analysis.com/sample/0815a68dfeb1aaa1027f9201111907d2d87efe3826ba6318a7699c702e84fff9/6125f92a7b1ce839115a7476