周日趣味挑战：SRUM取证！

本周由David Cowen提出的“周日趣味”挑战主题是SRUM取证。挑战内容如下：

挑战： 鉴于我们许多人都依赖SRUM来完成各种不同的任务，现在正是时候对大家频繁引用的计数器进行一些验证。本次挑战要求你测试并验证以下SRUM收集的指标，并记录它们是否准确捕获了数据，或者是否存在偏差。

需要在Windows 11或Windows 10上进行测试和验证的用例（必须注明所使用的系统）：

1. 在两个驱动器之间使用复制粘贴方式拷贝数据（查找磁盘读写活动）
2. 将数据上传到你选择的一个在线服务（查找进程网络流量）
3. 擦除文件（查找磁盘读写活动）

每日博客 #716: 周日趣味 2025年1月12日

那么，我们开始吧！

本次测试我将使用Windows 11 24H2版本，我生成数据的时间是AEDT（UTC+11）。输出结果中的时间是UTC时间。

数据生成

在两个驱动器之间使用复制粘贴方式拷贝数据

为了这项测试，我创建了一个虚拟磁盘和一个充满垃圾数据的大文件。每个磁盘大小为2GB，文件大小为750MB（磁盘上为786,432,000字节）。

在21:11，我复制了文件并将其粘贴到已挂载的vhdx中。

将数据上传到在线服务器

在21:15，我使用谷歌Chrome浏览器将同一个750MB文件上传到谷歌云端硬盘。为了确保不使用资源管理器，我特意通过Chrome浏览器，在drive.google.com网站内的“新建 –> 文件上传”部分完成操作。我在21:25左右意外中止了那次上传，因为我擦除了文件……所以我预计这个数字不会太准确，不过它大部分都上传完成了。

在21:17，我还通过在PowerShell窗口中执行复制命令，将同一文件复制到我的OneDrive中。文件在21:30左右完成上传到OneDrive。

擦除文件

最后，我在21:25左右擦除了我的传输文件，因为我已经有了它的几个副本！

注意：截图显示了一个名为TransferFile.txt的文件，在21:25被删除。

我还安装了Eraser，并在21:32擦除了虚拟磁盘中的文件。我选择直接在文件上右键单击并选择“擦除”（不确定这是否会改变任何结果）。

注意：截图显示了使用Eraser右键菜单擦除虚拟磁盘中的TransferFile.txt。

分析

对于分析，我选择使用KAPE收集数据，并希望使用一个新分叉的SRUMDUMP工具手动处理。这个版本与当前版本相同，但它使用Dissect的ESE模块而非libese。

在用esentutl修复后，我发现当前两个版本的Srumdump（libese和dissect）都不喜欢这个数据库，但是srumecmd运行得很好！我还没有研究它们为什么不喜欢它（有趣的是，新的.net v9 srumecmd也不喜欢它）。

注意：截图显示了esentutl修复过程、srumdump错误信息以及srumecmd成功运行。

对于分析，我决定将数据上传到Azure Data Explorer。首先，它是免费的；其次，它对于快速数据分析来说非常出色。

我将srumecmd的输出上传到了不同的表中；只包括AppResourceUseInfo、AppTimelineProvider、NetworkConnections和NetworkUsages。

数据复制

对于数据复制，我获取了Explorer.exe进程和AppResourceUseInfo表（我没有意识到数据摄取将其中一个字段当成了时间戳而不是长整型，所以必须转换它）。在这里我们可以看到，Explorer进程写入了大约750MB（字节数几乎完全正确），这与活动相符。有趣的是，它没有跟踪读取的字节数？

数据传输

ADX对于这类分析非常出色，因为它具有简单的绘图功能。不幸的是，我不太经常使用这台电脑进行更精细的绘图，但当你筛选Chrome.exe的BytesSent时，可以很容易地看到那个峰值。活动本身记录的时间戳是2025-01-13T10:43:00Z。

OneDrive显示了类似的活动，在2025-01-13T10:43:00Z记录了两个事件，BytesSent列中一个为144字节，另一个为883419280字节。这个发送字节数比文件大，但考虑到OneDrive添加的任何开销，这是可以预料的。

我还在学习如何充分利用ADX，但你可以做一些很酷的事情，比如将传输总结为离散的量，并查看网络流量中是否有峰值。

磁盘擦除

AppTimelineProvider显示了sdelete和eraser都在运行。我猜Eraser仍在后台运行，所以这并不能真正帮助我们显示它被用来擦除了某些东西。

在底层数据中，Sdelete被引用了两次；我想我可能运行了两次（但只擦除了一次文件）

接下来我检查了AppResourceUsageInfo表，有趣的是，sdelete没有出现。Eraser出现了，但读取字节数为0，写入字节数绝对不是750MB。这有点令人困惑。

（AppTimelineProvider中的时间戳让我有点困惑，因为我不知道为什么有几个不同的时间戳，需要回去查看我的笔记。其他表是按小时记录的。）

总结

好吧，我们学到了什么？

1. 出于某种原因，srumdump不喜欢我的数据库，但srumecmd运行良好。
2. 使用资源管理器在不同卷之间传输文件会被跟踪为ForegroundBytesWritten，但不会跟踪读取字节数。
3. 使用Chrome或OneDrive上传文件会被记录在NetworkUsages中，BytesSent会有一个峰值。当然，我在这里没有怎么使用电脑做其他事情，所以它确实很突出。
4. 使用Sdelete擦除文件会在AppTimelineProvider中被跟踪，但不会出现在其他表中。这个表不提供大小信息。
5. Eraser出现在AppTimelineProvider和AppResourceUsageInfo中，但它没有显示太多与数据擦除相关的内容，这很奇怪。仅凭这些数据很难证明有东西被擦除了。

所以，有些东西是一致的，有些则不然。听起来与我的经验一致……