イベントログで攻撃を検知する実践パターン｜Kerberoasting・DCSync・横展開の痕跡を追う

「ログは取っているが、何を見ればいいかわからない」——現場でよく聞く言葉です。Windowsのセキュリティログは膨大で、どのイベントIDが何を意味するのか、どれが攻撃の痕跡なのかを把握していないと宝の持ち腐れになります。

ログを「取っていること」と「読めること」は全く別のスキルです。本記事では、Kerberoasting・DCSync・横展開という代表的な攻撃手法がイベントログにどう記録されるかを、具体的なイベントIDと見るべきポイントとあわせて解説します。

KerberoastingとDCSyncの仕組みについては「KerberoastingとDCSyncの仕組みと防御策｜AD攻撃の2大手法を解説」で詳しく解説しています。本記事では「検知」の観点に絞って掘り下げます。

イベントログで攻撃を検知するとは

イベントログとは——Windowsが記録する操作の証跡

イベントログとは、Windowsが操作・認証・エラーなどの出来事を自動的に記録するログ機能です。

イベントログ（Event Log） Windowsが記録するシステム操作の証跡。「セキュリティ」「システム」「アプリケーション」などのカテゴリがある。セキュリティ上の調査では主に「セキュリティログ」を参照する。イベントビューアー（eventvwr.msc）またはPowerShellで確認できる。

攻撃者がADに対して行う操作——認証・チケット要求・レプリケーション・横展開——はすべて何らかの形でイベントログに記録されます。ただしデフォルト設定では記録されないイベントも多いため、監査ポリシーの設定が前提になります。

攻撃検知に使う主要イベントID

本記事で扱うイベントIDを先に整理します。

セキュリティログで確認すべき重要なイベントIDの全体像については「Windowsイベントログ重要ID一覧｜セキュリティ調査で使うIDまとめ」を参照してください。

Kerberoastingの痕跡を追う

Kerberoastingとは——検知の観点から

Kerberoastingは、SPNを持つサービスアカウントのTGSチケットを取得してオフラインでクラックする攻撃です。攻撃者はドメインの正規の機能を使うため、ログ上は通常のチケット要求と区別がつきにくいのが最大の難点です。

SPN（Service Principal Name：サービスプリンシパル名） Active Directoryにおいてサービスとアカウントを紐づける識別子。SPNを持つアカウントに対してはドメイン内の誰でもTGSチケットを要求できる。

それでも検知できる手がかりが2つあります。「RC4暗号の使用」と「短時間の大量TGS要求」です。

注目すべきイベントID（4769）とその見方

Kerberoasting検知の核心はイベントID 4769です。TGSチケットが要求されるたびに記録されます。

イベントID: 4769
ログ名: Security
発生場所: ドメインコントローラー（DC）

通常のTGS要求と攻撃を区別するために見るべきフィールドは以下です。

PowerShellでRC4のTGS要求を抽出する場合は次のように確認できます。

# RC4暗号（0x17）のTGS要求を抽出する
Get-WinEvent -ComputerName "DC01" -FilterHashtable @{
    LogName = "Security"
    Id      = 4769
} | Where-Object {
    $_.Message -match "0x17"
} | Select-Object TimeCreated, Message | Format-List

怪しいログの特徴——短時間の大量TGS要求

Kerberoastingは通常、ドメイン内のSPNアカウントを一括で列挙してチケットを取得します。そのため短時間に複数のSPNアカウントへのTGS要求が集中するのが特徴です。

1人のユーザーが数秒〜数分の間に複数のサービスアカウントへTGSを要求している場合、Kerberoastingの可能性を疑ってください。特に普段そのサービスを利用しないユーザーからのチケット要求は要注意です。

DCSync・横展開の痕跡を追う

DCSyncとは——検知の観点から

DCSyncは、DCのレプリケーション機能を悪用してパスワードハッシュを窃取する攻撃です。DCどうしのレプリケーションと同じイベントが記録されるため、発生元がDCか否かの確認が検知のポイントになります。

DCレプリケーション（DC Replication） 複数のDCがADデータを同期するための仕組み。DCSyncはこの正規の仕組みを悪用してパスワードハッシュを要求する。正規のレプリケーションと同じイベントが記録されるため検知が難しい。

ADのセキュリティ監査の観点については「ADのセキュリティ監査手順｜定期チェックで権限肥大化と設定ミスを防ぐ」も参照してください。

注目すべきイベントID（4662）とその見方

DCSync検知の核心はイベントID 4662です。ただしこのイベントはデフォルトでは記録されません。「ディレクトリサービスのアクセス監査」を有効にする必要があります。

イベントID: 4662
ログ名: Security
発生場所: ドメインコントローラー（DC）
前提条件: 「ディレクトリサービスのアクセス」監査ポリシーを有効化

イベント4662の中で特に確認すべきGUIDは以下の3つです。

このイベントの発生元アカウントがDCのホスト名でない場合、DCSyncの可能性が高いです。正規のレプリケーションはDCどうしで行われるため、一般的なユーザーアカウントやサーバー名から発生していれば異常です。

横展開（psexec）の痕跡——4624・4648・7045

攻撃者がpsexecを使って別のマシンに横展開する際には、複数のイベントが連鎖して記録されます。

イベントID 4648（明示的な資格情報でのログオン）

イベントID: 4648
ログ名: Security
発生場所: 送信元コンピューター

psexecは別のコンピューターに接続する際に明示的に資格情報を使います。このため送信元マシンに4648が記録されます。短時間に複数の宛先への4648が記録されている場合、横展開の試みが疑われます。

イベントID 4624（ログオン成功）

イベントID: 4624
ログ名: Security
発生場所: 接続先コンピューター
確認フィールド: ログオンタイプ（Type 3 = ネットワークログオン）

psexecによる接続はネットワークログオン（Type 3）として記録されます。深夜・休日・普段ログオンしない端末への接続は特に注意が必要です。

イベントID 7045（新しいサービスのインストール）

イベントID: 7045
ログ名: System
発生場所: 接続先コンピューター

psexecは接続先に一時的なサービスをインストールしてコマンドを実行します。このサービスのインストールが7045として記録されます。サービス名が「PSEXESVC」や短いランダムな文字列の場合は攻撃ツールの可能性があります。

3つのイベントを時系列で並べると「送信元4648 → 接続先4624（Type 3）→ 接続先7045」という流れが見えてきます。この連鎖が短時間に複数マシンで発生していれば横展開のシナリオです。

現場でよくある見落とし

① 監査ポリシーが未設定で4662が記録されない

DCSync検知に必須のイベントID 4662は、デフォルトでは記録されません。GPOで「ディレクトリサービスのアクセス」監査を有効にしていない環境では、DCSyncが発生しても痕跡が残りません。

確認方法：

# DC上でディレクトリサービスアクセス監査の設定を確認する
auditpol /get /subcategory:"ディレクトリ サービスのアクセス"

「成功」または「成功および失敗」が設定されていない場合は即座に有効化してください。

② ログの保存期間が短すぎて遡れない

デフォルトのセキュリティログの最大サイズは20MBです。活発なAD環境ではわずか数日で上書きされます。インシデント発生後に「ログが残っていなかった」という事態を防ぐため、最低でも128MB以上への拡張と、SIEMやログ転送による長期保存を検討してください。

③ アラートがなく誰も見ていない

ログを取得していても、誰かが定期的に確認する仕組みがなければ意味がありません。少なくとも以下の条件に一致するイベントはアラートとして通知する仕組みを作ることを推奨します。

• 深夜・休日の特権アカウントのログオン（4624）
• DC以外からのイベントID 4662の発生
• 短時間に大量のRC4 TGS要求（4769）
• 不審なサービスインストール（7045）

④ DC以外のログを収集していない

横展開の痕跡（4648・4624・7045）はDCではなく接続元・接続先の一般サーバーや端末に記録されます。DCのログだけを収集していると横展開の痕跡を見逃します。できればすべてのWindowsサーバーのセキュリティログとシステムログを収集対象に含めてください。

チェックリスト

監査ポリシーの確認

• 「ディレクトリサービスのアクセス」監査が有効になっている（4662記録のため必須）
• 「ログオン監査」が有効になっている（4624・4625記録のため）
• 「アカウントログオン監査」が有効になっている（4768・4769記録のため）
• セキュリティログの最大サイズを128MB以上に拡張している

ログ収集の確認

• DCのセキュリティログを収集・保存している
• 主要サーバー・端末のセキュリティログとシステムログも収集している
• ログの保存期間が少なくとも90日以上確保されている

検知の仕組み

• RC4のTGS要求（4769）を定期的に確認している
• DC以外からの4662発生をアラートとして通知している
• 深夜・休日の特権アカウントログオンを監視している
• 不審なサービスインストール（7045）を監視している

まとめ

今日確認すべきことは1つです。DCサーバーで「ディレクトリサービスのアクセス」監査が有効になっているか確認してください。

auditpol /get /subcategory:"ディレクトリ サービスのアクセス" をDC上で実行して、「成功」または「成功および失敗」が設定されていなければ即座に有効化してください。この設定がなければDCSyncは痕跡を残さずに実行されます。

イベントログの検知は「仕組みを知っているか」で大きく差が出ます。本記事で紹介したイベントIDと見るべきフィールドを押さえておけば、膨大なログの中から攻撃の痕跡を探し出す起点になります。

次のステップとして、これらのログをツールで効率的に解析する方法はAD演習編Vol.5「攻撃ログの検知・分析」で体験できます（公開準備中）。Hayabusaを使った攻撃タイムラインの可視化まで手を動かして学べます。

本記事で解析したイベントログは、AD演習編Vol.4で実際に攻撃を実行した記録そのものです。攻撃側を先に体験しておくと、今回のログパターンがなぜ・どう記録されるのかがより深く理解できます。

あわせてご覧ください

• KerberoastingとDCSyncの仕組みと防御策｜AD攻撃の2大手法を解説
• Windowsイベントログ重要ID一覧｜セキュリティ調査で使うIDまとめ
• ADのセキュリティ監査手順｜定期チェックで権限肥大化と設定ミスを防ぐ
• AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務

参考文献

• 参考：Detecting and Mitigating Active Directory Compromises（ASD・ACSC）
• 参考：Windowsセキュリティイベントの監査（Microsoft Learn）
• 参考：ASD Windows イベントログおよびフォワーディングガイダンス