Golden Ticket攻撃につながる活動をCortex XDRで検出・阻止

This post is also available in: English (英語)

概要

Benjamin Delpy氏が開発した「Golden Ticket」攻撃は防御側に大きな課題を突きつけました。日々のネットワークアクティビティに隠ぺい可能なポスト エクスプロイト テクニックとしての性質を持つため、検出がかなり難しい場合があります。

この攻撃に成功すると、偽造したKerberosチケット(Golden Ticket)を用いてActive Directory (AD)のすべてのサービスとリソースへ自由にアクセスできます。

本ブログ記事ではKerberosとGolden Ticketの概要と、攻撃者の動機を解説します。その上で、既存の検出手法とその注意点をご紹介します。最後に「Golden Ticket」を取得・生成する手口を2つ示した上で、攻撃につながる活動をCortex XDRによって検出・阻止する方法をご説明します。

Golden Ticketとは?

Kerberosの基礎知識

KerberosはActive Directory環境で主に使用されるネットワーク認証プロトコルです。チケットを発行してユーザーを認証しサービスの利用を許可することで、強力な認証を実現します。

チケットはKey Distribution Center (キー配布センター - KDC)によって配布されます。ほとんどの環境において、KDCはドメインコントローラ(DC)にインストールされます。

初期認証時に、チケット保証チケット(TGT)がユーザーに割り当てられます。後からTGTを使用してKDCにユーザーを認証し、Ticket Granting Service (チケット保証サービス - TGS)からサービスチケットを要求します。サービスチケットは、サービス認証用に付与されます。

Kerberos認証は以下のステップで構成されます。

1. ユーザーからのTGT要求(AS-REQ)を受けて、KDCが認証情報とユーザー情報の確認と検証を行います。
2. ユーザー認証後、KDCは暗号化したTGTを要求元ユーザーに返送します(AS-REP)。
3. ユーザーはTGTをDCに提示し、TGSを要求します(TGS-REQ)。
4. 暗号化されたTGSが要求元ユーザーに返送されます(TGS-REP)。
5. 要求したサービスをホストするサーバーにユーザーが接続し、サービス利用のためにTGSを提示します(AP-REQ)。
6. アプリケーションサーバーが(AP-REP)をクライアントに送信します。

Golden Ticket攻撃 - 攻撃者の動機

Golden Ticketは正規の認証を経ずに生成された「事前認証済み」を装う偽造TGTです。TGSを要求するため、認証を実施した偽の証拠として偽造TGTを用いるのです。Golden Ticketを利用すれば、正規の認証を行わずにリソースにアクセスすることや、攻撃を実行することが可能です。例えば、ドメイン上のすべてのコンピュータ、ファイル、フォルダーにアクセスできます。

その仕組みを理解するため、まずはKRBTGTアカウントについて触れます。

Microsoft TechNetの記述を引用します:

「KRBTGTアカウントはローカルのデフォルトアカウントであり、Key Distribution Center (KDC)サービスのサービスアカウントとして機能します。このアカウントは削除できず、アカウント名も変更できません。また、Active DirectoryからKRBTGTアカウントを有効化することはできません。

KDCはWindows Serverドメインのセキュリティプリンシパル名としてKRBTGTを使用します。この仕様はRFC 4120で定義されたものです。KRBTGTアカウントはKRBTGTセキュリティプリンシパルのエンティティであり、新規ドメインの作成時に自動作成されます。

Windows ServerのKerberos認証は、共通鍵で暗号化された特別なKerberos TGT (チケット保証チケット)を利用して実現されます。この鍵はサーバーのパスワードか、アクセス要求先サービスのパスワードから生成されます。KRBTGTアカウントのTGTパスワードを知るのはKerberosサービスだけです。セッションチケットを要求するにはKDCにTGTを提示する必要があります。また、KerberosクライアントへのTGTの発行はKDCが行います。」

簡単に言えば、KRBTGTアカウントがそのドメインのKerberos TGTチケットの暗号化と署名をすべて担当します。また、KDCサービスのためのTGTの暗号化と復号など、Kerberosチケットの検証もすべて実施します。つまり、単にKRBTGTアカウントで暗号化されただけで、偽造されたTGTは有効なチケットと見なされます。

下図は「Golden Ticket」を用いたKerberos認証の流れです。

言うまでもなく、Golden Ticketは攻撃者にとって重要な標的です。Golden Ticketを取得できればドメイン全体のあらゆるリソースへ高い権限で自由にアクセスできます。

「Golden Ticket」攻撃の前提条件

Golden Ticketを生成するにはネットワーク上で足場を築く必要があります。

Golden Ticketの生成に必要なものは次の通りです。

• ドメインの完全修飾ドメイン名(FQDN)。
• ドメインのセキュリティ識別子(SID)。
• KRBTGTのパスワードハッシュ。
• なりすましたいアカウントのユーザー名。

ネットワークに足場を築いた攻撃者ならFQDNは簡単に取得できると考えられるので、ここではKRBTGTのパスワードハッシュとドメインのSIDを取得する手口をご紹介しましょう。

既知のGolden Ticket検出方法とその注意点

Golden Ticketの検出方法はいくつか知られていますが、攻撃の性質と検出手段の制約から注意すべきポイントがあります。

TGT要求を伴わないTGS要求

検出方法の一案としては、TGT要求(EID 4768)を伴わないTGS要求(EID 4769)のイベントログを探す方法が挙げられます。ただし、この検出方法にはいくつかの注意点があります。

まず、ビッグデータを扱う場合、分析プロセスや監視プロセスで一部のイベントや情報の断片を見落とすことが珍しくありません。そうなれば、誤検出が発生してセキュリティ運用アナリストが混乱したり、判断を誤ったりする可能性があります。

また、TGTは有効期限が長いため、検出機能がTGT要求とTGS要求の時間差を「Golden Ticket」と見なして誤検出する可能性もあります。

さらに、複数のDCが存在する環境では、TGTとTGSで要求先のDCが異なる場合があります。仮に片方のDCしか監視していない場合、TGTを伴わないTGSと誤検出される可能性があります。

恣意的な寿命や、空欄または偽のドメイン名/アカウント名が設定されたTGTチケット

別の手段として、TGTそのものの異常を検出する手法が挙げられます。例えば、恣意的な寿命や偽のドメイン名/アカウント名などの異常があれば偽造の可能性があります。

この手法の最大の問題は攻撃者のミスに頼っている点です。攻撃者がプロの場合、有効な検出手法ではありません。

Cortex XDRを用いたGolden Ticket攻撃の検出

Cortex XDRは振る舞い検出・振る舞い分析機能と複数のデータソースを利用して、攻撃フェーズのあらゆる段階で攻撃の可能性を検出します。

ここではGolden Ticketを取得・生成する手口を示した上で、Cortex XDRによって各攻撃ステップを防御・検出できることを示します。

なお、攻撃チェーン全体を確認するため、エージェントをレポートモードに設定した上で攻撃を模擬しました。通常はエージェントのBehavioral Threat Protection (BTP: 振る舞いベースの脅威防御)ルールによって攻撃フェーズを防御・ブロックします。

Golden Ticketの取得 - 手法1: ローカルNTDS.ditのダンプ

Golden Ticketを生成する手法の1つとして、Active Directoryデータベース(NTDS.dit)をダンプして生成に必要な情報を抽出する手法が挙げられます。

まず、DC上でシャドウコピーを作成し、NTDS.ditファイルを取得します。次に、ファイルを分析してKRBTGTハッシュとドメインのSIDを抽出します。後はMimikatzを用いてGolden Ticketを生成できます。

この手法にはNTDS.ditファイルかDCへのアクセス権が必要です。

内訳:

NTDS.ditファイルはActive Directoryデータを保管するデータベースです。グループ、グループメンバーシップ、ユーザーオブジェクトなどの情報が含まれます。また、ドメイン内の全ユーザーのパスワードハッシュも保管するので、KRBTGTハッシュもこのファイルに格納されています。

KRBTGTアカウントのパスワードハッシュを取得するにはNTDS.ditファイルのコピーが必要ですが、単純にファイルをコピーするわけにはいきません。データベースはActive Directoryによって絶えず更新されるため、ファイルがロックされており、通常のコピーを行えないからです。

NTDS.ditをコピーする手段の1つが、ボリューム シャドウ コピーの作成です。シャドウコピーはコンピュータのボリューム/ファイルのバックアップコピーまたはスナップショットであり、ボリューム/ファイルを使用中でも作成できます。つまり、この仕組みを利用することでNTDS.ditのコピーを作成できます。シャドウコピー作成用のツールとしてはMicrosoftがVolume Shadow Copy Service (VSS)を標準提供しています。

まず、攻撃者はVSSを用いてDC上でシャドウコピーを作成します。次に、シャドウコピーからNTDS.ditのコピーを入手した上で、SYSTEMレジストリハイブもコピーします。

SYSTEMレジストリハイブをコピーする理由はBootKey/SysKeyが格納されているためです。この暗号鍵は機密情報(NTDS.dit、マシンアカウントのパスワード、システム証明書など)の暗号化に使用されます。

攻撃者はこのBootKeyを用いてNTDS.ditを復号し、その内容を読み取ります。

その後、NTDS.ditのコピーからKRBTGTデータを抽出します。

KRBTGTデータとSIDデータを入手できれば、Golden Ticketの生成が可能になります。

攻撃フロー

攻撃フローを追うにあたり、攻撃者がDCへのアクセス権を取得済みで、シャドウコピーを生成できる場合を想定します。

まず、攻撃者はVSSを用いてシャドウコピーを生成する必要があります。

シャドウコピーを生成したら、NTDS.ditを取得します。

次に、SYSTEMレジストリハイブもコピーが必要です。

この段階でシャドウコピーのトラックは削除できます。

PowerShellモジュール「DSInternals」を用い、保存したSYSTEMレジストリハイブからBootKey/Syskeyを取得します。

シャドウコピーから取得したNTDS.ditは多くの場合修復が必要なため、「esentutl」ユーティリティで修復します。

修復が完了したら、DSInternalsを用いてNTDS.ditのコピーからKRBTGTデータを抽出できます。

KRBTGTデータとドメインデータを入手したら、Mimikatzを用いて「Golden Ticket」を生成します。

Cortex XDRが提供するアラートと通知

Cortex XDRを導入している場合、攻撃フローの様々な段階でアラートと通知を受け取れます。

Volume Shadow Copyを作成してSYSTEMレジストリハイブをダンプすると、Cortex XDRが以下のアラートと通知を発します。

ダンプの因果関係チェーンも確認できます。

また、SYSTEMレジストリハイブのダンプとNTDS.ditへのアクセス(シャドウコピーからの抽出)に関するBTPルールも利用できます。

Identity Analytics Moduleはesentutlの実行を通知します。

Mimikatzを実行すると、以下のアラートが発生します。

MimikatzによるKerberosチケット注入の因果関係チェーンを確認できます。

手法2: DCSync

Golden Ticketの生成に用いられるもう1つの手法が、ShadowCoerceとActive Directory Certificate Services (ADCS)を用いてFile Server Remote VSS (MS-FSRVP)を悪用し、DCマシンアカウントの証明書を取得するやり方です。DCの証明書を取得すれば、DCを装って認証を行い、DCSyncを実行することで、Golden Ticketの生成に用いるKRBTGTデータを入手できます。

この手法は、低権限ユーザーからドメインのリソースに対する完全なアクセス権を持つGolden Ticketへと権限昇格を行う手法の一例です。

内訳:

ShadowCoerceはMS-FSRVPのRPCを悪用するツールです。

MS-FSRVPを実行するサーバーがIsPathSupportedメソッドとIsPathShadowCopiedメソッドを利用している場合、Server Message Block (SMB)プロトコルを通じて当該サーバーのマシンアカウントを特定のホストに対して認証させることが可能です。

ntlmrelayxをリレーサーバーとして用いることで、SMB認証のリスナーをセットアップできます。SMB認証を捕捉したら、リレーサーバーによってADCSサーバーへ認証を中継することで、当該マシンアカウントの証明書を取得できます。

* ADCS認証とその悪用についてはは「Active Directory Certificate Servicesの悪用をCortex XDRで検出」をご覧ください

マシンアカウントの証明書を取得したら、証明書を用いてDCのTGTを要求できます。TGTを入手できれば、「Pass the Ticket」の手口により、高い権限を持つマシンアカウントを装った認証を行えます。なお、これらの活動にはRubeusが使用されます。

まず、攻撃者はDCにリレーサーバーへの認証を行わせることで、DCを装った認証を実現します。DCを装った認証に成功したら、DCSyncを実行します。

手短に言えば、DCSyncとはドメインコントローラのレプリケーション手法です。悪用することで、KRBTGTハッシュなどのパスワードデータとパスワードハッシュを取得できます。

DCSyncを実行すると、KRBTGTハッシュとドメインのSIDを抽出できます。これらの情報とドメインのFQDNを組み合わせることで、Golden Ticketを生成できます。

生成したGolden Ticketを利用すれば、ドメイン上のあらゆるリソースにアクセスできます。

攻撃フロー

攻撃フローを追うにあたり、ADCS、MS-FSRVPサーバー、リレーマシンが存在するドメインで、攻撃者が何らかのマシンのアクセス権を取得済みだとします。

攻撃者はまずリレーサーバーをセットアップします。このサーバーはSMB認証をリッスンしてADCSサーバーに中継する役割を担います。

リレーサーバーのセットアップ完了後、SMB認証を捕捉したら、ShadowCoerceを用いてリレーサーバーに対する認証をDCに行わせます。

リレーサーバーによって認証をADCSサーバーに中継し、証明書を取得します。

証明書を手に入れたら、「Pass the Ticket」の手口とRubeusを用いてDCマシンアカウントのTGTを入手します。

下図のように、DCマシンアカウントのTGTを入手できました。

次に、Mimikatzを用いてDCSyncを実施し、KRBTGTハッシュとドメインSIDを取得します。

最後に、ドメインFQDN、ドメインSID、「Pass the Ticket」によって取得したKRBTGTのNTLMハッシュを用いてGolden Ticketを生成します。

これで、攻撃者はドメイン上のリソースにアクセスできるようになりました。

Cortex XDRが提供するアラートと情報

Cortex XDRを導入している場合、攻撃フローの様々な段階でアラートと通知を受け取れます。

ShadowCoerceが実行されると、Cortex XDRは以下のアラートと通知を発します。

標的サーバー上でのFSRVP悪用に関する因果関係チェーンを確認できます。

さらに、ShadowCoerceのSMBトラフィックと、リレーサーバーでの強制的なSMB認証により、以下のアラートが発生します。

Rubeusを実行すると、以下のアラートとBTP防御ルールが起動します。

Identity Analytics ModuleはRubeusとklistの実行を通知します。

DCではないマシンからDCマシンアカウントのTGTを要求されると、以下のアラートが発生します。

Mimikatzの実行に関しては、以下のアラートが発生します。

さらに、Identity Analytics Moduleによる通知も発生します。

Rubeusによるチケット注入とMimikatzの実行の両方について因果関係チェーンを確認できます。

最後に、DCSyncはBTPルールでブロックできます。

結論

Golden Ticket攻撃では、ドメイン上の全リソースに対する自由なアクセスが可能になります。

推奨する対策は、DCへのアクセス経路を制限するセキュリティポリシーを作成し、最小権限モデルを実装することです。

さらに、Cortex XDRなどのセキュリティプラットフォームをデプロイすることで、攻撃の各段階で保護と可視化を行う層を追加できます。

Cortex XDRの詳細は、Cortex XDRのWebページまたはXDR基本ガイドをご覧ください。