貴石のチケット: 詳解 次世代型Kerberos攻撃

  • 4,216
    people reacted
  • 0
  • 3 min. read

By and

Category: Threat Briefs and Assessments

Tags: , , , , ,

An illustrative example of Kerberos attacks using golden, diamond, or sapphire tickets

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

概要

Unit 42のリサーチャーが、新たな検出手法をご紹介します。これらの検出手法により、新種のKerberos攻撃(攻撃者はKerberosチケットを変更して特権アクセスを管理することが可能)の検出率を向上できます。こうした攻撃で有名な例は、Golden Ticket攻撃です。この攻撃を実行する脅威アクターは、チケットを偽造して高特権ユーザーに偽装できます。

今回新たに発見された2つの攻撃は、既存のチケットを変更して高特権アクセスを含める点で、Golden Ticket攻撃の機能強化版であり、偽造チケットはゼロから作成されません。本稿では、この3種類の攻撃の違いを考察し、新しい攻撃の検出が困難な理由を説明します。

Active Directoryの利用拡大によって、Kerberos攻撃が多くの脅威アクターの資金源となります。リサーチャーは、以下の新しい攻撃手法を発見しました。これらの手法を利用する攻撃者は、Active Directory (AD)ドメイン内ですべてのサービスとリソースに自由にアクセスできます。

  • Diamond Ticket
  • Sapphire Ticket

有名なGolden Ticket攻撃と類似していることから、脅威アクターは今後の活動でこれらの攻撃も使用する可能性があります。ユーザーは、この新しいKerberos攻撃に対応する検出手法を新たに採用することで、セキュリティを強化できます。

本稿で説明する攻撃に対応するように改善された検出手法を、Cortex XDRによってパロアルトネットワークスのお客様にお届けします。

関連するUnit 42のトピック Privilege Escalation、Golden Ticket、Kerberos

目次

Kerberosの基礎知識
Kerberosチケット内のコンポーネント
Kerberos特権属性証明(PAC)とは?
Kerberos委任
S4U2Self拡張機能
U2U認証
U2U + S4U2Self
2つのKerberos攻撃のしくみ
Sapphire Ticket
Diamond Ticket
新しいKerberos攻撃の威力
Diamond Ticket攻撃とSapphire Ticket攻撃の違い
TGTを偽装できる者
実際に報告されている偽造チケット攻撃
偽造チケット攻撃に対する検出手法の提案
Sapphire Ticket
Diamond Ticket
ドメイン管理者アカウント用のチケット生成
通常のドメインユーザーの権限昇格
グループメンバーシップの検出
結論
追加リソース
付録: 用語集

Kerberosの基礎知識

チケット攻撃とその影響を理解するには、Kerberosのしくみを理解することが役立ちます。理解すべきものには、チケット攻撃で使用される機能に関する一般的な用語に加え、チケットが使用されるしくみも含まれます。

Kerberosは、Active Directory (AD)環境で主に使用されるネットワーク認証プロトコルです。さまざまな業界で数千社の企業がActive Directoryのテクノロジを利用して、ユーザーアカウントなどの組織内リソースを管理しています。Active Directoryは最初のバージョンがWindows Server 2000でリリースされて以来、膨大な数のユーザーとリソースを管理する企業や大規模な組織において、特に普及しています。

Kerberosで用意されている強力な認証により、ユーザーを認証してチケットを発行し、サービスの利用を許可します。チケットはKey Distribution Center (キー配布センター - KDC)によって配布されます。ほとんどの環境において、KDCはドメインコントローラ(DC)にインストールされます。

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

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

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

Kerberosチケット内のコンポーネント

Kerberosチケットには、いずれも以下のフィールドが含まれています。

Kerberosチケット
Tkt-vno チケット形式に対応するバージョン番号
レルム チケットを発行したレルム
sname サーバー名。この名前のコンポーネントはすべて、サーバーの

IDの一部
Enc-part サーバーの秘密鍵で暗号化されている。

表1 Kerberosチケット

Enc-partにはさまざまなフィールドがありますが、ここでは以下について説明します。

  1. cname: クライアントのプリンシパル識別子の名前部分
  2. 認証データ: プリンシパルからの認証データをアプリケーションサービスに渡すために使用。プリンシパルではチケットが代理発行される。この部分には特権属性証明(PAC)が含まれる

Kerberos特権属性証明(PAC)とは?

Microsoftのドキュメントによると、PACは、認証関連情報を示す構造体であり、認証関連情報はDCで渡されます。PACを認証プロトコルで使用してIDを検証し、認証情報を転送してリソースへのアクセスを制御します。

PAC内のセキュリティ識別子(SID)、相対識別子(RID)といった認証データが、DCに含まれます。

Kerberos委任

Kerberos委任の一般的な使用例は、Webサーバーでデータベースサーバーからユーザーのデータを取得する場合です。データベースサーバーは、ユーザーデータへのアクセス権をユーザーにのみ付与できます。この場合、Webサーバーはユーザーを偽装する必要があります。この偽装をKerberos委任と言います。

本稿では制約付き委任に絞って説明します。Kerberos委任の各種手法については、「CortexXDRによるBronze Bit脆弱性からの保護」を参照してください。

制約付き委任: MicrosoftはKerberosの拡張機能を実装して、ユーザーのTGTをメモリに保持しません。この拡張機能はS4U (Service for User)と呼ばれ、S4U2SelfとS4U2Proxyから構成されます。S4U2Selfでは、ユーザーの代理でサービスが自分自身にチケットを要求できます。S4U2Proxyでは、あるサービスに別のサービスへの認証を許可します。

S4U2Self拡張機能

上記の通り、S4U2self拡張機能により、チケットでユーザーの認証データ(つまり、PAC)をサービスが受信できます。

このプロトコル拡張機能を使用するには、KRB_TGS_REQ発行ユーザーはサービスプリンシパル名(SPN)を1つ以上登録しておく必要があります。これにより、DCはサービスの秘密鍵を使用して、生成サービスチケットを暗号化できます。

S4U2U KRB_TGSのやり取りの流れ:

  1. サービスではPA_FOR_USERデータ構造体に情報を設定します。当該構造体にある情報は、ユーザーに関する情報です。サービスではユーザーの代理でサービスチケットを要求し、KRB_TGS_REQメッセージをTGSに送信します。
  2. KRB_TGS_REQメッセージを介してサービスチケットがサービスに送信されます。サービスチケットで戻されるPACには認証データが含まれます。

U2U認証

User-to-User認証はKerberos RFCで規定されています。認証検証団体に対して発行したTGTのセッション鍵を使用してKDC発行チケットの暗号化をクライアントが要求できる手法として規定されています。

KRB_TGS_REQでは、以下の機能があります。

  • 追加のチケット: 秘密鍵の取得先TGTが含まれます。
  • ENC-TKT-IN-SKEY: このオプションの指定により、渡される追加TGTからセッション鍵でエンドサーバーのチケットが暗号化されます。
  • サービス名(sname)はユーザーを意味することがあります。必ずしもSPNを持つサービスであるとは限りません。

U2U + S4U2Self

2つの手法を組み合わせると、SPNがないユーザーに対してS4U2Self拡張機能を使用できます。このやり取りで受信されるサービスチケットは、サーバーの秘密鍵で暗号化されます(この場合、サーバーはSPNがないユーザーとなる可能性があります)。したがって、対象ユーザーのPACはサーバーの秘密鍵を使用して復号できます。

KRB_TGS_REQパケットには、両方の手法の特徴がすべて備わります。

2つのKerberos攻撃のしくみ

Sapphire Ticket攻撃とDiamond Ticket攻撃はどちらも正当なTGTを複合し、そのPACを変更します。また、実行するには、攻撃者はKRBTGTアカウントの鍵(パスワードハッシュ)へのアクセス権が必要になります。Microsoft TechNet (現在のMicrosoft Docs)の記事によると、KRBTGTアカウントはローカルのデフォルトアカウントであり、KDCサービスのサービスアカウントとして機能します。

Sapphire Ticket

Sapphire Ticket攻撃(Charlie Bromberg氏が提唱)では、ドメインでユーザーの認証情報を入手する必要があります。このユーザーをJoeとしましょう。Joeの認証情報はTGTの入手に使用され(通常のKRB_AS_REQを使用)、後から高特権ユーザーのPACの復号に使用されます。

TGTが受信されると、攻撃者はU2U + S4U2Selfを使用します。

  1. 偽装するユーザー(高特権ユーザー)を決定します。
  2. 以下の特性を持つKRB_TGS_REQを生成します。
    1. 偽装ユーザーの情報がPA_FOR_USER構造体に含まれる
    2. サービス名(sname)がJoeのユーザー名である
    3. JoeのTGTが追加チケットフィールドに追加される
    4. KDCオプションのENC-TKT-IN-SKEYフラグが設定される
  3. 偽装ユーザーのサービスチケットを入手します。

KRB_TGS_REQ -

図2は多くのコード行であり、Joe.2というユーザー名でU2UとS4U2Selfを使用してKRB_TGS_REQを生成する方法を示しています。
図2.U2UとS4U2Selfの手法を使用して作成したKRB_TGS_REQ
図3は多くのコード行であり、Joeという名前のユーザーが設定オプションの設定を開始しています。
図3.KDCオプションでのENC-TKT-IN-SKEYフラグの設定

KRB_TGS_REP

図4は数行の連続コードであり、Joeという名前のユーザーがプロセスで設定オプションを設定し続ける方法を示しています。
図4. U2U + S4U2Self TGS-REP.

ご承知のとおり、サービスチケットはサービスの長期にわたる秘密鍵による暗号化です。つまり、攻撃者はJoeの認証情報を入手すると、サービスチケットを復号できます。攻撃者はKRBTGTアカウントの秘密鍵も入手しているため、JoeのTGTを復号して変更できます。TGTは前述の秘密鍵で署名されています。

Sapphire Ticketを偽造するために、攻撃者は偽装ユーザーのPACを抜き取り、以下の2つの方法でJoeのTGTを変更します。

  1. Joeの元々のPACを高特権PACに置き換えます。
  2. cnameを偽装ユーザーの名前と一致させます。

これにより、攻撃者は高特権ユーザーのTGTを利用できます。

Diamond Ticket

Diamond Ticket攻撃(Charlie Clark氏が提唱)の最初の部分で、TGTを入手します。これを行うには、以下のいずれかの手法を使用できます。

  • 攻撃者は低特権ユーザーの認証情報を使用してKRB_AS_REQを開始します。その結果、正当なTGTとなります。
  • Rubeusというツールにはtgtdelegというオプションがあります。このオプションはKerberosのGeneric Security Services Application Program Interface (GSS-API)を悪用して、現在のユーザーで使用可能なTGTを抽出します。このとき、ホストでの昇格は必要ありません。

KRB_AS_REP内でTGTを受け取ると、攻撃者はKRBTGTアカウントの鍵を使用してTGTを復号し、チケットの各部分を変更できます。

チケット変更後、攻撃者は以下のいずれかの手法を用いて権限を昇格できます。

  • TGTを生成して、ドメイン管理者またはドメイン内の他のユーザーを偽装する。
    この場合、攻撃者はチケットのcnameフィールド、およびPACを変更する必要があります。この方法では、ドメイン管理者(またはドメインの他のユーザー)の名前でチケットが偽造されます。これは、Golden Ticket攻撃と非常に似ています。
  • PACを変更して、通常のドメインユーザーの権限をドメイン管理者権限に昇格させる。

この方法では、ドメイン管理者権限を持つ低特権ユーザーの名前で攻撃者にチケットが提供されます。

新しいKerberos攻撃の威力

Diamond TicketとSapphire Ticketは偽造TGTであり、正当なTGTを変更することで作成します。これにより、追加の権限または新しいIDが付与されます。Golden Ticketが多数検出される要因としては、正当なDCでTGTが作成されないことがありますが、DCが正当なTGTを発行しても新しい攻撃で改ざんするので、検出が困難になります。

攻撃者は偽造TGTを使用して、希望するサービスまたはリソースへのTGSを要求します。たとえば、ドメインですべてのコンピュータ、ファイル、フォルダへのアクセスを要求できます。

Diamond Ticket攻撃とSapphire Ticket攻撃の違い

どちらの攻撃でも、正当なTGTのPACに対して改ざんが行われますが、変更方法に主な違いがあります。Diamond Ticket攻撃では、要求されたTGTで元のPACに対して変更が行われ、権限を追加したり完全に変更します。Sapphire Ticket攻撃では攻撃者はTGTを変更しますが、Kerberos委任を使用して高特権ユーザーの正当なPACを入手することで変更し、元のチケットのPACで置換します。

TGTを偽装できる者

このような攻撃を実行する基本的な要件として、KRBTGTアカウントのパスワードハッシュへのアクセスが攻撃者に必要です。

KRBTGTアカウントはドメインですべてのKerberos TGTチケットを暗号化して署名します。Kerberosチケットですべての検証(KDCサービスのTGTの暗号化と復号を含む)が、KRBTGTによって実行されます。つまり、単にKRBTGTアカウントで暗号化されただけで、偽造されたTGTは有効なチケットと見なされます。

さらに、TGTの偽造後、攻撃者はKRBTGTのパスワードハッシュでTGTを暗号化する必要があります。これにより、新しいTGTがKDCの検証に確実に合格して、希望するサービスにサービスチケットを発行します。

とはいえ、KRBTGTパスワードハッシュの入手は容易でないことに留意する必要があります。パスワードハッシュを入手すると、ドメインですべてのサービスとリソースへのアクセス権も入手するだけでなく、ネットワーク潜伏が有効になります。

実際に報告されている偽造チケット攻撃

偽造チケット攻撃は現実に確認されており、たとえばPlayful Taurus (APT15、Ke3chang、NICKELとしても知られる)による攻撃などで見られます。このグループは中国国外で活動している脅威アクターであり、2010年以来、世界中の石油会社、政府機関、在外公館、軍事組織、非政府組織を標的にしています。

2017年5月にNCC GroupのIRチームが実施した調査によると、対処措置を実施する場合に標的ネットワークで潜伏するために、Playful TaurusはMimikatzを使用して認証情報をダンプし、Kerberos Golden Ticketを生成しました。

MSTICの調査によると、2021年12月頃の別の活動において、悪意のあるツール(Mimikatz、WDigest、NTDSDumpといったパスワードダンプツールなど)を同一脅威アクターが使用して、標的システムで認証情報を収集しました。

攻撃者はMimikatzを使用して以下の活動を実施できます。

  • 認証情報の収集
  • DCSync攻撃の実行
    この攻撃はActive Directoryレプリケーションのプロセスを擬似的に再現し、ユーザーのパスワードハッシュを手に入れます。この攻撃を使用すると、KRBTGTパスワードハッシュを収集できます。
  • Golden Ticketの偽造

リサーチャーの推測では、Sapphire Ticket攻撃とDiamond Ticket攻撃はGolden Ticket攻撃と似ていますが、さらに発見が困難になるので、将来的に多様な脅威アクター(Playful Taurusなど)がこれらの攻撃を使用する危険性があります。

偽造チケット攻撃に対する検出手法の提案

KRBTGTパスワードハッシュを発見する困難さにより、偽造チケット攻撃では攻撃開始前でも多くの兆候が生じる可能性があります。この場合、Golden Ticket攻撃に適用される検出アイデアがここでも関連します。

こうした検出の詳細については、「Detecting and Preventing the Path to a Golden Ticket With Cortex XDR」を参照してください。

Sapphire Ticket

Sapphire Ticketは有効(つまり、正当なPACのチケット)であるように見えるので、分析だけでは使用の検出は困難です。ただし、以下のようにホストでその他の疑わしい活動は検出できます。

  • KRBTGTパスワードハッシュ窃取の兆候
  • 疑わしいツールの使用
  • 環境におけるDCSync攻撃、またはホストからDCへの疑わしい接続
  • U2UとS4U2Selfの属性を持つ不正なKRB_TGS_REQ
  • 対象ホストから高特権ユーザーによるKRB_TGS_REQ

攻撃者が攻撃直後にチケットを使用する場合、2人の異なるユーザーの同じIPからTGT要求とTGSが検出されます。対象マシンで2番目のユーザー(つまり、TGS要求に表示されるユーザー)の認証の兆候はありません。これは、Windowsイベントの4768と4769、およびネットワークトラフィックで監視できます。

図5は、低特権ユーザーによるTGT要求のスクリーンショットであり、ユーザーのアカウント名「Joe」がハイライトされています。クライアントのアドレスもハイライトされています。
図5.低特権ユーザーによるTGT要求
図6は、高特権ユーザーによるTGT要求のスクリーンショットであり、アカウント名とクライアントアドレスがハイライトされています。
図6 高特権ユーザーによるTGS要求

Diamond Ticket

ドメイン管理者アカウント用チケットの生成

ここでの検出はGolden Ticket検出機能または推奨のSapphire Ticket検出機能と非常に似ています。

通常のドメインユーザーの権限昇格

攻撃者がこの手法を使用する場合、正当な認証のように見えます。TGTとTGSの要求は同じユーザーに対するものとなり、推奨される検出機能が適切ではなくなります。

この活動を監視できる方法では異常を調査しますが、アクセスされるリソースの数と、ユーザーがアクセスしたリソースの内容の両方で調べます。攻撃者が高特権リソースにアクセスする可能性が高いので、この活動は新規になります。異常検出は大規模環境では扱いに注意を要する場合があり、攻撃が発見されずに混乱を招く危険性があります。

重要な留意点として、Diamond TicketとSapphire Ticketとの主な違いは、Sapphire Ticketには本物の高特権ユーザーの実際のPACがある点です。Diamond Ticket攻撃とGolden Ticket攻撃では、PACが攻撃者によって変更され、不正確になる可能性があります。この情報を使用して、これらの攻撃を検出できます。

グループメンバーシップの検出

この検出手法の詳細については、「Windowsイベント4627(S): Group membership information」を参照してください。このイベントは、Windowsイベントの4624(S)とともに生成されます。4624(S)のイベントはアカウントのログオン成功を示し、ログオン済みアカウントの所属グループの一覧が表示されます。

図7 Windowsイベント4627.出典: Microsoft

これには、Windows Server 2016、Windows 10以上のOSバージョンが必要です。有効にするには、Audit LogonサブカテゴリでSuccess Auditを有効にする必要があります。

このイベントを監視すると、ユーザーのグループメンバーシップでの不規則性を発見できます。偽造されたチケットにドメイン管理者権限を割り当てたい攻撃者は、ドメイン管理者RID(512)をPACに追加します。したがって、ログイン時にユーザーがドメイン管理者の一部として表示されます。

例として、低特権ユーザー(引き続き「Joe」を使用)をドメイン管理者権限に昇格させるDiamond Ticket攻撃の使用があります(図8と9を参照)。

図8のスクリーンショットでは、Windowsイベント4627に低特権ユーザーが表示される様子が示されています。強調部分は、Joeの名前とドメイン管理者としてのメンバーシップアクセスです。
図8.ドメイン管理者として表示される低特権ユーザー
図9は、Joeが「Members(メンバー)」タブに列挙されるメンバーではないことを示す「Domain Admins Properties(Domain Admins プロパティ)」ウィンドウのスクリーンショットです。
図9 Joeはドメイン管理者のメンバーではない

攻撃者が偽造TGTを使用して高特権ユーザーを偽装する場合、誤ったグループメンバーシップを割り当てる可能性があることは、注目に値します。したがって、それらにも注意を払う価値があります。

誤検知を避けるために(ユーザーが高特権グループに意図的に追加されるとき)、イベント4627をWindowsイベントの4732と4728(ユーザーがグループに追加されると表示)と相関させることができます。

結論

本稿では、関連するKerberos用語を簡単に紹介した後、このような攻撃の実行に必要な権限、およびさまざまな偽造チケット攻撃を監視する重要性について説明しました。さらに、Golden Ticket攻撃と新しい攻撃手法を扱う際に可能な検出アイデアが役立つ可能性ついて考察しました。

偽造チケット攻撃は一見したところ検出困難に思われます。これは、この偽造チケットが最初は正当なものに見えるからです。ただし、疑わしいネットワーク活動、悪意のあるツールの使用、Windowsイベントについて十分な情報が収集されると、効力のあるKerberos攻撃をいくつか検出できる可能性があります。

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

追加リソース

「Detecting and Preventing the Path to a Golden Ticket With Cortex XDR」: パロアルトネットワークス
「CortexXDRによるBronze Bit脆弱性からの保護」: パロアルトネットワークス
「The Essential Guide to XDR」: パロアルトネットワークス
「Understanding Microsoft Kerberos PAC Validation」: Microsoft
「The Kerberos Network Authentication Service (V5)」: MIT
「A Diamond (Ticket) in the Ruff」: Semperis

付録: 用語集

制約付き委任: サービスによって使用できる委任を安全な形で提供します。設定すると、指定サーバーがユーザーの代理で動作できる対象サービスが制約付き委任で制限されます。

DCSync攻撃: Windowsドメインコントローラのアプリケーション プログラミング インターフェイス(API)を悪用して、リモートのドメインコントローラからレプリケーションプロセスを擬似的に再現します。

ドメインコントローラ(DC): コンピュータのネットワークドメイン内でセキュリティ認証要求に応答するサーバーコンピュータです。ネットワークサーバーとして、ドメインリソースへのアクセスをホストに許可します。AD環境でのKDCとして機能します。

ENC-TKT-IN-SKEY: このオプションの指定により、渡される追加TGTからセッション鍵でエンドサーバーのチケットが暗号化されます。

Golden Ticket攻撃: KRBTGTアカウントのパスワードハッシュを持つ攻撃者が、「Golden Ticket」と呼ばれるKerberosのチケット保証チケット(TGT)を偽造する可能性があります。攻撃者はこのチケットを使用して、Active Directoryでアカウントの認証資料を生成できます。

Kerberos: Active Directory環境で主に使用されるネットワーク認証プロトコルです。

Kerberos委任: アプリケーションによるエンドユーザーアクセス認証情報の要求を許可する委任設定です。これにより、アプリケーションは要求元ユーザーの代理でリソースにアクセスできます。

Key Distribution Center (キー配布センター - KDC): 暗号化技術におけるキー配布センターは、機密データやプライベートデータを共有するネットワークユーザーに鍵を提供するシステムです。

KRBTGTアカウント: ローカルのデフォルトアカウントであり、KDCサービスのサービスアカウントとして機能します。

PA-FOR-USER: ユーザーの特定に使用される構造体です。ユーザーの代理で、サービスがユーザー名とユーザーレルムを使用してサービスチケットを要求します。

特権属性証明(PAC): 認証関連情報を示す構造体であり、認証関連情報はドメインコントローラ(DC)で渡されます。PACを認証プロトコルで使用してIDを検証し、認証情報を転送してリソースへのアクセスを制御します。

S4U: ユーザーのTGTをメモリに保持するのを避けるためのKerberos拡張機能です。S4U2SelfとS4U2Proxyで構成されます。

S4U2Proxy: あるサービスに別のサービスへの認証を許可します。

S4U2Self: ユーザーの代理でサービスが自分自身にチケットを要求できます。

サービスプリンシパル名(SPN): サービスインスタンスの一意の識別子です。SPNはKerberos認証で使用され、サービスインスタンスとサービス ログオン アカウントとの関連付けを行います。

Ticket Granting Service (チケット保証サービス - TGS): 指定した目的(ネットワーク サービス アクセスなど)でチケットの使用を検証します。

チケット保証チケット(TGT): KDCが発行するユーザー認証トークンであり、ドメインに連結された特定のリソース/システムでTicket Granting Service (TGS)からのアクセストークン要求に使用されます。

U2U認証: 検証者が長期のサービス鍵にアクセスできないときに認証を実行する手法です。この問題に対処するために、Kerberosプロトコルでは、認証検証機関に対して発行されたTGTのセッション鍵を使用して、KDCから発行されたチケットを暗号化するようにクライアントは要求できます。