【実務・中級編】 Windowsイベントログの収集とSIEM連携 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

なぜ「デフォルトのログ」だけでは侵入を防げないのか？

「イベントビューアーを見ています」という運用担当者の言葉ほど、インシデント対応の現場で不安を覚えるものはない。Windows標準のログ収集は、言うなれば「玄関のチャイムが鳴ったか」を記録する程度のものだ。侵入者がいつ、どの窓から入り、どの部屋の鍵を複製したのかを知るためには、もっと高解像度なカメラが必要になる。

攻撃者は今、PowerShellの難読化や、正規の管理ツール（Living off the Land）を悪用して、いかにログを残さずに権限を奪うかを競っている。彼らは「管理者権限さえ奪えば、ログを消せる」ことを知っているからだ。

だからこそ、我々が取り組むべきは「ログの収集」ではなく「攻撃者が足跡を隠せなくなる監視基盤の構築」である。今日は、Microsoftの「Sysmon」を使い、攻撃者の挙動を丸裸にするための実戦的な話をしよう。

—

1. なぜ「Sysmon」が不可欠なのか

標準のWindowsイベントログは、ログイン成功や失敗といった「点」の記録には優れているが、プロセスが生成した子プロセスや、メモリ内で完結する悪意あるスクリプトの実行を追うには力不足だ。

Sysmon（System Monitor）を導入すると、以下の「線」が見えるようになる。

プロセス生成の親子関係: w3wp.exe（IIS）が、なぜか powershell.exe を起動していないか？
ネットワーク接続のプロセス紐付け: どの実行ファイルが、どこの外部IPへデータを送信したのか？
ファイル作成時刻の改ざん: 攻撃者がタイムスタンプを偽装しても、システムがそれを記録しているか？

—

2. 実践：Sysmon設定ファイルの要所

Sysmonの設定ファイルは、闇雲にすべてを取得するのではなく「リスクの高い操作」を重点的に叩く必要がある。以下の設定は、攻撃者が頻用する「プロセスの親子関係の不整合」を検知するためのテンプレートだ。

<!-- Sysmon設定ファイル抜粋: config.xml -->
<Sysmon schemaversion="4.90">
  <EventFiltering>
    <!-- プロセス生成を監視（特にWebサーバーやOfficeアプリからの起動） -->
    <ProcessCreate onmatch="include">
      <ParentImage condition="contains">w3wp.exe</ParentImage>
      <ParentImage condition="contains">php-cgi.exe</ParentImage>
      <CommandLine condition="contains">powershell</CommandLine>
    </ProcessCreate>

    <!-- ネットワーク接続監視: 外部への不審な通信を追跡 -->
    <NetworkConnect onmatch="include">
      <DestinationPort>4444</DestinationPort> <!-- よく使われるバックドアポート -->
      <DestinationPort>8080</DestinationPort>
      <Image condition="end with">cmd.exe</Image>
    </NetworkConnect>
  </EventFiltering>
</Sysmon>

この設定を適用するコマンドは以下の通りだ。
sysmon64.exe -i config.xml

—

3. SIEM連携：データを「価値」に変える

ログを取るだけでは意味がない。SIEM（Splunk, ELK, Azure Sentinel等）に集約し、相関分析を行う必要がある。

例えば、Webサーバーが突然 cmd.exe を実行し、同時に 8080 ポートへアウトバウンド通信を始めたら、それは「Webシェルによるバックドア接続」の可能性が極めて高い。この「相関」を検知するために、ログ転送には Winlogbeat を推奨する。

以下は、Winlogbeat の設定例だ。

# winlogbeat.yml の一部
winlogbeat.event_logs:
  - name: Microsoft-Windows-Sysmon/Operational
    processors:
      - drop_event:
          when:
            # 不要なノイズ（定期的な管理タスクなど）を除外してストレージを節約
            equals:
              winlog.event_id: 255

—

4. エンジニアへの警告：攻撃者の盲点

現場でよくある失敗は、「ログの書き込み権限を攻撃者が奪える状態にしている」ことだ。

もしあなたのサーバーがドメインコントローラーや管理端末なら、ログ転送先（SIEM）の権限は、そのサーバーのローカル管理者権限から「切り離して」管理すること。これが鉄則だ。攻撃者がサーバーを乗っ取った瞬間、彼らが最初に行うのは「イベントログサービスの停止」や「過去ログの抹消」である。

今日からできるアクションプラン

1. Sysmonを導入せよ: OS標準のログだけでは、今の高度な脅威には太刀打ちできない。
2. 「Webサーバーからシェル起動」をアラート化せよ: w3wp.exe や php-cgi.exe が cmd.exe や powershell.exe を叩くことは、正常なWebアプリケーションではまずあり得ない。これ即ち「侵入成功」のサインだ。
3. ログの整合性を守れ: SIEMに送ったログは、Write-Only（追記のみ可能）なストレージへ隔離せよ。

最後に一つだけ覚えておいてほしい。セキュリティとは「100点を目指す」ものではなく、「攻撃者にコストを支払わせる」ものだ。ログを完璧に可視化しておくことは、攻撃者にとって「このターゲットは面倒だ」と思わせる最強の抑止力になる。

自分の守るシステムが今、何をしているのか。その解像度を上げる努力を惜しまないでほしい。それが、プロのエンジニアとしての矜持だ。