USB应急响应取证排查

在实际的应急响应和安全事件调查中，USB 几乎永远是一个“被低估的风险点”。USB 不需要复杂的攻击链，也不依赖网络通信。它只需要一次短暂的插入，就足以完成数据拷贝、恶意程序执行，甚至规避绝大多数网络侧的安全监控。也正因为如此，在涉及数据泄露、内部威胁、可疑文件访问等场景时，USB 取证往往不是“可选项”，而是必须纳入调查范围的核心环节。

USB 注册表

在 USB 相关的应急响应中，Windows 注册表几乎是第一站。原因很简单：只要 USB 设备被系统识别过，哪怕只插入几秒钟，注册表里几乎一定会留下痕迹。这些痕迹不仅能证明“插没插过”，还能回答插的是什么、什么时候插的、是不是外接存储等关键问题。

USBSTOR：外接存储取证的核心入口

在所有 USB 相关注册表项中，最重要、也最常被使用的一个路径是：

HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR

这个键只记录外接存储类设备，比如 U 盘、移动硬盘等，不包含键盘、鼠标这类普通 USB 外设。USBSTOR 往往是确认 USB 是否参与数据拷贝事件的第一块证据。

通过这个路径，我们通常可以获取到：

• USB 设备的型号与产品名称
• Windows 分配的设备序列号
• 设备最后一次连接的时间
• 与该设备关联的唯一标识信息

这些信息对于判断 USB 是否与某次安全事件有关，往往具有决定性意义。

USBSTOR 下子键的作用

当系统第一次识别某个 USB 存储设备时，USBSTOR 下会生成对应的子键。这些子键名称看起来通常是随机字符串，但实际上对应的是设备在系统中的标识信息。

展开之后，会看到大量与该设备相关的字段，包括：

• Friendly Name：设备在系统中显示的名称
• Container ID：设备容器标识，在多数据源关联分析时非常有价值

在内部威胁或数据泄露调查中，设备名称有时能直接指向真实场景，比如“Kingston DataTraveler”“SanDisk Ultra”等，这对还原使用者行为非常有帮助。

连接与断开时间：构建时间线的关键

在 USBSTOR 相关子键下，继续向下展开，可以找到 Properties 目录。用系统自带的注册表工具无法正常查看，需要使用RegistryExplorer打开。

在这里，有两个对取证极其重要的子项：

• 0064：USB 设备连接系统的时间
• 0066：USB 设备从系统断开的时间

这两个时间戳通常以 UTC 时间记录，在应急分析中需要注意与本地时间的换算。

这一步的意义在于：可以非常明确地回答一个问题——USB 是在什么时候插入，又在什么时候拔出的。将这些时间与以下信息进行对齐，往往能直接还原事件真相：

• 告警触发时间
• 文件访问时间
• 用户登录 / 解锁时间
• 网络异常时间

在很多真实案例中，正是这一步让“猜测”变成了“证据”。

不只是 U 盘：USB 设备类型的区分

除了 USBSTOR，还有另一个常被用到的注册表路径：

HKLM\SYSTEM\CurrentControlSet\Enum\USB

这个键记录的是所有通过 USB 接口连接的设备，包括：

• 键盘
• 鼠标
• 蓝牙适配器
• 网卡
• 以及存储设备

在应急响应中，这个路径的主要作用是：确认某个 USB 设备到底是什么类型。

通过查看其中的 Service 字段，可以判断设备的用途：

• disk：通常表示存储类设备（U 盘、移动硬盘）
• BTHUSB：蓝牙适配器
• 其他值则对应不同的 USB 外设类型

这一步在调查中非常重要，因为它可以避免误判。并不是所有 USB 插入行为，都意味着存在数据拷贝风险。

USB 事件日志

在 USB 取证中，注册表通常是我们最先查看的证据来源。但在真正严谨的取证排查中，只靠注册表是不够的。原因很现实：注册表更像“状态记录”，而事件日志才是真正的“行为轨迹”。

因此，在确认 USB 设备确实插入过系统之后，下一步一定要做的，就是用 Windows 原生事件日志对时间点和设备信息进行交叉验证。

为什么事件日志在 USB 取证中很重要

在取证实践中，有一个非常重要的原则：同一事实，至少要由两个以上的数据源相互印证。

USB 相关的事件日志，正是用来验证以下问题的关键证据：

• USB 是不是在某个具体时间点被系统识别
• 系统是否成功加载了该设备的驱动
• 这个 USB 被分配了哪个盘符
• 日志时间是否与注册表中的时间戳完全一致

当注册表 + 事件日志在时间线上完全重合时，USB 行为的可信度就非常高了。

USB 事件日志位置

在 Windows 中，USB 相关的日志主要分布在：

事件查看器 → 应用程序和服务日志 → Microsoft → Windows

在这个目录下，有大量系统级日志源，其中有几类对 USB 取证尤为重要。

Partition 日志：确认磁盘级别的 USB 设备

第一类需要关注的是 Partition 日志。在这类日志中，一个非常关键的事件是：

• Event ID 1006

这个事件通常在 USB 存储设备被系统识别并初始化分区时 产生。

在应急响应中，我们重点关注的是：

• 事件时间是否与注册表中记录的 USB 连接时间一致
• 日志中是否包含磁盘大小、序列号、厂商信息等细节

当 Event ID 1006 的时间与 USBSTOR 中的连接时间完全吻合时，基本可以确认：这个 USB 存储设备确实在该时间点被系统识别并使用过。

Kernel-PnP：USB 驱动加载的关键证据

接下来，是 USB 取证中极其重要的一类日志来源：Kernel-PnP。在这个日志源中，我们通常重点关注两个事件 ID：

• Event ID 400
• Event ID 410

其中，Event ID 400 尤其关键，它表示：系统成功为一个外接设备完成配置（也就是驱动加载）。

在这个事件中，通常可以看到：

• 设备名称（与 USBSTOR 中一致）
• 设备的 Class GUID
• 驱动加载的精确时间戳

在真实事件中，一个非常有价值的现象是：Kernel-PnP 日志中的设备名称和 Class GUID，往往与注册表中的信息完全一致。这意味着已经可以把“注册表记录”升级为“系统行为证据”。

NTFS 日志：USB 被分配了哪个盘符

仅知道 USB 插入过，还不够。在数据泄露调查中，更重要的是：文件路径里出现的盘符，是否真的来自这个 USB？这时候，就需要用到 NTFS Operational 日志。

在这个日志中，我们重点关注：

• Event ID 142

这个事件记录的是：系统为某个存储设备分配卷和盘符的过程。

通过查看该事件的内容，你通常可以直接看到：

• USB 被分配的盘符（例如 E:、F:）

这一点在后续分析中非常关键，因为：

• 如果在文件访问日志、Shellbags、Jump Lists 中看到 E:\xxx
• 而 NTFS 日志确认该时间点 E: 对应的是 USB

那么就可以非常有把握地判断：这些文件操作，确实发生在该 USB 设备上。

实战组合用法

在真实 USB 数据外带事件中，常见的取证逻辑是：

1. 注册表（USBSTOR）
   • 确认设备是谁、是否插过、初步时间点
2. Partition + Kernel-PnP 日志
   • 确认系统是否真正识别并加载了该设备
3. NTFS 日志
   • 确认 USB 被分配的盘符
4. 文件与用户行为痕迹
   • 结合盘符，判断是否存在真实的数据访问或拷贝行为

当这几类证据在时间线上形成闭环时，USB 的角色就非常清晰了。

Shellbags 确认 USB 上哪些目录被访问过

在 USB 取证中，有一个非常关键、但经常被忽略的问题：

USB 插过 ≠ 数据被看过，更不等于数据被拷走

注册表和事件日志只能回答“设备是否存在、什么时候插入”，而真正能说明用户在 USB 上“看了什么”的是 Shellbags。

什么是 Shellbags?

ShellbagExplorer : https://ericzimmerman.github.io/#!index.md

Shellbags 并不是一个新概念，但在实战中它的价值常常被低估。简单来说，Shellbags 是 Windows 为了记住“文件资源管理器视图状态”而留下的痕迹。用户通过 GUI 文件管理器（也就是资源管理器）浏览目录时，系统会记录：

• 目录结构
• 文件夹名称
• 目录层级关系
• 用户最后一次访问这些目录的时间

关键点在于：即便文件或目录后来被删除，这些访问痕迹也可能依然存在。在数据泄露、内部威胁、恶意拷贝场景中，这一点往往非常致命。

在 USB 相关事件里，Shellbags 通常能帮助我们解答这些问题：

• USB 上有哪些目录被用户真正打开过
• 用户是“随便看了一眼”，还是深入浏览了特定目录
• 是否存在明显指向敏感项目、内部资料的目录名称
• 用户访问这些目录的大致时间点

很多时候，目录名称本身就已经说明了动机。例如一些非常敏感的文件名。哪怕没有直接的文件拷贝证据，这类目录的访问记录，本身就已经非常敏感。

Shellbags 存储位置

Shellbags 的一个重要特点是：它是用户维度的取证证据。

相关注册表位置包括：

• NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU
• NTUSER.DAT\Software\Microsoft\Windows\Shell\Bags
• USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
• USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\Bags

这意味着什么？意味着你分析的是哪个用户的 NTUSER.DAT，Shellbags 就代表哪个用户通过 GUI 实际访问过这些目录。在多用户系统中，这一点非常关键。

在 USB 场景中如何使用 Shellbags

在前面的步骤中，我们已经通过事件日志确认：

• USB 被分配了具体盘符（例如 E:）

接下来，在 Shellbags 中，我们就可以沿着这个盘符往下追。

当在工具中展开 E: 时，看到的每一层目录，都意味着：用户至少在资源管理器中点开过这一层路径。这不是推测，而是实实在在的用户行为痕迹。

经常被忽略的细节：ZIP 文件

Shellbags 还有一个很多人不知道的能力：它不仅记录文件夹，也可能记录 ZIP 文件内部的目录结构。但前提是：

• 用户通过资源管理器打开了 ZIP 文件
• ZIP 文件未加密
• 用户实际浏览了 ZIP 内部的目录

这意味着什么？意味着即使：

• ZIP 文件本身没有被解压
• 文件没有被复制到本地

在真实案例中，这一点经常用来证明：“用户确实查看过USB压缩包里的内容”，而不仅仅是“USB 里存在这个文件”。

Jump Lists 取证：明确访问文件和程序

JumpList Explorer : https://ericzimmerman.github.io/#!index.md

在 USB 取证的所有证据里，如果要选一个最接近“实锤”的用户行为证据，Jump Lists 往往排得非常靠前。原因很简单：Shellbags 证明“进过这个目录”，Jump Lists 证明“点开过这个文件，甚至执行过程序”。

在真实事件里经常会听到这样的解释：

• “我只是看了一眼，没打开文件”
• “U 盘插过，但没用”
• “文件名我都不知道是什么”

Jump Lists 的价值，就在于直接打破这种模糊说法。它可以证明：具体打开了哪个文件、用什么程序打开的、大致发生在什么时间、文件当时所在的完整路径。而且非常重要的一点是：即便 USB 已经拔掉，文件已经删除，Jump Lists 中的记录仍可能长期保留在系统里。

Jump Lists 是 Windows 从 Windows 7 开始引入的一项功能，用于在开始菜单、任务栏中，快速展示某个程序“最近使用的文件”。从取证角度看，你可以把它理解为：“按应用维度记录的历史文件访问清单”它不是日志，也不是注册表，而是一组独立存在的二进制取证文件。

Jump Lists 的两种类型

在 Windows 中，Jump Lists 分为两类：

• Automatic Destinations
• Custom Destinations

打开时遇到这个报错忽略即可。两者的区别对调查影响不大，重要的是：它们都可能记录用户通过某个程序访问过的文件路径。这些文件的特点是：

• 文件名由 AppID（16 位十六进制） 组成
• 后缀为 .automaticDestinations-ms 或 .customDestinations-ms
• 默认在资源管理器中不可见

对应路径一般位于：

C:\Users\%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Recent\
  ├─ AutomaticDestinations
  └─ CustomDestinations

Jump Lists 的作用

在 USB 事件中，Jump Lists 最有价值的地方在于：它直接记录“某个文件，被某个程序，在某个时间点打开过”。典型可提取信息包括：

• 文件名
• 文件完整路径（例如 E:\Secret_Project_LD\Dumped_Passwords.txt）
• 使用的程序（Notepad、Word、PowerShell、EXE 等）
• 最近访问时间

比如当你已经确认USB 盘符是 E:，并且E: 确实对应某次 USB 插入，而 Jump Lists 又显示某个敏感文件从 E: 被打开，那么这条证据链已经非常完整了。

USB 自动化取证工具

在前面的分析中，我们已经通过多个维度还原了 USB 的使用痕迹：

• 注册表：确认 USB 是谁、是否插过
• 事件日志：确认系统层面的识别与盘符
• Shellbags：确认用户浏览过哪些目录
• Jump Lists：确认具体文件被打开或程序被执行

这些方法在单台主机、重点调查场景下非常有效，但在真实应急响应中，往往会遇到一个现实问题：时间不够、人手不够、主机不止一台。这时候，自动化解析工具就显得非常重要。

为什么需要自动化 USB 取证

手工分析有两个天然问题：

• 慢：逐条查注册表、日志、Shellbags、Jump Lists
• 容易漏：时间线一长，很容易遗漏关键关联

而自动化工具的价值在于：

• 快速聚合多种 USB 取证证据
• 自动做时间线对齐
• 减少人为遗漏和误判
• 适合多主机、批量分析场景

在应急响应的中后期，自动化工具往往用于验证结论、补全细节，而不是替代分析思路本身。

USB Detective：自动化聚合 USB 证据

https://usbdetective.com/download/245

这里使用的自动化工具是 USB Detective。它的核心能力很简单，但非常实用：自动解析与 USB 相关的所有常见取证痕迹，并按设备维度整理结果。这样我们需要做的事情只有一件：提供已经采集好的取证数据（如注册表、日志等）。剩下的事情由工具完成。

目标主机运行 KAPE（或类似采集工具），选择 USB / Registry / Logs 相关 Target，输出到一个目录（例如 Usb Artifacts）。

这里选择刚才KAPE导出的文件夹进行自动化分析。

分析完成后就能得到这台设备上所有的usb记录，相比于手工分析效率会提升非常多，但本质上取证的原理还是一样的。

赞赏

微信赞赏支付宝赞赏