新しい攻撃経路? ASリクエストのサービスチケット

Jul 18, 2023

ホーム » サイバーセキュリティ » SBN ニュース » 新しい攻撃経路? ASリクエストのサービスチケット

Andrew Schwartz の Kerberos FAST の投稿を手伝っているときに (FAST とは何か、どのように機能するかについて詳しく説明しているので、ぜひ読んでください)、興味深いことに気づきました。 マシン アカウントの AS-REQ は保護されていません。 これについては Microsoft が次のように説明しています。

Kerberos 保護では、デバイスのチケット認可チケット (TGT) を使用して KDC との認証サービス交換を保護するため、コンピューターの認証サービス交換は保護されません。 ユーザーの TGT は、KDC との TGS 交換を保護するために使用されます。

このため、認証サービス (AS) にサービス チケット (ST) を要求できるかどうか疑問に思いました。 AS に ST を要求できると、新たな攻撃パス、検出バイパス、セキュリティ制御の潜在的な弱体化など、いくつかの影響が生じます。 この投稿で説明したすべての問題は Microsoft に報告され、「仕様によるものとみなされました」(図 1)。

まず、典型的な Kerberos フローの概要を次に示します (図 2、ADSecurity から引用)。

チケットごとにセッション キーが発行されるという事実は、次の調査にとって重要な特徴です。 このセッション キーは、応答の暗号化されたセクション内で要求元のアカウントに返されます。 暗号化キーは要求者にすでに知られています。

たとえば、TGT セッション キーは、TGT を要求するときに要求者の ID を証明するために使用されるキーで暗号化されたセクション内に保存されます。 このキーは通常、アカウントの長期キー (パスワード ハッシュ) です。 ただし、Kerberos プロトコルの初期認証用公開キー暗号化 (PKINIT) の場合、キーは証明書から派生します。 ST セッション キーは、TGT セッション キーで暗号化されたセクション内に保存されます。

チケット セッション キーは、Kerberos フローの次のステップでチケットを使用するために必要です。

Kerberos リクエストには 2 つの主要なセクションがあります。

req-body はほとんどが平文で送信され、いくつかの情報が含まれています。

Kerberos 応答にはいくつかのセクションがあり、暗号化された部分が含まれています。

この投稿で焦点を当てる Kerberos フローの部分は AS-REQ/AS-REP で、通常は TGT を要求するために使用されます。 通常の動作では、AS-REQ はその中に 2 つの値のうちの 1 つを持ちます。脱ぐreq-body 内のフィールド:

Kerberos Flexible Authentication Secure Tunneling (FAST) が適用されていても、マシン アカウントは保護されていない状態で AS-REQ を送信していることに気付きました。 TGT ではなく AS-REQ を使用して ST を直接リクエストできるかどうか疑問に思いました。 このため、Rubeus を変更して、脱ぐ AS-REQ の場合、DC はその SPN の ST で応答します。 結局のところ、答えは「はい」でした (図 3)。

マシン アカウントを使用すると、FAST が強制されているときにアーマーリングを使用せずに ST をリクエストできます。 他に何が可能ですか?

Tim Medin によって発見された Kerberoasting は、サービス アカウント (通常は SPN を持つユーザー アカウント) の平文パスワードまたは NT ハッシュを回復する方法です。 ST の一部がサービス アカウントの長期キー (パスワード ハッシュ) で暗号化されているため、Kerberoasting が可能です。 チケットの暗号化部分を抽出すると、さまざまな平文パスワードからハッシュを作成し、暗号化部分の復号化を試みることができます。 復号化が成功した場合、使用されるハッシュはチケットの暗号化に使用される長期キーです。 そのキーは最終的にサービス アカウントとして認証するために使用できます。

さらに、どのアカウントでも、どのサービスに対しても ST をリクエストできます。 したがって、攻撃を実行するには、Active Directory (AD) に対して認証する機能が必要です。 少なくとも、かつてはそれが真実でした。

まず、事前認証（DONT_REQ_PREAUTH）を必要としないアカウントを使用して ST をリクエストしようとしました。 アカウントの認証に事前認証が必要ない場合は、何らかの形式の資格情報 (パスワード ハッシュ、証明書など) で暗号化された事前認証データを必要とせずに TGT を要求できます。 攻撃者がアカウントの有効な資格情報を取得していない場合、有効な事前認証を生成できません。 事前認証が必要ない場合、これは問題ありません。

事前認証なしでチケットが要求された場合、結果には暗号化された部分が含まれます。 この暗号化部分は、認証に使用される資格キーで暗号化され、応答に含まれるチケットのセッション キーが含まれます。 これは、Will Schroeder による ASREProast 攻撃で使用された暗号化データです。 TGT セッション キーが必要であるため、結果として得られる TGT は、要求元のアカウント キーにアクセスする場合にのみ使用できます。

ただし、Kerberoasting の場合、セッション キーへのアクセスは必要ありません。 結果として得られる ST (より正確には、要求元のアカウント キーで保護されていない ST の暗号化された部分) のみが必要です。 したがって、アカウントが事前認証を必要としないように構成されている場合は、事前認証なしで Kerberoast を実行できます。どれでも資格。 この Kerberoasting の方法は、この PR 内の Rubeus に実装されています。

有効なアカウントへのアクセスがまだ確立されていないため、LDAP をクエリできません。 代わりに、潜在的なサービス アカウントのリストが必要です。 Arseniy Sharoglazov による以前の調査では、実際の SPN を必要とするのではなく、サービス アカウントのユーザー名のみを使用して ST をリクエストできることが示されており、この調査には非常に役立ちます。

ユーザー名のリストは、DC 上のヌル セッションを使用したユーザーの列挙、オープンソース インテリジェンス (OSINT) を使用したユーザー名のリストの生成、潜在的なユーザー名の推測など、いくつかの方法で生成できます。 潜在的なユーザー名のリストは、事前認証なしで AS-REQ を送信することで簡単に検証できます。 事前認証を必要とする有効なユーザー名は、KDC_ERR_PREAUTH_REQUIREDエラーが発生します (図 4)。

事前認証を必要としない有効なユーザー名は TGT を受け取ります (図 5)。

無効なユーザー名は、KDC_ERR_C_PRINCIPAL_UNKNOWNエラーが発生します (図 6)。

図 7 に示すように、デモンストレーションの目的で、enum4linux-ng の RID サイクリング メソッド (-R) を使用して、DC 上のヌル セッションを使用してリストが生成されます。

このユーザー名のリストを使用すると、AD で事前認証を必要としないアカウントを簡単に判断できます (図 8)。

事前認証のない AS-REQ は、アカウントが事前認証を必要としない場合を除き、Windows イベントとして記録されないことに注意してください。

ユーザー名のリストと事前認証を必要としないアカウントのユーザー名を使用して、攻撃を開始できます (図 9)。

結果の出力は、オフラインでのパスワードクラッキングを試みるために使用できます。

もう 1 つの興味深い結果は、中間者 (MitM) の位置から Kerberoast を実行できることです。 通常、このタイプの攻撃は TGS-REQ では不可能です。CKサム AP-REQ 内のオーセンティケーター内のフィールドは、要求の req-body を保護し、正規の Windows Kerberos クライアントに含まれることがよくあります。 したがって、脱ぐオーセンティケータ内のチェックサムを更新せずに TGS-REQ を実行すると、オーセンティケータのチェックサムが無効になり、KRB_AP_ERR_MODIFIEDエラー。 しかし、これは AS-REQ にとっては問題ではありません。要求本体、その結果、脱ぐフィールドは保護されません。

このアプローチをテストしているときに、AS-REQ は何度も再生できることがわかりました。 攻撃者は、異なる AS-REQ を多数送信するために 1 つの AS-REQ をキャプチャするだけで済みます。脱ぐ価値観。

このアプローチを実証するために、大まかな概念実証 (POC) を作成しました。 この POC である RoastInTheMiddle は、DC と被害者システムの間に ARP スプーフィングを実装して、MitM 攻撃を実行します。 その後、POC は AS-REQ をリッスンしながらトラフィックを通過させます。 AS-REQ が見つかると、POC は Kerberoast を実行します。 POC は攻撃の準備ができていませんが、攻撃が可能であることを示しています。

まず、POC は、スニファー、ARP スプーファー、再アセンブラー (複数のパケットに分割されたリクエスト用)、およびロースターの 4 つのスレッドを開始します (図 10)。

AS-REQ を検出すると、POC は提供されたリストの Kerberoast 試行を開始します。リストにはユーザー名または SPN が含まれる可能性があります (図 11)。

図 11 に示すように、この試みにより、受信した ST がハッシュキャット形式で出力され、オフラインでのパスワード クラッキングの準備が整います。

AS-REQ を MitM して変更し、再生する機能は、他の攻撃の開発にも役立つ可能性があります。 kdc-options を変更して、代理可能なフラグ。これにより、次のチケットが生成されます。代理可能なフラグセット。 しかし、そのチケットとフラッグを使った攻撃経路を見つけることができませんでした。 この動作により、他のアカウントを使用して Kerberoast を実行できるようになる可能性があり、攻撃者が侵害されたアカウントの書き込みを回避できるようになります。

このプロセスでは、いくつかの改善が可能になる可能性があります。 まず、AS-REQ をインターセプトし、KRB_AP_ERR_BAD_INTEGRITYエラー。 これを行うと、クライアントは AS-REQ を送信して再認証することが強制されます。

また、DHCPv6 ネームサーバー インジェクション (Dirk-jan Mollema の mitm6 や Kevin Robertson の Inveigh など) を使用してこの攻撃を実行し、LDAP サービスの SRV DNS クエリに応答し、次の LDAP 接続を処理することも可能です。

変更のサポートタイプWill Schroeder がここで説明しているように、リクエスト内では、環境が許せば暗号化タイプのダウングレード攻撃が可能になります。

最後に、POC では、主に ARP スプーフィングのために、POC (sharppcap を使用する) を実行しているシステムに Npcap をインストールする必要があります。 IPv6 ルートを選択するか、生のソケットを使用して ARP 応答を実装する場合は、この依存関係を削除できます。

Kerberos 検出の多くは 4769 イベント (Kerberos サービス チケットが要求されました) に依存しています。 ただし、AS-REQ を使用してサービス チケットを要求すると、4769 イベントではなく 4768 イベントが生成されます (Kerberos 認証チケット (TGT) が要求されました)。

図 12 は、AS-REQ を使用して ST が要求されたときの 4768 イベントを示しています。

したがって、この方法を使用する攻撃者は、4769 イベントに依存する多くの検出を簡単に回避できます。

AS から S4U2self チケットをリクエストできませんでしたが、AS から取得した ST にはチケット チェックサムがありません (Jake Karnes によるブロンズ ビット攻撃から S4U2self チケットを保護するために導入されました)。

最後に、TGS から要求された ST は通常、PAC とともに返されます (図 13)。

TGS から PAC なしで ST をリクエストすることは可能ですが、その場合はサービス アカウントを変更する必要がありますNO_AUTH_DATA_REQUIREDuseraccountcontrol 属性のビット (図 14)。

この設定が行われている場合、返されたチケットのサイズの違いが示すように、返された ST には PAC がありません (図 15)。

PAC なしの ST は、PA-PAC-OPTIONS PA データ セクションを false に設定するだけで AS から要求できます。/nopacルベウスに切り替えます (図 16)。

このアプローチは、PAC なしで ST をリクエストし、それをenc-認可データリクエストのセクション。 また、他の潜在的な攻撃経路を提供する可能性もあります。

Microsoft はこれらの問題を修正する価値があるとは考えていないため、組織内から検出することが唯一の選択肢です。 前に示したように、AS から ST が要求されると、イベント 4768 がログに記録されます (図 17)。

このイベントでは、サービス名とサービス ID が一致していないことがわかります。krbtgt。AS からリクエストされたすべての本物のチケット。カドミン/changepwチケットのサービス名とサービス ID は、かぶとgt(図18)。

ネットワーク トラフィックに対象外の AS-REQ がないかチェックしています。krbtgt/ドメインまたはカドミン/changepwはこれらのリクエストも検出する必要があります (図 19)。

この調査と Microsoft の対応は、継続的な監視と適切な強化措置の必要性を示しています。現在の検出を回避し、認証されていない位置から Kerberoasting などの効果的な攻撃を実行できる能力は、無視すべきではない重大な問題です。 ここで説明した研究はさらなる新たな攻撃につながり、組織をより高いリスクにさらす可能性があります。

このようなタイプのチケット要求が行われたときに、検出が行われるようにしてください。

この研究への貢献を次の方々にお願いします。

新しい攻撃経路? AS リクエスト サービス チケットは、Semperis に初めて登場しました。

*** これは、Charlie Clark が執筆した Semperis の Security Bloggers Network シンジケート ブログです。 元の投稿を読む: https://www.semperis.com/blog/new-攻撃-paths-as-requested-sts/