一次疑似伪装更新器样本的静态与动态观察记录

发布于6小时前6小时

decoded[i] = encoded[i] ^ key[i % key_len]; } decoded[config_len] = 0;

这时可以直接从样本中抠出密文和 key，写脚本还原配置，而不一定要完整跑起来。

3. 持久化行为

观察到的持久化方式主要有两种：注册表 Run 项和计划任务。伪装更新器样本更偏好计划任务，因为看起来更像正常软件更新机制。

常见注册表路径：

HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run
HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run

常见计划任务命令：

schtasks /Create /SC MINUTE /MO 30 /TN \"MicrosoftEdgeUpdateTask\" /TR \"%APPDATA%\\Microsoft\\EdgeUpdate\\update.exe\" /F

需要注意，任务名经常仿冒：

GoogleUpdateTaskMachineCore
MicrosoftEdgeUpdateTaskMachineUA
AdobeFlashUpdate

但真实路径、签名、创建时间往往对不上，排查时不要只看任务名。

操作步骤

1. 隔离环境准备

建议使用快照虚拟机，网络走可控环境，比如 INetSim、FakeDNS 或仅 Host-Only。不要在办公机或主力机直接分析。

基础工具可以准备：

Detect It Easy：查看壳、编译器、段信息
PE-bear / CFF Explorer：检查 PE 结构
strings / FLOSS：提取静态字符串
x64dbg：动态调试
Procmon：观察文件、注册表、进程行为
Process Explorer：查看进程树和句柄
Wireshark / Fiddler：观察网络行为

2. 静态初筛

先计算哈希并记录：

certutil -hashfile sample.exe SHA256
certutil -hashfile sample.exe MD5

然后查看导入表和字符串。若字符串中出现大量正常更新器相关文案，但没有有效签名，且落地路径在用户目录下，就要提高警惕。

3. 动态运行观察

运行前先打开 Procmon，过滤条件可以设置为：

Process Name is sample.exe
Operation contains RegSetValue
Operation contains CreateFile
Path contains Run
Path contains Tasks

运行后重点看以下行为：

是否复制自身到 %APPDATA%、%LOCALAPPDATA%、%TEMP%
是否创建计划任务或 Run 项
是否启动子进程执行 cmd.exe、powershell.exe、wscript.exe
是否访问固定域名或硬编码 IP
是否创建互斥体防止重复运行

4. 调试定位关键行为

在 x64dbg 中可以优先对这些 API 下断：

bp CreateProcessW
bp ShellExecuteW
bp WinExec
bp RegSetValueExW
bp RegCreateKeyExW
bp CreateFileW
bp WriteFile
bp URLDownloadToFileW
bp WinHttpSendRequest
bp InternetConnectW
bp CreateMutexW

如果样本做了 API 动态解析，可以在 GetProcAddress 下断，观察解析出的函数名。很多时候网络 API、注册表 API 都会在运行时被解析出来。

代码示例

下面是一个简单的 XOR 配置还原脚本。实际分析时可以根据样本里的密文数组和 key 修改。这个脚本不依赖第三方库，适合快速验证。

from pathlib import Path

# 示例：从样本中提取出来的密文，实际使用时替换
enc = bytes.fromhex(
    \"3b 0a 1f 10 5d 17 01 0c 16 54 0b 07 1d 1a 45 11\"
    \"06 1d 0a 1b 54 00 0a 1d 0d 45 16 0a 1e 1e\"
)

key = b\"upd_key\"

def xor_decode(data: bytes, key: bytes) -> bytes:
    out = bytearray()
    for i, b in enumerate(data):
        out.append(b ^ key[i % len(key)])
    return bytes(out)

plain = xor_decode(enc, key)

print(\"[+] decoded bytes:\", plain)
try:
    print(\"[+] decoded text:\", plain.decode(\"utf-8\"))
except UnicodeDecodeError:
    print(\"[!] not utf-8 text\")

Path(\"decoded_config.bin\").write_bytes(plain)

如果还原后能看到类似 URL、任务名、落地路径，就可以反向验证动态行为。例如：


MicrosoftEdgeUpdateTask
%APPDATA%\\Microsoft\\EdgeUpdate\\update.exe

分析时建议把域名做中括号处理，避免误点。

注意事项

1. 不要只依赖字符串结论

字符串里出现更新器名称不代表它真的是正常更新器。判断时至少结合签名、路径、父进程、网络目标、持久化方式一起看。正常更新组件一般有稳定厂商签名，路径也较固定。

2. 留意延迟执行

不少样本会先 Sleep 很久，或者检测运行时间、鼠标移动、进程列表。可以在调试器里跳过 Sleep，或者对 Sleep、NtDelayExecution 下断后修改参数。

bp Sleep
bp NtDelayExecution

遇到长延迟时，不建议傻等。直接观察调用栈和返回地址，回到业务逻辑处继续跟。

3. 网络请求要做隔离

如果样本会访问真实 C2，不建议直接放通公网。可以先用 FakeDNS 把域名指向本地，再配合 INetSim 看它请求的路径、User-Agent、POST 数据格式。这样既安全，也能拿到足够的协议特征。

4. 关注落地文件

很多伪装更新器本体只是 loader，真正功能在后续下载的二阶段。Procmon 中如果看到写入新的 EXE、DLL、DAT 文件，要及时复制出来单独分析。常见落地位置：

%APPDATA%\\Microsoft\\
%LOCALAPPDATA%\\Temp\\
%PROGRAMDATA%\\
%PUBLIC%\\Documents\\

总结

这类伪装更新器样本的难点通常不在算法，而在行为链路比较碎：先解密配置，再复制自身，随后创建计划任务，最后联网拉取二阶段。分析时建议按“静态确认入口、动态抓行为、调试断关键 API、脚本还原配置”的顺序推进。

实际排查中有几个比较有效的判断点：无有效签名、用户目录伪装系统组件、计划任务名称仿冒、网络目标异常、API 动态解析。把这些证据串起来，比单独看某一个字符串或某一个行为更可靠。

5小时前5小时

可以补一条排查思路：这类“更新器”如果静态看起来没什么明显恶意 API，动态阶段建议重点盯它的“持久化”和“二阶段加载”行为，很多样本真正的载荷不在初始文件里。我一般会这样做： 1. 先看是否有安装/更新器伪装痕迹重点查 VersionInfo、签名、图标资源、清单文件：

sigcheck -m -i sample.exe
sigcheck -h sample.exe
strings -n 6 sample.exe | findstr /i "update setup install http https powershell cmd regsvr32 mshta rundll32"

如果 VersionInfo 里公司名、产品名和签名主体不一致，或者签名是无效/吊销/时间戳异常，基本可以作为疑点记录。 2. 动态观察建议加 Procmon 过滤过滤条件可以先设：

Process Name is sample.exe
Operation is RegSetValue
Operation is CreateFile
Operation is WriteFile
Operation is Process Create

重点看这些路径：

%AppData%
%LocalAppData%
%ProgramData%
%Temp%
C:\Users\Public\
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run

不少伪装更新器会先把自身复制到 `%AppData%` 或 `%ProgramData%`，再改名成类似 `UpdateService.exe`、`WindowsUpdate.exe`、`GoogleUpdate.exe`。 3. 注意父子进程链如果样本本体退出很快，要看它有没有拉起下面这些进程：

powershell.exe
cmd.exe
wscript.exe
cscript.exe
mshta.exe
rundll32.exe
regsvr32.exe
schtasks.exe
wmic.exe
bitsadmin.exe
certutil.exe

可以用 Sysmon 辅助记录，至少开进程创建、网络连接、文件创建这几类事件。比如 Sysmon 事件里重点看：

Event ID 1  - Process Create
Event ID 3  - Network Connection
Event ID 11 - File Create
Event ID 13 - Registry Value Set
Event ID 22 - DNS Query

4. 如果怀疑它通过计划任务维持可以在运行前后各导出一次计划任务对比：

schtasks /query /fo LIST /v > before.txt
运行样本
schtasks /query /fo LIST /v > after.txt
fc before.txt after.txt

常见任务名会伪装成：

UpdateTask
GoogleUpdateTaskMachine
MicrosoftEdgeUpdateTask
WindowsUpdateCheck
AdobeUpdateService

5. 网络侧不要只看域名有些样本第一次访问的是正常 CDN 或短链，后面才跳转。建议抓包时同时保存 DNS、HTTP Host、TLS SNI：

tshark -i 1 -f "tcp port 80 or tcp port 443 or udp port 53" -w update_sample.pcap

如果是 TLS 流量，可以重点看：

dns.qry.name
http.host
http.request.uri
tls.handshake.extensions_server_name

6. 静态里可以补查资源节和熵值更新器类伪装样本经常把 payload 放在资源段或附加数据里。可以用 Detect It Easy / PE-bear 看节名和熵值，尤其注意：

.rsrc 体积异常
.overlay 存在大块数据
节名类似 .data/.text 但熵值接近 7+
导入表很少但运行时行为很多

如果导入表很干净，只看到 `LoadLibrary/GetProcAddress/VirtualAlloc/VirtualProtect/CreateThread` 这类组合，就要考虑运行时解密或内存加载。另外，建议记录运行前后文件系统快照，比单纯盯窗口行为更有用：

dir /s /b %AppData% > appdata_before.txt
dir /s /b %LocalAppData% > local_before.txt
dir /s /b %ProgramData% > programdata_before.txt

运行样本

dir /s /b %AppData% > appdata_after.txt
dir /s /b %LocalAppData% > local_after.txt
dir /s /b %ProgramData% > programdata_after.txt

fc appdata_before.txt appdata_after.txt
fc local_before.txt local_after.txt
fc programdata_before.txt programdata_after.txt

如果后续能补一下样本的哈希、PE 时间戳、父子进程链和新增文件路径，基本就能判断它是单纯广告安装器、下载器，还是带持久化的木马下载器。

创建帐户或登录后发表意见

注册帐户

立刻登录

https://www.hackhat.org/Hacker-topic/26846.html/

粉丝

转到主题列表

没有会员查看此页面。

登录