USN 日志能证明文件被拷贝到 U 盘吗?

部分能。源卷日志记录用户打开了什么,以及拷贝之前发生的任何 temp/zip 暂存。要证明真正的写入,需要目标 U 盘镜像 — 它自己的 $UsnJrnl:$J 携带每个被拷贝文件的 FileCreate 和 DataExtend 事件。再把 USB 身份与注册表痕迹 (SYSTEM\MountedDevices、MountPoints2) 以及 Setup 硬件事件关联起来。

$UsnJrnl 中经典的数据暂存模式是怎样的?

三个信号同时出现:在一个暂存目录 (Temp、Public、Downloads) 中爆发的 FileCreate;紧接着在一个归档 (.zip、.7z、.rar、.tar.gz) 上的 FileCreate + DataExtend,其大小近似于暂存文件的总和;以及最后对暂存目录的一次 FileDelete 清扫。单独看每一个都很嘈杂;组合起来就具有诊断价值。映射到 MITRE T1074 Data Staged。

如何发现云同步外泄 (OneDrive、Dropbox、Google Drive)?

寻找两种模式。大量 RenameNewName 记录,新父目录是已知的同步目录 (\Users\ \OneDrive\、\Users\ \Dropbox\、\Users\ \Google Drive\),旧父目录是用户配置文件目录。还有同步文件夹内文件出现 DataExtend | Close,但没有对应的用户应用 FileCreate — 这些是同步代理推送上去的上传。重命名的另一半保留了文件原来的父引用,可证明来源。

哪些外泄手段不会产生有用的 USN 信号?

直接从内存中上传 (浏览器 POST、PowerShell 用 Invoke-WebRequest 推送变量)、读取由你不掌控的底层文件系统提供的网络共享、屏幕截图外泄 (只有截图文件落到磁盘上),以及打印。对这些场景,改用 Security.evtx、Sysmon 网络事件、浏览器历史或 PRINTERS\ 打印池痕迹。

create 爆发的检测应使用什么阈值?

从 60 秒内一个目录中超过 50 次 FileCreate 开始,然后根据基线调整。对桌面主机来说,这个范围基本能捕获所有现实的内部窃取和 infostealer 模式,在通过路径排除 Office 的另存为文件夹事件和 IDE 重建爆发之后,误报极少。

用 USN 日志检测数据外泄与 U 盘拷贝

仅次于勒索软件,DFIR 中第二常被问到的问题是"有东西从这里走出去了吗?"的某种变体。USN 日志是开始回答它的最便宜的地方之一。每一次 U 盘拷贝、每一次云同步上传、每一次"把所有东西丢进 temp 文件夹再压成 zip"的操作,都会在 $J 中留下可辨识的形状 — 可辨识到只需两个过滤器加上一次基于父路径的转视角,通常在二十分钟内就能完成一次候选外泄窗口的分诊。

本文是一份按外泄通道分门别类查找这些模式的实操手册。

U 盘留下的痕迹最清晰

当用户接入一个可移动卷时,Windows 会为其分配盘符;如果卷是 NTFS,该设备会拥有自己的 $UsnJrnl。复制到 U 盘的文件会以 FileCreate | Close 加一连串 DataExtend | Close 记录落到目标日志中。从源磁盘复制出去的文件则在源端留下较柔和的痕迹:open 和 close 事件,通常因 AV 扫描和读取之后的文件系统缓存而产生 BasicInfoChange | Close。

在真实案件中你通常手里会有:

源磁盘的日志。显示打开了什么、创建了什么 temp 或归档文件,以及用户如果善后过的话最后那一波删除。
注册表 hive。SYSTEM\MountedDevices、SYSTEM\CurrentControlSet\Enum\USBSTOR、NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 与 setupapi.dev.log 一同标识出哪个物理设备在何时被插入。用 registry parser 解析它们。
目标卷的日志(如果你有 U 盘镜像)。真正的文件写入活在这里。

源端决定性的信号是拷贝前归档的模式,因为大多数有所隐瞒的用户在把驱动器带走之前会去用 7-Zip 或 Explorer 自带压缩:在 temp 路径下对一个 .7z、.zip、.rar 或随机命名文件的 FileCreate,然后持续的 DataExtend | Close 记录直到文件达到最终大小。路径通常是 \Users\\AppData\Local\Temp\、\Users\\Desktop\ 或用户配置文件根目录。

在 USB 识别端,把日志中的时间戳与 Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx 的连接/断开事件相互参照 — 用 EVTX 解析器只需几下点击。再配合 \Users\\AppData\Roaming\Microsoft\Windows\Recent\ 下的 LNK 文件和 jump lists,就能得到用户从 U 盘明确打开过文件的证据。

经典的暂存-再归档模式

在 MITRE ATT&CK 中映射到 T1074 Data Staged,在磁盘上看起来是这样:

FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
DataExtend | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\customers.csv
DataExtend | Close   ...
...
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3.zip
DataExtend | Close   ...           ← 大量,文件持续变大
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (清理)

三个信号按顺序出现:

在一个暂存目录内 FileCreate 的爆发。
紧接着对一个归档的 FileCreate 加上持续 DataExtend,最终大小近似于暂存文件之和。
归档关闭后不久对暂存目录的一次删除清扫。

每个单独的信号都很嘈杂。组合起来则具有诊断价值。过滤 \AppData\Local\Temp\、\Users\Public\、\Downloads\ 等用户树内可写位置中的 FileCreate,然后按父目录聚类,寻找 60 秒内超过 50 次创建。这个节奏可以捕获内部窃取的暂存和大多数 infostealer 工作负载。把已知的构建路径 (node_modules\、target\、Debug\、Release\、obj\、.next\、dist\) 从过滤器中去掉;它们会产生形状相同的爆发,否则会主导结果。

云同步暂存

OneDrive、Dropbox、Google Drive 和 Box 都维护一个本地同步文件夹,代理一旦发现内容就会立即推送上去。日志暴露两种诊断性模式:

进入同步文件夹的批量 RenameNewName。 新父目录是 \Users\\OneDrive\、\Users\\Dropbox\、\Users\\Google Drive\ 或 \Users\\Box\;旧父目录是 Desktop\、Documents\ 或 Downloads\。重命名的另一半保留了文件原来的父引用,这意味着即使文件不在了你也能证明来源。

同步文件夹内文件出现 DataExtend | Close 但没有对应的用户应用 FileCreate。 这些是代理自己在写入 — 从云端到本地副本的下载。你想要上传方向的创建。OneDrive.exe 和 Dropbox.exe 等后台同步代理还会在它们各自的 AppData\Local\ 子目录中写日志文件,当重命名证据不足时,这又是一种界定活动范围的途径。

不常见但值得知道:有些操作者会把一个 Copy-Item 编排进指向云文件夹的 junction 或 symlink,这会在重命名对之外额外产生 ReparsePointChange 记录。

BITS、原生上传工具和 living-off-the-land 外泄

近几起勒索软件案件中我更频繁看到的模式:操作者使用 bitsadmin.exe 或 PowerShell 的 Start-BitsTransfer 把文件推出去,有时推往持有有效证书、由攻击者控制的云存储。日志会显示:

\ProgramData\Microsoft\Network\Downloader\ 下 BITS 作业状态文件的 FileCreate (对应 qmgr.db、qmgr0.dat、qmgr1.dat)。
对于上传:传输之前立即被暂存到 \Users\\AppData\Local\Microsoft\BITS\ 的源文件。

把它们与 Microsoft-Windows-Bits-Client%4Operational.evtx 中事件 ID 59(作业创建)、60(作业已传输)、61(作业完成)关联起来 — BITS 外泄的 EVTX 关联是可用的最干净的关联之一。

rclone.exe 和 MEGAsync.exe 也是类似情况。它们在应用目录和日志文件中产生可预测的文件创建签名;查看 \Users\\AppData\Roaming\rclone\ 以获取列出目标的配置。

真正经得起考验的启发式

在足够多的案件之后,真正能稳定标记真实外泄的启发式:

create 爆发。 T 秒内一个目录中超过 N 个 FileCreate 事件。按基线调整;桌面主机的起点是 N=50, T=60。

爆发后归档。 在 create 爆发后的几分钟内,出现一个带 .zip、.7z、.rar、.tar.gz、.tar.zst 或 .iso 扩展名的单一 FileCreate,后续 DataExtend 持续累计到数 MB。归档大小大致匹配暂存文件累计大小。

跨目录边界的大规模重命名。 新父路径与旧父路径结构上不同的 RenameNewName 记录 — Documents\ 到 OneDrive\,Desktop\ 到 Users\Public\,Downloads\ 到 \AppData\Local\Microsoft\BITS\。在 MFT 解析的完整路径上很容易用正则表达式表达。

非工作时间爆发。 上述任何一项发生在用户正常工作时间之外。用 Security.evtx 的 4624 登录事件作为实际会话边界的相互参照。

归档后的删除清扫。 归档关闭后,在暂存目录上一次 FileDelete 集群。这是用户在试图善后。集群形态 — 数秒内大量文件被删除,且都共享一个父目录 — 在开发/构建流程之外极不常见。

本页的解析器直接公开了时间窗和按 reason 过滤,使爆发检测和重命名聚类各自只需一次点击。要做非工作时间分析,导出为 CSV 并按一天中的小时数透视。

`$UsnJrnl` 中看不到的内容

一些真实的外泄技术不会产生有用的 USN 信号:

通过浏览器 POST、从变量调用的 Invoke-WebRequest -InFile,或将 Get-Content 管道到 curl 进行的直接从内存上传。没有任何东西落到磁盘上。
读取源端不拥有的网络共享。你主机上的日志中没有任何东西,因为文件不住在那里。
屏幕截图外泄。只有截图文件落到磁盘上;真正的数据通过渲染图像离开。
打印。只在 \Windows\System32\spool\PRINTERS\ 留下活动,这是它自己的取证痕迹。
DNS 或 ICMP 隧道。不触及磁盘;转向网络抓包和 Sysmon 事件 3。

对这些,转向 EVTX、Sysmon 网络连接(事件 3)、浏览器历史、按进程网络字节数的 SRUM、RAM 转储,或 PRINTERS 打印池痕迹。MITRE ATT&CK 的 Exfiltration 战术页列出了每种技术,并备注了它实际在哪里留下痕迹。

一个实战示例

真实案件中你可能为证明外泄而导出的 CSV:

时间	Reasons	路径	备注
19:42:11	FileCreate Close	`\Users\b\Temp\q3\`	新文件夹
19:42:13–14	FileCreate × 84	`\Users\b\Temp\q3\*.xlsx`	爆发
19:44:08	FileCreate Close	`\Users\b\Temp\q3.zip`	归档
19:44:08–22	DataExtend × ~40	`\Users\b\Temp\q3.zip`	增长到 187 MB
19:44:45	RenameNewName Close	`\Users\b\OneDrive\q3.zip`	移到同步
19:45:11	FileDelete × 84	`\Users\b\Temp\q3\*`	清理

这条时间线就是确凿证据。没有日志的话,你需要从注册表、Prefetch、卷影副本和 OneDrive 自己的日志去重建它 — 工作量是五倍,信心是一半。