nguyenduchuywork23-sudo/Malware_Analysis_Tesla

# 恶意软件分析报告 ## I. 环境与工具 - **初步识别与静态分析：** Detect It Easy v3.10 - **进程与内存空间监控：** System Informer - **网络流量模拟与监控：** INetSim - **逆向工程 (Disassembler/Decompiler)：** Ghidra - **动态调试器 (Debugger)：** x32dbg ## II. 阶段 1：静态分析 (STATIC ANALYSIS) - 外壳层 ### 1. 文件信息 - **格式：** PE32 - **架构 (Architecture)：** 32-bit - **编译器 (Compiler)：** Microsoft Visual C/C++ - **语言 (Language)：** C - **打包器/安装程序 (Installer)：** Nullsoft Scriptable Install System (3.11) [lzma] - **Overlay 数据：** 存在 (NSIS data) ### 2. 初步技术分析 #### 2.1. 架构与语言分析 - 文件结构属于 PE32 格式。调试过程需要使用 32 位调试器 (x32dbg)，排除了 x64dbg。 - 文件使用 C/C++ 编译，未使用 .NET 平台。逆向过程排除了 dnSpy 工具，因为架构不兼容。 #### 2.2. 打包器/安装程序分析 - 分析的文件具有 Dropper/Wrapper 的特征，不包含原始的 payload 代码。 - 文件结构集成了 Nullsoft NSIS 安装程序来封装 payload。Payload 使用 LZMA 算法压缩，并存储在 Overlay 分区中。 - 文件的执行过程将触发以下指令链：从 Overlay 区域解压数据，将 payload 释放 (drop) 到系统中并启动该 payload 文件。  ## III. 阶段 2：动态分析 (DYNAMIC ANALYSIS) - 解包与提取 ### 1. 解包过程与反调试 (Anti-Debugging) 机制 #### 2.1. 表面与入口点 (Entry Point) 静态分析 - **操作：** 将可执行文件加载到 x32dbg 调试器中。跳过系统断点 (System Breakpoint) 以到达原始入口点 (Original Entry Point, OEP)。 - **收集的数据：** 在 OEP 处，内存中包含静态字符串：`"Error writing temporary file. Make sure your temp folder is valid."` - **结论：** 可执行文件使用 NSIS 安装程序结构作为外壳 (Wrapper/Dropper)。  #### 1.2. 监控内存分配 API - **目标：** 确定 RAM 上分配的用于包含 Payload 的内存区域。 - **操作：** - 在 API `VirtualAlloc` 处设置软件断点 (Software Breakpoint) (`bp VirtualAlloc`)。 - 继续运行进程 (Run)。 - **结果：** 进程在调用 `VirtualAlloc` 函数时停止。 - **下一步操作：** 执行直至返回 (Execute till return) 并步过 (Step Over) 指令。检查 `EAX` 寄存器中的返回值。 - **收集的数据：** `EAX` 寄存器包含新分配内存区域的基地址。检查内存 (Follow in Dump) 确认该区域值为 `00`，并在首字节包含部分 NSIS System 插件的 Metadata。  #### 1.3. 反调试机制分析 (SEH Manipulation) - **目标：** 在数据写入已分配内存时提取 Payload。 - **操作：** 在刚确定的空内存区域设置写入 (Write) 类型、Dword (4 bytes) 大小的硬件断点 (Hardware Breakpoint)。继续执行进程。 - **结果：** 硬件断点未被触发。进程引发了异常 (Exception)。 - **收集的数据 (异常 1)：** - 调试器记录了 First chance exception：`EXCEPTION_ACCESS_VIOLATION` (错误代码：`C0000005`)。 - 引发异常的指令：`mov dword ptr ds:[edi], edi`。寄存器 `EDI` 包含无效的内存地址。 - **机制结论：** 恶意软件执行错误的内存写入指令，以触发结构化异常处理 (SEH - Structured Exception Handling) 机制。这是一种基于进程异常处理响应来检测调试器的技术。  - **下一步操作：** 忽略异常 (Pass Exception) 以将异常处理权交还给进程。 - **收集的数据 (异常 2)：** 调试器记录了 Last chance exception：`STATUS_USER_CALLBACK_EXCEPTION`。 - **最终状态：** 进程终止执行 (Process Terminated)。通过硬件断点监控的区域未记录到 Payload 数据。  ### 2. 独立进程监控 动态分析过程转向使用专门的工具 (Process Hacker / System Informer) 在操作系统环境中监控独立进程，以绕过之前的反调试机制。 #### 2.1. 初步网络行为分析 - **操作：** 终止 x32dbg 上的调试会话并独立执行样本。启动 INetSim 工具模拟响应 TLS/SSL 证书的服务器。 - **收集的数据：** 系统记录了有关证书不匹配的“安全警报”。 - **结论：** 进程启动后立即执行了网络连接 (C2 Callback) 的函数调用。  #### 2.2. 内存空间 (Memory Space) 探测 - **操作：** 使用 System Informer 监控进程。执行静态字符串搜索 (Strings search) 技术，使用 DOS Stub 的特征关键字 (`This program cannot be run`)。 - **收集的数据：** 查询返回了 65 个结果。所有这些结果的 Base Address 都指向原始外壳的内存 (`0x400000`) 以及 Windows 的标准动态链接库 (DLL) (`0x6...`, `0x7...`)。 - **结论：** 解压后的 Payload 不以原始可执行文件 (PE file) 的形式存在 (不包含 DOS Header)。该对象使用了清除标头 (Wipe PE Header) 技术或直接加载 Shellcode，以规避字符串扫描机制。 #### 2.3. Payload 提取 (Memory Dump) - **操作：** 根据大小和保护属性 (Protection) 过滤并检查进程的内存分区列表。 - **收集的数据：** 系统记录了一个动态分配的内存分区，大小为 31.96 MB，具有 `RWX` (Read/Write/Execute) 属性。检查该分区的 Base Address 显示起始字节为 `E9` (Assembly 中 `JMP` 指令的 Opcode)。 - **结论：** `RWX` 内存分区结合起始字节 `E9` 是 Shellcode 执行空间特征结构的标志。该内存区域被确定为包含恶意软件核心功能 (Payload) 的位置。  - **下一步操作：** 提取 (dump) 该 31.96 MB 分区的所有数据，并保存为 `shellcode_payload.bin` 文件，以便用于后续的静态分析步骤。  ## IV. 阶段 3：静态分析 (STATIC ANALYSIS) - 剖析恶意软件核心 (SHELLCODE) ### 1. 初始化静态分析环境 - **工具：** Ghidra - **操作：** 将原始二进制数据块 (`shellcode_payload.bin`) 加载到工作区。设置文件加载参数 (Import Format) 和处理器结构为 `x86:LE:32:default:windows` 格式 (x86 架构，Little Endian，32 位，Windows 编译器)。特别地，**跳过自动分析过程 (Auto Analyze)**，以防止系统错误识别入口点 (Entry Point)。 - **结果：** 数据成功映射到 CodeBrowser 模块的虚拟内存空间中，从基地址 `0x00000000` 开始。  ### 2. 数据验证与收集失陷指标 (IoC) - **操作：** 通过 Ghidra 的 "Import Results Summary" 对话框确认文件加载成功。 - **收集的数据：** Ghidra 自动计算并提取了 `payload.bin` 文件的哈希值。这些是极其重要的失陷指标 (Indicators of Compromise - IoC)，用于在威胁情报 系统上识别恶意核心： - **MD5：** `05c958ec9f79091f582d9b7ee2c20da4` - **SHA256：** `79c48473073d43d36bf4b9c93125ccc9894b4107eb9e7f547ab30eb0df08e235` - **结论：** Shellcode 文件已成功以 Raw Binary 格式和 x86 (Little Endian) 架构加载到工作区。  ### 3. 初始化控制流 (Initial Control Flow) 分析 - **操作：** 在基地址 `0x00000000` 处手动执行强制反汇编 (Force Disassembly)。 - **收集的数据：** - 基地址处的起始字节记录为 `66` (而不是动态分析过程中记录的 `E9`)。 - 输出的汇编 (Assembly) 代码块包含前 3 条算术指令：`PCMPGTD`, `PADDUSB`, `PADDSW`。 - 就在地址 `0x0000000a` 处，控制流遇到了无条件跳转指令：`JMP LAB_00000055`。 - **结论：** - 初始算术指令集具有垃圾代码 (Junk Code) 的特征。插入这种技术的目的是为了混淆 控制流，并绕过安全软件的静态签名识别机制。 - `JMP` 指令起到了中断线性控制流的作用，将指令指针 (EIP) 重定向越过垃圾代码区，跳转至 `0x00000055` 处真正的核心指令分区。  ### 4. 跳转点 (0x00000055) 处的指令块分析 - **操作：** 将分析指针移动到从前一个跳转指令引用 (XREF) 的标签 `LAB_00000055` (地址 `0x00000055`)。执行强制 Assembly 反汇编。 - **收集的数据：** - 在地址 `0x00000055`，执行的第一条指令是 `AND EAX, EAX`。 - 紧接着调用了 `PMULHW MM0, MM5` 指令。 - 就在地址 `0x0000005a` 处，控制流再次遇到另一条无条件跳转指令：`JMP LAB_0000006e`。 - 从地址 `0x0000005c` 开始，Ghidra 无法插值出有效的 Assembly 代码 (显示为 `??` 符号以及诸如 `C3h`, `E1h` 的垃圾字节)。 - **结论：** - 与 Entry Point 类似，`0x00000055` 处的代码区继续使用了 Obfuscation (混淆) 技术。诸如 `AND EAX, EAX` 和 `PMULHW` 之类的指令在逻辑上没有意义，它们扮演着空指令 (NOP Sled) 或垃圾代码的角色，旨在欺骗静态分析算法。 - `JMP LAB_0000006e` 指令表明该对象继续将真正的控制流隐藏到另一个地址 (0x0000006e)。跳转指令之后紧接着存在垃圾字节块 (从 0x0000005c 开始)，这证实了该 Shellcode 经过了多层加密/混淆的假设。  ### 5. Shellcode 中的规避技术 (Evasion Techniques) 分析 - **操作：** 跨越离散的内存分区追踪控制流字符串 (从 `LAB_00000055` 到 `LAB_000000f8`)。 - **收集的数据：** - 控制流被一系列无条件跳转指令 (JMP) 高度碎片化。 - 跳转指令之间的空间被对程序逻辑毫无贡献的 SIMD/MMX 算术指令集 (如 `PUNPCKHBW`, `PSUBW`, `PSUBD`) 填充。 - 核心数据的初始化过程分散进行的：`MOV EDI, 0x5744fc15` 指令 (位于 `0x0000006e`) 结合了 `ROL EDI, 0x5` 指令 (位于 `0x000000c2`)。 - **结论：** - 恶意软件样本使用了 **Spaghetti Code** (碎片化跳转指令链) 结合 **Dead Code Insertion** (插入垃圾代码) 的技术，以破坏 Assembly 流的线性特征。其目的是使静态签名扫描 机制失效。 - 在 `EDI` 寄存器上操作的算法 (`MOV` 结合 `ROL`) 是正在初始化 **API Hashing** (哈希函数) 机制的明显证据，用于解析系统 API 函数而无需使用明文字符串。 - *(参考：下方体现 Jump Chaining 和 Dead Code Insertion 行为的文件证据链)。*       ### 6. 解密存根 (Decryptor Stub) 循环与自修改代码 (Self-Modifying Code) 分析 - **操作：** 在使用脚本 `GhidraJmpBypass.java` 扫描规避跳转链后，调查并静态逆向位于地址 `0x00001835` 的目标内存区域。 - **收集的数据：** - 通过向后控制流确认循环结构 (从 `0x00001872` 的 XREF)。 - 指令流包括推进内存指针的操作 (`INC ECX`)。 - 记录了直接交互和修改内存的指令：`XCHG dword ptr [ECX], EBX` (将寄存器内容与内存地址交换)。 - 通过条件分支指令确认循环出口：`JA LAB_0000187e`。 00001835 2b dc SUB EBX,ESP 00001837 a0 89 72 d4 69 MOV AL,[DAT_69d47289] 0000183c 77 40 JA LAB_0000187e 0000183e 41 INC ECX 0000183f 87 19 XCHG dword ptr [ECX],EBX - **结论：** - 这段代码是一个使用 **Self-Modifying Code** (自修改代码) 技术的 **Decryptor Stub** (解密外壳)。 - 恶意软件执行循环，直接将核心 Payload 覆盖、解压或解密到正在执行的内存空间中 (In-memory Decryption)，以规避静态分析工具的检测。 - 核心 Payload 的执行点预计位于循环出口地址 `0x0000187e`。  ### 7. 静态分析的局限性与方法论的转换 - **操作：** 评估解密循环出口 (从地址 `0x00001835` 起) 的 Assembly 指令流和 C 伪代码。 - **收集的数据：** - 静态反编译器 返回异常警告：`WARNING: Control flow encountered bad instruction data`。 - 伪代码流出现错误中断函数 `halt_baddata();`。 - Assembly 分析器 在地址 `0x00001841` 处标记了结构错误。 - **结论：** - 由于 **Self-Modifying Code** 的特性，静态分析技术已达到极限。当前的内存数据块尚未被解密，导致反汇编器 错误地将垃圾数据编译成了指令集。 - 必须将流程转换为 **模拟执行** 或 **动态调试** 方法，以迫使恶意软件在虚拟内存中自动完成外壳解密 过程。  ### 8. Shellcode 的反模拟 (Anti-Emulation) 技术 - **操作：** 通过模拟器 `scdbg` (Libemu) 启动二进制代码块的动态分析。 - **收集的数据：** - 模拟器在第一步执行 (`step: 0`) 时突然停止。 - 错误信息记录了指令集异常：`opcode 0f 66 not supported`。 - Terminal 上的详细执行日志： C:\Users\malware\Desktop\malware\43e7...94a>scdbg.exe -f payload.bin -s -1 Loaded 1ff5000 bytes from file payload.bin Initialization Complete.. Max Steps: -1 Using base offset: 0x401000 0 opcode 0f 66 not supported 0 ???? No memory At Address step: 0 foffset: 0 eax=0 ecx=0 edx=0 ebx=0 esp=12fe00 ebp=12fff0 esi=0 edi=0 EFL 0 Stepcount 0 - **结论：** - 恶意软件应用了复杂的 **Anti-Emulation** (反模拟) 技术。将 SIMD/MMX 指令集 (如 `PCMPGTD` - 对应 opcode `0F 66`) 插入到执行链中，旨在利用常见的 Shellcode 模拟器 (如 Libemu) 不支持扩展指令集的弱点。 - 结果，自动化分析过程在第一步就被“击垮”，彻底阻止了 Sandbox 系统提取 API call。  ### 9. 动态调试参数配置 (Dynamic Debugging Setup) - **操作：** 使用 `BlobRunner` 工具分配虚拟内存并加载原始字节串 (Shellcode) 以准备调试环境。 - **收集的数据：** - 加载器 返回分配参数：`|-Base: 0x03600000`。这是操作系统为包含恶意代码的内存区域分配的基地址。 - 对比静态分析过程 (阶段 3)，解密循环的出口 (核心 Payload 的 Entry Point) 记录在偏移量 为 `0x187e` 处。 - **结论：** - 核心 Payload 在 RAM 内存上的实际绝对地址 通过基本数学运算提取得出：`0x03600000 (Base) + 0x187e (Offset) = 0x0360187e`。 - 需要在调试器 (x32dbg) 中的地址 `0x0360187e` 处设置断点 (硬件/软件)。此操作旨在内存解密 完成时立即拦截 控制流，从而转储 核心 Payload 的全部内容。  ### 10. 反分析规避机制 (Anti-Analysis Evasion) 评估 - **操作：** - 在 x32dbg 上部署 `ScyllaHide` 插件 (配置 Profile：VMProtect/Themida；针对 `NtGetContextThread` 和 `NtSetContextThread` 函数补充 hook)。 - 在解密循环的目标地址处的调试寄存器上设置硬件断点，取决于分配的基地址，例如 `0x02EE187E`)。 - 授予 `BlobRunner.exe` 进程的线程 继续执行的权限。 - **观察数据：** - x32dbg 界面记录进程状态转为 "Terminated" (已终止)。 - 在 EIP 寄存器达到设置硬件断点的地址之前，执行流自动中断。 - 在进程终止之前，调试器没有捕获到任何异常。 - **技术分析：** - 收集到的数据显示，在用户态 空间的 API Hooking 机制 (通过 ScyllaHide 作用于如 `ntdll.dll` 等系统 DLL) 无法阻止恶意代码的自毁逻辑。 - 在尚未提取到退出函数 调用分支处的具体 Assembly 指令流时，进程自动终止的现象可能源于以下规避机制 (按可行性程度排序)： 1. **直接内核通信：** Shellcode 执行机器码 `syscall`/`sysenter` 将系统中断直接下推至 Kernel-Mode，从而绕过调试器在 User-Mode 层的 hook 点。 2. **执行时间测量：** 使用硬件指令 (如 `RDTSC`) 计算 CPU 周期的增量，从而检测由手动调试过程引起的延迟。 3. **内部异常处理：** 主动制造内存分配错误 (或除零错误) 以便操作系统返回 `CONTEXT` 结构。Shellcode 在内部级别自行分析此结构，在 ScyllaHide 进行干预之前读取 `DR0-DR7` 寄存器的状态。 4. **环境检查：** Shellcode 查询虚拟机的标识信息 (MAC 地址、VMWare/VirtualBox 的注册表键) 或通过不在默认监视列表中的 API 函数探测进程列表 (`x32dbg.exe`)。 

标签：DAST, DNS 反向解析, JS文件枚举, 云安全监控, 云资产清单, 域名枚举, 安全研究报告, 恶意软件分析, 网络信息收集, 逆向工程, 静态分析