SRUMday Funday!
本周由David Cowen提出的Sunday Funday挑战聚焦于SRUM取证。挑战内容如下：
挑战： 鉴于我们中许多人依赖SRUM实现各种用途，现在需要对许多人引用的计数器进行验证。本次挑战将测试并验证以下SRUM收集的指标，记录它们是否准确捕获数据或存在偏差。
在Windows 11或Windows 10上测试和验证的用例（必须记录所用系统）：
- 使用复制粘贴在两个驱动器之间复制数据（查找磁盘读写活动）
- 将数据上传到自选的在线服务（查找进程网络流量）
- 擦除文件（查找磁盘读写活动）
每日博客 #716：Sunday Funday 2025年1月12日
那么让我们开始吧！
本次测试我将使用Windows 11 24H2，数据生成时间以AEDT（UTC+11）为准。输出中的时间以UTC显示。
数据生成
在两个驱动器之间使用复制粘贴进行复制
为此测试，我创建了一个虚拟磁盘和一个充满垃圾数据的大文件。磁盘各为2GB，文件大小为750MB（磁盘上为786,432,000字节）。
在21:11，我复制了该文件并将其粘贴到已挂载的vhdx中。
将数据上传到在线服务器
在21:15，我使用Google Chrome将相同的750MB文件上传到Google Drive。为确保不使用资源管理器，我通过Chrome在drive.google.com内的“新建–>文件上传”部分完成。大约在21:25，我意外终止了上传，因为文件被擦除…所以我不期望这个数字接近准确，但它大部分已完成。
在21:17，我还通过PowerShell窗口中的复制命令将相同文件复制到我的OneDrive。文件大约在21:30完成上传到OneDrive。
擦除文件
最后，我在21:25左右擦除了传输文件，因为我有它的几个副本！
我还在21:32安装Eraser并擦除了虚拟磁盘中的文件。我选择直接右键单击文件并选择“擦除”（不确定这是否会改变任何结果）。
分析
对于分析，我选择使用KAPE收集数据，并希望使用SRUMDUMP的新分支手动处理。此版本与当前版本相同，但它使用Dissect的ESE模块而不是libese。
使用esentutl修复后，我发现当前两个版本的Srumdump（libese和dissect）都不喜欢该数据库，但srumecmd工作正常！我尚未研究它们不喜欢的原因（但有趣的是，新的.net v9 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中的时间戳让我有点困惑，因为我不知道为什么有几个不同的时间戳，需要回顾我的笔记。其他表按小时记录。）
总结
好的，我们学到了什么
- 出于某种原因，srumdump不喜欢我的数据库，但srumecmd工作正常。
- 使用资源管理器跨卷传输文件被跟踪为ForegroundBytesWritten，但不跟踪读取字节。
- 使用Chrome或OneDrive上传文件在NetworkUsages中记录，BytesSent出现峰值。这里我并没有真正使用计算机做其他事情，因此它确实很突出。
- 使用Sdelete擦除文件在AppTimelineProvider中跟踪，但不在其他表中。此表不提供大小。
- Eraser出现在AppTimelineProvider和AppResourceUsageInfo中，但与数据擦除相关的信息不多，这很奇怪。仅凭此很难证明某些内容被擦除。
所以有些内容一致，有些则不一致。听起来与我的经验一致…