幽灵之眼：银狐是如何做到VT全绿的？

DisaPDB

前情提要：【杂谈】如何使用IDA+Agent自动化分析样本——我的一次实战记录
样本：白加黑 1x_病毒样本 分享&分析区
是什么样本能够骗过卡巴斯基的分析师，让其拉黑了一个“错误的”DLL呢？
下面是完整分析。

一、样本概述

本样本为典型的「白加黑」DLL侧加载攻击。攻击者以合法的流氓软件壁纸YXCalendar.exe作为宿主，通过无签名的恶意 SDK 组件实现静默注入，最终在系统合法进程colorcpl.exe中驻留并建立 C2 通信。

二、完整执行流程

阶段 1：宿主启动与 DLL 侧加载

1. YXCalendar.exe
   
2.   │
   
3.   ├─ 静态导入：KERNEL32.dll, USER32.dll, SHELL32.dll 等系统 DLL
   
4.   │
   
5.   ├─ 运行时动态加载（LoadLibraryW）：
   
6.   │    ├─ CommonLogin64.dll  ──→ CreateCommonLogin()  [合法]
   
7.   │    └─ x64/LYSDK2.dll    ──→ [恶意·无签名·直接触发攻击链]
   
8.   │
   
9.   └─ LYSDK2.dll 的 DllMain / 初始化代码开始执行

复制代码

YXCalendar.exe 在运行时调用 LoadLibraryW 加载 x64/LYSDK2.dll。由于 Windows 优先从应用程序目录加载 DLL，攻击者将恶意LYSDK2.dll放置在应用目录的x64/子目录中，替换或伪装为合法的 SDK 组件。

阶段 2：LYSDK2.dll 初始化——加载伪 SQLite DLL

1. LYSDK2.dll
   
2.   │
   
3.   ├─ 导入表中直接声明依赖：
   
4.   │    vtksqlite-9.6.dll → vtksqlite_sqlite3_open_v2
   
5.   │
   
6.   ├─ Windows 加载 vtksqlite-9.6.dll（无签名）
   
7.   │    └─ vtksqlite DllMain 执行（标准 SQLite 初始化，无明显恶意行为）
   
8.   │
   
9.   └─ LYSDK2 主流程继续执行

复制代码

vtksqlite-9.6.dll 分析说明：
该 DLL 导出完整的vtksqlite_sqlite3_*API，内部实现与正版 SQLite 高度一致，包含标准的 Win32 VFS 结构体和 CRT 初始化代码，静态免杀效果极佳。LYSDK2 使用其vtksqlite_sqlite3_open_v2读取配置文件中的 shellcode 数据。


阶段 3：读取并解码 shellcode（dkcinst.ini）


在第三阶段，恶意程序会从系统目录下读取一个名为 `dkcinst.ini` 的文件，它实际上是一个被伪装的载荷文件，大小约为 193KB。这个文件并非普通的文本配置，而是经过了自定义编码处理。程序会调用特定的解码函数，将文件内容还原为可执行的机器码。这个解码过程本质上就是 Base64 算法的变种——它将数据按 6 比特一组进行转换，每 6 比特对应一个可打印字符。但与标准 Base64 不同的是，它使用了一套完全自定义的 64 字符映射表（包含 `!@#$%^&*()_+~` 以及大小写字母等），而不是标准的 `A-Za-z0-9+/` 顺序。

1. 字母表：!@#$%^&*()_+~ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxy

复制代码

解码后，文件会被还原成一段约 145KB 的 x86 架构的 shellcode（即可以直接执行的二进制代码）。通过将攻击代码伪装成配置文件并采用非标准的编码方式，恶意软件能够有效规避安全软件的静态扫描，因为此时文件看起来更像是一个无害的 INI 配置，而非包含可执行内容的危险文件。

阶段 4：进程注入——线程上下文劫持

该恶意模块实施了一种典型的进程注入技术，具体为线程上下文劫持（Thread Context Hijacking）结合挂起进程注入。执行流程首先选定一个合法系统二进制文件作为宿主进程，优先尝试启动 `colorcpl.exe`（32位颜色控制面板），若失败则回退至 `msinfo32.exe`（系统信息工具）。调用 `CreateProcessA` 时，通过设置 `CREATE_SUSPENDED`（0x4）与 `CREATE_NO_WINDOW`（0x80）标志（合并值为 0x84），确保目标进程在初始挂起状态下无窗口静默创建。

为了规避静态导入表检测并提升兼容性，注入器并未直接链接相关 API，而是在运行时通过 `LoadLibraryA` 动态加载 `kernel32.dll` 并利用 `GetProcAddress` 逐一解析所需函数地址，包括内存分配（`VirtualAllocEx`）、内存写入（`WriteProcessMemory`）、线程上下文操纵（`GetThreadContext` / `SetThreadContext`）以及线程恢复（`ResumeThread`）。随后，它在挂起的宿主进程内通过 `VirtualAllocEx` 申请一块具备可读、可写、可执行（RWX）权限的内存区域，并将上一阶段解码出的 144,831 字节的 x86 shellcode 完整写入该空间。

紧接着，注入器调用 `GetThreadContext` 获取宿主主线程的当前执行上下文，将其指令指针寄存器（EIP）劫持并重定向至分配内存基址加上指定偏移量（`ep_offset`）的入口点，再通过 `SetThreadContext` 将修改后的上下文写回。最终，调用 `ResumeThread` 恢复主线程运行，此时宿主进程的执行流被强制转向注入的恶意 shellcode，从而在合法系统进程掩护下完成恶意载荷的隐蔽启动。

阶段 5：shellcode 执行——反射式 PE 加载

1. colorcpl.exe 进程内·shellcode 执行（VA = 分配基址）
   
2.   │
   
3.   ├─ PEB 遍历找 kernel32.dll 基址：
   
4.   │    mov eax, fs:[0x30]    ; PEB
   
5.   │    mov eax, [eax+0x0C]   ; PEB_LDR_DATA
   
6.   │    mov esi, [eax+0x14]   ; InMemoryOrderModuleList
   
7.   │    ... 遍历链表找 kernel32
   
8.   │
   
9.   ├─ 栈上 XOR 解码 API 字符串（每字节 -0x10）：
   
10.   │    ├─ "GetProcAddress"
    
11.   │    ├─ "LoadLibraryA"
    
12.   │    ├─ "VirtualAlloc"
    
13.   │    └─ "Sleep"
    
14.   │
    
15.   ├─ 内嵌 PE 位于 shellcode+0xFBF（MZ 头，32位，168KB）
    
16.   │
    
17.   └─ 反射加载内嵌 PE：
    
18.        ├─ VirtualAlloc 申请内存
    
19.        ├─ 复制 PE 各节区到内存
    
20.        ├─ 修复重定位表
    
21.        ├─ 解析并填充 IAT
    
22.        └─ 跳转到 PE 的 OEP 执行 RAT 主体

复制代码

在第五阶段，注入至宿主进程（如 colorcpl.exe）内的 shellcode 开始执行，其核心任务是实现反射式 PE 加载，从而将内嵌的最终恶意模块（RAT 主体）在内存中完整展开并运行。该 shellcode 首先采用经典的进程环境块（PEB）遍历技术，通过 fs:[0x30] 获取 PEB 指针。
然后通过PEB Walk技术定位目标kernel.dll的内存地址。定位到 kernel32.dll 后，shellcode 并不直接明文存储所需 API 名称，而是在栈上通过逐字节异或（XOR）或加减常量（此处为每字节减去 0x10）的方式进行解码，动态还原出 GetProcAddress、LoadLibraryA、VirtualAlloc 及 Sleep 等关键函数名的字符串。随后利用已获取的 kernel32 基址，通过解析其导出表来获得这些 API 的实际入口地址，从而在无需导入表的情况下获得运行时调用能力。
此时，shellcode 自身内存布局中内嵌了一个完整的 32 位可执行映像，其偏移量固定为 shellcode+0xFBF，并具有标准的 MZ 头部标记，大小约 168KB。该 PE 文件即为最终远控工具的主体。

反射加载过程包括：调用 VirtualAlloc 在宿主进程中分配一片具备可执行权限的虚拟内存，将 PE 文件的各个节区按照其节头中定义的虚拟地址进行逐一映射和复制；接着遍历并应用基址重定位表，以适应实际加载地址与 PE 首选基址之间的偏差；然后解析导入表，通过已获取的 API 地址填充 IAT，确保所有外部函数引用得以正确绑定；最后，在完成所有初始化工作后，shellcode 将执行流跳转至该 PE 的原始入口点（OEP），从而启动完整的 RAT 功能，实现恶意行为的持久化控制。


阶段 6：RAT 主体执行

通过创建全局互斥体 "Global\\App_L_SingleInstance" 进行单例检查，确保系统中仅有一个活动实例在运行；若互斥体已存在，则主动终止进程，以避免重复运行导致的资源冲突或多实例行为异常。

调用 RegCreateKeyW 与 RegSetValueExW 在 HKCU\SOFTWARE\Persistent 项下写入启动条目，从而使得用户在登录系统后，恶意代码能够被自动激活。同时，为支持灵活的远程控制配置，它利用 HKCU\SOFTWARE\IpDates_info 注册表项对 C2 服务器的 IP 地址与端口信息进行读写和缓存，确保后续通信能够动态加载连接参数。

在网络通信层面，样本首先调用 WSAStartup 初始化 Winsock 环境，随后创建 TCP 流式套接字（AF_INET, SOCK_STREAM）。通过 gethostbyname 解析预设域名获取 C2 服务器 IP 后，调用 connect 建立连接。在连接保持期间，程序进入 send 与 recv 循环，持续接收来自控制端的指令数据，并根据指令执行相应的恶意操作，同时将执行结果或窃取的数据回传至服务端。

三、C2 配置
RAT payload 的.data节中存储了反转字符串形式的 C2 配置：

1. 原始（反转存储）：
   
2. :zf|1:lc|1:dd|1:3t|2808:3o|moc.yckbrhs:3p|1:2t|1808:2o|moc.yckbrhs:2p|1:1t|0808:1o|moc.yckbrhs:1p|

复制代码

1. 还原后：
   
2. |p:1|o:shrbjky.com|t:8080:1|p:2|o:shrbjky.com|t:8081:2|p:3|o:shrbjky.com|t:8082:3|

复制代码

参数	值
C2主机	shrbjky.com
C2端口1	8080
C2端口2	8081
C2端口3	8082
协议	TCP（原始套接字）
BotID	d33f351a4aeea5e608853d1a56661059

四、IoCs

MD5：
vtksqlite-9.6.dll c3d6b73e54ff4efd29651e46f751fe5b
LYSDK2.dll 91e9b61aeb427f56a870f7b1d781fc9a
dkcinst.ini 504930990b3e34b1db226675b9d56380

0殺神在心0

小黑的典中典了

ELOHIM

学习大佬技术，nb

夜光星

白加黑好几年了依然是杀毒的软肋

wowocock

夜光星 发表于 2026-6-24 23:22
白加黑好几年了依然是杀毒的软肋

我在10几年前就说过，未来最难整的是BOOTKIT,和白利用。现在前者因为微软的不断努力，基本很少了，后者因为成本低，效果好，杀软监控成本太高而广受欢迎。

DisaPDB

wowocock 发表于 2026-6-25 10:01
我在10几年前就说过，未来最难整的是BOOTKIT,和白利用。现在前者因为微软的不断努力，基本很少了，后者因 ...

白利用确实是一个滥用点，而且现在很多木马作者都会使用白文件Patch/白切黑这种免杀方式，恶意代码藏在非常多的白代码里面，机器学习和特征码都不太好检测。

wowocock

DisaPDB 发表于 2026-6-25 11:58
白利用确实是一个滥用点，而且现在很多木马作者都会使用白文件Patch/白切黑这种免杀方式，恶意代码藏在非 ...

就是专门针对AI的，让你们学习。学成脑抽风