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

WindowsイベントログとSysmonの深層：攻撃者の「隠れ場所」を剥ぎ取るインフラ監視アーキテクチャ

こんにちは。数々のインシデントレスポンスやレッドチーム演習の現場を渡り歩いてきた中で、いつも痛感させられる事実がある。それは、「侵入を防ぎ切ることは不可能に近いが、侵入後の攻撃者の足跡を完全に消し去ることは、もっと難しい」という点だ。

多くの組織がいまだに、デフォルト設定のWindowsイベントログをダラダラと収集し、「うちはSIEMに入れているから大丈夫だ」と安心している。しかし、攻撃者はそんな甘い環境を熟知している。彼らは「Living off the Land（LolBins）」を駆使し、正規の管理ツールに偽装してメモリ空間を揺らし、ネットワークの暗号化パケットの隙間を縫って横方向への移動（Lateral Movement）を行う。

今回は、サイバー犯罪グループや国家支援型ハッカーが最も嫌う、「Windowsイベントログの厳格なフィルタリング」と「Sysmon（System Monitor）によるOS深層の可視化」について、現場の泥臭い知見とアーキテクチャ設計の観点から徹底的に解説する。

—

1. デフォルトログの限界と、攻撃者が悪用する「死角」

OS標準のセキュリティイベントログ（Security.evtx）は、確かに広範な監査機能を持っている。しかし、そのまのでは「ノイズの海」であり、同時に「致命的な情報の欠落」を抱えている。

例えば、プロセス生成を追うために ID 4688（新しいプロセスが作成されました）を有効にしている企業は多いだろう。だが、デフォルトではコマンドライン引数が記録されない。攻撃者が powershell.exe -enc <Base64Payload> のような難読化スクリプトを実行しても、標準の 4688 では単に「PowerShellが動いた」という事実しか見えず、肝心のペイロードの断片すら掴めないのだ。

さらに、攻撃者は次のような手法でログの目を盗むか、無効化する。

ログのクリアとサービス停止: wevtutil を用いたイベントログの消去、あるいは監査サービスの強制停止。
プロセスのインジェクション: 正規のプロセス（例: explorer.exe や svchost.exe）のメモリ空間にシェルコードを直接流し込み、新規プロセスを生成せずに悪意あるコードを実行する（プロセス・hollowings / Process Injection）。

これに対抗するためには、OSカーネルに近いレイヤで何が起きているかをフックし、より詳細な文脈（Context）を収集する仕組みが不可欠となる。それが Sysmon の導入だ。

—

2. Sysmonを用いたプロセス生成とネットワークの深層可視化

Sysmonは、Sysinternalsが提供するWindowsのシステムサービスおよびデバイスドライバであり、カーネルモードで動作してプロセスの作成、ネットワーク接続、ファイル変更などを詳細にキャプチャする。

しかし、Sysmonをデフォルト設定のまま導入してはならない。すべてのイベントを吸い上げれば、SIEMのライセンス費用を高騰させるだけでなく、重要なアラートがノイズに埋もれてしまう。攻撃者のTTPs（Tactics, Techniques, and Procedures）に焦点を当てた、厳選された設定（Configuration）が必要だ。

以下に、実戦で耐えうるSysmon設定のキモとなるXML設定のサンプルを示す。

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <!-- 
      ルールロジック: 原則として「除外（exclude）」ベースでノイズを削り、
      攻撃者が好んで使う手法を「包含（include）」で確実に捕らえる。
    -->
    
    <!-- イベントID 1: プロセス作成 (Process Creation) -->
    <ProcessCreate onmatch="include">
      <!-- 攻撃によく使われるLiving off the Land Binaries (LolBins) の監視 -->
      <Image condition="is">C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Image>
      <Image condition="is">C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe</Image>
      <Image condition="is">C:\Windows\System32\cmd.exe</Image>
      <Image condition="is">C:\Windows\System32\wbem\wmic.exe</Image>
      <Image condition="is">C:\Windows\System32\mshta.exe</Image>
      <Image condition="is">C:\Windows\System32\certutil.exe</Image>
      <Image condition="is">C:\Windows\System32\rundll32.exe</Image>
    </ProcessCreate>

    <!-- イベントID 3: ネットワーク接続 (Network Connection) -->
    <NetworkConnect onmatch="exclude">
      <!-- 既知の安全なブラウザや頻繁に出るドメインのノイズをここで除外する -->
      <Image condition="is">C:\Program Files\Google\Chrome\Application\chrome.exe</Image>
      <DestinationPort condition="is">443</DestinationPort> <!-- 実際の本番環境ではHTTPSを全て除外せず、ドメインや宛先IPで精査する -->
    </NetworkConnect>

    <!-- イベントID 8: RemoteThread作成 (DLLインジェクション検知の要) -->
    <CreateRemoteThread onmatch="include">
      <!-- 別プロセスへのスレッドインジェクションはマルウェアの常套手段。すべてキャプチャする -->
      <SourceImage condition="contains">powershell.exe</SourceImage>
      <SourceImage condition="contains">cmd.exe</SourceImage>
      <TargetImage condition="contains">lsass.exe</TargetImage> <!-- LSASSへのアクセスは絶対に逃がさない -->
    </CreateRemoteThread>

  </EventFiltering>
</Sysmon>

この設定において、特に注目すべきは Event ID 8 (CreateRemoteThread) および Event ID 10 (ProcessAccess) の監視だ。特にメモリ上の資格情報を窃取するツール（Mimikatzなど）は、必ず lsass.exe のメモリ空間に対してハンドルを開くか、リモートスレッドを作成する。ここを捉えることが、初期侵入後の致命的なクレデンシャル・ダンプを防ぐ防衛ラインとなる。

—

3. WindowsイベントログのフィルタリングとSIEM転送のベストプラクティス

集めたログをすべてSIEMにリアルタイム転送するのは、ネットワーク帯域とコストの無駄遣いだ。現場のセキュリティアーキテクトとしては、「エンドポイント側での前処理（Filtering at the Edge）」を徹底し、意味のあるシグナルだけを上流に流すアーキテクチャを構築する必要がある。

Windows標準の wevtutil や、グループポリシー（GPO）、あるいは「Advanced Audit Policy Configuration」を用いて、不要なイベント（例：大量の成功したファイルアクセスなど）を完全にミュートする。

監査ポリシーの推奨設定アプローチ

1. プロセスツリーの追跡: Object Access や Detailed Tracking の中で、プロセス生成に関連するものだけを厳選。
2. アカウント管理: 特権アカウント（Domain AdminsやLocal Administrators）のメンバ変更、およびログオン失敗のしきい値監視（ブルートフォース検知）。
3. PowerShell Script Block Logging: Event ID 4104 を有効化する。これにより、難読化されたPowerShellスクリプトがメモリ上で展開された瞬間のコードブロック全体が記録される。攻撃者がディスク上にファイルを残さない「ファイルレス攻撃」を仕掛けても、このログが命綱となる。

—

4. 現場のセキュリティエンジニアへの警鐘

ログを収集し、SIEMのダッシュボードに綺麗なグラフを表示させただけでは、セキュリティは1ミリも向上しない。

攻撃者は、ログ転送エージェント（Winlogbeatや各種EDRエージェント）のプロセスを停止させたり、レジストリを書き換えて監査をバイパスする技術を洗練させている。だからこそ、以下のメタ監視（監視の監視）を忘れてはならない。

エージェントの死活監視: Sysmonサービス（Sysmon64）や転送エージェントが突然停止した場合、それを即座に検知してSOC（Security Operations Center）へアラートするメカニズムを必ず用意する。
ログの整合性担保: 収集したログがローカルで改ざんされていないか、WORM（Write Once, Read Many）特性を持つストレージや、リモートのセキュアなSIEMへ即時転送されているかを確認する。

インシデントは「起きるか起きないか」ではなく、「いつ見つかるか」の問題だ。攻撃者がシステム内部で潜伏する「Dwell Time（滞留時間）」をいかに短縮するか。その鍵を握るのは、今日あなたが設定する、この静かで堅牢なログ収集のアーキテクチャに他ならない。