設定していますか？Windowsにおけるユーザ操作追跡のためのプロセス監査

【IIJ 2025 TECHアドベントカレンダー 12/19の記事です】

IIJ SOCではIIJ C-SOCサービスをご契約いただいているお客様の環境を監視しており、不審なものを発見した際にはお客様に通知しています。ご契約いただいている監視対象にもよりますが、ユーザの操作に起因する攻撃は多く見受けられるものの1つです。原因となるユーザの操作にはメールに記載されたURLにアクセスしてしまった、添付ファイルを開いてしまった、不審なWebサイトにアクセスして書かれている通りに操作してしまったなど様々なものがあります。

ユーザの操作を調査する際に有効な情報の1つとして、操作ログがあります。初期状態でもある程度のログは記録されていますが、残念ながらOSをインストールした直後の状態のログ設定では十分な情報が記録されず、結果として状況を調査できないことが多くあります。本稿ではWindowsを対象として、実行ファイル（EXEファイル）を実行した記録を残す手法について記載します。なお、本稿の内容はWindows 11 25H2で確認しています。

監査ポリシー

Windowsのログと言えば、基本はイベントログです。Windowsの標準機能であり、初めから多少のログが記録されています。初期設定で記録されるログは主にサインイン及びサインアウトに関するもので、ユーザの操作を調査するための情報としては残念ながら不足しています。

追加の情報を取得するための方法として、監査ポリシーの設定があります。Pro版以上のWindowsにおいては、端末毎に設定する場合は「Windowsツール」の「ローカルセキュリティポリシー」から設定することが可能であり、ドメイン環境の場合はグループポリシーで設定することも可能です。コマンドラインからはauditpol.exeを用いて設定することができ、こちらはHome版のWindowsでも利用可能です。監査ポリシーを設定をすることで、イベントログにWindowsの動作を記録することができます。

ログは可能であれば全部記録されているのが望ましいかも知れませんが、一方で情報量が多くなり過ぎると調査が難しくなったり、ディスク容量を圧迫したりします。ここでは実行ファイルの実行の記録に有効な、「プロセス追跡の監査」をご紹介します。監査ポリシーでこの項目の「成功」を記録するようにすると、イベントログにユーザが実行した実行ファイルが記録されるようになります（図1）。ユーザの操作を追跡できるようになるほか、意図しない場所から実行された実行ファイルの存在も確認することが可能です。

監査ポリシーで設定した項目は、Windowsの「セキュリティ」ログに記録されます。プロセスの新規実行はイベント4688、終了はイベント4689です。

監査ポリシーを設定する箇所は2箇所ありますが、ここでは「監査ポリシー」を設定しています（図2）。

ここではなく、左側ツリーの一番下にある「監査ポリシーの詳細な構成」から設定すると、より細かい監査の設定が可能となります。ただし、監査ポリシーの詳細な構成をローカルセキュリティポリシー又はグループポリシーから1つでも変更すると、定義されていない監査項目が全て「監査なし」となります。その結果、Windowsの標準で取得されるログが記録されなくなり、例えばサインインやサインアウトのログ取得も監査ポリシー内で明示する必要が生じます。Windows 11標準の監査設定を表1に示しますので、詳細な構成を設定する場合の参考にしてください。この設定はコマンドプロンプト（管理者）などで「auditpol.exe /get /category:*」と実行することで取得できます。

表1. Windows 11標準の監査設定

カテゴリ	サブカテゴリ	監査イベント
システム	システムの整合性	成功・失敗
	その他のシステム イベント	成功・失敗
	セキュリティ状態の変更	成功
ログオン/ログオフ	ログオン	成功・失敗
	ログオフ	成功
	アカウント ロックアウト	成功
	特殊なログオン	成功
	ネットワーク ポリシー サーバー	成功・失敗
ポリシーの変更	監査ポリシーの変更	成功
	認証ポリシーの変更	成功
アカウント管理	セキュリティ グループ管理	成功
	ユーザー アカウント管理	成功
上記以外の全て		監査なし

なお、auditpol.exeを用いてプロセス監査の設定を追加した場合は、標準設定は上書きされません。監査ポリシーの詳細な構成を用いて設定をする際は、影響を確認した上で設定するようにしてください。

コマンドライン

先述の方法でプロセスの実行履歴を記録できるようになっていますが、情報としてはまだ不足しています。プロセスの実行時には、実行ファイルに引数を付けて実行することが多くあります。図3はコマンドプロンプトからPowerShellを、起動時に著作権情報を表示せずに実行する「-NoLogo」オプションを付けて実行したものです。タスクマネージャーのプロセスID（PID）は10進数で6932、ログ内に記録されているプロセスIDは16進数で0x1b14となっていることから、同一のものであることが分かります。タスクマネージャーを見ると確かにコマンドラインがありますが、イベントログからはその引数を見ることができません。引数が重要となるプロセスを記録するには、これでは不完全です。

グループポリシーの コンピューターの構成 > 管理用テンプレート > システム > プロセス作成の監査 から、「プロセス作成イベントにコマンドラインを含める」を「有効」にすると、ログ中にコマンドラインを追加することができます（図4）。ドメインに参加していない端末であってもPro版以上のWindowsであればポリシーを設定することは可能であり、Home版であってもレジストリのDWORD値HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabledを1とすることで設定可能です。

この設定をすることで、コマンドラインも記録されるようになります（図5）。

最大ログサイズ

プロセスの履歴に限らず、監査ポリシーで設定したログは「セキュリティ」ログに記録されます。セキュリティログに限らず、イベントログには最大サイズが設定されており、インストールした直後のWindows 11におけるセキュリティログでは20MBとなっています。Windowsではユーザが実行せずともバックグラウンドで様々なプロセスが動作していることから、20MBはすぐに越えてしまいます。最大サイズを超過すると古いログ項目から順に消去されてしまうため、せっかくログを取得する設定をしても、調査できなくなってしまいます。そのため、監査ポリシーを設定した際には、最大サイズも変更しておいてください。

最大サイズはイベントビューアーでそのログを右クリックし、「プロパティ」を開くことで設定できます（図6）。ここにはKB単位の容量を設定します。Windows Server 2008のドキュメントには推奨の最大値が公開されていましたが、現在のWindowsドキュメントでは言及されていません。設定後はしばらく様子を見て、ログサイズの変化を確認してみてください。

最大サイズはイベントビューアーに加えてwevtutilコマンドで設定できるほか、Pro版以上のWindowsやドメイン環境においてはグループポリシーで最大サイズの設定を配布することが可能です。また最大ログサイズを増加させる他に、Syslogなどのプロトコルを用いて、ログをログサーバなどに転送することでも最大サイズ問題を回避できます。攻撃ツールなどによっては端末上のイベントログを消去することがありますので、リアルタイムにログを転送した方が情報の保全の観点では安全かもしれません。

Sysmon

ここまではWindowsの標準機能を用いたプロセス実行の記録でしたが、ここでツールを1つご紹介します。Sysinternalsと呼ばれるツール群の1つである、Sysmonです。SysmonはWindowsの様々な動作を監視し、記録したり一部の不審な挙動を止めたりすることができるツールです。

Sysmonをダウンロードし、ZIPファイルを展開します。その後、コマンドプロンプト（管理者）から「Sysmon64.exe -i」を実行することでインストールすることが可能です。ARM版Windowsの場合は「Sysmon64a.exe -i」を実行してください。初めて実行した際には使用許諾契約書が表示され、同意するとインストールされます（図7）。

このコマンドラインを実行するとSysmonの実行ファイルがC:\Windowsにコピーされますので、実行ファイルはどこに置いても問題ありませんし、インストール後は削除しても構いません。SysmonのZIPファイルには32ビットバイナリのSysmon.exeも含まれますが、64ビット版Windowsでこれを実行しても、64ビット版のSysmonがインストールされます。この場合、インストールされるファイルはSysmon64.exeと同一ですが、コピー先のファイル名はSysmon.exeとなります。

Sysmonのログはイベントビューアーの アプリケーションとサービスログ > Windows > Sysmon > Operational から閲覧することが可能です。SysmonのWebページには本稿執筆時点で29番までのイベント（とエラー）が掲載されていますが、初期設定ではほとんどは記録されません。しかし、プロセスの実行（イベント1）と終了（イベント5）は初期設定で記録されます（図8）。Sysmonのログにはコマンドラインが標準で記録されるほか、ファイルのハッシュ値やバージョンなどのメタデータも保存されます。調査の観点ではこちらの方が分かりやすいかもしれません。

Sysmonのログは、64MBが標準の最大サイズとなっています。こちらも比較的早く上限に達してしまいますので、最大サイズは調整して使用するようにしてください。

Sysmonは個別にZIPファイルをダウンロードしてインストールすることが必要となることから、特に大規模なエンタープライズ環境では導入が難しいかもしれません。しかし、2026年にはWindowsに標準で含める計画があることが11月に公表されており、来年の今頃にはもう少し導入が簡単になっているかもしれません。

攻撃実行のログ例

図9・10は2024年中盤から2025年にかけて多く話題となった攻撃において使用されたコマンドラインを実行してみたものです。具体的なURLは隠していますが、このコマンドラインはWindowsに含まれるmshta.exeを使用して、インターネット上からコンテンツを取得するものです。攻撃で使用されるファイルの取得元となったURLが分かることから、その後の動作や影響を調査しやすくなります。また、攻撃の過程で別の実行ファイルがダウンロードされるなどした場合は、その実行ファイルを見つけやすくなります。

おわりに

本稿ではプロセスの実行履歴をログに残す方法をご説明しました。本稿に記載している内容は特に新しいものでもなく、特にセキュリティ関係の皆様は見飽きた内容かもしれません。しかし、設定がされておらず、詳細を追跡できない場面があるのも事実です。ご自身の環境やお客様の環境をご確認いただき、必要なようであれば設定するようご提案いただければと思います。インシデントは起きないことが最善ですが、起きてしまった場合にもできるだけ詳細な調査ができる状況を作っておくことも、1つのセキュリティ対策です。