附件类型鉴定与哈希
邮件与即时通讯投递的附件要先确认“真实身份”：扩展名与文件头不一致（例如名为文档实为可执行文件或压缩包）本身就是危险信号，也直接影响后续处置方式。标准做法是先识别类型与计算哈希，再尝试按容器格式展开，逐层展开、逐层记录。常见需要关注的形态包括：文档中带宏、压缩包内含脚本或快捷方式、快捷方式指向远程地址、多层嵌套压缩以规避检测。
基本信息
| 适用平台 | 隔离的分析环境（Linux 或 Windows 分析机） |
|---|---|
| 基本步骤 | file 识别类型 → 计算哈希 → 按格式试探展开 → 逐层记录 |
| 常用命令 | file、sha256sum、7z l、unzip -l 等 |
| 宏文档工具 | oletools 等工具集可用于识别与提取宏代码（需另行安装） |
| 记录要求 | 每一层的文件名、类型、哈希与展开命令都要留档 |
典型使用场景
- 确认钓鱼邮件附件的真实类型与是否携带可执行内容
- 提取压缩包内的下一层载荷并记录哈希，形成传播链
- 检查文档是否带宏、宏是否自动执行、是否有提示语
- 确认快捷方式文件的指向目标，判断是否为远程加载
- 为报告提供附件层面的完整证据链：从接收文件到嵌套载荷
鉴定与展开
鉴定与展开
# 1) 真实类型与哈希（扩展名仅作参考）
file attachment.doc
sha256sum attachment.doc
# 2) 判断是否可展开（压缩包、复合文档等）
7z l attachment.doc 2>/dev/null | head -20
unzip -l attachment.zip 2>/dev/null | head -20
# 3) 展开到独立目录，逐层记录哈希
mkdir -p out/level1 && 7z x -oout/level1 attachment.zip >/dev/null
find out -type f -exec sha256sum {} + > out/layer-hashes.txt
# 4) 宏文档：识别是否存在宏与自动执行属性（工具安装后执行）
# oleid attachment.doc / olevba attachment.doc形态对照
| 形态 | 含义 | 风险 |
|---|---|---|
| 类型与扩展名不符 | 伪装投递 | 最高优先级，可能直接是可执行载荷 |
| 压缩包嵌套 | 规避检测与沙箱 | 需逐层展开，注意解压路径安全 |
| 带宏文档 | 宏可执行命令 | 关注自动执行与提示语，提取宏代码 |
| 快捷方式文件 | 指向本地或远程目标 | 远程指向可能触发下载执行 |
| 脚本附件 | 直接可读的脚本 | 常见下载执行与持久化动作 |
多层嵌套（压缩包内含快捷方式或脚本）要逐层展开并逐层记录哈希：只记录最外层会让后续引用无法对应到具体文件。
展开压缩包要在隔离环境进行，并注意解压路径安全（避免路径穿越把文件写到系统目录）与可能的解压炸弹（体量异常放大）。