検証環境：Windows 11 Pro 25H2
サンプルとして実行したコマンドが、 SRUM に記録されるのか？というテストを生成AI（Gemini）を利用しつつ確認していきます。
生成AIによる文ここから---
Diagnostic Policy Service (DPS) の概要と SRUM との関係
Windows OSにおいて、システムの診断やトラブルシューティングを司る重要なサービスが Diagnostic Policy Service (DPS) です。フォレンジック調査、特に SRUM (System Resource Usage Monitor) を解析する上では、このサービスの挙動を理解することが不可欠です。
1. DPS とは何か？
Diagnostic Policy Service (DPS) は、Windows コンポーネントの不具合を検出し、トラブルシューティングや解決を可能にするためのサービスです。
-
サービス名:
DPS -
表示名:
Diagnostic Policy Service -
実行プロセス:
svchost.exe -k LocalServiceNoNetwork -p -
関連DLL:
C:\Windows\System32\dps.dll
主な役割は、システムのパフォーマンス低下、ネットワーク接続の問題、デバイスの不具合などのイベントを監視し、診断データを収集することにあります。
2. SRUM との密接な関係
DFIR（デジタルフォレンジック）の観点で最も重要なのは、DPS が SRUM データの「書き込み」を制御しているという点です。
SRUM はアプリケーションの実行履歴やネットワーク使用量を記録しますが、そのデータはリアルタイムでディスク上の SRUDB.dat に書き込まれるわけではありません。
データのフロー
-
収集: カーネルや各プロバイダーから送られるリソース使用データが、DPS によってメモリ上に蓄積されます。
-
保持: システム負荷を抑えるため、データは一定期間（通常 30分〜60分）メモリ内に留まります。
-
書き込み（フラッシュ）: 特定のトリガー（一定時間の経過、シャットダウン、サービスの停止など）が発生した際に、DPS が
C:\Windows\System32\sru\SRUDB.datへデータを書き出します。
3. フォレンジック検証における重要性
Windows 11 25H2 などの新しい環境で SRUM の挙動を検証する場合、DPS の以下の特性に注意する必要があります。
データの即時性（アーティファクトの欠落防止）
検証作業中に「特定のアプリを動かした直後に SRUDB.dat をコピーしても、記録が残っていない」という事象がよく起こります。これは DPS がまだデータをメモリに保持しているためです。 検証時に最新のデータを確定させるには、DPS サービスを明示的に停止させる（net stop dps） ことで、メモリ上のデータをディスクへ強制的にフラッシュさせる手法が有効です。
実行の痕跡（SrumDiagnostics タスク）
DPS はタスクスケジューラとも連携しており、\Microsoft\Windows\System\SrumDiagnostics というタスクを通じて定期的なクリーンアップや診断を実行します。このタスクの実行履歴も、システムが正常にリソースを監視していたかの証跡となります。
---生成AIここまで
Geminiの解説では、30分～60分とありますが、一般的におおむね60分間隔になっているのではないでしょうか。30分というケースがあるのかはちょっと分かりません。
※NetworkUsageについては、約 4分間隔で記録されるパータンはあるようですね。
まず、SRUMに現時点でのメモリ内容を反映させるため、管理者権限のCMDから下記コマンドを実行します。
net stop dps
net start dps
上記のdpsサービスの再起動によりメモリ上のデータがSRUMに書き込まれるので、以降で実行したコマンドはメモリ内（後レジストリもなんですかね）に記録されていく事になります。
ここでは、SRUM に記録が残りにくいコマンドをGeminiに列挙するように指示し、Geminiが候補としたコマンドを実行していきます。
ほかにも色々なコマンドが提案されていましたが、すべて試すのも大変なのでまずは簡単なコマンド実行から確認
whoami
tasklist
net user
quser
reg save HKLM\SAM sam.hiv
hostname
ipconfig
nslookup google.com
curl -I https://www.google.com
ping -n 1 192.168.1.1
wmic process get caption
コマンド実行直後に、dps サービスを再起動すると通信サイズの集計などが正しく完了してない？ことがあるようなので、少し待ってから再度dpsサービスを再起動した方がよいかもしれません。
※特に一定サイズ以上のデータ通信を行ったりした場合数分、例えば4分程度待ってからのほうが期待した値になるかもしれません。
サービスを再起動した後、NirSoftのAppResourcesUsageViewとNetworkUsageViewを使って確認していきます。（正統派？であれば SrumECmd かもしれませんが）
※再起動した日時のタイムスタンプを持つレコード内にコマンドあるかを検索
| NO | コマンド | AppResourcesUsageView | NetworkUsageView |
| 1 | whoami | なし | なし |
| 2 | tasklist | なし | なし |
| 3 | net user | なし | なし |
| 4 | quser | なし | なし |
| 5 | reg save HKLM\SAM sam.hiv | なし | なし |
| 6 | hostname | なし | なし |
| 7 | ipconfig | なし | なし |
| 8 | nslookup google.com | なし | 記録あり |
| 9 | curl -I https://www.google.com | なし | 記録あり |
| 10 | ping -n 1 192.168.1.1 | なし | なし |
| 11 | wmic process get caption | なし | なし |
通信を発生させているnslookupとcurlはNetworkUsageに記録が残りますが、pingは ICMP ゆえか残らない。
なぜ実行したコマンドがAppResourcesUsageに記録が残らないのか？というあたりは、Gemini に質問すると色々な理由を説明してくれます。
なお単純に起動時間が短いと残らないということでもなく、例えばメモ帳（notepad.exe）を起動後にすぐ終了した場合においても、手元では記録が残りました。
以下生成AIによる説明文ここから---
検証結果の分析：25H2 における SRUM の「視界」
1. なぜ AppResourcesUsageView はすべて「なし」なのか
リストにある 11 個のコマンドすべてで AppResourcesUsageView（アプリケーション・リソース使用量）が記録されなかったのは、主に以下の 2 点が原因と考えられます。
-
短命プロセス (Short-lived Processes) の壁:
whoamiやhostname、net userなどのコマンドは、実行から終了までが数ミリ秒〜数十ミリ秒と極めて短時間です。SRUM は一定のサンプリング間隔でデータを収集しているため、その「網の目」をすり抜けてしまった可能性が高いです。 -
リソース消費の閾値: SRUM はシステム負荷を抑えるため、CPU 使用時間やディスク I/O が極めて微量な活動は「記録するに値しない」と判断してドロップする傾向があります。
2. NetworkUsageView の「明暗」を分けたもの
ネットワークに関しては、非常に示唆に富む結果が出ています。
-
nslookup と curl が記録された理由: これらは TCP または UDP 通信を発生させます。SRUM のネットワーク・プロバイダーは、プロセスの実行時間そのものよりも、**「発生した通信量」**に対して敏感です。たとえ
curl -I（ヘッダーのみ取得）のような少量の通信でも、ネットワークインターフェースを通じた明確な送受信としてカウントされたため、記録に残ったと考えられます。 -
ping が「なし」だった理由:
ping（ICMP）は、SRUM のネットワークテーブルにおいて記録対象外となるか、あるいはping -n 1という極少量のパケットでは記録の閾値（通常は KB 単位の丸め処理など）に達しなかった可能性があります。
3. wmic (WMI) の隠蔽効果
11番の wmic が「なし」だった点は重要です。 前述の通り、WMI 経由の操作は wmiprvse.exe が代行するため、もし記録が残るとしても wmic.exe ではなく wmiprvse.exe 側にリソースが計上されます。今回の単発実行では、代行者側でも閾値を越えなかったようです。
---生成AI ここまで
この後、Geminiからはwhoamiを 100回とか500回実行したらどうなるかを、このスクリプトでテストしてみなさい！といった提案を行ってきたので 100回実行するスクリプトを実行してみましたが、100回でも500回でも記録なしでした。
そして、終わりなく色々提案が続きましたが、EDRなりSysmonなりでちゃんとログを取得しておきましょうね、とBlog記事には書いておけ！ということでした。
