Active Directoryにおける「SPN」設定ミスがアカウントロックアウトを伴わないKerberoastingを可能にする

Active Directoryでよく見られる設定ミスの一つに、サービスプリンシパル名(SPN)を通常のユーザーアカウントに割り当ててしまうというものがあります。

この設定ミスはKerberoasting攻撃への見落とされがちな侵入経路となり、攻撃者は特権アクセスを必要とせず、またアカウントロックアウトを引き起こすこともなく、認証情報を窃取できてしまいます。

Kerberoastingは通常、SQL Server、Webアプリケーション、LDAPといったサービスを識別するためにKerberosが利用するSPNを保持する、Active Directoryのサービスアカウントを標的にします。

ドメインユーザーは、あるSPNに対してKerberosのチケット発行サービス(TGS)チケットを要求できます。このチケットには、対象のサービスアカウントに紐づくパスワード由来の鍵で暗号化されたデータが含まれています。

Active DirectoryにおけるSPN設定ミス

攻撃者はこのチケットをオフラインに持ち出し、解読を試みることができます。オンラインのログインページに対して繰り返しパスワードを試行する場合と異なり、オフラインでの解読は認証失敗イベントを発生させず、アカウントロックアウトのカウンターも増加させません。

標的となったアカウントが弱いパスワードや推測しやすいパスワードを使用していた場合、攻撃者は通常ログイン失敗によって残る痕跡を一切残すことなく、認証情報を復元できてしまう可能性があります。

Trellixの研究者であるMaulik Maheta氏とHenry Bernabe氏は、標準的なユーザーアカウントに割り当てられたSPNが検知作業を複雑にする可能性があると警告しています。

セキュリティチームは通常、不要なSPN、過剰な権限、期限切れが近い認証情報、脆弱な暗号化方式などがないか、サービスアカウントの棚卸しとレビューを行っています。しかし、通常のユーザーアカウントについては、こうした精査が手薄になりがちです。

比較ホームセキュリティシステム

これは軽視できない見落としです。というのも、SPNが割り当てられたユーザーアカウントは、通常のサービスアカウントと同様にKerberoastingの標的になり得るからです。すでに有効なドメイン認証情報を入手している攻撃者は、環境全体のSPNを列挙し、通常とは異なるアカウントとSPNの紐づきを特定した上で、価値の高い標的に対してチケットを要求できます。

設定ミスは、Active Directoryにおける権限委任からも生じる可能性があります。例えば、別のディレクトリオブジェクトに対してGenericWrite権限を持つアカウントは、組織の通常のサービス導入プロセスを経ずに、そのオブジェクトのSPN属性を変更できてしまう可能性があります。

変更後のSPNは正規のサービス識別子のように見えるため、攻撃者はそのアカウントをKerberoastingの標的に転用できてしまいます。

このような状況は、ID管理上の見落としを、認証情報の窃取や横展開、権限昇格を可能にする攻撃経路へと変えてしまいます。

Active DirectoryがKerberosサービスチケットに対してRC4-HMAC暗号化を引き続き許可している場合、リスクはさらに高まります。暗号化タイプ0x17で表されるRC4-HMACは、現代のKerberos暗号化オプションと比べて脆弱であると広く認識されており、Kerberoastingと関連付けられることが多い方式です。

TGSチケットを取得した後、攻撃者はキャッシュされたチケットデータをエクスポートし、パスワード解析ツールを使ってオフラインで解読できます。解読に成功すると、背後にあるアカウントのパスワードが判明し、それが他のシステムやサービスへのアクセスに再利用されるおそれがあります。

さらに、窃取されたKerberosチケットはパスザチケット攻撃に悪用される可能性があり、攻撃者は平文パスワードを再度入力することなく、チケットの正規の持ち主として認証を突破できてしまいます。

この一連のプロセスが特に厄介なのは、隠密性と持続性を兼ね備えている点にあります。問題のあるSPN割り当ては、管理者がそれを特定して削除するまでそのまま残り続けます。一方でオフラインでの解読は、防御側がパスワード攻撃の検知に頼りがちなログイン失敗のイベントを一切発生させません。

防御側はまず、指定されたサービスアカウントに紐づくものだけでなく、ドメイン内のすべてのSPNを監査することから始めるべきです。セキュリティチームは、一般の従業員アカウントや管理者アカウントに割り当てられたSPNを調査し、それぞれの紐づけが正規のサービスを裏付けているかを検証するとともに、ユーザーがディレクトリ属性を変更できる委任権限を見直す必要があります。

比較ホームセキュリティシステム

その他の防御上の優先事項は以下のとおりです。

  • 影響を受けたアカウントのパスワードをリセットし、サービスアカウントには長く一意な、できればマネージドな認証情報の使用を義務付ける
  • 不要なSPNを削除し、承認済みのアカウントとサービスの紐づけを文書化する
  • 互換性が許す範囲でRC4-HMACを無効化し、より強固なKerberos暗号化方式を優先する
  • Kerberos TGS要求を監視する。特に異常な件数、見慣れないリクエスト元ホスト、ユーザーに紐づくSPNに対するチケット発行に注意する
  • PowerShellによるSPN列挙、ディレクトリ属性の変更、チケットのエクスポート動作、不審な認証情報アクセスツールについてアラートを設定する

Trellixによると、同社のネットワーク検知・対応(NDR)プラットフォームは、認証情報の窃取や横展開が発生する前の段階で、SPNの列挙行為を検知していました。

同社の調査ワークフローは、この活動をMITRE ATT&CKの技術T1558.003(Kerberoasting)に紐づけ、要求を行ったユーザー、標的とされたSPN、エンドポイント、プロセス、対応措置を相関分析しました。

ここから得られる教訓はシンプルです。SPNは単なるサービス設定上の詳細事項ではありません。誤ったアカウントに紐づけられたり、誤った権限主体によって変更可能な状態になっていたりすると、従来のロックアウトに基づく防御をすり抜ける、潜在的な認証情報窃取の手段になり得るのです。

調査の遅れによるインシデントを防止しましょう。15,000のSOCが活用する脅威インテリジェンスで、Tier 1の対応力を強化できます。 SOCにTI Lookupを統合する

翻訳元: https://gbhackers.com/active-directory-spn-misconfigurations-enable-kerberoasting/

本記事は gbhackers.com の記事を翻訳・要約したものです。