ChatGPTにWindows Event Logの解析を"雑に"依頼してみた

Last updated at 2025-10-19Posted at 2025-10-19

本稿に記載した内容は筆者個人の見解であり、所属組織の公式見解ではありません。
本記事における検証は検証環境のサーバーのログを利用しています。本番環境のログを生成 AI にアップロードする場合はセキュリティ懸念を考慮して自己責任でお願いします。

背景

インシデントの調査をしていると、「 AI に丸投げしたいな」と思うことがしばしばあります。生成 AI が評価され始めた 2022 年後半頃にも一度試してみましたが、トークン数、確率モデルの性能などの制約によってあまりいい精度は出ていなかった印象です。現在（2025年10月時点）では、生成 AI のモデルも進化し、 ChatGPT にはプロジェクト機能も実装されました。現在時点では Windows Event Log の解析を雑にお願いした際に、期待した結果が得られるのかを試してみたいと思いました。

概要

2025 年時点での ChatGPT にて Windows Event Log の解析というタスクにおいてどのような結果が得られるのかを試し、 ChatGPT で得られた解析結果の評価をしました。結果としてはChatGPT による Windows Event Log（特に RDP 関連イベント）の解析は実用レベルに近づいていると感じました。しかし、どうしてもユーザーによる詳細な調査が必要になるため、最初のトリアージなどに素早く全体感をつかみ、調査の手がかりとして利用するのがよさそうです。

前提

タスク : Windows Event Log から RDP 接続に関する調査をする
AI サービス : ChatGPT
利用モデル : ChatGPT5 Thinking
補助ツール : EvtxECmd ( Eric Zimmerman's Tools )
データの与え方 : CSVファイルをChatGPTのプロジェクトファイルにアップロード

検証

それでは早速 Windows Event Log の解析を雑にお願いしてみます。

プロンプト①

eventlogのファイルをアップロードしました。
RDPの接続が行われたのかを調査してください。

回答（一部）①

解析が終わりました — 結論を先に書きます。

結論（要約）

RDP の接続（ネットワーク接続の確立）は確認できました。
Windows の Terminal Services / RemoteDesktopServices のイベント（EventId 1149 や Microsoft-Windows-RemoteDesktopServices-RdpCoreTS 系のイベント）により、RDP のネットワーク接続が複数回記録されています。

EventId 1149 のイベントのうち、代表的なものは以下です（CSV にも保存済み）:

  * **2025-09-23 05:27:41** — User=`Administrator` — SourceIP=`192.168.150.20` — Computer=`Velociraptor-Server01`
  * **2025-09-23 05:31:25** — User=`Administrator` — SourceIP=`192.168.150.20` — Computer=`Velociraptor-Server01`
  * **2025-09-23 05:42:50** — User=`Administrator` — SourceIP=`192.168.150.20` — Computer=`Velociraptor-Server01`
  * **2025-09-23 08:02:31** — User=`Administrator` — SourceIP=`192.168.150.20` — Computer=`Velociraptor-Server01`
  * **2025-09-23 08:10:10** — User=`Administrator` — SourceIP=`192.168.150.20` — Computer=`Velociraptor-Server01`
  * **2025-10-17 02:06:43** — User=`Administrator` — SourceIP=`192.168.150.3`  — Computer=`Velociraptor-Server01`

（上の時刻・ユーザー・IP は、該当イベントの Payload 中の Param1(ユーザー) / Param3(送信元IP) を抽出したものです。）

プロンプト②

①の結果としてはEvent IDが1149,4624でChannelがSecurityのものだけフィルターをしてくれました。しかし、 Windows Event Log からRDPの接続履歴を正しく調査するには接続パターン（接続→ログオン→再接続/切断→ログオフ）全てを評価し、つなぎ合わせる必要があります。そこで、普段私がRDPの調査をする際に利用する Timeline Explorer のフィルターを与えてみました。
※プロンプト①の続きとしてプロンプト②を入力しています。

TimelineExplorerでのフィルターですが、以下のフィルターをよく使用して調査をします。
これを加味した調査結果を教えてください。
```
[Event Id] In (21, 22, 23, 24, 25, 39, 40, 1149, 4624, 4625, 4634, 4647, 4778, 4779, 9009) 
And [Channel] In ('Microsoft-Windows-TerminalServices-LocalSessionManager/Operational',
'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational',
'Security',
'System')
```

回答（一部）②

結論（要点）

RDP 接続（1149: RDP-Tcp 接続確立）は発生しています。
1149 の直後〜近接時間帯に 4624（ログオン成功） が同一 Source IP・同一アカウントで確認できるセッションが複数あり、実際に認証成功してリモート対話セッションに入っている可能性が高いです（LogonType はイベントによって記録揺れがあり、10 が無いものもあるため、IP/時刻/アカウント相関で判定）。
一部のセッションでは 4778（再接続）/4779（切断）/4634（ログオフ）/4647（ユーザー主導ログオフ） の存在も確認され、RDP セッションのライフサイクル（接続→ログオン→再接続/切断→ログオフ）が整合しています。
4625（ログオン失敗）がある時間帯も限定的に見られますが、同一 IP からの連続失敗→成功のパターンは今のところ顕著ではなく、ブルートフォース痕跡は強くありません（※回数・間隔の閾値次第で見方は変わります）。

解析ハイライト（相関の見方）

以下は、Computer + SourceIP + Account 単位で 20 分ギャップごとに区切った「セッション要約」の読み方です。

CONNECTED（1149）→ LOGON_SUCCESS（4624）→ LOGOFF/DISCONNECT（4634/4647/4779）
この並びが揃っていれば、RDP ネットワーク接続が成立し、実ユーザーの対話ログオンが成功し、正常/異常に関わらずセッション終了まで一貫性があります。
CONNECTED のみで 4624 が無い場合：接続試行のみ／認証未達／ネットワーク層のみの到達の可能性。直前直後に 4625（失敗）があるかを要確認。
4625 多発：間隔や回数によっては淺いブルートフォース／誤打鍵の可能性。同一 IP・同一アカウントで短時間に連発していないか要確認。

具体的な観測（代表例）

（※実データは上記 CSV で網羅しています。ここでは代表的なパターンを例示します）

Session A（例）
- 1149 RDP 接続確立：User=Administrator From=192.168.150.20
- 近接して 4624 ログオン成功：User=Administrator IpAddress=192.168.150.20（LogonType は記録揺れあり）
- その後 4779（切断）または 4634/4647（ログオフ）が同一 Account で発生
  → 接続〜ログオン〜切断/ログオフ までの一連の流れが確認でき、実使用の RDP セッションである蓋然性が高い。
Session B（例）
- 1149 のみで 4624 が見当たらない
  → 接続試行のみ（認証未達／キャンセル等）の可能性。前後に 4625（失敗）が付随するかを追跡。

21/22/23/24/25/39/40/9009 の扱い

これらは TerminalServices-LocalSessionManager（LSM） や System の運用イベントで、セッション状態遷移や OS レベルの通知が多いカテゴリです。
今回は RDP 成否の補助証拠として主に「時系列整合性（接続前後で不自然な再起動やサービス停止がないか、再接続/切断の連鎖は自然か）」を見るために含めています。
例：
- 4778（再接続）が 1149 の後に頻発 → RDP クライアントの再接続（ネットワーク不安定やスリープ復帰等）。
- 4779（切断）直後に 4634/4647（ログオフ）が無いケース → 切断でセッションが残留していないか、後続の Timeout/Idle 処理で落ちていないか確認。

追加でおすすめの深掘り

4624 の LogonType を補正的に判定
- 記録揺れがある環境では、**ProcessName（mstsc.exe / termsrv/ svchost）や AuthenticationPackageName（Negotiate/NTLM/Kerberos）**も合わせた特徴量で RDP 寄与度を推定します。必要なら追加抽出します。
プロセス起動（4688）連鎖の追跡
- ログオン後に **高権限の横展開痕跡（psexec, powershell, cmd, at/schtasks, regsvr32, rundll32 等）**が無いかを時系列で重ねます（要：Security ログに 4688 が出力されていること）。
ネットワーク境界との突合
- FW/EDR の通信ログで 3389/TCP の到達元・宛先・回数を突き、外部到達があれば優先精査。今回は 192.168.150.* といった内向きが多く、内部横移動の文脈で調べると良いです。
Administrator の正当性確認
- 管理用 RDP の運用ルール（許可時間帯、踏み台経由の必須化、MFA の有無）と突き合わせ、**逸脱（深夜/休日・直打ち・多重ログオン）**がないか確認。

全体的な所感

今回の検証を通して、ChatGPT による Windows Event Log（特に RDP 関連イベント）の解析は実用レベルに近づいていると感じました。
単純なイベント ID の抽出だけでなく、イベント同士の時系列的・論理的な関連性（接続→ログオン→切断など）を自動的に整理してくれた点は特に印象的です。

一方で、セッション単位での正確なグルーピングやイベントの微妙な時差を考慮した因果関係の把握といった部分は、まだ人間の分析力に頼る必要があると感じました。
ChatGPT は相関関係を自然言語で説明するのは得意ですが、裏付けのローデータを検算するような処理は不得手です。そのため、最終的な分析結果の妥当性を判断するには、やはりアナリストの知見が不可欠です。ただし、2022年頃の ChatGPT ではできなかった Python を用いたデータ分析をうまく用いて、フィルターや分析を行ってくれる点については非常に進化したなと感じました。プロジェクトの機能も、データを与えて処理を行ってもらうという観点においては有用に感じました。 Windows Event Log のファイルサイズは 272MB もあり、以前はこのような大容量ファイルを扱えなかったと思います。

また、プロンプトの与え方次第で出力の精度が大きく変わる点も印象的でした。
初回の「雑な依頼」では単純な抽出に留まりましたが、Timeline Explorer のフィルター条件を明示して再依頼したことで、格段に構造的な結果を返すようになりました。
このことから、生成 AI にログ解析を依頼する際は、「どのイベントをどの観点で見たいか」を明示的に指定することが非常に重要だといえます。

総じて、初動調査や一次スクリーニングの自動化という観点では、すでに現場で有効活用できる段階にあります。
RDP に限らず、今後は「セッション単位の相関」や「プロセス連鎖・通信ログとの突合」などを自動で補完できる仕組みを組み合わせれば、AI 補助によるフォレンジック調査の標準化・省力化が現実味を帯びてくると感じました。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up