ゴールデンチケット攻撃

ゴールデンチケット攻撃とは？

ゴールデンチケット攻撃は、ドメインの権限を乗っ取り、持続的に悪用する高度な攻撃です。この攻撃では、攻撃者はKerberos認証プロトコルの脆弱性を悪用し、認証チケットを偽造します。これにより、ドメイン内でKerberos認証に対応しているすべてのサービス（ドメインコントローラー、ファイルサーバー、DNS、プリントサーバーなど）を自由に操作できる状態を確立します。

攻撃について

Kerberosプロトコルは、ユーザー、キー配布センター（KDC）、アクセス先サーバーの3者が連携して、セキュアな認証・認可を実現しています。KDCは、ドメインコントローラー上で動作するサービスであり、Kerberos認証プロセス全体を管理する役割を担っています。

Kerberosプロトコルの概要

1. ユーザーがシステムへのログインを試みる際、事前認証データ（ユーザーアカウントのパスワードハッシュで暗号化されたタイムスタンプ）がKDCに送信されます。

2. KDCがユーザー名を読み取ります。そして、ドメインコントローラー（DC）のセキュリティアカウントマネージャ（SAM）からパスワードハッシュを取得し、事前認証データの復号を試みます。復号が成功すると、ユーザーは有効な認証情報を持っていると判断され、ドメイン内のサービスにアクセスする権限が与えられます。

3. KDCが、ユーザーの認証要求に応じて、チケット付与チケット（TGT）を発行します。TGTは、ユーザーの詳細情報を保持しており、KRBTGTアカウント（認証のための特別なアカウント）のパスワードハッシュで暗号化されています。TGTのデフォルト有効期間は10時間ですが、管理者による変更が可能です。この有効期間内であれば、ドメイン内のサービスにアクセス要求を行う際、ユーザー認証が不要になります。

4. TGTを使ってサービスへのアクセス要求が生成され、KDC内のチケット付与サーバー（TGS）に送信されます。TGSはアクセス要求を復号し、サービスチケットを発行します。そして、新しいセッションキーをサービスチケットに追加し、サービスアカウントの認証情報で署名を行った後に、そのサービスチケットをユーザーに送信します。ユーザーは、TGSから受け取ったサービスチケットを対象のサーバーに提示することで、そのサーバーへの直接接続が許可されます。

脆弱性

KRBTGTアカウントのパスワードは、Kerberos認証において最も重要な要素です。攻撃者は、KRBTGTアカウントのパスワードハッシュを窃取し、ゴールデンチケット（KDCが認証したかのように見せかけたTGT）を作成します。このゴールデンチケットをTGSに送信することで、正当なサービスチケットを不正に発行できます。

偽造されたTGTの有効期間は、最大で10年に設定できます。つまり、KRBTGTパスワードがリセットされるまで、攻撃者は長期間にわたりチケットを悪用できます。

攻撃の流れ

攻撃者が、フィッシングメールを使用してネットワーク内のユーザーアカウントへのアクセスを取得したと仮定しましょう。

1. 攻撃者は、ユーザーアカウントにドメインコントローラー（DC）に対する管理者権限またはレプリケーション権限を付与することで、そのアカウントの権限を昇格させます。

2. Mimikatz（悪用されることが多いセキュリティツール）をインストールし、DCSyncコマンドでKRBTGTアカウントのパスワードハッシュを不正に取得します。

3. ユーザー名、ドメイン名、ドメインセキュリティ識別子（SID）、グループID、窃取したパスワードハッシュを使用して、ゴールデンチケットを作成します。このチケットは認証情報キャッシュに格納され、サービスチケットを取得するために使用されます。たとえば、攻撃者は、「ファイル管理者」というADグループ名と、その相対識別子（RID）を使用してゴールデンチケットを作成します。これにより、サービスチケットを取得し、機密データが保存された重要なファイルにアクセスできます。

4. 攻撃者は、長期にわたってネットワーク内に潜伏します（ゴールデンチケットの有効期限が数年先に設定されている可能性があるため）。

ゴールデンチケット攻撃を検知する方法

ゴールデンチケット攻撃を検知するには、継続的にネットワークを監視し、以下のような侵害の指標（IoC）を察知する必要があります。

特権昇格

ユーザーアカウントによる新しいプロセスの実行（DCSync）
特権ユーザーアカウントの異常な挙動

Mimikatzのインストール

アンチウイルスソフトウェアが危険だと判断するような悪意のあるソフトウェアのインストール

攻撃後に行われる悪意のあるアクティビティ

エンドユーザーによる重要なリソースへの初回アクセス
エンドポイントでのデータの蓄積
普段と異なるユーザー行動（不審な時間帯にアクセス要求が行われているなど）

イベントの調査

イベントID：4769

このイベントは、ユーザーがサービスチケットを要求した際に、ドメインコントローラーに記録されます。正当な理由でチケットの要求が失敗する場合もありますが、エラーコードを確認し、詳細に調査することで、以下のような攻撃の兆候が明らかになるケースがあります。

偽造されたTGTに、正規のものと異なる点がある。「グループIDなどの一部のフィールドに空白がある」「偽のユーザー名が使われている」など
許可されていないサービスに対してアクセス試行が何度も行われている。
暗号化の強度が低い。
KRBTGTアカウントのパスワードがリセットされているにもかかわらず、リセット前のパスワードハッシュで署名されたTGTが何度も送信されている。

上記のようなIoCは、SIEM（セキュリティ情報およびイベント管理）ソリューションを活用することで、容易に特定できます。SIEMソリューションは、疑わしいアクティビティをリアルタイムで追跡・検知し、攻撃の被害を軽減します。

ゴールデンチケット攻撃のIoCを検知するには、以下のような機能を備えた効果的なSIEMソリューションを選ぶ必要があります。

1. 高度な分析機能とリアルタイムアラート：SIEMソリューションは、ネットワークのログデータを収集・分析することで、異常なアクティビティを特定できます。さらに、脅威に関するリアルタイムアラートを生成し、インシデントの調査や軽減を支援します。SIEMソリューションには、ネットワークセキュリティに関する重要な情報を提供する直感的に使いやすいダッシュボードが備わっています。これにより、特権昇格の試行、疑わしいユーザーアクティビティ、悪意のあるソフトウェアのインストールを容易に特定できます。

2. UEBA（ユーザーおよびエンティティの行動分析）：UEBAは、SIEMソリューションと連携することで、通常のネットワークアクティビティの傾向を読み取り、ユーザーの標準的な動作パターン（ベースライン）を特定できます。ユーザーがベースラインから逸脱した場合、脅威であると判断され、そのユーザーのリスクスコアが引き上げられます。

3. インシデント対応：SIEMソリューションは、ゴールデンチケット攻撃のIoCを検出した際に、適切に対応できるよう支援します。インシデント管理コンソールには、アラートを生成するための定義済みワークフローが備わっており、インシデント対応の自動化が可能です。

ゴールデンチケット攻撃の被害拡大を抑えるためには、KRBTGTアカウントのパスワードを2回リセットする必要があります。なぜなら、Active Directoryには現在のパスワードと、1つ前のパスワードが保存されているからです。つまり、パスワードを1回リセットしただけでは、依然としてリセット前のパスワードが記憶されているため、そのハッシュを保持するTGTチケットは有効のままとなります。

パスワードのリセットは、Active DirectoryまたはSIEMソリューションのパスワード管理コンソールを使って手動で実施できます。また、今後のゴールデンチケット攻撃のリスクを軽減するためには、ADのメンバーやグループを再編成し、必要な権限のみをユーザーに割り当てることも必要です。

Log360によるゴールデンチケット攻撃の検知と軽減

ゴールデンチケット攻撃はステルス性が高く、検知が困難です。大量の誤警報に振り回される事態を避けるには、侵害の指標（IoC）の特定と徹底的な調査を組み合わせた戦略が欠かせません。

Log360は、セキュリティオペレーションセンター（SOC）が持続的な攻撃に対する調査・対応を実施できるよう支援します。SIEMソリューションであるLog360は、以下のような有用な機能を提供します。

重要なイベントを把握するためのリアルタイムアラート
フォレンジック分析に役立つログ検索機能
異常なアクティビティを検出する定義済みレポート

アラートによる検知
ログ検索による調査
レポートによる調査

アラート

失敗イベントID：4769

1. Log360は、サービスチケットの失敗イベント（イベントID：4769）を検出し、その原因が記載された通知をユーザーに送信します。また、今後ゴールデンチケットの使用を結果コードで発見した場合、その結果に応じてアラート条件を追加できます。

0x6：存在しないユーザー名に対するTGSリクエスト
0xC：ユーザーはサービスへのアクセスを許可されていない
0x40：TGTの署名が無効

2. Log360には、Kerberosチケットにおける暗号化の脆弱性を検出するアラートプロファイルも用意されています。このアラートは、0x1や0x3などの結果コードを参照します。

対策: 生成されたアラートをインシデントとして登録・管理し、Log360のインシデントダッシュボードで対応ワークフローを即座に実行します。このワークフローには、攻撃の進展を阻むためのアクション（プロセスの強制終了、ユーザーのログオフと無効化、コンピューターの無効化など）が組み込まれています。

ログ検索による調査

アラートで上記のイベントが確認された場合、ログ検索機能を用いて詳細を調査できます。イベントID 4624と4672を参照して、ログオンアクティビティを分析できます。また、Log360では、ログフィールド内に不自然なデータがないか、また空のフィールドが存在しないかを検知できます。さらに、イベント履歴の閲覧や、データ精査のための条件追加（ユーザー名やSIDなど）も可能です。