前回（第1回）の記事では、Active Directory（AD）のドメインコントローラ上に格納される重要データベース ntds.dit と、そのダンプがなぜ危険なのかを解説し、ntds.dit から KRBTGT アカウントの秘密情報（パスワードハッシュ）が抽出され得ること、そして Kerberos チケット偽造（ゴールデンチケット）につながることに触れました。

本記事では前回の続編として、ファイブアイズ（Five Eyes）のガイダンスでも重大な攻撃手法として扱われる 「ゴールデンチケット／シルバーチケット」 を取り上げ、これらのリスクに対して Tenable Identity Exposure で何が可視化できるのか、について解説します。

ゴールデンチケット攻撃とシルバーチケット攻撃は、どちらも Kerberos 認証プロトコルを悪用する攻撃です。
Kerberos認証は、ユーザー認証→チケット発行→サービスアクセスという流れで認証を成立させる仕組みであり、ドメイン環境の認証基盤そのものです。
この「チケット」を偽造できてしまうと、正規ユーザーになりすましたアクセスが成立し、侵害の影響が非常に大きくなります。

Kerberos認証では基本的に以下の流れで認証を行います。

• ユーザー認証：ユーザーがログインすると、Kerberosクライアントは認証サーバー（KDC: Key Distribution Center）にリクエストを送ります。（AS REQ）
• チケット発行：KDCはユーザーを認証し、TGT（Ticket Granting Ticket）というチケットを発行します。このTGTは、ユーザーが他のサービスにアクセスする際に使用されます。(AS REP)
• サービスアクセス：ユーザーが特定のサービスにアクセスしたい場合、TGTを使ってKDCにTGS（サービスチケット）をリクエストします。KDCはTGSを発行し、ユーザーに返します。(TGS REQ/TGS REP)
• サービス利用：ユーザーはTGSを使って、目的のサービスにアクセスします。サービスはこのTGSを確認し、ユーザーのアクセスを許可します。(AP REQ/AP REP)

ゴールデンチケット攻撃は、ドメインコントローラが利用する KRBTGT アカウントの秘密情報（パスワードハッシュ）を悪用し、有効な Kerberos チケット（TGT）を偽造する攻撃手法です。

KRBTGTアカウントのパスワードハッシュ は Kerberos 認証サービスのTGT作成に使用される、ドメイン内の認証にとって極めて重要な位置づけです。
この秘密情報が攻撃者に渡ると、TGTを偽造することができます。
偽造TGTチケットで認証済みに見せることができるため、Kerberos認証におけるユーザ認証を回避してドメイン内のリソースへ広範なアクセスが可能になり得る点が危険視されています。

さらに前回触れた通り、ゴールデンチケット生成に必要なKRBTGTアカウントのパスワードハッシュは、ntds.dit のダンプにより取得されます。
つまり、ntds.dit を取得できる権限または侵害状態にある環境では、ゴールデンチケットの成立条件に近づいている可能性がある、ということになります。

シルバーチケット攻撃は、特定サービスのTGSを偽造し、正規ユーザになりすます攻撃です。
ゴールデンチケットが KRBTGT を起点に「ドメイン全体」へ影響し得るのに対し、シルバーチケットは 特定サービス（サービスアカウント）を狙う点が特徴です。
攻撃者はサービスアカウントの秘密情報（NTLM ハッシュ等）を取得し、それを使って有効なサービスチケットを偽造する、と説明されています。

両者は「Kerberos チケット偽造」という点で共通していますが、悪用する秘密情報と影響範囲が異なります。

• ゴールデンチケット：KRBTGT の秘密情報を悪用し、任意ユーザーとしてのTGTを偽造できるため、ドメイン全体のリソースへ広範にアクセス可能となり得る。
• シルバーチケット：サービスアカウントの秘密情報を悪用し、特定サービスへのアクセスになりすます。

ゴールデンチケット攻撃やシルバーチケット攻撃が成立するかどうかは、Kerberos認証における重要なアカウントの秘密情報が攻撃者に取得されているかどうかに大きく依存します。特に、KRBTGTアカウントのパスワードハッシュが窃取された場合、攻撃者は任意のチケットを生成することが可能となり、ドメイン全体に対する不正アクセスが成立してしまいます。

また、これらの攻撃は、Domain Admins 等の管理グループに所属するアカウントや、それに準ずる権限を持つアカウントが侵害されることによって実行可能となるケースが多く見られます。
すなわち、KRBTGTの管理だけでなく、高い権限を持つアカウント全体の適切な管理が極めて重要であるといえます。

そのため、KRBTGTアカウントのパスワードを定期的に更新し、過去に発行された不正なチケットを無効化することに加え、これらの特権アカウントがどれくらい存在するのか、また意図せず同等の権限が付与されていないかを把握することが、ゴールデンチケット／シルバーチケット攻撃のリスクを評価するうえで非常に重要になります。

Tenable Identity Exposure は、このような管理グループやKRBTGTに関連するリスクを可視化することで、チケット偽造攻撃につながる権限の有無や過剰付与の状況を把握することを可能にします。

KRBTGTアカウントで前回行ったパスワード変更　

検知概要①：
KRBTGT は Kerberos チケット（TGT）の暗号化／署名に関わる中核であり、その秘密情報（ハッシュ）が漏えいすると、攻撃者は偽造した TGT（ゴールデンチケット）を作成して任意のアカウントになりすまし、ドメイン内リソースへのアクセス材料を生成できる可能性があります。
本 IoE では、KRBTGT の「前回のパスワード変更」状況（変更が長期間行われていない／運用上の更新が適切に実施されていない等）を可視化し、ゴールデンチケットによる長期的な侵害・永続化リスクが高い状態を早期に把握します。

検知例①：

対策①：
過去に生成されたゴールデンチケットの影響を封じ込めるには KRBTGT のパスワードを 2 回変更して無効化する運用が推奨されており、更新状況の監視は侵害時対応・平時の予防の両面で重要です。
※なぜ2回の変更が必要なのか？
KRBTGT アカウントは 、DC間の整合性のために、現在のパスワードと1つ前に設定されていたパスワードの両方がチケット検証に使用される設計です。
そのため1回だけ変更しても「前回のパスワード」が残り、古いパスワードで発行されたチケットが一定期間有効になり得ます。
出典：https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password （閲覧日：2026/4/23）

ネイティブ管理グループメンバー　

検知概要➁：
ネイティブ管理グループとは規定の管理（特権）グループを意味しており、これらのグループに所属するアカウントの数が多すぎると、認証秘密情報の盗取リスクが高くなります。過剰な権限設定になっており、攻撃者のAD乗っ取りとする「特権奪取」のリスクに直結する可能性があります。

Domain Admins 検知例➁：

対策➁：
不要なアカウントを削除、権限変更する、Domain Adminsグループから除外する、管理（特権）グループから除外する、など実施して下さい。

ゴールデンチケット／シルバーチケットは、どちらも Kerberos 認証の“チケット”を偽造することで、正規ユーザーになりすましたアクセスを成立させる攻撃手法です。

特にゴールデンチケットは KRBTGT の秘密情報（ハッシュ）を悪用し、ドメイン内の広範なリソースに影響し得る点が危険であり、シルバーチケットは 特定のサービスアカウントを起点に、狙ったサービスへのアクセスを成立させる点が特徴です。

重要なのは、これらの攻撃が「特殊なテクニック」ではなく、“成立条件が揃った瞬間に現実的な脅威になる”ということです。

Tenable Identity Exposure のような可視化の仕組みを用いて、Tier0 資産（KRBTGT、特権グループ、サービスアカウント周り）に直結する露出を継続的に点検し、成立条件を先回りで減らすことが、運用として最も効果的な対策になります。

特に注意すべきなのは、「長年の運用の積み重ね」により、誰も全体像を把握できていない権限や、本来不要な特権・サービスアカウントが残ってしまうケースです。

ゴールデンチケット／シルバーチケットは、こうした“見えない露出”が温床になりやすく、一度成立すると影響範囲が大きく、検知も難しくなりがちです。

そして、これらのチケット偽造に至るまでの現実的なルートとして頻繁に登場するのが、DCSync などの「AD から秘密情報を引き出す」手法です。

次回（第3回）は、この DCSync を取り上げ、どのような条件が揃うと成立し得るのか、また 運用上どこを押さえるべきかを、今回のチケット攻撃との関連も踏まえて解説します。ぜひ次回もご覧ください。