Kerberosの要：TGT（Ticket Granting Ticket）を徹底解説 - 概要・脅威・検出・実務対策

2025年11月25日 最終更新日時 : 2025年11月25日 エバープレイ編集部

はじめに — Ticket Granting Ticket（TGT）とは何か

Ticket Granting Ticket（TGT）は、Kerberos認証プロトコルにおける中心的な証明書（チケット）で、ユーザーがシングルサインオン（SSO）を実現するためにKDC（Key Distribution Center）から発行されます。TGT自体は「ユーザーがKDC（TGS機能）に対してサービスチケット（TGS/Ticket Granting Serviceチケット）を要求できる権利」を表すもので、直接サービスに対するアクセス権そのものではありません。正しく取り扱われないと強力な攻撃対象になり得るため、セキュリティ設計と運用上の理解が必須です。

Kerberosの全体像とTGTの位置づけ

Kerberos（特にKerberos V5）は、対称鍵暗号を基礎にした認証プロトコルで、主に次の役割を担うコンポーネントから成ります：

  • KDC（Key Distribution Center） — 認証サーバ（AS）とチケット発行サーバ（TGS）を含む。
  • クライアント — 認証を受けるユーザーやサービス。
  • サービス — クライアントがアクセスしたいリソース（ファイルサーバ、APなど）。

基本フローは次のようになります：クライアントがASに対してAS-REQを送り、認証が成功するとAS-REPでTGT（およびクライアントとKDC間のセッションキー）を受け取る。クライアントはこのTGTを使ってTGSにTGS-REQを送り、目的のサービスに対するサービスチケットを取得してから実際のサービスにアクセスします。TGTは「KDCに再認証なしでサービスチケットを要求できるトークン」と考えると分かりやすいです。

TGTの取得と構造（AS-REQ / AS-REP）

TGTはAS（Authentication Service）によるやり取りで発行されます。典型的な流れは以下の通りです：

  • クライアントはAS-REQを送る。通常はプリオーセンティケーション（pre-auth）情報（PA-ENC-TIMESTAMPなど）を添えて送信する。
  • KDCはクライアントの認証情報を確認し、AS-REPを返す。AS-REPには暗号化された部分が含まれ、そこにTGT（Ticket）、クライアント/KDC間のセッションキー、各種期限等が含まれる。

TGT自体はKDC（またはTGS）によって暗号化されており、通常クライアント側では復号できません。TGTの主なフィールドは次の通りです：

  • クライアントプリンシパル（クライアントID）
  • 対象プリンシパル（TGS/KDC）
  • セッションキー（クライアントとKDCの間でTGS要求時に使う）
  • 有効開始・有効期限・再利用可能期限（renewable lifetime）
  • フラグ（forwardable, renewable, proxiable, ok-as-delegateなど）
  • 認証局（realm）情報

TGTのフラグとオプション（実務で重要なもの）

TGTには複数のフラグがあり、各動作を制御します。主なもの：

  • forwardable：クライアントが他マシンへチケットをフォワード（転送）できるか。リモートでのSamba/SSH等に関わる。
  • proxiable：他主体が代理で使える「proxy ticket」を発行できるか。
  • renewable：TGTの有効期限を延長（renew）可能か。長時間のセッション継続を許容する。
  • ok-as-delegate：委任に関するフラグ（MS拡張との関係が深い）。

有効期間と更新（renewal）

TGTには短い「有効期間（ticket lifetime）」と、条件付きで長い「renewable lifetime」が存在します。一般的なActive Directoryのデフォルト値は、チケット有効期間が10時間、renewable lifetimeが7日程度です（環境で設定可能）。renewableフラグが付与されたTGTは、期限内であればTGS-REQを通じてrenew（更新）でき、長時間の連続セッションを維持できます。ただしrenewableは誤用されると長期の侵害持続を許すため、ポリシーで慎重に管理します。

Windows ADにおける実務的な追加情報（PAC、krbtgtなど）

Active Directory（AD）にはKerberosの標準仕様に加え、Microsoft固有の拡張があります。代表的なもの：

  • PAC（Privilege Attribute Certificate）：サービスチケットに含まれる認可情報（グループメンバーシップや属性など）。サービスはPACを検証してアクセス制御を行う。PACはKDC（krbtgt）によって署名される。
  • krbtgtアカウント：KDCがTGTを暗号化／署名するために用いるキーを持つ特殊なドメインアカウント。このアカウントのNTLM/キーが流出すると「Golden Ticket」攻撃が可能になる。
  • 既定のTGT有効期間や許容差（クロック同期の許容範囲）などはドメインポリシーで設定される。

よくある攻撃と脅威（TGTが標的になる理由）

TGTは「KDCに対してサービスチケットを要求できる権利」を与えるため、攻撃者にとって非常に有用です。代表的な攻撃とポイントは以下の通りです。

  • Pass-the-Ticket：盗んだTGTを別ホストのセッションに注入して認証を突破する（Windows環境でmimikatzやRubeusが利用される）。
  • Golden Ticket：ドメインのkrbtgtアカウントのキー（ハッシュ）を入手し、任意のTGTを偽造してKDCに提示、結果的に無制限に任意ユーザーになりすます攻撃。これが成功すると期限や権限を自由に設定できるため致命的。
  • Silver Ticket：サービスアカウントのハッシュを使ってサービスチケット（TGS）を偽造する攻撃。これはTGTを直接改竄する必要はないが、ターゲットのサービスに対する有効なチケットを作れる。
  • AS-REP Roasting：pre-authが無効化されたアカウントに対してAS-REQを送り、AS-REPに含まれる暗号化データをオフラインで総当たりしてパスワードを割る攻撃。
  • Overpass-the-Hash（Pass-the-Key）：NTLMハッシュやKerberosキーを用いてTGTを直接要求または偽造する手口。特権アカウントのハッシュを握ると重大。

検出とログ分析のポイント

TGTやKerberos関連の異常はログに痕跡を残します。Windows環境では以下のイベントIDが有効です：

  • 4768 — Kerberos 認証チケット（TGT）のリクエスト（成功／失敗）
  • 4771 — Kerberos pre-auth の失敗（AS-REQの失敗）
  • 4769 — Kerberos サービスチケット（TGS）のリクエスト
  • 4770 — Kerberos チケットの更新（renew）

検出観点としては、長期のrenewable TGTが頻繁に更新されている、短時間に大量のTGSリクエストが発生している、異常に長い有効期限を持つチケットが使用されている、特定のホストで頻繁にTGTが注入されている等が挙げられます。Golden Ticketの使用は通常PAC署名の矛盾やkrbtgtキーに関する不整合、異常なSIDやグループ情報を伴うため、これらの指標で検出を試みます。

対策とベストプラクティス

TGTを安全に運用するための現実的な対策を列挙します。

  • 最小特権の原則：ドメイン管理者やkrbtgtアカウントのアクセスを厳格に制限する。特にkrbtgtの資格情報は厳重に保護。
  • krbtgtアカウントのローテーション：侵害が疑われる場合はkrbtgtのパスワードを2回連続でリセットする（Microsoftは2回のパスワード変更を推奨している）。ただし運用影響を理解した上で計画的に実施すること。
  • 強力な暗号化（AES）を推奨：RC4-HMAC等の古い暗号を無効化し、AESベースの暗号スイートを利用する。これはチケットの耐久性を高める。
  • プリオーセンティケーション（pre-auth）の有効化：AS-REP Roastingを防ぐため、pre-authを有効にする。ADでは多くの環境で既定で有効。
  • 監視と検出体制：イベントログ（4768/4769/4771/4770など）をSIEMで監視し、異常なTGTやTGSのパターンを検知する。
  • 限定的なdelegation設定：Unconstrained delegationはリスクが高く、代わりにconstrained delegationやresource-based constrained delegationを使用する。
  • Privileged Access Workstations（PAW）：ドメイン管理者などの高権限アカウントは専用の安全な端末からのみ操作させる。
  • パッチ適用およびツール制御：mimikatz等のツールでLSAメモリからチケットを取り出す攻撃を抑止するため、エンドポイントの保護と実行制御を行う。

クロスレルムとS4U（実運用での注意点）

大規模環境では複数のレルム（realm）やフォレストがあり、クロスレルム認証が使われます。TGTはレルム間で相互に信頼関係を張ることで、あるレルムのTGTを用いて別レルムのTGSを要求することができます（相互信頼設定が必要）。またMicrosoft拡張のS4U（Service for User）機能は、サービスがユーザーの代理で別のサービスにアクセスする際に用いられ、S4U2Self/S4U2Proxyなどの仕組みがあります。これらは便利ですが、誤設定すると横展開や権限昇格の手がかりになります。

運用上の注意点とよくある誤解

いくつかの誤解や注意点：

  • TGTは「パスワードそのもの」ではないが、TGTを奪われるとそのユーザーになりすますことが出来るため、パスワード流出に匹敵する危険がある。
  • krbtgtのパスワード変更は慎重に行う必要があり、単に一度変更すれば良いわけではない（二重変更の必要性や複数DC間のレプリケーション遅延を考慮する）。
  • サービスチケット（TGS）とTGTの混同に注意。TGTはKDCへ行くための“パス”を与えるもので、実際のサービスアクセスはTGS（サービスチケット）で行う。

実践的な検査・ツール

セキュリティ検査や調査で使われるツールの例：

  • Rubeus — Kerberos攻撃・検査ツール（TGT抽出、過去チケットの操作、AS-REP Roasting等）
  • mimikatz — LSAメモリからチケットを抽出・注入するツール（Pass-the-Ticket、Golden Ticketの作成など）
  • Wireshark — Kerberosトラフィックのパケット解析（ポート88）
  • SIEM（Splunk等） — Kerberosイベントの相関分析、異常検出

これらは防御目的と攻撃評価の両方で有用ですが、利用は適切な同意を得た上で実施してください。

まとめ

Ticket Granting Ticket（TGT）はKerberosの認証アーキテクチャにおいて中心的な役割を果たします。適切に保護・監視されていないと、TGTや関連する鍵（特にADのkrbtgtキー）は深刻な侵害につながります。設計・運用では「最小権限」「鍵管理」「暗号強化」「監視・検出」の4点を意識し、必要ならば専用の運用手順（krbtgtキーのローテーション手順やPAWの導入）を定めることが重要です。

参考文献

カテゴリー
IT
前の記事
リミックス完全ガイド：定義・歴史・制作プロセス・法的ポイントと現代技術を徹底解説New!!
2025年11月25日
次の記事
音楽アンソロジーの全貌：定義・歴史・タイプ・制作プロセスとデジタル時代の価値と権利問題New!!
2025年11月25日