项目地址：HuskyHacks/PMAT-labs: Labs for Practical Malware Analysis & Triage
mikesiko/PracticalMalwareAnalysis-Labs: Binaries for the book Practical Malware Analysis
任务一
PMAT-labs样本
SHA1
certutil -hashfile 样本文件名.exe
两个签名值：
a5adb98b5bc49dc3f9f060b2d65e9e264ed2b05f
f7bc8beb30e9673d8fc4f6363eab07094ed35b59
MD5
两个签名值：
39f15ed00a66cc10efb238b7931ae4a8
60ff78514d6df20c6e82b7b777151c5c
SHA256
两个签名值：
3b4773db51a514ef19515b0323fb46691176be163f2a6a71c643f65d9a211867
3279fb36cf70bdc4d5ccf02e6be855681a39602a9506fbf4cee0bc92323e6a9d
上传到VT 查看文件大小 文件类型 文件时间戳
https://www.virustotal.com/gui/home/upload
NotPacked:
Packed:
PracticalMalwareAnalysis-Labs样本
SHA1
a4b35de71ca20fe776dc72d12fb2886736f43c22
SHA256
f50e42c8dfaab649bde0398867e930b86c2a599e8db83b8260393082268f2dba
MD5
290934c61de9176ad682ffdd65f0a669
上传到VT
01.dll:
01.exe
文件大小 类型 编译时间戳依照千问方式进行查找
任务二
PMAT-labs
使用Detect It Easy打开样本，查看“壳”信息
Malware.Packed.exe
PE32:代表这是32位windows系统上的可执行文件。
Compiler: Microsoft Visual C/C++ (12.20.9044) 和 Tool: Visual Studio (6.0) ：这是用 Visual Studio 6.0 编写并通过Microsoft Visual C/C++ (12.20.9044)编译的，这个ide和编译器版本发布于 1998 年 。
恶意软件作者喜欢用老版本编译器，因为老版本生成的代码不依赖现代**.NET框架**，在老旧或精简的windows系统上也能稳定运行
**Operation system: Windows(95)[I386, 32 位, GUI]：**告诉windows，自己是一个GUI图形界面程序 而不是黑框框
Packer: UPX(3.96)[NRV,best]：使用UPX这个开源压缩软件，版本是3.96，压缩级别是best
因为是UPX壳，只需要下载UPX工具包，然后在目录下敲命令：
upx -d MalewarePacked.exe
就能脱壳
Maleware.NotPacked.exe
未加壳的程序样本
对比加壳样本与脱壳样本的差异
判断PE文件有没有加壳：
1.看节区名称和大小
Malware.NotPacked.exe的节表：
Malware.Packed.exe的节表：
2.看导入表：未加壳的导入表非常丰富，导入函数几十上百；未加壳的导入表极其干净，因为它为了防止猜到它的意图，会把真正的导入表藏起来，一般类似 LoadLibraryA GetProcAddress 等，因为壳只需要这两个函数，就能在内存中把真正需要的API动态加载进来
Malware.NotPacked.exe的导入表
Malware.Packed.exe的导入表：
3.看入口点：未加壳的入口点的地址都落在.text节区范围内；加壳后的入口点基本不在.text节内，它会指向一个新加的节区，比如.UPX1，或指向一个极其怪异的地址。因为壳代码必须先于原始代码运行，所以入口点基本上不落在原始代码内。
这里“未加壳的入口点的地址基本落在.text节区范围内；加壳后的入口点基本不在.text节内”是因为有一种可能，入口点还是在.text内，正常执行流程中对.text后面的代码进行解密后继续执行。所以可以看.text节属性里有没有写权限，要在.text内解密数据并放到.text内执行的话必须得拥有.text内的写权限。
Malware.NotPacked.exe：
明确指向了.text节
Malware.Packed.exe：
指向的是.UPX1，先通过.UPX1解压原代码，确定其加过壳。
4.看熵值（0-8）：未加壳的节区的熵值一般在4.0到6.0之间，但是加了壳的熵值会特别高，一般在7.9以上
Malware.NotPacked.exe：
Malware.Packed.exe：
对upx壳进行脱壳
使用upx工具：Release UPX 5.1.1 · upx/upx
upx -d 文件名.exe -o unpacked.exe
发现信息和NotPacked.exe信息基本一样
没有指定输出的话会覆盖原文件，所以最好-o 输出文件.exe
任务三：字符串与导入表分析
从这个任务开始 一直使用主样本
使用Strings提取字符串
字符串 – Sysinternals | Microsoft Learn
对Packed.exe:
strings64.exe C:\Users\27906\Desktop\analyze_lab\PMAT-labs-main\labs\1-1.BasicStaticAnalysis\Malware.PackedAndNotPacked.exe.malz\Malware.PackedAndNotPacked.exe\Malware.Packed.exe > strings1.txt
加壳后的文件提取出来的字符串大致分为三类：
·95%都是无规则的二进制噪音，属于是压缩后的无规则的二进制字节被工具误判。在其中发现clac.exe
·壳的特征信息：
·.rsrc资源节区内的数据。
UPX默认只压缩.text和.data（数据段）的内容，但不会压缩.rsrc（资源段），因此这些资源节区的内容正常显示
对NotPacked.exe:
strings64.exe C:\Users\27906\Desktop\analyze_lab\PMAT-labs-main\labs\1-1.BasicStaticAnalysis\Malware.PackedAndNotPacked.exe.malz\Malware.PackedAndNotPacked.exe\Malware.NotPacked.exe > strings2.txt
·.text和.data节区内暴露出来的原始代码和数据段，可进行分析
一大堆类似于连接建立与发送请求的代码，可以确定这是ApacheBench压测工具，这种工具内部的代码包含大量的请求和连接建立代码，黑客在其中插入一些额外的网络连接或信息传输后，不易察觉，是一个完美的宿主软件
·暴露出来的其它信息
恶意软件制作者在本地编译的路径
从这些信息可以看出这原本是一个Apache压力测试工具，是一个披着合法网络测试工具的恶意软件。因为Apache官方不可能在内部硬编码写calc.exe，这个一般是黑客用来验证代码执行或者是验证程序GUI正常执行的一些手段。
ab.exe是著名的开源工具，很多杀软对其有白名单，放恶意代码进去可能可以绕过杀软。
使用PE-bear查看导入表
Releases · hasherezade/pe-bear
对Packed.exe:
仅仅包含以上四个函数，并没有 CreateProcess ,VirtualAllocEx ,WriteProcessMemory,CreatFlie,WriteFile等
壳代码运行时，会将被压缩的原始代码解压到内存中，并且调度CPU执行。因为原来的内存不可写或不可执行，所以需要 VirtualProtect修改内存页面的读/写/执行权限。
之后的 LoadLibraryA + GetProcAddress是动态加载的核心，它可以通过解压之后生成的需要调用的函数清单，动态地申请所有需要的API。
之后的 ExitProcess就是强制结束进程的函数
ab.exe肯定会用到网络API，但是对应的 winhttp.dll和 urlmon.dll根本没出现在依赖列表中
注册表API，虽然导入了ADVAPI32.dll，但计数值是1，不可能同时包括多个注册表操作函数，因此后期进行了动态导入。
对NotPacked.exe:
文件操作相关API
可以看到在这个KERNEL32.dll中，并没有隐藏这些需要的API:
·CreateFileA
·CreateFileW
网络相关的API：
存在socket函数。存在一个16进制是17的函数，十进制就是23，23在Windows Sockets库中，序号23对应的正是 socket函数
同时，WS2_32.dll明确导入了 WSARecv和 WSASend，是用于接收数据和发送数据的。
注册表相关的API：
只看到了 AllocateAndInitializeSid函数，这个函数用来在内存中创建并初始化一个安全标识符（SID），跟权限相关。可以用来检查自己的权限，而ab.exe根本不需要检查用户权限，因此这是一个攻击者试图进行的操作，便于后期执行攻击载荷或其它。
前一个 FreeSid用来释放 AllocateAndInitializeSid在内存中分配的空间（SID）。
任务四：深度反汇编分析
该任务使用
PMAT-labs-main\labs\2-5.AntiAnalysis\1.simpleAntiAnalysis\simpleAntiAnalysis-cpp.exe
这个样本没有壳，先给它加壳，然后把加壳与不加壳放入IDA中对比
未加壳：
加壳：
可以发现加壳之后在IDA里面显示的函数就非常少，只有有关于UPX压缩的函数，程序原本的主函数功能函数都被隐藏
所以在进行恶意代码分析的时候，一定要率先去检查有没有加壳，如果遇到了IDA中函数显示是少量甚至是一片空白，极大可能是因为壳的缘故，也有可能是因为丢失需要去还原
定位main函数或入口点
为什么__main就是主函数，而其他不是呢？
因为像WinMainCRTStartup之类的函数，都是编译器自动生成的环境初始化代码
这是最简单的寻找主函数的方法，但是在实际分析中，恶意代码通常会去除符号表
也就是说，程序里根本就不会有__main 甚至
start 这些名字，所有的函数全变成了像 sub_401000这样的名字
第一种方法是我们可以直接按下快捷键Ctrl + E，选择Entry Point 双击跳入，这就是操作系统第
一步执行的地方
然后在这段启动代码中往下滚动，寻找一个非常典型的汇编特征组
因为main 函数通常有 3 个参数 (argc ,argv ,envp) 在 32 位汇编中，调用它之前会有 连续的 3 个push 指令，紧接着是一个 call，而且这个 call 之后往往紧跟一个对 exit()函数的调用，找到那个被调用的 sub_xxxxxx ，双击进去，大概率就是主函数了
第二种方法是交叉引用法，就是找字符串，找那些跟主函数相关的字符串，进行一个交叉引用，一般来说引用的要么是主函数，要么就是离主函数不远
第三种方法是API查找，寻找程序必须要用的核心 API，比如CreateProcess 、RegSetValue 双击这个 API，按 X键，看哪个函数调用了它，顺着调用链往上找，很快就能摸到控制这些行为的主函数
使用交叉引用（xref）追踪可疑字符串的调用位置
shift+F12就可以来到字符串窗口
发现一个可以字符串 "Boom!"
双击进去，光标来到 "Boom!"所在位置，ctrl+x进行交叉引用
点击OK之后，就来引用了这个字符串的函数位置，F5进行反编译之后就得到了伪C函数
可以看到逻辑是检测当前进程是否被调试器监控。是的话弹出对话框“你认为你很聪明吗”嘲讽调试者，然后立刻退出；环境安全的话才会执行真正的恶意载荷，即弹出”Boom!”窗口。
识别关键函数调用链，分析控制流图
用ctrl+x一个个找调用还是容易头晕
所以可以生成直观的调用图
点击菜单栏 View ->Open subviews ->Proximity browser
这是一个交互式的关系网，可以点击节点展开它的调用关系
任务五：Capa自动化分析
安装方法一：python库安装
pip install flare-capa
安装方法二：下载预编译的独立二进制文件
mandiant/capa: The FLARE team’s open-source tool to identify capabilities in executable files.
下载应操作系统的发行版二进制之后，直接在对应目录的命令行终端即可执行capa程序
安装方法三：IDA插件
运行分析
依旧使用PMAT-labs实验一的两个样本
Malware.Packed：
Malware.NotPacked：
分析实验内容
由上述两张图可以看到，首先加了壳的样本，capa是直接分析不出来的，它会直接提示你，这个样本是有加壳的，无法分析
而脱了壳的样本，capa可以分析出一大堆内容出来
第一个框：
md5 / sha1 / sha256: 文件的哈希值，这个恶意软件的数字指纹，可以在VirusTotal中检索该样本，可以发现都跟任务一我们去手动分析的结果一模一样
analysis : static 表示这是静态分析，也就是在不运行程序的情况下扫描代码
os / format / arch: 表明这是一个基于 Windows 系统的 PE 格式文件都是 .exe 格式，架构为 32位(1386)
第二个框：
这部分将恶意软件的行为映射到了网络安全界标准的 MITRE ATT&CK 框架中，说明它在宏观上的攻击策略：
·DEFENSE EVASION，这是防御规避，说明这个程序试图隐藏自己，绕过安全软件的检测
·Obfuscated Files or Information [T1027]:使用了混淆技术，比如可以给数据加密等等之类的操作
·Virtualization/Sandbox Evasion [T1497]:试图检测自己是否运行在虚拟机或沙箱环境中，如果是，它可能会停止运行以防止被分析，也就是反调试
第三个框：
ANTI-BEHAVIORAL ANALYSIS是反行为分析，也就是恶意软件试图对抗安全人员或自动化沙箱的分析
·具体行为：Virtual Machine Detection::Instruction Testing
·含义：它在内部执行了特定的 CPU 指令测试，用来检测自己是不是运行在虚拟机环境里，这是恶意软件非常经典的反调试手段，如果它发现自己在虚拟机里，可能就会直接退出或者伪装成正常程序，防止被动态抓取恶意行为
DATA 是恶意软件在内部如何处理和转换数据
·具体行为: Check String ，检查字符串
Encode Data::Base64 Base64编码和解码
Encode Data::XOR 异或 编码和解码
·含义: 这个样本内部包含了用于 Base64 和 XOR 加解密的算法，恶意软件极少明文硬编码关键信息，它通常会用 XOR 或 Base64 把真正的恶意载荷、C2 服务器的 IP 地址或者关键 API 名称加密隐藏起来，运行时再解密。
DEFENSE EVASION 是防御规避，恶意软件试图躲避杀毒软件或终端检测响应系统的查杀
·具体行为：Obfuscated Files or Information::Encoding-Standard Algorithm
·含义：混淆文件或信息。结合上面DATA 部分的发现，这就指明了该样本使用了标准的编码算法来混淆自己的内部信息，从而规避静态特征码扫描。
第四个框：
这是 capa 工具分析结果中比较具体的部分，它是表明 capa 是根据代码里的哪些线索得出上面那些宏观结论的
检测虚拟机环境
Capability:check for VM using instruction VPCEXT ，是使用 VPCEXT 指令检查虚拟机
Namespace:anti-analysis/anti-vm/vm-detection ，是反分析/反虚拟机/虚拟机检测
VPCEXT ，Virtual PC eXtension是用来和老旧的 Virtual PC 虚拟机宿主机进行通信的指令，恶意软件会在代码中故意执行这条指令：
如果在真实物理机上运行，这条指令是非法的，会触发异常，恶意软件会捕获这个异常并继续执行它的恶意行为如果在 Virtual PC 虚拟机中运行，这条指令会成功执行，恶意软件借此就能判断出自己在沙箱/虚拟机里，从而提前退出
Base64 字符串引用
Capability:reference Base64 string，引用了 Base64 字符串
Namespace:data-manipulation/encoding/base64 ，数据操作/编码/Base64
capa 在程序的内存或数据段中扫描到了标准的 Base64 索引表，也就是
这样的连续字符ABCDEF...0123456789+/
这就说明，程序内部有隐藏的数据需要用 Base64 解码才能看到真正的内容
XOR 异或加密/解密
Capability:encode data using XOR (2 matches) ，使用异或操作编码数据，发现2处匹配
Namespace:data-manipulation/encoding/xor 数据操作/编码/异或
capa 通过分析汇编代码流，识别出了经典的异或循环特征，通常是一个循环体中包含xor 指令，用来遍历修改一段内存数据
2 matches说明在代码中至少发现了两个不同位置在做这种操作，这通常是恶意软件在内存中解密自己真正的恶意载荷或配置信息的解密函数
PDB 调试路径残留
Capability:contains PDB path ，包含 PDB 路径
Namespace:executable/pe/pdb ，可执行文件/PE结构/PDB
PDB，全称是Program Database，是微软 Visual Studio 在编译程序时生成的调试符号文件
很多恶意软件作者在编译时忘记关闭调试信息，导致编译环境的绝对路径被硬编码到了最终的.exe 文件中
导出JSON
capa.exe C:\Users\27906\Desktop\analyze_lab\PMAT-labs-main\labs\1-1.BasicStaticAnalysis\Malware.PackedAndNotPacked.exe.malz\Malware.PackedAndNotPacked.exe\Malware.NotPacked.exe -j > 1.json
这段 JSON 是 capa 工具生成的底层原始分析数据
它不仅记录了样本的基础指纹和底层的内存区段布局，最核心的价值在于它为截图中列出的所有恶意行为，比如反虚拟机检测、Base64/XOR 加密隐藏等提供了确凿的代码级证据，比如具体的内存绝对地址和文件偏移量
