警惕GitHub恶意病毒项目，持续活跃释放远控木马

作者：火绒安全
发布时间：2024-05-28
阅读量：921

近期，火绒安全实验室在日常威胁巡视中发现一 GitHub 仓库发布的项目存在病毒风险行为，火绒安全工程师第一时间提取样本进行分析。分析中发现样本会通过多种手段对抗杀软，并最终释放 Remcos 商业远控木马控制受害者机器，且病毒作者仍在积极开发当中。目前，火绒安全产品可对上述病毒进行拦截查杀，请广大用户及时更新病毒库以提高防御能力。

火绒 6.0 查杀图

观察到的病毒样本来源于一个名为 "CodeBlock" 的 GitHub 仓库发布的项目，没有任何有关的项目描述，但已有不少受害者中招。调查分析过程中发现该程序利用多层文件进行跳转，利用层层解密进行免杀，除此之外还利用包括 “天堂之门” 在内的多种手段对抗分析。通过最终释放远控木马，攻击者能够执行各种远程操作，从而使用户机器沦为”肉鸡”。

样本来源仓库

样本执行流程图如下所示：

执行流程图

在此，火绒工程师提醒大家对来历不明的文件应保持警惕，同时安装可靠的安全软件保护设备免受恶意软件和病毒的侵害。目前，火绒 6.0 已上线公测，针对用户的真实应用环境，升级反病毒引擎等核心技术，推出9大硬核功能，可有效解决无文件攻击、系统进程保护、流氓软件等诸多安全问题，为“杀、防、管、控”增强壁垒。欢迎大家前往火绒官方网站下载体验。

一、样本分析

第一阶段分析：

（由于病毒作者的积极开发，样本分析以附录中的 HASH 为准）

从恶意仓库中下载的 "CodeBlock-wallet_v1.3.1.zip" 压缩包内容如下，运行 "CodeBlock-wallet_v1.3.1.exe" 后其只加载 CodeBlock-wallet_v1.3.1-0.bin 和 CodeBlock-wallet_v1.3.1-1.bin 两个文件：

解压文件

"CodeBlock-wallet_v1.3.1.exe" 由 Embarcardero Delphi 编译，是 Inno Setup 的引导程序，其会加载同目录下的 CodeBlock-wallet_v1.3.1-0.bin 进行第二阶段 Payload 文件的释放：

文件信息

Inno Setup 标志

CodeBlock-wallet_v1.3.1-1.bin 是 Payload 的源文件，样本分段读取并解密 CodeBlock-wallet_v1.3.1-1.bin 的内容后，在 C:UsersAdministratorAppDataRoaming 目录下先以xxxx.tmp 的形式释放，再重命名为 bigmouth.ai、nighttime.xlsx、relay.dll、UIxMarketPlugin.dll、UniversalInstaller.exe，随后执行 UniversalInstaller.exe 开启下一阶段流程：

文件重命名

解密文件展示

第二阶段分析：

在前面释放的文件中 UIxMarketPlugin.dll 并没有被加载执行，UniversalInstaller.exe 直接通过 LoadLibraryW 加载同目录下 relay.dll ，调用其 DllMain 函数执行后续主要操作：

加载relay.dll

部分解密逻辑梳理：

relay.dll 的 DllMain 函数会加载同目录下的 nighttime.xlsx 文件并进行解密，先是定位到固定的 D6C0 位置处，获取文件数据区的正向偏移后开始解密 D6C0 处的内容，解密方式是从第 4 位偏移开始，以 DWORD 为单位向前递加，具体细节如下所示：

解密逻辑

解密前后对比

解密后的内容中，前面是需要调用的字符串，relay.dll 会分别定位解密数据前面的 3 个字符串 LoadLibraryA、VirtualProtect、dbghelp.dll，获取其函数地址并进行调用，然后加载 dbghelp.dll 进内存空间准备执行后续注入操作：

定位字符串并调用

解密后的字节码有很多都是用于标记位置的“偏移值”，在加载 dbghelp.dll 后，会先获取用于定位注入 dbghelp.dll 位置的偏移写入解密代码，再根据“划分数据段的”的偏移限制注入大小，以此“分段”执行——即执行代码位于 dbghelp.dll 中，但相关数据依旧存在于解密空间中：

解密内容展示

定位及注入逻辑

注入代码展示

解密关系图

dbghelp.dll 注入代码分析：

Dump 出解密代码进行分析，其先动态获取所需函数，执行相关初始化操作：

动态获取函数

随后读取同目录下 bigmouth.ai 文件进行第一次解密，第一次解密后 0x8、0xC、0x10 偏移处的值是后续调用 RtlDecompressBuffer 函数解压缩的参数：

一层解密代码

一层解密

解压缩后得到真实的数据和代码，包含前面的数据区和后面的代码区：

二层解压缩

同样的读取解密代码前面的字符串数据继续执行下一步注入，这里定位解密代码入口点并替换到加载的 pla.dll 的入口点处：

定位入口点

替换后入口点代码如图所示：

注入入口点

pla.dll 注入代码分析：

pla.dll 中注入的解密代码会读取前面数据区中的 ruzNode_test 字符串用于在 C:UsersAdministratorAppDataRoaming 目录下创建备份文件夹，然后调用 CopyFileW 函数将原先释放的 bigmouth.ai、nighttime.xlsx、relay.dll、UIxMarketPlugin.dll、UniversalInstaller.exe 复制过来作为备份：

复制文件

备份文件目录

随后创建以 C:UsersAdministratorAppDataRoamingruzNode_test 目录下的 UniversalInstaller.exe 为主体的执行进程替换 C:UsersAdministratorAppDataRoaming 目录下的 UniversalInstaller.exe 以执行后续操作：

替换 UniversalInstaller.exe

新启动的 C:UsersAdministratorAppDataRoamingruzNode_testUniversalInstaller.exe 会重复上述解密流程，随后继续以类似的逻辑将分段代码注入到 shdocvw.dll 中（这里不再细究），并在该区段内调用 CreateProcessW 函数创建 "C:WindowsSysWOW64cmd.exe" 进程用于注入第三阶段 shellcode：

创建 cmd 进程

当前进程关系

天堂之门利用：

在创建 cmd 进程后，为了隐藏 API 的调用痕迹，并干扰安全研究人员分析，还特别调用了天堂之门来 “遮掩” 其内存注入的操作：

天堂之门

dump 出的 shellcode 如下，其中传参用的 rcx、rdx、r8、r9 分别由不同的 [rbp-xxh] 来赋予：

64 位指令解密

通过天堂之门调用 Ntdll!NtCreateThreadEx、Ntdll!NtWriteVirtualMemory 等 API，将下一阶段 shellcode 以远程线程注入到 "C:WindowsSysWOW64cmd.exe" 中——先是将完整的 pla.dll 写入 cmd 的内存空间中，随后再将解密的代码注入到 pla.dll 的 .text 段入口点，最后调用 Ntdll!NtResumeThread 恢复线程：

调用 Ntdll!NtWriteVirtualMemory 展示

被注入的入口点

其中，与 "C:WindowsSysWOW64cmd.exe" 的通信是通过管道进行的，最后会通过管道向 "C:WindowsSysWOW64cmd.exe" 写入"rn" 使其执行注入的 shellcode：

管道通信

第三阶段分析：

第二阶段的代码在成功注入 "C:WindowsSysWOW64cmd.exe" 后会在 "C:UsersAdministratorAppDataLocalTemp" 目录下释放加密的字节码文件，被注入的 "C:WindowsSysWOW64cmd.exe" 在执行过程中会读取该文件的内容并进行解密：