图文分析报告 - waitfor/bindup.dll
1.6
4aededd1a9551228e658ef60fced42653339a4565399ed6a530ae528b9bc44ea
初始载荷msi - bindup.dll
释放文件
释放第一波文件
C:\Program Files (x86)\ToDesk_Setup\ToDesk_Setup

其中bindup.dll emjio.tmp resource.png为黑文件
解压resource.png释放第二波文件
C:\Users\Administrator\AppData\Roaming\BluTm_82jd

其中dvacore.dll emjio.tmp ClenaTemp.bat为黑文件
调用链
msi释放完文件后调用bindup.dll内部函数
1.写入注册表payload
payload实际为ToDest_setup目录下的emjio.tmp







最终实现将payload写入注册表中
2.调用ClenaTemp.bat


进行启动第二波释放的文件
最后挖空注入waitfor.exe
3.waitfor劫持进行远控
无持久化保护
incremation.exe - dvacore.dll
ClenaTemp.bat内容如下:
1 | @echo off |
启动incremation.exe,incremation被dvacore.dll挟持
dvacore.dll内容如下

打开的是同目录下emjio.tmp
直接APC创建线程
emjio.tmp主要逻辑内容如下


进行对ipconfig的挖空注入,最后由前文的ClenaTemp监控持久化
后续分析
2026/1/6 9:59:08.3628482
初始载荷.msi
第一次释放
释放第一批文件C:\Users\Administrator\AppData\Roaming\BluTm_82jd



increm以下全部是白文件.tmp与deacore和ClenaTemp.bat
主要调用链是 ClenaTemp.bat调用incremation.exe并做持久化,检测如果incremation消失就再次创建 .bat内容如下
1 | @echo off |
从CreateProcess下断点分析到的是对ipconfig进行挖空注入,这个时候注册表就已经有payload了,再通过hex值匹配最终确定这部分代码是.tmp的,.tmp的内容如下



分析dvacore.dll,有很强的字符串名字混淆,
a1的值是\emjio.tmp
并且这里得到的值和注入的一样,所以tmp是payload,这里是在文件头的11D3偏移
后续有VirtualAlloc和APC的注入函数,然后运行
按顺序来
白文件incremation运行,加载dvacore黑dll
dvacore.dll通过VirtualAlloc和QueueUserAPC运行emjio.tmp从11D3开始的函数
emjio.tmp先是动态解壳(通过运行时偏移确定)然后进行挖空注入,运行注册表中的payload
单独运行.bat文件,并不会使我删除的注册表payload恢复,重新运行.msi才能恢复,或许向msi写值是第二部分释放文件做的,因为第一部分确实很完善了,
第二次释放
释放文件,文件路径 C:\Program Files (x86)\ToDesk_Setup\ToDesk_Setup

3.加载bindup.dll(算黑dll吗)里面有动态计算形式的混淆,不过主要逻辑基本不在动态计算混淆里
bindup.dll部分

大致总结流程
先是这个函数

内部有



进行取值,最后使得v459为注册表中HKEY_CURRENT_USER\Software\DeepSer\MyData的值
然后是注入函数

内部:


这里传入的v459与v466作为a2 a3 在内部进行复制给lpBaseAddress

此时完成内存的注入
创建进程 , 挖空进程 ,改写信息,这里是要进行经典注入了




最后重启线程,完成注入
payload
最后是注入的payload 提取后应该就是最终载荷了,因为日志上也是这一步之后开始反连了
1
注册表 HKEY_CURRENT_USER\Software\DeepSer\MyData 写入 payload