恶意样本静态逆向实践：XOR 函数指针表与进程镂空注入

今天尝试对一个 Windows 恶意样本进行静态逆向分析，主要学习 PE 文件结构、API 调用分析以及恶意程序常见行为模式。

1. 分析过程

今天尝试第一次完整分析一个 Windows 恶意样本。最开始通过 PE 信息确认样本结构，随后使用 IDA 跟踪关键函数。在分析过程中发现，样本并没有直接调用敏感 API，而是通过动态解析隐藏真实调用，这也是我第一次比较直观地接触到恶意程序对抗静态分析的方法。随后结合 IDA 对关键函数进行跟踪，发现程序并没有直接调用敏感 API，而是通过动态解析方式获取函数地址，增加静态分析难度。
报告依据

样本未直接调用敏感 API，而是在 .data 段存放异或加密的函数指针表（密钥 qword_408000 = 0x6BF72FD7E5809F41），运行时通过 qword_408000 ^ qword_408xxx 还原真实地址，如 0x40100D（WinMain_DecryptCall_Dispatcher）解密出 0x401634 后间接调用。
示例：sub_401B45 中的 LoadLibraryW("ADVAPI32.dll")、OpenSCManagerW 等调用全部经此机制动态解析，规避静态分析。

截图：0x40100D 处异或解密调用模式

2. 关键发现

2.1 进程注入分析

分析过程中发现样本通过挂起创建进程、远程内存分配以及写入 payload 的方式实现代码注入，涉及 CreateProcessW、VirtualAllocEx、WriteProcessMemory 等 API。
报告依据

核心注入函数 sub_4046D1（0x4046D1）实现进程镂空：先 CreateProcessW(自身路径, ..., CREATE_SUSPENDED=0x8000000, ...) 挂起创建进程，再 VirtualAllocEx(hProc, 0, 72, 0x3000, PAGE_EXECUTE_READWRITE=4) 远程分配可执行内存，最后 WriteProcessMemory(hProc, addr, payload, 72, 0) 写入 payload。
备用注入路径：sub_403851 使用 NtAllocateVirtualMemory / NtWriteVirtualMemory（ntdll 原生 API）；sub_403A37 使用 PostQueuedCompletionStatus / ZwSetIoCompletion 执行。

截图：sub_4046D1 反编译中的异或动态调用

这让我认识到，HIPS 不应该只关注单个 API 调用，而应该关注 API 调用组合形成的行为链，例如“创建挂起进程 + 远程写入 + 执行权限内存”。

2.2 反静态调试分析

样本存在 API 动态解析、字符串 XOR 加密以及跳板函数等混淆方式，使传统静态分析工具难以直接获得真实行为。
报告依据

API 动态解析：函数指针表存于 .data 段，运行时经 qword_408000 ^ qword_408xxx 异或还原（密钥 0x6BF72FD7E5809F41）。
字符串 XOR 加密：宽字符 char = 低字节 ^ 高字节（如 0x408008 → ADVAPI32.dll、0x4083BC → bdservicehost.exe）；ANSI 单字节 XOR 尾字节（如 0x408082 → OpenSCManagerW）。
跳板函数混淆：大量 jmp short 跳板（如 0x401B38 → sub_401B45、0x401FD3 → sub_401FE0、0x40284C → sub_402859），真实函数地址隐藏于异或表之后。

截图：运行脚本后 IDA Python 控制台的解密输出
截图：跳板函数示例

这让我进一步理解为什么安全工具需要结合静态分析和运行时行为监控。

2.3 对 HIPS 设计的启发

此次分析也反向验证了之前设计 HIPS 行为规则的一些思路。例如恶意程序常通过多个正常 API 组合完成攻击，因此检测重点应该从单 API 判断转向行为链分析。
CREATE_SUSPENDED + VirtualAllocEx + WriteProcessMemory + CreateRemoteThread

3. 今日总结

通过此次分析，我开始从攻击者视角理解 Windows 内部机制。之前开发 ARK/HIPS 时更多关注“如何监控系统”，而逆向分析让我认识到“攻击者如何利用系统机制”同样重要。后续计划继续学习恶意代码分析，并将相关行为抽象为安全检测规则。