背景

某客户单位发现有一台终端有可疑网络外连行为,友商应急后发现是一个rootkit,猜测是APT事件,于是我方介入调查分析.

反调试

样本为使用VMP2.x保护的驱动rootkit,通常分析这种样本会使用双机调试方法,但加载rootkit时VMP会检测是否开启内核调试(即双机调试),如果开启直接返回错误.

VMP中常用的内核反调试手段是：

• KdDebuggerEnabled
• KdDebuggerNotPresent

将这些地方处理掉即可成功加载rootkit.

调试技巧

因为没有符号,双机调试时需要在Rootkit入口点下断点,根据不同的系统有不同的方法:
uf /c @rip查看函数调用

• Win7 IopLoadDriver 函数中的call qword ptr[xxx + xxx]
• Win10低版本IopLoadDriver -> _guard_dispatch_icall -> jmp rax
• Win10高版本(19xx和Win11)IopLoadDriver -> PnpCallDriverEntry-> _guard_dispatch_icall -> jmp rax

入口点断下来以后,前面为壳的处理代码,不是我们要关心的.
可以使用unicorn_pe工具对加了壳的Rootkit进行dump处理.
unicorn_pe.exe <filename> -k -dump
还可以使用条件断点,通常情况下驱动程序都需要创建设备,使用的函数为IoCreateDevice.
对该函数设置条件断点(此处使用的是Windbg Data Model),只有来自rootkit对该函数的调用时才会命中断点.
lm查看模块,rootkit的地址范围为fffff80014020000-fffff8001403c000
此时要注意下断点时不能下到函数头部,VMP会检测函数头,所以通常要往下几个字节.此处我选择的是 + 5的位置.
bp /w "@$curthread.Stack.Frames[0].Attributes.ReturnOffset > fffff80014020000 && @$curthread.Stack.Frames[0].Attributes.ReturnOffset < fffff8001403c000" nt!IoCreateDevice+5

创建设备时成功命中：

样本分析

样本首先创建设备,设备名为\\Device\\A8B4U8M6M32001
后续进行创建系统线程(Thread1),设置MajorFunction,设置键盘过滤,注入Explorer(Thread2)等操作后主线程进入循环.

线程1：

线程1会先从自身解密出来C2和DNS
C2:secure.pig.vip
xor key:0xCB2FA36AAA9541F0
DNS:8.8.8.8和114.114.114.114
端口:21|25|53|80|808|443|

接着进行设备HOOK,此操作可以对网络连接进行隐藏.使用了两种方法,一种是NsiProxy,另一种是TCP.均是获取设备对象后对MajorFunction[IRP_MJ_DEVICE_CONTROL]进行HOOK.


然后进行隐藏文件的操作:
通过对ntfs的MajorFunction[IRP_MJ_CREATE]进行HOOK,应用层通过CreateFile获取ROOTKIT的文件句柄时,返回的是fltMgr.sys的句柄.

接着使用APC对Explorer进行注入操作.Shellcode具备以下操作：

然后Rootkit使用TDI进行网络通信,通过DNS对C2进行解析获取通信IP,随机选择前面解密出来的端口,创建连接,获取本地信息发送到远程服务器.



并创建系统线程进入命令模式.

后续通信均是在内核中完成,使用netstat或Process Hacker等工具均无法发现.
但Sysinternals套件中的TCPView可以看到远程连接.
配置好的sysmon也可以看到远程连接.



ARK工具PCHunter可以检测到nsiproxy hook

其他

通过vt关联发现另一个相似的样本,当前两个样本在vt上均是0查杀状态.


从时间戳上来看,两个样本均为几年前编译的.且样本2在19年已经提交到vt上.


那么这两个样本至少已经存在了3年以上,对于rootkit的检测来说,情况可能并不乐观.
C2懒得分析了.

IOCs

domain:secure.pig[.]vip
IP:93.189.63[.]214