最近参加面试拿到了一个银狐样本，但是限于面试时间比较短，没有办法完全走完一整个完整的样本分析流程。看都看了看到一半就撇了，总感觉如鲠在喉如芒刺背，所以本文将是一篇以分析思路为导向的样本分析复健指南。同时也适合新手参考，属于最具备实际效益样本分析方法论。当然，如果有什么能够改进升级的地方，欢迎给我留言分享和指正，我将不胜感激。
本文将展示怎么从一个混乱样本里，一层一层把攻击链捋出来，并把能落地检测的点提炼出来。最终目标有三个：
- 捋清楚整体的攻击链；
- 行为模块功能区分；
- 沉淀样本中可以转化为规则的线索。
一、样本分析的基本思路#
拿到未知样本时，不建议一上来就硬啃 IDA。更稳的方式是先建立画像，再用行为反推代码，最后围绕关键行为做动态跟踪。
1. 基础画像#
通过内部引擎、VT、微步或其他沙箱结果建立初步假设，先判断样本大概是什么类型、可能属于哪个家族、入口文件是什么。
2. 静态特征观察#
获取样本本身的基础信息：
- 文件类型；
- 数字签名；
- 编译时间；
- 导入表和导出表；
- 文件来源；
- 是否有壳、混淆、异常资源或 overlay。
3. 动态行为观察#
把样本放到隔离测试环境中运行，观察：
- 进程树；
- 文件释放；
- 注册表修改；
- 计划任务；
- 服务创建；
- 网络外连；
- 内存行为。
4. 静态代码分析#
带着前面抓到的行为进入 IDA。重点是用行为反推代码。
5. 动态代码跟踪#
当静态分析看不出有效逻辑时，再使用 x64dbg、WinDbg 或 IDA Remote Debugger 做动态跟踪。跟踪时应以行为结果为依据，围绕 API 边界和关键缓冲区定位。
如果以上步骤仍不能解决任务，可以先搁置样本，过一段时间再从头复盘。很多时候不是有什么技术难点，而是第一轮漏掉了某个关键边界。
二、样本分析环境检查#
1. 防止病毒本地运行#
存放病毒的分区必须通过组策略设置为不可运行。
- 运行“gpedit.msc”,打开组策略对话框。
- 在组策略中依次打开“计算机配置”→Windows设置→安全设置→软件限制策略(Software Restriction Policies)→其他规则(Additional Rules),新建路径规则，填入路径保存后重启计算机
2. 防止病毒局域网传播#
给 vmnat.exe 建“出站阻止规则”，阻止它访问远端 139/445端口。这里要选“远程端口”，不是本地端口。 图形界面做法
- 按 Win + R，输入 wf.msc 回车。
- 左侧选“出站规则”。
- 右侧点“新建规则”。
- 选择“自定义”。
- 程序路径填： C:\Windows\System32\vmnat.exe 如果你机器上也有这个文件，再单独建一条： C:\Windows\SysWOW64\vmnat.exe
- 协议选 TCP。
- 远程端口填： 139,445
- 操作选“阻止连接”。
- 配置文件全选：域、专用、公用。
- 名字可以叫： Block vmnat SMB TCP 139 445
三、进入正式拿到样本：#
解压 获取文件格式 更改后缀
是一个安装包 再用7z解压
直接去定位到disk1.cab 一般存在恶意的文件就是在这里面
解包后定位到关键文件：
查验下这两个程序的证书，一黑一白，此时已经可以收敛到入口样本为：VC_radist.x64.exe
从命名上看，它伪装成 VC 运行库安装程序。实际行为更像 Inno Setup 风格的安装器/释放器。
第一层，样本基础画像。#
样本初筛参考 VT 与安全引擎命名，其中 ESET、卡巴等引擎的命名可作为家族方向参考，但不能单独作为最终归因依据。
第二层，静态特征观察。#
使用 Detect It Easy 等工具查看样本基础信息：
文件类型；数字签名；编译时间；导入表和导出表；文件来源；是否有壳、混淆、异常资源或 overlay。
当前静态观察可知，入口样本可继续解包，最外层不是最终恶意逻辑。
第三层，动态行为观察。#
样本在沙箱/测试环境中运行后，通过火绒剑、PCHunter 等行为监控工具可观察到进程、文件、注册表与网络行为。
行为监控结果#
释放或捕获到的文件如下：
行为日志如下（只抓可疑的）：
网络侧也观察到 C2 暴露（通过微步威胁情报平台确认此情报）：
在微步上，除了确认家族信息，还可以获取关联样本，之后若有需要以此做拓线找同源样本很方便。
针对释放的组件做静态分析#
当前静态观察中较关键的异常点包括：
gjSum.exe证书无效，导入函数显示存在lz.L模块，函数名存在混淆，且后续行为集中发生在其进程上下文中；lz.L.dll导出表函数名存在混淆；Zsa9H.s.PNG像加密载荷容器；
gjSum.exe 证书异常：
导入函数函数名混淆：
lz.L.dll 导出函数名存在混淆：
Zsa9H.s.PNG 大概率是shellcode加密载荷
综合以上结果做上下文推断#
样本——>攻击链#
入口安装包 VC_radist.x64.exe -> 落地 gjSum.exe、lz.L、Zsa9H.s -> 启动 gjSum.exe -> 加载 lz.L -> 读取 Zsa9H.s -> 执行 icacls 保护落地目录 -> 执行 PowerShell 关闭安全提醒和 UAC -> 写入随机扩展名关联和二进制注册表数据 -> 在内存中释放多个功能模块 -> 载荷解密、config.ini 读取和 C2 生成 -> 连接 192.238.192.11:22行为日志——>具体行为#
防护规避与目录加固#
gjSum.exe 拉起 cmd.exe 执行 icacls：
C:\Windows\System32\cmd.exe /c icacls "." /deny "Users":(D) & icacls "." /grant "Users":(OI)(CI)(RX)随后 cmd.exe 分别拉起两个 icacls.exe：
icacls "." /deny "Users":(D)icacls "." /grant "Users":(OI)(CI)(RX)实际被设置权限的文件包括：
C:\ProgramData\uNKTL\jwffIQ\gjSum.exeC:\ProgramData\uNKTL\jwffIQ\lz.LC:\ProgramData\uNKTL\jwffIQ\Zsa9H.s关闭安全提醒与关闭 UAC#
gjSum.exe 拉起两个 PowerShell 进程：
powershell -Command "Set-ItemProperty -Path 'HKCU:Software\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.SecurityAndMaintenance' -Name 'Enabled' -Value 0 -Force"该命令用于关闭当前用户安全和维护提醒。
powershell.exe -Command "New-ItemProperty -Path 'HKLM:Software\Microsoft\Windows\CurrentVersion\policies\system' -Name 'EnableLUA' -PropertyType DWord -Value 0 -Force"随后在注册表写入：
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA = 0随机扩展名文件关联与 DOS 设备映射实现隐蔽启动#
在持久化阶段，样本表现出与公开银狐情报中“文件关联 + 虚拟设备映射 + PendingFileRenameOperations”组合技法高度一致的行为。该技法并非依赖传统 Run 键或直接投放可执行文件到启动目录，而是将多个看似低风险的系统机制组合使用，从而降低单点行为被安全软件拦截的概率。
首先，行为日志显示 gjSum.exe 创建随机扩展名文件关联，例如 HKLM\SOFTWARE\Classes\.f51so = Oi0S3，以及 HKLM\SOFTWARE\Classes\.6hn3A = T2efh、HKLM\SOFTWARE\Classes\T2efh\Shell\Open\Command -> gjSum.exe。这意味着当系统打开对应随机扩展名文件时，会通过 Windows 文件关联机制拉起恶意主程序。由于扩展名和 ProgID 均为随机字符串，该行为不属于常见的 .exe、.dll、.lnk 等高敏感关联篡改，因此更容易被视为弱风险注册表修改。
其次，样本修改 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices\O:，将 O: 映射到 \??\C:\ProgramData\Microsoft\Windows\Start Menu\Programs。该路径是公共启动目录 Startup 的上层目录。通过这种 DOS 设备映射，样本后续可使用 O:\Startup\... 访问真实的公共启动目录，从而在行为日志和安全监控中弱化对真实启动目录路径的直接暴露。
随后，日志中出现 gjSum.exe 打开 C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\TZpf4.f51so 这类随机后缀文件的行为，说明样本确实触达了公共启动目录下的随机扩展名锚点文件。结合 PendingFileRenameOperations 相关痕迹，可以推测样本可能利用 Windows 会话管理器在重启早期执行延迟文件操作，将随机扩展名文件投放或处理到启动目录，再借助文件关联完成 gjSum.exe 的启动。
需要注意的是，样本多次运行会生成不同的随机扩展名、随机 ProgID 和随机锚点文件名，因此 .6hn3A、T2efh、TZpf4.f51so 等不应作为固定 IOC 使用。
除上述启动链相关注册表外，样本还写入 ：
HKLM\SOFTWARE\lfvZ2cRnO7Du2-NoQl15DaoG疑似载荷/配置。
第四层，静态代码分析。#
值得使用 IDA 做静态分析的，主要是 gjSum.exe、lz.L.dll。
丢到 IDA 里看，首先看左侧的 Function 表，找主函数（main、start），再搜索字符串，看下有没有值得定位的。
但这两个文件在实际分析过程中，并没有可以直接看到的有效逻辑，说明真实逻辑可能被壳、虚拟化、动态解密或内存加载隐藏。
打开 lz.L.dll，在代码中看到存在反调试/反分析相关迹象。IDA 不断崩溃、卡死，难以继续进行静态代码分析，因此直接转入下一层动态跟踪。
第五层，动态代码跟踪。#
核心思路：盯住“内存变成可执行”的瞬间，然后 dump 那块内存区域。
最实用的做法有三种
- x64dbg 手工抓
- 用 PE-sieve 自动扫
- 用 Process Hacker / System Informer /火绒剑 辅助定位
如果用dbg手工抓，就是传统的下断点，注意内存权限变为可执行的地方。
如果用火绒剑，选中程序，内存列表，筛选出，已提交的可执行内存，再做内存转储。
如果用 PE-sieve ,没什么特别需要说明的，对银狐/侧载/内存载荷这类，PE-sieve 经常能直接把关键区域 dump 出来。很好用。
本篇的样本在实际过程中，使用PE-sieve 从 gjSum.exe 进程中 dump 出了 628aaf0.exe。
IDA 复查后确认它包含以下功能：
- 枚举进程并匹配目标进程名/路径；
- 收集目标 PID 并终止；
- 加载
IPHLPAPI.DLL、winnsi.dll等网络相关库； - 通过 NSI/TCP 表逻辑重置目标进程的 TCP 连接；
- 枚举服务；
- 查找
fix\Dsmain相关路径； - 通过隐藏
cmd.exe /c rmdir /s /q "<path>"清理目录； - 删除相关服务。
由此可知，628aaf0.exe 为内存驻留的目标抑制/清理子模块。
但是这些功能无法解释进程行为中出现的 PowerShell、目录 ACL、Zsa9H.s 解密与最终 C2 通信行为。因此不能把全部行为都归因到 628aaf0.exe。
icacls 与 PowerShell 命令的触发来源确认#
为确认目录权限加固与 PowerShell 命令究竟由哪个模块触发，分析过程中在 gjSum.exe 进程内对 CreateProcessW 下断。命中断点时，当前 RIP 位于 kernelbase.dll 的系统 API 内部，因此不能直接以当前指令地址作为归因依据。x64 调用约定下，CreateProcessW 入口处的栈顶 [RSP] 保存了 API 返回后的调用者地址，因此通过查看 [RSP] 及调用栈中第一个非系统模块地址，可以判断真实触发来源。
在 CreateProcessW 命中时，参数中可见样本准备执行如下命令：
C:\Windows\System32\cmd.exe /c icacls "." /deny "Users":(D) & icacls "." /grant "Users":(OI)(CI)(RX)此时返回地址为：
[RSP] = 00000000032ADA08该地址在内存布局中位于无模块名的 MEM_PRIVATE 私有内存区域。由此可确认，icacls.exe 目录权限加固命令由运行时解密/加载后的内存代码发起。
该结论也解释了为什么单纯分析 gjSum.exe 的导入表、导出表或磁盘文件难以定位相关行为：关键逻辑已经转移到进程内的私有可执行内存中执行。后续针对 PowerShell 命令的触发源也可采用同样方法验证。
Zsa9H.s 解密与 shellcode 定位结果#
在后续调试中，重点围绕 Zsa9H.s 的读取、解密和执行转移进行跟踪。断点下在：
CreateFileW / ReadFileVirtualAlloc / VirtualProtect重点观察 Zsa9H.s 的读入缓冲区、解密前后内存变化、新建 RX/RWX 内存区域以及首次执行入口。
调试结果显示，程序会读取 Zsa9H.s，并将其内容作为后续内存载荷进行处理。原始文件内容被读入后，经过解密/变换，最终执行流转移到 0x03D70040 附近。该地址位于新建的私有可执行内存区域，因此可确认其为 Zsa9H.s 解密后 shellcode 链的第一层执行入口。
对该内存区域进行完整 dump 后，以 raw binary 方式导入 IDA 分析。由于该内存并非标准 PE 文件，不能直接按 PE 结构解析。通过 IDA MCP 辅助识别，可见两个关键函数：
0x40 ShellcodeEntry_JumpToDecoder0x2E04 DecodePayloadInPlace_ThenRetJump其功能可以描述为： shellcode 入口先跳转到解码器； 解码器取得内联加密载荷地址； 对后续内存区域进行原地解码/反混淆； 解码完成后通过 ret 转移到解码后的 payload 入口。
因此，0x03D70040 所在内存区域应被理解为第一层 shellcode loader 与内联加密载荷的组合，而不是最终远控模块本体。该阶段证明样本已经进入 Zsa9H.s 派生出的 shellcode 执行链，后续仍需跟踪解码器跳转后的执行流，才能获得下一层真正执行的 shellcode 或 PE 模块。
config.ini 读取与 C2 线索出现#
在继续跟踪 0x03D70040 后续执行流时，调试器观察到样本打开并读取同目录下的 config.ini。这说明 Zsa9H.s 解密出的内存代码已经进入下游配置加载流程。
在运行时继续跟踪后，内存中能够观察到 C2 地址相关内容。这表明 C2 配置并非直接以明文完整保存在磁盘文件中，而是在运行时由内存代码读取配置、解码/拼接后生成。
因此，config.ini 的读取行为可以作为连接 Zsa9H.s shellcode 与后续 C2/远控模块的重要证据：Zsa9H.s 解密后的代码负责继续加载配置，并在内存中恢复后续通信所需的 C2 信息。
后续远控/后门模块追踪结果#
继续沿 Zsa9H.s 解密后的执行链跟踪后，在内存中发现了解码出的 PE 结构内容。该内容可以被 dump 并导入 IDA，但整体混淆程度较高，代码段可读性很差，难以通过静态分析直接还原完整逻辑。
从现有线索（字符串）来看，该阶段已经不再是单纯的解密 shellcode，而是进入了下游能力模块的加载与执行流程。结合前面的配置读取、内存执行、C2 相关线索以及运行时行为，可以判断该模块具备远控/后门方向的能力特征。
由于 dump 出来的模块经过较强混淆，当前无法准确还原其完整命令集、通信协议和具体函数实现。因此，本文不对其具体远控功能做过度推断，仅将其归类为由 Zsa9H.s shellcode 链加载的疑似远控/后门模块，并将 C2 配置恢复、网络通信行为与 API 字符串作为支撑证据。
结论#
本次分析确认，该样本是一个银狐系多阶段加载样本。入口 VC_radist.x64.exe 主要负责释放组件，随后由 gjSum.exe 承载后续执行流程，并加载 lz.L、读取 Zsa9H.s 与 config.ini。
行为层面上，gjSum.exe 触发了目录 ACL 加固、关闭安全通知、关闭 UAC、随机扩展名文件关联、DOS 设备映射以及 Startup 随机锚点文件访问等动作。其中“随机扩展名文件关联 + DOS Devices\O: 映射 + PendingFileRenameOperations/Startup 投放”与公开银狐情报中披露的无痕启动持久化技法高度一致。
内存层面上，PE-sieve 从 gjSum.exe 中 dump 出的 628aaf0.exe 可归类为目标抑制/清理子模块，主要用于进程抑制、服务/目录清理和 TCP 连接重置，但它不能解释全部后续行为。继续跟踪 Zsa9H.s 后，执行流进入 0x03D70040 附近的私有可执行内存。IDA 分析显示该区域是第一层 shellcode loader，会继续原地解码并跳转到下一层 payload。
后续跟踪中，样本读取 config.ini 并在运行时恢复出 C2 相关内容，随后内存中出现疑似远控/后门能力模块。由于该模块混淆较强，本文不展开完整命令集和通信协议，仅将其作为后续深入分析方向。
因此，本文最终沉淀的核心价值是：从行为日志、内存 dump 和动态调试中重建了 VC_radist.x64.exe -> gjSum.exe -> lz.L/Zsa9H.s -> shellcode loader -> config/C2/疑似远控模块 的执行链，并提取出可用于检测的进程链、注册表、启动项、内存载荷和网络外连线索。