ADの神を偽る「禁断のチケット」：Kerberosの深淵とGolden/Silver Ticket攻撃の脅威
「Active Directory（AD）が落ちれば、会社は止まる」。これはインフラエンジニアなら誰もが一度は背筋を凍らせる真実だ。だが、今の時代、物理的なダウンよりも恐ろしいのは、ADという認証の「神」が乗っ取られることだ。
今日は、AD環境における認証の要である「Kerberos認証」を悪用した、最も凶悪な攻撃手法の一つである「Golden Ticket」および「Silver Ticket」攻撃について、現場の視点から深掘りしていく。これを理解することは、単なる攻撃手法の学習ではない。ネットワークの境界が曖昧になったゼロトラスト時代において、「何を信頼すべきか」を定義するための必須教養だ。
—
1. Kerberosの通信フロー：なぜ「チケット」が最強の武器になるのか
Kerberos（TCP/88）は、チケットベースの認証プロトコルだ。クライアントはKDC（Key Distribution Center）とやり取りし、正当なチケットを取得することで、ターゲットとなるサービスへアクセスする。
このプロトコルの美しさは、「パスワードをネットワーク上に流さない」点にある。しかし、その裏返しとして、「チケットさえ偽造できれば、無制限の権限が手に入る」という致命的な構造的脆弱性を抱えている。
攻撃のシーケンス（簡略化版）
1. AS-REQ/REP: クライアントがKDCに対し、TGT（Ticket Granting Ticket）を要求する。
2. TGS-REQ/REP: TGTを提示し、特定のサービス（例：CIFS, HTTP）へアクセスするためのST（Service Ticket）を要求する。
3. AP-REQ: 取得したSTをサービス提供元（ファイルサーバやWebサーバ）に提示し、アクセスを開始する。
攻撃者が狙うのは、このチケットそのものだ。
—
2. Golden TicketとSilver Ticket：その破壊的な違い
現場でこの手のインシデントに遭遇したとき、まず見極めるべきは攻撃の深さだ。
Golden Ticket（TGTの偽造）
ドメインコントローラー（DC）の krbtgt アカウントのパスワードハッシュを入手し、KDC自身を騙す攻撃だ。
- 威力: 期限を数十年先に設定した「最強のTGT」を生成可能。ドメイン内の全権限を永続的に掌握できる。
- 検知: 非常に困難。DCに触れずとも認証を通せてしまう。
Silver Ticket（STの偽造）
特定のサービス（例：HTTP/web-server.corp.local）のサービスアカウントのパスワードハッシュを使い、特定のサービス用チケットだけを偽造する。
- 威力: DCにアクセスする必要がないため、イベントログに痕跡が残りにくい。
- 検知: ネットワーク上の特定のサービスへの不自然なアクセス（KDCを経由しない認証）を追う必要がある。
—
3. 実務で備えるための「泥臭い」対策とコード例
インフラエンジニアとして、これらの攻撃をどう食い止めるか。まずは「攻撃者が何を見ているか」を知る必要がある。例えば、攻撃者は Impacket ライブラリなどを使ってチケットを生成・注入する。
攻撃の手口（概念コード：Python/Impacket）
攻撃者は、取得したNTLMハッシュを使って以下のようにチケットを偽造する。
# 攻撃者がImpacketを使用してGolden Ticketを生成する際のイメージ
# 実際にはドメイン名、SID、krbtgtのNTLMハッシュが必要
from impacket.krb5.kerberos import Ticket
# 偽造チケットのパラメータ定義
# 悪意あるユーザーをドメイン管理者（RID 500）として偽装する
domain = "CORP.LOCAL"
user_id = 500
krbtgt_hash = "f7c...（krbtgtのハッシュ）"
# このチケットがあれば、DCは「このユーザーは管理者だ」と信じ込む
# 運用側としては、このハッシュが漏洩すること自体がゲームオーバーを意味する運用側が今すぐやるべき「防御策」
① Kerberoasting対策（パスワードポリシーの強化）
サービスアカウントに、推測不可能な長くランダムなパスワードを設定せよ。servicePrincipalName (SPN) が設定されたアカウントは、オフライン攻撃の標的になりやすい。
② ログの監視（SIEMへの統合）
Event ID 4768（TGT要求）や 4769（サービスチケット要求）を監視し、異常な暗号化アルゴリズム（RC4など）が使われていないかチェックする。
# PowerShellで不審なチケット要求を抽出するコマンド例
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} |
Where-Object {$_.Message -match "0x17"} # RC4暗号化（古いアルゴリズム）は攻撃の兆候③ 境界の防御：認証の「ゼロトラスト化」
Web APIを設計する際、Kerberosに依存しすぎるのは危険だ。特にパブリックなAPIを公開するなら、OAuth 2.0 や OIDC を活用し、AD認証のみに依存しない多要素認証（MFA）を強制せよ。
—
最後に：ネットワークは「嘘をつく」
Kerberosは、ある種「性善説」に基づいた信頼のプロトコルだ。ひとたび鍵が盗まれれば、そのネットワーク内では悪意あるパケットも正当なチケットを纏って平然と往来する。
現場の運用者諸君、ログを信じすぎないでほしい。「認証が通っているから安全」なのではなく、「認証を通すための鍵が守られているから安全」なのだ。
もし皆さんの環境で、krbtgt アカウントのパスワードを1年以上更新していない、あるいはサービスアカウントが特権を持ったまま放置されているなら、それはすでに「チケットを偽造してください」と言っているようなものだ。今すぐ設定を見直し、境界防御の先にある「ID中心の防御」へとシフトしてほしい。
技術は常に進化するが、攻撃者はいつだって「一番脆い部分」を狙ってくる。その脆さを埋めるのは、仕様書を読み解く力と、泥臭い検証を厭わない諸君の執念だ。健闘を祈る。
コメント