银狐应急

本文首发先知社区：https://xz.aliyun.com/news/92229

一、起因

2026.4.6 12:53，朋友告诉我说他的电脑被黑了，黑客用他的电脑给微信群里面群发广告，发完之后就给他电脑关机了

二、初步排查

第一次很漫无目的的检查，无果，想了一会想到一个关键点：“发完之后就给他电脑关机了”

我突然想到关机行为必然会在系统日志中留下记录

Win + R，输入eventvwr.msc打开系统日志，搜索事件ID为1074，按照时间定位

任务管理器搜索pcRFjwAb.exe，有两个进程，描述是Java Chromium Embedded Framework (JCEF) Helper，启动用户名是system，pid是8872，20020，文件目录是C:\Users\Public\Videos\5933Xnen，到这里已经是十拿九稳了，因为这里有几个关键点：

• C:\Users\Public是Windows中所有用户都拥有读写权限的目录，这里是木马落地的热门地点，就像/tmp一样。更离谱的是exe居然在Videos目录里。

• 随机生成的8位字母名，通常是CS、MSF或者某些免杀加载器随机生成的混淆名

• 名字是pcRFjwAb.exe，描述却是Java Chromium Embedded Framework (JCEF) Helper

• 真正的JCEF Helper只是一个图形界面渲染辅助进程，它只会以当前登录的普通用户身份运行，不会是system。

打开文件所在位置，可以看到一个包含如下文件的文件夹

dll文件有500MB，而exe相比之下很小，只有604KB

定位到这里就可以去看一下外联IP了

威胁情报

三、后门清除

4.6是第一次中毒，今天是第二次了，我问朋友这段时间里有没有关机，他说关过，关过机器还能再上线说明做了维权，记事本打开readme.md同一时间蹦出了好几个txt的窗口，这里不知道是什么原因，记事本的内容是对注册表的操作记录，还有一些乱码，既然动了注册表意味着可能做了维权，所以排查一下后门

这里借助Autoruns工具进行排查，定位到后门路径后就很容易筛查了，很快就定位到银狐创建的一项服务

禁用

sc delete删除服务

到这里应急就结束了，不过在我打算打包样本的时候发现这个文件夹做了隐藏

attrib -s -a -h取消隐藏

四、样本分析（AI）

4.1 样本概览

文件	大小	MD5	说明
pcRFjwAb.exe	604KB	c9f234656cc0854941d94464a097353b	合法CEF Helper，DLL侧加载宿主
libcef.dll	512MB	ee8848acb44a986f4b0450a75e413d4b	恶意DLL，体积膨胀+CFF混淆
View.conf	510B	-	加密配置文件（二进制数据）
README.md	280KB	-	加密载荷/Shellcode（二进制数据）

4.2 pcRFjwAb.exe 分析

pcRFjwAb.exe 是一个合法的 CEF（Chromium Embedded Framework）辅助进程，使用 MSVC/C++ 编译，导入了38个 libcef.dll
的导出函数。它本身不包含任何恶意代码，攻击者利用它作为 DLL侧加载（DLL Sideloading） 的宿主。

启动流程：

1. 进程监控线程：启动后第一步不是执行CEF逻辑，而是调用 CreateToolhelp32Snapshot + Process32FirstW/NextW遍历进程快照，找到自身的父进程PID，然后以 SYNCHRONIZE（0x100000）权限 OpenProcess 打开父进程句柄。随后用_beginthreadex 创建监控线程，该线程执行 WaitForSingleObject(父进程句柄, INFINITE)，一旦父进程退出就调用ExitProcess(0) 自我终止。这是一种自清理机制——父进程结束后木马进程不会残留。

2. DLL验证：调用 cef_api_hash(0) 获取DLL返回的API哈希字符串，与硬编码值504dbb53deeebd11a16ea01533c5d9ecfa6be555 比对，确认加载的是”正确”的DLL。

3. 执行CEF流程：验证通过后调用 cef_execute_process()。但实际上恶意DLL中这个函数是一个空壳（只有一条 retn指令），真正的恶意逻辑在 cef_api_hash 被调用时已经触发。

4.3 恶意DLL分析

这个DLL是整个攻击的核心，使用 MinGW-w64（GCC） 编译，与exe的MSVC编译风格形成鲜明对比。

体积膨胀： DLL的 .text 代码段大小为512MB（0x20008000），但实际有效代码仅67个函数。绝大部分空间被无意义的填充数据占据，这是典型的 文件膨胀（File Inflation/Pumping） 手法，目的是：

• 超出杀软/沙箱的文件大小扫描上限（很多沙箱默认不处理超过100MB的文件）
• 增加上传到在线分析平台的难度
• 减慢逆向分析工具的加载速度

导出函数伪装： DLL导出了与真正 libcef.dll 完全一致的38个函数名，但其中 **11个关键函数（包括 cef_execute_process、cef_get_path、cef_log 等）全部指向同一个地址 0x180003B40**，该地址只有一条 retn指令——纯粹的空壳函数。这样做是为了满足exe的导入表要求，避免加载失败。

CFF控制流平坦化： DLL中所有有实际逻辑的函数均采用了 控制流平坦化（Control Flow Flattening） 混淆：

• cef_api_hash：1551字节，106个基本块，通过大量 switch-case和魔数（如3689580290、-605387006等）构建状态机，将原始逻辑打散
• DllMain：同样被CFF混淆，使用嵌套switch和数值比较隐藏真实控制流
• 底层函数 sub_180001BC0（2413字节，98个基本块）和 sub_180002530（1501字节，58个基本块）也全部采用CFF

TLS回调： DLL注册了两个TLS回调函数，在 DllMain 之前执行：

• TlsCallback_0：DLL_PROCESS_ATTACH 时调用初始化函数
• TlsCallback_1：DLL_PROCESS_DETACH / DLL_THREAD_DETACH 时清理资源

关键API调用：

• VirtualProtect：修改内存页属性（将只读/不可执行内存改为可执行），用于内存中解密和执行Shellcode
• Sleep(0x3E8)：循环等待1秒，用于线程同步，也有一定反沙箱效果
• VirtualQuery：查询内存页信息，配合 VirtualProtect 使用
• _InterlockedCompareExchange64：原子操作实现线程安全的DLL初始化锁

推测执行流程：

加载DLL → TLS回调初始化 → DllMain（CFF混淆）→ exe调用 cef_api_hash 时触发真正的恶意逻辑 → 通过 VirtualProtect 修改内存权限 → 解密并执行内存中的Shellcode → 读取 View.conf（C2配置）和 README.md（加密载荷）→ 连接C2服务器 →建立远控通道

4.4 补充文件分析

View.conf（510字节）：
内容为纯二进制数据，非明文配置。可能是加密的C2地址、端口或通信密钥。文件较小，符合配置文件的特征。

README.md（280KB）： 虽然扩展名为 .md，但内容完全是二进制数据。

五、疑惑点

其实这个readme.md文件在受害者机器上用notepad打开后会弹出多个记事本窗口，每个窗口的内容都不一样，有的是对注册表的操作记录，还有一些乱码，而在我自己的电脑上面打开就是纯乱码

5.1 claude-opus-4-6的解释：

README.md 定性：银狐的多段加密容器

如果是在中毒机器上打开的，一切就说得通了。README.md 是银狐木马的自定义多段加密数据容器，格式是：

[85 21] ← 2字节 magic
[FF FF] ← 段分隔符
Section 0 32,562 bytes
[FF FF]
Section 1 16,195 bytes
[FF FF]
Section 2 161,101 bytes ← 最大段
[FF FF]
Section 3 10,110 bytes
[FF FF]
Section 4 58,591 bytes
[FF FF]
Section 5 8,274 bytes
[00 03 0F 00 0F 00 00 00] ← 8字节 trailer（段元数据）

6 个加密段，每段独立加密（AES/RC4 级别，不是简单 XOR）。木马运行时用 libcef.dll 中的解密逻辑 + View.conf中的密钥来解密。

你看到的现象完全吻合：

• 明文窗口（注册表操作记录）：这几段解密后是木马的操作日志——它记录了自己对注册表做的所有修改（创建服务、写启动项、持久化配置等），这也解释了你用 Autoruns 能精准定位到它创建的服务
• 乱码窗口：这几段解密后是二进制 payload（shellcode、C2通信配置、远控模块），不是人类可读的文本，所以即使解密了在记事本里也是乱码

木马以 SYSTEM 权限运行，很可能通过 minifilter 驱动或文件系统监控检测到 README.md 被访问，触发解密并逐段弹出 Notepad
窗口展示。这个行为本身也说明银狐的功能模块化程度很高——把日志、payload、配置全部打包在一个伪装文件里，加密存储，运行时
按需解密。

5.2 Gemini 3.1 pro preview说：

严重不合理

Claude 试图解释“为什么双击 README.md 会弹出好几个 txt 窗口”，它的推论是：木马在后台监控文件，发现你打开了文档，于是实时解密并分段弹出了好几个记事本展示给你看。

这个推论在恶意代码分析的实战中，犯了两个极其致命的常识性错误：

错误 1：底层技术逻辑不通（透明加解密不会产生多窗口）

Claude 提到了 minifilter 驱动监控（这是企业级防泄密软件 DLP 常用的技术）。
如果木马真的用了文件系统过滤驱动，当你在桌面上用 Notepad（记事本）双击打开这个文件时，驱动会在底层把解密后的字节流交还给 Notepad。
结果应该是：这一个 Notepad 窗口里，显示出了所有解密后的内容。
底层的 I/O 驱动是绝对不可能主动去解析你文件里的 FF FF 分隔符，然后越俎代庖地调用 CreateProcess 给你额外创建 5 个新的 notepad.exe 进程的！产生多个窗口，必然是木马主程序的“主动行为”，而不是文件读取的被动解密。

错误 2：黑客的 OpSec（操作安全）逻辑不通（谁会主动自首？）

“银狐”是一个高度商业化、极其狡猾的黑客团伙。
木马千方百计把注册表操作日志和 Shellcode 加密隐藏在 README.md 里，就是为了防追踪。它怎么可能专门写一段代码：“一旦发现安全人员双击了这个文件，我就贴心地把我的作案记录和远控代码分别用记事本弹出来给他看”？
这就像一个小偷把赃物藏在保险箱里，然后设置了一个机关：只要警察碰一下保险箱，就自动播放幻灯片展示偷窃过程。这符合逻辑吗？

这里两个AI说法不一，所以尝试让AI用mcp连接试图找到解密密钥，但是失败了，目前这里还原不出来明文，搁置了

六、流程图（AI）

? = 基于IDA证据的推测，受CFF混淆限制未完全验证，其余均已通过IDA反编译确认

DLL侧加载阶段
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  pcRFjwAb.exe 被执行
              │
              ▼
  Windows加载器解析导入表，发现依赖 libcef.dll，从同目录加载恶意DLL（DLL侧加载）
              │
              ▼
  DLL加载流程（exe的main之前）
  ├─ TlsCallback_0 设置标志位
  ├─ sub_180001000 线程同步初始化，Sleep(1000ms) 循环等待
  ├─ VirtualProtect 修改内存权限（只读 → 可执行）
  ├─ _initterm 执行全局构造函数  ? 可能在此阶段解密并准备恶意载荷
  └─ DllMain（CFF混淆）
              │
              ▼
  DLL加载完成，控制权返回exe
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
              │
              ▼
exe主逻辑阶段
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  sub_140002A40：进程监控与线程创建
  ├─ CreateToolhelp32Snapshot 枚举进程 → 找到当前进程 → 取父进程PID
  ├─ OpenProcess(SYNCHRONIZE, 父PID)
  └─ _beginthreadex 创建监控线程
              │
              ├─► 监控线程（StartAddress）
              │     └─ WaitForSingleObject(父进程句柄, INFINITE) → 父进程退出后 ExitProcess(0) 自我终止
              │
              └─► 主线程
                    │
                    ▼
              cef_api_hash(0)  ? 该函数体积异常（1551字节/106个基本块/CFF混淆），恶意逻辑可能在此触发
                    │
                    ▼
              strcmp(返回值, "504dbb53deeebd11a16ea01533c5d9ecfa6be555")
                    │
                    ├─ 匹配 → cef_execute_process()（DLL中为空壳retn，无实际操作）
                    └─ 不匹配 → return 0
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

注意： 受CFF控制流平坦化混淆限制，恶意逻辑的确切触发时机无法通过纯静态分析确定。cef_api_hash 在DLL中是一个1551字节、106个基本块的CFF混淆函数，仅返回一个哈希字符串不需要这么多代码，因此恶意逻辑很可能藏在这个函数或DLL加载阶段的 VirtualProtect 调用链中，需要动态调试验证。View.conf 和 README.md 的文件名在DLL的31条字符串中未出现，读取方式同样无法仅凭静态分析确定。

七、免杀手法

7.1 执行层对抗 —— 白加黑

攻击者没有使用任何容易被拦截的直接执行手段，而是构建了一个无懈可击的信任链：

1. 高信誉签名白名单：利用带有合法签名的 pcRFjwAb.exe (伪装为 JCEF Helper) 作为启动器，杀软看到合法签名通常会直接放行，从而在暗中带起同目录下的恶意 libcef.dll。
2. 完美导出表伪造：为了让白文件不报错，恶意 DLL 精心伪造了 38 个与真实 CEF 组件一模一样的导出函数名。其中 11 个核心函数（如 cef_execute_process）被置空，仅包含 retn 指令。这种“外壳合规、内部掏空”的手法，不仅欺骗了 Windows 加载器，也欺骗了基于导入导出表匹配的轻量级检测。
3. 载荷分离与模块化：真正的核心远控代码和 C2 配置并不在 DLL 中，而是作为纯二进制数据（README.md, View.conf）强加密存放。这种“加载器与载荷分离”的架构，使得恶意 DLL 中没有任何敏感字符串，完美避开静态特征扫描。

7.2 静态扫描对抗

1. 利用沙箱性能瓶颈：通过文件膨胀将恶意 DLL 的 .text 段恶意填充垃圾数据至 512MB，而实际工作代码只有头部的24KB和尾部的7KB。由于大多数云沙箱和本地杀软受限于性能开销，对超过体积过大的文件会直接 Bypass 跳过扫描，导致防线在此刻完全失效。
2. **非主流编译器绕过：放弃了黑客常用的 MSVC 编译器，转而使用 MinGW-w64。由于市面上大多数杀软的启发式检测规则（如入口点特征、异常处理表、CRT 初始化）都是针对 MSVC 训练的，这种“换编译器”的底层差异化操作，能够低成本且高效地绕过大量基于 PE 结构的启发式规则。

7.3 动态行为对抗 —— 反调试与反沙箱

在运行态，木马展现出了极强的自我保护与反逆向意识：

1. 抢占执行先机（TLS 回调前置）：在 DLL 的 DllMain 甚至程序的 OEP（入口点）执行之前，通过注册 TLS（线程局部存储）回调函数提前执行恶意逻辑。大量未能正确模拟 TLS 回调的沙箱和初级调试器，会直接漏掉这段最核心的行为。
2. 绞肉机式的代码混淆（控制流平坦化 CFF）：针对 67 个真实有效的函数施加了极其复杂的控制流平坦化。原本简单的逻辑被肢解成上百个由魔数驱动的 switch-case 状态机。这让蓝队在用 IDA 分析时如同陷入迷宫，极大地拉长了防守方的响应时间。
3. 伴生死亡机制（父进程监控与自清理）：木马启动后会死锁监听其“上游投递程序”（父进程）。一旦发现父进程被杀软拦截或人工关闭，木马会立刻调用 ExitProcess(0) 战术自尽，确保它不会作为孤儿进程暴露在任务管理器中。

7.4 持久化与隐蔽运营

在成功驻留后，样本将隐蔽性做到了极致：

1. “灯下黑”的路径与属性隐藏：选择所有普通用户皆有默认读写权限的 C:\Users\Public\Videos 作为据点。这种降级写入策略巧妙地规避了写入敏感目录（如 Program Files）时会触发的 UAC 权限弹窗，确保初始落地的绝对静默。配合 +s +a +h（系统级隐藏属性）在默认资源管理器下完全隐形
2. 系统级持久化（服务驻留）：摒弃了低维度的注册表 Run 键，攻击者利用已获取的管理员权限将木马注册为系统自动运行的服务。这不仅是持久化手段，更是关键的权限跃迁跳板——借助 Windows SCM 的机制，使得后门在每次开机时，直接由操作系统以SYSTEM 权限拉起。这使得木马在用户还未登录到桌面时（Session 0）便已悄然连接 C2，完美融入后台底层噪音，让使用者无从察觉。

八、沙箱分析

1. 样本在沙箱中的表现与受害者机器上的表现有些不同，受害机器上面落地位置是C:\Users\Public\Videos\5933Xnen，而沙箱中是c:\users\admin\appdata\local\temp\

2. 样本记录到的sleep时间是1s，但沙箱捕获到木马还尝试了 sleep 1898秒

3. 受害者机器上看到的是 C:\Users\Public\Videos\5933Xnen\libcef.dll大小为512MB，md5为ee8848acb44a986f4b0450a75e413d4b。但沙箱里释放的是 c:\users\admin\appdata\local\temp\libcef.dll只有102MB，md5为e093b64fac5ebd1fe1a89ab54a2bb09b

4. 沙箱中还提到了一条IOC：subduedcurvy.yachts

具体的报告连接：https://sandbox.ti.qianxin.com/sandbox/page/detail?type=file&id=AZ20PRbFONZSmF3-jLPz

九、总结

由于文件落地已经有一段时间，目前已经想不起来是如何“中招”的了，有一点可惜，另外关于readme.md文件也没有搞清楚，不知道有没有大佬感兴趣想分析一波