本帖最后由 huoronganquan 于 2025-9-27 02:49 编辑
三. 任务载荷(通过感染载荷释放的具有白签名的EXE通过任务计划侧加载的npwzwmc64.dll)分析 1. 结构分析 [1] 白签名EXE签名信息 任务载荷由计划任务启动一个具有白签名的EXE, EXE详细签名信息如下:
白签名EXE详细签名信息
[2] 通过WINDOWS签名特性修改文件哈希值 细心的读者可能注意到, 之前的感染载荷流程中, 感染载荷释放文件时将文件的最后一个字节进行了修改, 但是此处签名依然有效。 Windows在计算PE文件的哈希时会跳过文件末尾的数字签名数据,也就是WIN_CERTIFICATE结构体,该结构体由可选头的安全目录指向。其中,dwLength必须是8的整倍数,表示整个结构体的长度（包括结构体头部和它本身）。因此, 这里篡改后签名仍然有效的原理很简单,在数字签名末尾夹带数据,并对应调整结构体大小就行。 在这里被利用的白签名EXE文件中导入表中包含对"npwzwmc64.dll"的导入, 该病毒通过DLL侧载的原理, 将恶意DLL放到EXE相同路径下, 替换了本应被导入的该DLL, 从而使得DLL被加载。
白签名文件导入表信息
该DLL疑似由VMProtect进行保护, 文件详情如下
任务载荷文件详细信息
2. 执行流程分析 [1] 通过RC4解密SPACE.ICO, 将其写入白文件入口点继续执行 对任务载荷主函数进行优化, 得到代码如下:
- __int64 virus_main(__int64 a1, __int64 a2)
- {
- kernel32_SetProcessShutdownParameters(1, 1);
- kernel32_SetConsoleCtrlHandler(sub_7FFF678D2F00, 1);
-
- ZeroMemory(v142, 24);
- {
- const unsigned char k1[8] = {122, 196, 169, 246, 204, 248, 31, 73};
- qmemcpy(v132, InitializePair(v135, k1, v57), sizeof(v132));
- AssignContainer(v142, v132, v58);
- }
-
- ZeroMemory(v141, 24);
- {
- const char k2[4] = {';', 'G', '_', 'f'};
- qmemcpy(v133, InitializePair(v136, k2, v55), sizeof(v133));
- AssignContainer(v141, v133, v59);
- }
-
- ZeroMemory(v140, 24);
- LoadEncryptedFile(v140);
-
- if (v18)
- {
- ZeroMemory(v139, 24);
- ProcessEncryptedSegment(v139, v140, v142, v141);
-
- if (v28)
- {
- HANDLE hProcess = kernel32_GetCurrentProcess();
- HMODULE hModule = kernel32_GetModuleHandleW(0);
- MODULEINFO mi;
- kernel32_K32GetModuleInformation_0(hProcess, hModule, v137, 24);
-
- kernel32_WriteProcessMemory(
- hProcess,
- (LPVOID)v138,
- (LPVOID)v139[0],
- (SIZE_T)(v139[1] - v139[0]),
- v143);
-
- kernel32_DisableThreadLibraryCalls(a1);
- }
- CleanupObject_0(v139, 0);
- }
-
- CleanupObject_0(v140, 0);
- CleanupObject_0(v141, 0);
- CleanupObject_0(v142, 0);
-
- return 1;
- }
从代码可知, 其功能为加载并通过RC4算法解密文件space.ico, 将文件写入自身进程的入口点, 从而在回到入口点时执行其自定义的代码。
任务载荷修补入口点代码图
四. 过程载荷(被任务载荷解密的SPACE.ICO)分析 过程载荷解密"vdi_ipc.dat", 通过ManualMap函数将其映射到内存中, 找到其中的导出函数"KMDrvFaxGetJobStatusType", 对其进行调用。
过程载荷主代码逻辑图
五. 最终载荷(过程载荷解密的vdi_ipc.dat)分析 1. 结构分析 该文件的大小为0x616755(6.08MB), 文件信息分析如下, 被VMProtect+OLLVM保护。
最终载荷文件分析详情图
2. 执行流程分析 由于程序混淆力度较强, 控制流杂乱, 我们主要对该程序的组成模块进行分析, 不再分析其执行条件顺序。 [1] 程序遍历所有进程, 通过进程名找到安全软件对应的进程ID并记录 搜索的安全软件名称如下:
安全软件名称列表
[2] 程序加载漏洞驱动结束安全软件进程 (1) 程序运行时读取C:\Windows\TEMP\ranchserv.jpg作为驱动文件数据 (2) 程序创建管道, 名称为"\\.pipe\ntsvcs" (3) 程序通过RPC协议创建服务 程序通过RPC协议发送RPC_CMD_ID_CREATE_SERVICE来创建服务, 服务名称为"TCLService" 在Windows中, 进程可以通过RPC向"367abb81-9844-35f1-ad32-98f038001003"发送请求来创建服务, 在本样本中, 载荷通过RPC创建名称为"TCLService"的服务。具体原理———附录：参考文章[6] 加载驱动代码图 (4) 程序通过加载漏洞驱动并终结安全软件进程 程序通过服务加载"TrueSight"漏洞驱动, 然后打开其IO设备, 通过IO控制码0x22E044强制终结所有被搜索到的安全软件进程。 [3] 程序尝试创建或检测互斥体 名称如下: {4E062DDA-444A-A2A8-84CE-E105F66A5AB3} Global\8E416074-5245-AF71-E9F7-7D3194498C53 Global\3575D265-2C4F-5C20-EB78-D147D5670A9C [4] 程序扫描火绒安全软件 程序扫描火绒主进程和主防进程, 如果在调用漏洞驱动终结进程后还存在则停止执行后续逻辑。
扫描火绒安全软件代码图
[5] 程序读取“C:\Users\Public\Music\desktopbak.ini”
读取对应文件代码图
[6] 程序枚举注册表子项“HKEY_LOCAL_MACHINE\SOFTWARE\SysConfigDate”
打开注册表键代码图
[7] 程序进一步访问下一步C&C(已下线) 在检测一系列条件后, 程序从内存中异或解密出被加密的C&C字符串。 其密文为： - blob1 = bytearray(b"\x00\xEA\xCB\xDB\xF4\xD0\xC6\xD2")
- blob2 = bytearray(b"Lm",n,$( 2!%>b,"&)[ DISCUZ_CODE_122 ]lt;0'{585v<(r7.8`")
密文串获取对应代码
对其算法去虚拟化后, 得到最终解密算法为将所有字节异或4。 - blob1 = bytearray(b"\x00\xEA\xCB\xDB\xF4\xD0\xC6\xD2")
- blob2 = bytearray(b"Lm",n,$( 2!%>b,"&)[ DISCUZ_CODE_123 ]lt;0'{585v<(r7.8`")
- for b in range(len(blob1)):
- blob1[b] ^= 4
- for b in range(len(blob2)):
- blob2[b] ^= 4
- url = blob1.decode() + blob2.decode()
- print(url)
最终代码解密结果
目前该病毒C&C已失效, 后续流程通常是继续获取用户主机的控制权, 从而在用户主机中布置远控后门, 实现个人信息的窃取和利用。具体细节可查看参考文章中往期分析对银狐样本的报告。
五、结语 该样本总体上来说攻击方法相比较之前的银狐样本并未有太大改变, 在往期分析报告中也分析到过与本文样本行为相似的恶意样本, 地址在参考文章中。———附录：参考文章[5] 与往期分析报告不同的是, 本文样本的代码混淆强度和方式得到了明显提升, 这背后可能对应着一条完整的"免杀"产业链。在"黑客"群体中, 有这样一种人: 其掌握着对代码进行混淆、变异等各种手段欺骗安全软件使其对原本"报毒"的样本不再报毒的手段, 专门通过为其他人的病毒提供"免杀"服务来谋取利益。 但是只要代码还需要被二进制化执行, 就一定可以被分析。其考验安全从业人员的功底, 也意味着安全软件的自动化分析流程不断面临新的挑战。
六、附录 参考文章: HASH: C&C:
|
收藏