コンテンツにスキップ
stellvia.dev

PAC と Silver / Golden Ticket

PAC と偽造チケットが重要な理由

Section titled “PAC と偽造チケットが重要な理由”

Kerberos チケットに含まれる PAC（Privilege Attribute Certificate）は、サービスがアクセス権を判断する材料です。PAC が偽造されると、サービスが意図しない権限でアクセストークンを作る可能性があります。特定サービス向けのチケットを偽造する手法を Silver Ticket、TGT を偽造する手法を Golden Ticket と呼びます。

  • PAC はグループ情報だけでなく、トークン生成に使う情報を持ちます。
  • Silver Ticket はサービス鍵、Golden Ticket は krbtgt 鍵を使います。
  • 影響を受ける範囲が異なるため、確認すべきログや防御策も変わります。

Kerberos チケットの前提

Section titled “Kerberos チケットの前提”

Kerberos は AS（Authentication Service） で TGT を、TGS（Ticket Granting Service） で特定 SPN のサービステケットを発行します。クライアントは TGT を提示して TGS-REQ を送り、返ってきたサービステケットをサービスに渡します。サービス側は自分の鍵でチケットを復号し、PAC と Authenticator を検証したうえで LSA にアクセストークン生成を依頼します。

クライアント --AS-REQ/REP--> KDC(AS)
クライアント --TGS-REQ/REP--> KDC(TGS)
クライアント --AP-REQ--> サービス（チケット+PACを検証）
サービス --AP-REP(任意)--> クライアント
  • TGT は KDC 内部専用、サービステケットは SPN ごとでサービス鍵を使う
  • サービスは PAC・Authenticator・チケット有効期限をローカルで検証する
  • LSA が PAC を評価しローカルアクセストークンを作る点が認可境界

PAC の仕組み

Section titled “PAC の仕組み”

PAC が持つ情報

Section titled “PAC が持つ情報”

PAC は ユーザー属性と認可コンテキストの署名付きバンドル で、サービスがローカルでアクセストークンを作る材料です。KDC が生成し、サービステケットや TGT に埋め込みます。単なる SID の羅列ではなく、署名・検証の前提を含む「認可証明書」です。

PAC に含まれる SID とログオン情報

Section titled “PAC に含まれる SID とログオン情報”
  • User SID と Group SIDs: 所属グループの SID。ドメインローカル/グローバル/ユニバーサルが混在。グループ情報は PAC に含まれる（含まれないとアクセストークンが組み立てられない）。
  • Extra SIDs: 委任や S4U で付与される追加 SID。サービス委任の文脈を表す。
  • Logon SID: ログオンセッションを一意に示す SID。監査やセッション分離に利用。
  • ユーザーフラグ/ログオン情報: ユーザータイプ、ログオン種別、トークン制約。Kerberos policy に沿った署名。

LSA とは何か

Section titled “LSA とは何か”
  • LSA (Local Security Authority) は Windows のローカルセキュリティサブシステム。Kerberos/NTLM/SSPI のローカル部分とポリシー評価を担う。
  • 役割: PAC 検証をサービスから委託され、署名確認・SID 評価・特権付与/削除を行い アクセストークン を生成する。
  • LSA 自体は DC ではなく各ホスト上で動作し、PAC の信頼性を ローカルポリシーと署名検証 で判断するのがポイント。

PAC からアクセストークンができるまで

Section titled “PAC からアクセストークンができるまで”
  • サービスは PAC の署名を検証後、LSA に渡して アクセストークン を生成させる。
  • LSA はトークンフィルタ（特権削除、制約付き委任時の縮小）を適用し、ユーザー権利/特権を評価。
  • ログオン種別（Service/Network/Interactive など）に応じた既定特権やフィルタリングを適用。

PAC の整合性検証と「正しい組み合わせ」の判断

Section titled “PAC の整合性検証と「正しい組み合わせ」の判断”
  • 署名二重化: PAC には KDC 署名とサーバー署名が付く。サービスは KDC 公開鍵/共有鍵で KDC 署名を検証し、PAC 改ざん有無を確認。
  • SID の由来とスコープ: PAC 内の Group SIDs は KDC が AD 属性（tokenGroups 等）から計算して入れる。LSA は SID スコープ（ドメインローカル/グローバル/ユニバーサル）やトラスト境界を見て有効/無効を決める。
  • 組み合わせ NG 例
    • ドメイン外で有効にならない Domain Local SID を別ドメインサービスで使う（スコープ外で無効化）。
    • SIDHistory が現在の SID と矛盾（SIDHistory にだけ特権 SID を入れても LSA が削除する）。
    • kvno 不整合や krbtgt/サービス鍵の世代差で署名検証失敗（KRB_AP_ERR_MODIFIED など）。
    • トラスト不一致: フォレスト外 SID でトラストが無い場合は無効化される。
    • ログオン種別ミスマッチ: Network ログオンでインタラクティブ専用特権が剥がれる。
  • 正しく機能しないケース（実務/演習で遭遇しがち）
    • PAC に Domain Admins(512) を入れても、UAC/トークンフィルタで特権が削られ管理者になり切らない。
    • RODC や古い kvno の DC が発行した PAC を新 kvno のサービスが検証できず失敗。
    • SID を手動で足した Silver Ticket が、サービス側 RBAC（SQL/SharePoint）で追加検証され拒否。

SID を追加しても権限が得られない場合

Section titled “SID を追加しても権限が得られない場合”

  • 特権フィルタリング: ローカルポリシーやトークン制約により SeTcbPrivilege などが除去される。

  • グループスコープ/ロール依存: ドメインローカル SID は外部ドメインでは無効、ユニバーサル/グローバルの組み合わせで有効範囲が変わる。

  • サービス側の独自検証: SQL Server や SharePoint などは PAC の SID だけでなくデータベース権限や内部ロールを再評価するため、SID 追加のみでは完全管理者にならないことがある。

  • PAC は署名付きの認可コンテキストで、SID 羅列以上の意味を持つ

  • LSA が PAC を再評価し特権をフィルタするため、SID を盛っても削られる場合がある

  • ログオン種別やサービス固有の検証が最終権限を決める

Silver Ticket

Section titled “Silver Ticket”

サービスチケット偽造の前提

Section titled “サービスチケット偽造の前提”

サービスアカウント（または computer account）の NT ハッシュ/AES 鍵 を得て、特定 SPN 用の サービステケットを自作 する攻撃です。PAC も攻撃者が自由に組み立てられます。

どこで検証されるか

Section titled “どこで検証されるか”

偽造チケットは DC を経由せずサービスに直接渡されます。サービスは自分の鍵で復号し PAC 署名を検証するだけなので、KDC の署名検証を経ない ことが成立の理由です。

影響範囲と検知

Section titled “影響範囲と検知”
  • できる: 盗んだサービス鍵で保護された SPN への認証を偽装し、PAC に応じた権限を得る。
  • できない: 他の SPN には使えない。ドメイン全体の TGS 発行権は得られない。
  • 検知の難しさ: DC ログ（4769）が出ない。サービス側 Security ログや KRB_AP_ERR_MODIFIED などで違和感を追う必要がある。

防御と監査

Section titled “防御と監査”

  • gMSA の利用: 自動ローテーションするグループ管理サービスアカウントで鍵窃取リスクを低減。

  • 最小権限のサービス設計: 高権限サービスアカウントを避け、ローカル管理者権限の付与を最小に。

  • サービスログ監視: 4769 不在でもアプリ/サービスログ（IIS/SQL/SMB）や不一致イベントを監視。

  • サービス鍵を持てば DC を経ずにサービステケットを偽造できる

  • 影響は特定 SPN に限定されるが PAC を自由に組める

  • 検知はサービス側ログ・鍵ローテーション・最小権限運用が鍵

Golden Ticket

Section titled “Golden Ticket”

TGT 偽造の前提

Section titled “TGT 偽造の前提”

ドメインの krbtgt アカウント鍵 を窃取し、任意のユーザー SID で TGT を偽造 する攻撃です。発行元は DC に見えるため、TGS 取得が無制限になります。

KDC の信頼を利用する仕組み

Section titled “KDC の信頼を利用する仕組み”

KDC は TGT の署名鍵として krbtgt を信頼の根に置きます。攻撃者が同じ鍵で TGT を署名すれば、KDC 自身が発行したかのように受理 され、以降の TGS-REQ を拒否できません。これは 認証基盤そのものの境界崩壊 です。

影響範囲と検知

Section titled “影響範囲と検知”

  • できる: 任意のユーザー/SID で TGT を作り、全 SPN に対する TGS を取得。永続性を持たせた長寿命 TGT も作成可能。

  • できない: フォレストを越えるには信頼関係の鍵が別途必要。RC4 無効環境では AES 対応が必要。

  • 検知: 4768/4769 の大量発行、非現実的な有効期限の TGT、kvno 不一致、krbtgt ローテーション後の拒否ログを監視。

  • krbtgt 鍵を得ると TGT を無制限に偽造でき DC と同格になる

  • すべての SPN に TGS を要求できるためドメイン全域に影響

  • 検知はログ異常と krbtgt ローテーション、長寿命 TGT の監視が中心

Golden Ticket から Silver Ticket への展開

Section titled “Golden Ticket から Silver Ticket への展開”

連鎖が利用される理由

Section titled “連鎖が利用される理由”

Golden で得た TGT を元に TGS を取得し、そこからサービス鍵を抜いて Silver を量産 すると、DC を経由しない横展開が可能になります。krbtgt ローテーションで Golden が失効しても、盗んだサービス鍵で Silver を継続できるため永続化に使われます。

連鎖の流れ

Section titled “連鎖の流れ”

  • Golden 段階: krbtgt 鍵入手 → 任意 SID で長寿命 TGT 偽造 → 好きな SPN の TGS を取得

  • サービス鍵抽出: 取得した TGS を復号/メモリダンプ → 対応サービスアカウントの鍵を窃取

  • Silver 量産: 窃取したサービス鍵で特定 SPN 向け Silver Ticket を自作 → DC を経ずに横展開/永続化

  • Golden は全 SPN へのアクセス鍵、Silver は個別 SPN の持続鍵として連鎖する

  • krbtgt を失ってもサービス鍵が残れば Silver で活動を継続できる

  • 連鎖を断つには krbtgt とサービス鍵双方のローテーション・監視が必要

演習で見られる挙動

Section titled “演習で見られる挙動”

Administrator で認証できても権限が低い場合

Section titled “Administrator で認証できても権限が低い場合”

PAC に SID を盛っても、LSA のフィルタや UAC により特権が削除されることがあります。特にリモートログオン（Network ログオン）では SeTcbPrivilege などが削られ、ローカル管理者でも一部操作が拒否されます。

グループ SID 512 を入れても管理者にならない場合

Section titled “グループ SID 512 を入れても管理者にならない場合”

512 (Domain Admins) を PAC に入れても、トークンが Owner にならず SIDHistory の扱いやグループスコープの制約で期待権限が付与されないことがあります。加えて、サービス固有の RBAC が PAC と組み合わせでチェックされ、特定グループセットでのみ昇格する挙動が起きます。

ドメインエラーに見える失敗

Section titled “ドメインエラーに見える失敗”

KRB_AP_ERR_MODIFIED や「無効なドメイン」風のエラーは、SPN 不一致や PAC 署名検証失敗、トークン組み立て時の不整合で発生することがあります。DC ではなくサービス側イベントログや klist 出力を確認することが重要です。

  • PAC 改ざん後も LSA や UAC が特権を削るため「思ったより弱い」権限になり得る
  • SID を足すだけではサービス固有の RBAC を突破できず挙動が揺れる
  • エラーの多くは PAC 署名や SPN 整合性の問題で、DC ログに出ない

設計と監査で押さえる点

Section titled “設計と監査で押さえる点”

Kerberos は「KDC が PAC を署名する」という前提で認可をサービスに委任しています。PAC の信頼境界が壊れると、認証と認可の分離が成り立たなくなります。設計段階で境界を意識し、鍵管理と監視を組み合わせて防御する必要があります。

  • 認証（KDC/PAC 署名）と認可（サービス/LSA トークン）の境界を明確にし両方を監視する
  • 「AD グループで守る」は鍵窃取や PAC 偽造で崩れるため、鍵ローテーションとサービス側 RBAC を組み合わせる
  • 実務では gMSA/最小権限/ログ監視/krbtgt とサービス鍵の定期ローテーションを徹底する