标签 反调试 下的文章

一、概述

近期，天穹沙箱团队在追踪银狐家族的攻击活动时，发现其最新样本采用了高度复杂且极具迷惑性的攻击链。该攻击链通过多阶段反调试检测、伪装合法软件安装、内存反射加载等技术，并结合隐蔽的进程注入与DLL侧载（DLL Side-Loading）等手段，以规避安全检测，实现持久驻留于受害者主机。

二、样本信息

  • 样本名： Rar0092_v3.53.278_2xdcey.exe
  • SHA1：50715a3abd66e17654255b7881b035d006dce605
  • 文件类型：EXE
  • 文件大小：127.03 MB
  • 家族归属：银狐家族
  • 报告链接：天穹沙箱分析报告

三、样本分析

该样本具备高度隐蔽性，在执行过程中反复侦测运行环境，其执行逻辑具有明显的多层次、复杂化特征。天穹智能化沙箱系统凭借其全链路行为深度建模与动态分析能力，成功完整捕获并解析了该样本从初始释放、伪装执行、多阶段内存加载到最终持久化与 C2 通信的全过程。系统不仅精准识别了其反调试、环境探测、权限提升等规避行为，还完整提取了各阶段解密后的恶意载荷。以下结合沙箱动态分析结果细致分析样本的恶意行径。

图1 攻击流程

1、反调试检测

首先，样本运行后先检测自身是否处于调试状态，通过检查 PEB->BeingDebugged 字段识别当前是否被用户态调试器附加调试。
接着，调用 NtQuerySystemInformation(SystemBasicInformation) 接口获取当前系统基本信息，检测 CPU 核心数量是否满足 >= 3 核，以及物理内存大小是否满足 >= 3G，样本依据上述硬件配置判断是否处于沙箱分析环境。

图2 反调试检测

当以上检测要求通过后，样本开启真正的恶意能力释放。为保护自身核心代码和逻辑不被轻易窥探，外部函数调用均通过手动查找 LDR 链表获取模块基址，再解析 PE 头获取函数地址，增加函数调用的隐蔽性。
这类多层环境感知检查被深度内嵌在代码执行流的关键节点上，形成贯穿始终的对抗屏障，阻碍安全人员的动态调试和静态分析。

2、伪装安装程序

环境检测通过后，样本再度检查自身是否具有管理员权限，权限满足后会在 C:\\ProgramData 目录下创建随机字符串的目录，并释放多个文件：

app.exe._ (MD5：f041793908111b5395226bc9ed5e6698)
README.md (MD5：daa5414f94d8f43925efffd79979cf75)
View.dat (MD5：c2db56df94b92d6370c87303d1506f54)
Web.dat (MD5：937ab7f863261a046ba3dd46df7cb270)
åº ç ¨å® .exe (MD5：34f435f15a846ae677f88ea412c074d1)
View.conf (MD5：85fac9d703132b9a28beb11d8ec3d181)
alt text
图3 创建目录释放文件

其中 åº ç ¨å® .exe (MD5：34f435f15a846ae677f88ea412c074d1) 为腾讯应用宝的可信安装程序，其余文件为样本后续阶段运行的加密 payload。
为掩盖程序真实意图，样本在释放恶意文件后，调用 WdcRunTaskAsInteractiveUser 接口运行腾讯应用宝安装程序，制造正常操作的假象，欺骗用户。随后，样本隐蔽地拉起 app.exe 进程，进入下一阶段的恶意操作。

图4 伪装程序

3、Payload 加载与执行

第一阶段： View.dat 文件 payload 为 raw 数据，样本通过 VirtualAlloc 分配内存，将 payload 解密后写入内存，并调用 CreateThread 函数创建线程执行该段 payload。
解密后的 payload 是一段具备内存反射加载 PE 文件功能的 shellcode，会加载 raw 数据中夹带的 DLL 文件，并调用其入口函数 DllEntryPoint 进入下一阶段逻辑。

图5 加载 payload

第二阶段： 内存加载的 DLL 文件注册服务并运行 svchost.exe 进程，并注入其他两个文件中包含的 payload (app.exe._ 和 View.dat)

图6 注入 payload

值得说明的是，在本阶段执行注入操作时样本会判断运行环境，高版本 Windows 系统将使用 PoolParty (泳池派对) 注入技术。
注入的恶意代码会在用户目录下释放两个文件：WebViewHelper.exe 和 libcef.dll，其中 WebViewHelper.exe 为具备合法签名的白文件，被用来加载黑文件 libcef.dll，达到混淆视听的目的。

图7 释放文件

svchost.exe 进程通过自启动服务方式运行重命名之后的 WebViewHelper 进程，进入下一阶段逻辑。

第三阶段： WebViewHelper 进程加载的恶意 DLL 文件 (libcef.dll) 会进行一系列的环境检测，包括判断运行环境、所属 session 以及管理员权限等，检测通过后与 C2 服务器建立通信。

图8 环境检测
图9 网络通信
图10 样本攻击链

整个攻击链逻辑错综复杂，层层递进，分析难度极大。同时，攻击者通过伪装合法安装程序、利用白文件加载黑文件等方式混淆视听，进一步干扰了用户和安全人员的判断。

四、IOC

恶意文件（MD5）

481577b35e4d09510c49d78f5c3fa98c    Rar0092_v3.53.278_2xdcey.exe
0c0d6806bb8caf68d4dfa5208db52a17    app.exe
f041793908111b5395226bc9ed5e6698    app.exe._
daa5414f94d8f43925efffd79979cf75    README.md
c2db56df94b92d6370c87303d1506f54    View.dat
937ab7f863261a046ba3dd46df7cb270    Web.dat
34f435f15a846ae677f88ea412c074d1    åº ç ¨å® .exe
85fac9d703132b9a28beb11d8ec3d181    View.conf
c154442ddf6363b6ac5822e47028d672    WebViewHelper.exe
74be16979710d4c4e7c6647856088456    libcef.dll

恶意IOC

192.238.201.32[:]30009              C2 地址

报告链接

分析报告：天穹沙箱分析报告

五、检出规则

天穹沙箱已针对该银狐变种样本编写如下YARA规则，供用户参考使用：

rule Trojan_SilverFox
{
    meta:
        description = "银狐变种的检测"
        date = "2026-01-04"
    strings:
        $seq1 = { 81 E2 FF 00 00 00 03 C2 25 FF 00 00 00 2B C2 88 04 24 48 63 44 24 04 48 8B 4C 24 20 8A 04 01 88 44 24 01 0F B6 04 24 48 63 4C 24 04 48 8B 54 24 20 4C 8B 44 24 20 41 8A 04 00 88 04 0A 0F B6 04 24 48 8B 4C 24 20 8A 54 24 01 88 14 01 }

        $seq2 = { 81 E2 FF 00 00 00 03 C2 25 FF 00 00 00 2B C2 48 8B 4C 24 20 88 81 01 01 00 00 48 8B 44 24 20 0F B6 80 00 01 00 00 48 8B 4C 24 20 8A 04 01 88 04 24 48 8B 44 24 20 0F B6 80 01 01 00 00 48 8B 4C 24 20 0F B6 89 00 01 00 00 48 8B 54 24 20 4C 8B 44 24 20 41 8A 04 00 88 04 0A 48 8B 44 24 20 0F B6 80 01 01 00 00 48 8B 4C 24 20 8A 14 24 88 14 01 48 8B 44 24 20 0F B6 80 00 01 00 00 48 8B 4C 24 20 0F B6 04 01 48 8B 4C 24 20 0F B6 89 01 01 00 00 48 8B 54 24 20 0F B6 0C 0A 33 C1 }

    condition:
        all of them
}

六、技术支持与反馈

星图实验室深耕沙箱分析技术多年，致力于让沙箱更好用、更智能。做地表最强的动态分析沙箱，为每个样本分析人员提供便捷易用的分析工具，始终是我们追求的目标。各位同学在使用过程中有任何问题，欢迎联系我们。

技术报告, ,

666 大佬，请问这两个也是直接放在根目录 代码命名为 typora-patch.js 对吗？ （是否需要阻止更新啥的呀）
PS: windows 也能用的是吧

📌 转载信息
原作者：
grvdd
转载时间：
2026/1/24 06:38:07

一、概述

近期，天穹沙箱团队在追踪银狐家族的攻击活动时，发现其最新样本采用了高度复杂且极具迷惑性的攻击链。该攻击链通过多阶段反调试检测、伪装合法软件安装、内存反射加载等技术，并结合隐蔽的进程注入与DLL侧载（DLL Side-Loading）等手段，以规避安全检测，实现持久驻留于受害者主机。

二、样本信息

  • 样本名： Rar0092_v3.53.278_2xdcey.exe
  • SHA1：50715a3abd66e17654255b7881b035d006dce605
  • 文件类型：EXE
  • 文件大小：127.03 MB
  • 家族归属：银狐家族
  • 报告链接：天穹沙箱分析报告

三、样本分析

该样本具备高度隐蔽性，在执行过程中反复侦测运行环境，其执行逻辑具有明显的多层次、复杂化特征。天穹智能化沙箱系统凭借其全链路行为深度建模与动态分析能力，成功完整捕获并解析了该样本从初始释放、伪装执行、多阶段内存加载到最终持久化与 C2 通信的全过程。系统不仅精准识别了其反调试、环境探测、权限提升等规避行为，还完整提取了各阶段解密后的恶意载荷。以下结合沙箱动态分析结果细致分析样本的恶意行径。

图1 攻击流程

1、反调试检测

首先，样本运行后先检测自身是否处于调试状态，通过检查 PEB->BeingDebugged 字段识别当前是否被用户态调试器附加调试。
接着，调用 NtQuerySystemInformation(SystemBasicInformation) 接口获取当前系统基本信息，检测 CPU 核心数量是否满足 >= 3 核，以及物理内存大小是否满足 >= 3G，样本依据上述硬件配置判断是否处于沙箱分析环境。

图2 反调试检测

当以上检测要求通过后，样本开启真正的恶意能力释放。为保护自身核心代码和逻辑不被轻易窥探，外部函数调用均通过手动查找 LDR 链表获取模块基址，再解析 PE 头获取函数地址，增加函数调用的隐蔽性。
这类多层环境感知检查被深度内嵌在代码执行流的关键节点上，形成贯穿始终的对抗屏障，阻碍安全人员的动态调试和静态分析。

2、伪装安装程序

环境检测通过后，样本再度检查自身是否具有管理员权限，权限满足后会在 C:\\ProgramData 目录下创建随机字符串的目录，并释放多个文件：

app.exe._ (MD5：f041793908111b5395226bc9ed5e6698)
README.md (MD5：daa5414f94d8f43925efffd79979cf75)
View.dat (MD5：c2db56df94b92d6370c87303d1506f54)
Web.dat (MD5：937ab7f863261a046ba3dd46df7cb270)
åº ç ¨å® .exe (MD5：34f435f15a846ae677f88ea412c074d1)
View.conf (MD5：85fac9d703132b9a28beb11d8ec3d181)
alt text
图3 创建目录释放文件

其中 åº ç ¨å® .exe (MD5：34f435f15a846ae677f88ea412c074d1) 为腾讯应用宝的可信安装程序，其余文件为样本后续阶段运行的加密 payload。
为掩盖程序真实意图，样本在释放恶意文件后，调用 WdcRunTaskAsInteractiveUser 接口运行腾讯应用宝安装程序，制造正常操作的假象，欺骗用户。随后，样本隐蔽地拉起 app.exe 进程，进入下一阶段的恶意操作。

图4 伪装程序

3、Payload 加载与执行

第一阶段： View.dat 文件 payload 为 raw 数据，样本通过 VirtualAlloc 分配内存，将 payload 解密后写入内存，并调用 CreateThread 函数创建线程执行该段 payload。
解密后的 payload 是一段具备内存反射加载 PE 文件功能的 shellcode，会加载 raw 数据中夹带的 DLL 文件，并调用其入口函数 DllEntryPoint 进入下一阶段逻辑。

图5 加载 payload

第二阶段： 内存加载的 DLL 文件注册服务并运行 svchost.exe 进程，并注入其他两个文件中包含的 payload (app.exe._ 和 View.dat)

图6 注入 payload

值得说明的是，在本阶段执行注入操作时样本会判断运行环境，高版本 Windows 系统将使用 PoolParty (泳池派对) 注入技术。
注入的恶意代码会在用户目录下释放两个文件：WebViewHelper.exe 和 libcef.dll，其中 WebViewHelper.exe 为具备合法签名的白文件，被用来加载黑文件 libcef.dll，达到混淆视听的目的。

图7 释放文件

svchost.exe 进程通过自启动服务方式运行重命名之后的 WebViewHelper 进程，进入下一阶段逻辑。

第三阶段： WebViewHelper 进程加载的恶意 DLL 文件 (libcef.dll) 会进行一系列的环境检测，包括判断运行环境、所属 session 以及管理员权限等，检测通过后与 C2 服务器建立通信。

图8 环境检测
图9 网络通信
图10 样本攻击链

整个攻击链逻辑错综复杂，层层递进，分析难度极大。同时，攻击者通过伪装合法安装程序、利用白文件加载黑文件等方式混淆视听，进一步干扰了用户和安全人员的判断。

四、IOC

恶意文件（MD5）

481577b35e4d09510c49d78f5c3fa98c    Rar0092_v3.53.278_2xdcey.exe
0c0d6806bb8caf68d4dfa5208db52a17    app.exe
f041793908111b5395226bc9ed5e6698    app.exe._
daa5414f94d8f43925efffd79979cf75    README.md
c2db56df94b92d6370c87303d1506f54    View.dat
937ab7f863261a046ba3dd46df7cb270    Web.dat
34f435f15a846ae677f88ea412c074d1    åº ç ¨å® .exe
85fac9d703132b9a28beb11d8ec3d181    View.conf
c154442ddf6363b6ac5822e47028d672    WebViewHelper.exe
74be16979710d4c4e7c6647856088456    libcef.dll

恶意IOC

192.238.201.32[:]30009              C2 地址

报告链接

分析报告：天穹沙箱分析报告

五、检出规则

天穹沙箱已针对该银狐变种样本编写如下YARA规则，供用户参考使用：

rule Trojan_SilverFox
{
    meta:
        description = "银狐变种的检测"
        date = "2026-01-04"
    strings:
        $seq1 = { 81 E2 FF 00 00 00 03 C2 25 FF 00 00 00 2B C2 88 04 24 48 63 44 24 04 48 8B 4C 24 20 8A 04 01 88 44 24 01 0F B6 04 24 48 63 4C 24 04 48 8B 54 24 20 4C 8B 44 24 20 41 8A 04 00 88 04 0A 0F B6 04 24 48 8B 4C 24 20 8A 54 24 01 88 14 01 }

        $seq2 = { 81 E2 FF 00 00 00 03 C2 25 FF 00 00 00 2B C2 48 8B 4C 24 20 88 81 01 01 00 00 48 8B 44 24 20 0F B6 80 00 01 00 00 48 8B 4C 24 20 8A 04 01 88 04 24 48 8B 44 24 20 0F B6 80 01 01 00 00 48 8B 4C 24 20 0F B6 89 00 01 00 00 48 8B 54 24 20 4C 8B 44 24 20 41 8A 04 00 88 04 0A 48 8B 44 24 20 0F B6 80 01 01 00 00 48 8B 4C 24 20 8A 14 24 88 14 01 48 8B 44 24 20 0F B6 80 00 01 00 00 48 8B 4C 24 20 0F B6 04 01 48 8B 4C 24 20 0F B6 89 01 01 00 00 48 8B 54 24 20 0F B6 0C 0A 33 C1 }

    condition:
        all of them
}

六、技术支持与反馈

星图实验室深耕沙箱分析技术多年，致力于让沙箱更好用、更智能。做地表最强的动态分析沙箱，为每个样本分析人员提供便捷易用的分析工具，始终是我们追求的目标。各位同学在使用过程中有任何问题，欢迎联系我们。

技术报告, ,


0x1.前言
Brute Ratel C4（以下简称BRC4）是一位印度老哥开发的C2，用于对抗EDR，也是一款极其优秀的C2了。本文使用的BRC4版本为1.2.2（早已经有更新的破解版本了，但载荷都大差不差）。生成马被称为Badger，类似CobaltStrike的Beacon。如下图是它支持的一些规避方法。在第一篇文章后分析其实现方式，第二篇文章实现此睡眠混淆方式，以及如何在自己开发的马中实现Sleeping Masking。
什么是睡眠混淆，简单的来说就是你的马运行后，为了opsec，需要Sleep，CobaltStrike等C2就是默认Sleep 60s，这就是睡眠的概念。混淆就是指为了规避AV/EDR的内存扫描，需要在内存中对我们的马进行加密，这样就绕过了内存扫描。
在本文中分析BRC4的睡眠混淆方法中的利用APC来达到Sleeping Masking。什么是APC参考MSDN： https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls 。

image-20260109111047796.png

0x02.利用APC进行Sleeping Masking分析
搭建BRC4这些就不说了，创建的监听器的时候，设置Sleep Mask为APC。

image-20260109150623146.png
然后生成马子进行分析，Stageless即可。

image-20260109150850812.png
写个简单的加载器，直接开始调试就行。开头有大量push操作，猜测是核心载荷被压入栈，直接跳过这些。

image-20260109152541979.png
需要先绕过NtGlobalFlag的反调试，把ZF标志位改了就行，接着往下。

image-20260109153108824.png
在通过Hash的方式获取到一些API的地址后，RC4解密出了一个被抹掉MZ头的PE文件，带解密的内容很显然是前面push压入的数据。得到的是核心载荷，后面可能被反射式注入执行。

image-20260109153249913.png
我们将这个PE文件从内存中Dump出来。

image-20260109153413118.png
然后很显然接下来的这个call，开始反射式注入此解密出PE文件了。

image-20260109154412958.png
然后call rax，跳到修复后DLL执行DllMain开始执行。这大概就是Badger的执行上线流程。

image-20260109154716516.png
上线后，我们关注点是Sleeping Masking。直接定位到睡眠混淆的地方。

image-20260109165852761.png
可以根据动态函数地址以及前面Dump出的PE，在IDA中修改函数名（其中调用很多函数都是通过Syscall），进行分析。首先会在堆上分配很多CONTEXT结构，这里的0x4D0代表CONTEXT结构体大小。

image-20260109170053749.png
往下判断是否开启CFG，开启的话，使用SetProcessValidCallTargets扩展CFG允许集合。这是为了后续构造ROP链执行做准备。

image-20260109171734879.png

image-20260109172111715.png
为什么这里判断是否开启CFG？在实际中，一般shellcode都是注入到别的系统进程中，而不是自己写的Loader，系统进程例如RunTimerBorker.exe基本都是开启CF Guard的。所以这里的判断很合理也必要。

image-20260109172406849.png
继续往下看。第一个if块这里不太明白是在干嘛，像是获取当前PE的VA，调试发现不会进入这一块，先跳过。第二个if块是最关键的位置，显然能够进入此if块执行，第一个条件是创建了一个Event对象，第二个是创建了一个挂起的线程，入口点是TpReleaseCleanupGroupMembers + 0x450的地方。这个线程主要是为了后续调用ZwGetThreadContext，为分配的CONTEXT结构体，提供一个正常的CONTEXT和执行APC回调的地方。

image-20260109173644610.png
往下进入第二个if块内容。首先给这几个CONTEXT结构体赋值，表明对什么寄存器感兴趣。然后通过ZwDuplicateObject赋值了当前线程的句柄。然后调用ZwGetThreadContext获取前面TpReleaseCleanupGroupMembers + 0x450入口线程的CONTEXT。并依次赋值到所有的CONTEXT中去。

image-20260109182034372.png
在sub_10019490函数中，之所以没有rename是因为找不到合适的名字，这个函数获取了一个CONTEXT。这个CONTEXT是从当前进程但不是当前执行线程的CONTEXT，在ZwGetThreadContext后，在对这个CONTEXT的Rsp值和Rip值进行处理。

image-20260109182323048.png
奇怪的是该函数返回后并不会进入下面的if分支。不过这里像是在做堆栈欺骗类似的动作？先不管吧，继续往下。

image-20260109182658006.png
开始构造ROP链，对前面分配的每个CONTEXT进行赋值。Rcx、Rdx、R8、R9分别是前四个参数，Rip是要执行的API，返回地址为NtTestAlert，作用就是为了触发APC队列。ROP链执行函数的顺序为ZwWaitForSingleObject、NtProtectVirtualMemory、SystemFunction032、ZwGetContextThread、ZwSetContextThread、WaitForSingleObjectEx、SystemFunction032、NtProtectVirtualMemory、ZwSetContextThread、RtlExitUserThread。

image-20260112100700434.png

image-20260112102159224.png
其中SystemFunction032可能会让我们感到疑惑，这是微软未公开的函数，其实就是一个RC4加密算法，ReactOS可以看到定义，在advapi32.dll模块中实现。前后各调用一次，即是对在内存的载荷加解密。

image-20260112160004248.png
然后到了最关键的地方，通过NtQueueApcThread插入到指定线程的APC队列，回调函数为ZwContinue，其作用是恢复CONTEXT下文，参数即为前面分配赋值的CONTEXT。插入完成后，NtAlertResumeThread恢复ThreadHandle，这里的Thread就是前面的TpReleaseCleanupGroupMembers + 0x450，然后设置Alerted状态，开始执行APC队列。
首先执行ZwWaiteForSingleObject，这里是为了等待NtSignalAndWaitForSingleObject Signal EventHandle，然后Waite ThreadHandle。

image-20260112104428693.png
执行NtProtectVirtualMemory将内存属性修改为RW，这样极大减少了被扫描的可能性，很多AV内存扫描的目标仅仅是带有X属性的内存。

image-20260112113705851.png
SystemFunction032 RC4加密相关内存。

image-20260112113947107.png
然后调用ZwGetThreadContext，获取前面通过ZwDuplicateObject复制的TargetHandle句柄（badger执行的主线程）的CONTEXT结构，调用ZwSetThreadContext设置TargetHandle的CONTEXT为sub_10019490获取的CONTEXT，这里像是在做调用堆栈的伪装，但是前面没进入那个IF块，又不像堆栈欺骗。这里可能是在睡眠期间，将调用堆栈也做了混淆，目的是看不出在进行了APC等睡眠混淆的操作。
调用WaitForSingleObjectEx模拟正常睡眠，这个时间就是Listener或Profile中设置的Sleep时长（0x4E20 == 20000）。

image-20260112115746030.png
睡眠完成后开始恢复，首先是再次调用SystemFunction032 RC4解密内存。

image-20260112120012634.png
然后NtProtectVirtualMemory恢复内存属性。

image-20260112120056230.png
调用ZwSetThreadContext还原TargetHandle的CONTEXT上下文。最后RtlExitUserThread退出TpReleaseCleanupGroupMembers + 0x450线程。
至此一个完成睡眠混淆流程结束。对于一个存活时间长的马，睡眠时间栈大多数，执行任务的时间很短。
可能有人要问，为什么我不能直接对马改内存属性和加密呢？还要写APC回调？这样写其实解决了加密代码不能加密自己的问题，以及修改了内存属性如何改回来的问题，万一有些AV就专门盯着你写的那块加密代码，这样马就被杀了。
下一篇文章中，根据分析结果实现APC Sleeping Masking

​