Kerberos認証とゴールデンチケット攻撃｜Active Directory環境のチケット偽造リスクと防御設計

社内のWindowsサーバーを使っている企業なら、ほぼすべてが依存している認証基盤がKerberos（ケルベロス）です。普段は名前すら意識しないのに、一度攻撃者に突破されると「チケット1枚でドメイン全体を制圧」という最悪の事態になりかねない。それがゴールデンチケット攻撃（Golden Ticket Attack）です。

この記事では、Kerberos認証の仕組みをおさらいしながら、ゴールデンチケット攻撃がなぜ危険なのか、そして情シス担当者が取れる現実的な防御策を解説します。

Kerberos認証とは？（なぜ企業ネットワークの認証の核心か）

Kerberos認証は、Active Directory（AD）環境でユーザーがリソース（ファイルサーバー・プリンター・社内アプリなど）にアクセスするときに使われる認証プロトコルです。Windowsドメインに参加した端末では、ログイン後の認証処理をほぼすべてKerberosが担っています。

認証方式にはパスワード・証明書・生体認証・OTPなど複数の種類がありますが、Active Directory環境ではKerberosが標準プロトコルとして採用されています。

仕組みは「チケット」を使ったトークン方式で、主な登場人物は次の通りです。

・KDC（Key Distribution Center）: 認証局の役割を担う。ドメインコントローラー（DC）内に存在する
・TGT（Ticket Granting Ticket）: ユーザーが最初にログインしたときにKDCから受け取る認証チケット。有効期限は通常10時間
・TGS（Ticket Granting Service）: TGTを使って個々のサービス（ファイルサーバーなど）への接続チケットを払い出すサービス
・KRBTGT: KDCがTGTを署名・暗号化するために使う特殊なドメインアカウント。このアカウントのパスワードハッシュが攻撃者の最大ターゲットになる

ユーザーが「ファイルサーバーにアクセスしたい」と思ったとき、毎回パスワードを入力するのではなく、TGTを見せてサービスチケットをもらい、そのチケットをファイルサーバーに提示します。ユーザーにとっては透過的でシームレスな体験ですが、このチケットの仕組みが攻撃者に悪用される余地を生みます。

ゴールデンチケット攻撃の仕組み（敵を知る）

ゴールデンチケット攻撃は、KRBTGTアカウントのパスワードハッシュを奪取した攻撃者が、正規のTGTを模倣した「偽造チケット」を自力で作成する手法です。

1. 攻撃の流れ

攻撃は主に次の4ステップで進みます。

①ドメインコントローラーへの侵入・権限昇格
攻撃者はまず何らかの方法でDCへのアクセス権を取得します。フィッシング・パスワードリスト攻撃・横展開（ラテラルムーブメント）など多彩な侵入口があります。

②KRBTGTアカウントのハッシュ奪取
Mimikatzなどのツールを使って、DCのメモリ（LSASSプロセス）からKRBTGTのNTLMハッシュを取得します。このハッシュさえ入手すれば、攻撃者はDCへのアクセスを失っても攻撃を継続できます。

③偽造TGTの生成
KRBTGTハッシュを使い、任意のユーザー（存在しないアカウントや削除済みのドメイン管理者）として署名されたTGTを生成します。このTGTを「ゴールデンチケット」と呼びます。

④ドメイン内の自由なアクセス
偽造TGTはKDCが「正規」とみなすため、ドメイン内のあらゆるサービスへのアクセスが可能になります。ファイルサーバー・メールサーバー・ERP・Azureハイブリッド連携まで、ドメインに参加しているリソースは原則すべて標的になります。

# ゴールデンチケット攻撃の概念的な流れ（攻撃コード自体は掲載しない）
# 1. DC侵害 → KRBTGTハッシュ取得（ntds.dit の抽出や LSASS ダンプ）
# 2. ゴールデンチケット生成（KRBTGTハッシュ + ドメインSID + 任意のユーザー名）
# 3. 偽造TGTを用いてサービスチケット(TGS)を要求
# 4. サービスチケットを使いファイルサーバー等に接続
#
# 重大なポイント:
# KRBTGTハッシュを知っている限り、DC復旧後も攻撃を継続できる
# TGTの有効期限を20年などに設定した偽造チケットは長期潜伏にも使われる

重大なのは「KRBTGTハッシュを入手した後は、DCへのアクセスを失っても攻撃を継続できる」点です。パスワードリセットをしなければ、侵入者は何か月も潜伏し続けられます。

2. シルバーチケット攻撃との違い

同じチケット偽造系の攻撃に「シルバーチケット攻撃（Silver Ticket Attack）」があります。両者の違いを整理しておきましょう。

ゴールデンチケットはドメイン全体に影響するという点で破壊力が桁違いです。シルバーチケットは範囲が限定的な分、KDCとの通信を経由しないためSIEMへの記録が残りにくく、検知が難しいケースがあります。どちらも「KDCを経由しない」という共通点があり、ネットワーク監視だけでは捕捉しにくい点に注意が必要です。

具体的な防御手順

1. KRBTGTアカウントのパスワードを2回リセットする

ゴールデンチケット攻撃を無効化する最も直接的な対処は、KRBTGTアカウントのパスワードリセットです。ただし、Kerberosの仕様上、2回連続でリセットする必要があります。1回目のリセット後もKerberosは旧パスワードを一時的に受け付けるため、間隔をあけて2度実施します。

Microsoftは「New-KrbtgtKeys.ps1」スクリプトを公開しており、ADレプリケーションの状態を確認しながら安全にリセットできます。侵害を疑う場合は、1回目の実施後に数時間（AD複製が完了するまで）待って2回目を実行してください。

# KRBTGTパスワードリセットの手順概要（PowerShell）
# Microsoftの New-KrbtgtKeys.ps1 スクリプトを使って実施する

# 1回目のリセット（ロールアウトモード）
# .\New-KrbtgtKeys.ps1 -Mode ModeBoth

# ADレプリケーション完了を確認（通常4時間以上）
# repadmin /showrepl でレプリケーション状態を確認

# 2回目のリセット
# .\New-KrbtgtKeys.ps1 -Mode ModeBoth

# 注意事項:
# 作業前にADのフルバックアップを取得すること
# 業務時間外に実施し、ヘルプデスクへの連絡体制を準備しておくこと

2. 特権アカウントの最小化と「Protected Usersグループ」の活用

KRBTGTハッシュを攻撃者に取られる前段として、ドメイン管理者（Domain Admins）のアカウント数を必要最小限に抑えることが根本的な防御になります。最小権限の原則の考え方をAD管理に徹底適用することが重要です。

Windows Server 2012 R2以降には「Protected Usersグループ」という仕組みがあり、このグループに追加したアカウントはKerberos委任の対象外になり、資格情報のキャッシュが大幅に制限されます。特権アカウントはすべてこのグループへの追加を検討してください。

・Domain Adminsのメンバーを最小化（目標は2名以下）: 日常業務には権限を絞った通常ユーザーアカウントを使う
・Protected Usersグループに特権アカウントを追加: RC4（NTLMハッシュ）での認証を不可にし、Mimikatzによるハッシュ奪取を困難にする
・Credential Guard（Windows 10/Server 2016以降）を有効化: LSASSプロセスをVirtualization-Based Security（VBS）で保護し、メモリダンプによるハッシュ奪取を阻止する
・DCへの日常業務アクセスを禁止: ドメインコントローラーはメール閲覧・Webブラウジング・通常業務には使わない

3. イベントログで早期検知する

ゴールデンチケット攻撃はDCへの直接ログインなしに動作するため検知が難しいですが、以下のWindowsイベントIDが手がかりになります。

特に「TGTの有効期限が異常に長い（デフォルトは10時間なのに20年など）」「存在しないユーザーアカウントのSIDを持つTGT」が検知できれば、ゴールデンチケット使用の強い兆候です。Microsoft Defender for Identity（旧Azure ATP）はこれらの異常を機械学習で自動検知します。

Linuxサーバーをドメイン参加させている環境では、Samba/SSSD経由でもKerberos認証が行われます。Linux側のKerberosログ（/var/log/krb5kdc.log相当）の監視については、姉妹サイトLinuxMaster.JPでLinuxのログ管理手法を詳しく解説しています。

中小企業でも今日からできること

「Defender for Identityを導入すればいい」とは言っても、コスト面で難しい企業も多いはずです。予算をかけずに実施できる対策を整理します。

・Domain Adminsグループの棚卸し（今すぐ実施）: PowerShellで「Get-ADGroupMember ‘Domain Admins’」を実行し、現在のメンバーを確認。不要なアカウントをすぐに削除する。これだけで侵害時のリスクを大幅に下げられる
・KRBTGTリセット手順の事前文書化: 有事に素早く実行できるよう、手順書を作成してオフラインでも参照できる場所に保管しておく
・DCのWindowsイベントログ保存期間を延ばす: セキュリティログを最低90日分保持するようグループポリシーで設定する。侵害調査のときにログが消えていると原因特定が困難になる
・ADの詳細監査ポリシーを有効化: グループポリシーエディター→「コンピューターの構成」→「Windowsの設定」→「セキュリティの設定」→「詳細な監査ポリシーの構成」でKerberos認証関連を「成功と失敗」に設定する
・ADの定期バックアップ確認: Windows Server バックアップでシステム状態バックアップが正常に取得できているか月次で確認する

よくある誤解と注意点

【注意1】KRBTGTパスワードを1回だけリセットしても不十分

Kerberos仕様上は2回のリセットが必要です。1回だけでは旧ハッシュを使った攻撃継続が可能な期間が残ります。Microsoftのスクリプトを使い、必ず2回実施してください。

【注意2】クラウド移行（Microsoft Entra ID）だけでは解決しない

Microsoft Entra ID（旧Azure AD）単体はKerberosを直接使いませんが、オンプレADとのハイブリッド構成の場合、オンプレADの侵害がクラウド側にも波及します。ゴールデンチケットで奪取した権限を使ってAzure ADに横展開するケースも確認されており、ADが残る限りKerberos対策は必須です。

【注意3】ユーザーのパスワードを変えてもゴールデンチケットは無効にならない

ゴールデンチケットはユーザーのパスワードではなく、KRBTGTアカウントのハッシュで署名されています。ユーザー側のパスワードを変更しても偽造チケットは引き続き有効です。KRBTGTのリセットが唯一の根本対処です。

本記事のまとめ

Kerberos認証はActive Directory環境の要であるだけに、一度突破されたときの被害が甚大です。「完全に防ぎ切る」ことより「侵害前提で検知・対処できる状態を作る」という考え方が現実的です。

最初の一歩として、今すぐDomain Adminsのメンバーを確認するところから始めてみてください。それだけでも侵害時の被爆範囲を大きく絞ることができます。