権限を昇格するために受約束委任（constrained delegation）を攻撃する

本記事は、Kerberos の委任に関する一連の記事の締めくくりです。読む前に、Active Directory の委任 と Kerberos の委任 の両方に精通していること、そして リソースベースの制約付き委任（resource-based constrained delegation） と 制約なしの委任（unconstrained delegation） がどのように構成され、どのように悪用され得るのかについて概要を説明している、シリーズの以前の記事を読んでおくことをおすすめします。

この記事では、constrained delegation 攻撃により、敵対者が重要なサービスへの特権昇格されたアクセスを得られる仕組みを説明します。

Constrained Delegation

constrained delegation により、管理者は Active Directory のユーザーまたはコンピューター アカウントが委任できるサービスと、使用できる認証プロトコルを設定できます。これは、AD オブジェクトの「委任（Delegation）」タブで設定します。:

アカウントで constrained delegation が設定されると、裏側で次の 2 つのことが起こります。:

• オブジェクトの userAccountControl 属性が “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION” フラグで更新されます。
• msDS-AllowedToDelegateTo 属性には、指定した SPN が設定されます。

制約付き委任（Constrained Delegation）攻撃

理論上、制約付き委任（Constrained Delegation）は、AD アカウントが侵害された場合に生じ得る被害を制限します。しかし、制約付き委任は悪用される可能性があります。つまり、制約付き委任が特定のサービスに対して設定されているアカウントの平文パスワード、またはパスワード ハッシュを攻撃者が入手すると、環境内の任意のユーザーになりすまして、そのサービスにアクセスできてしまいます。たとえば、制約付き委任が Microsoft SQL の SPN に対して設定されている場合、攻撃者はそのデータベースへの特権アクセスを取得できる可能性があります。

攻撃の流れ

次のように仮定します。

• 私たちは IT 環境で足場を確保しました。
• ワークステーション上のローカル管理者権限を持つアカウントを侵害しました。
• 私たちは Mimikatz を使って、ログオン後にメモリに残っていたパスワードハッシュを取得しました。また、関連するアカウント（「notadmin」アカウント）には制約付き委任が設定されています。

つまり、ここまでで得られているのは、私たちが侵入した 1 台のマシンへのアクセスと、制約付き委任が設定されたアカウントのパスワードハッシュだけです。

ステップ 1. 偵察

制約付き委任を悪用するには、3つの重要な要素が必要です。

• 制約付き委任が設定された侵害済みアカウント
• サービスへのアクセスを要求する際になりすますための対象の特権アカウント
• これからアクセスするサービスをホストしているマシンに関する情報

1つ目は手に入ったので、残り2つも入手しましょう。

1.1: まずは、‘notadmin’ アカウントの制約付き委任（constrained delegation）が何に対して設定されているかを見てみましょう：

1.2: これで、constrained delegation が SBPMLAB-DC2 ホスト上の CIFS および LDAP SPN 用に設定されていることが分かりました。では、SBPMLAB-DC2 ホストが一体何なのかを正確に理解しましょう（名前からある程度は察しがつきますが！）。もしかすると、そのコンピューターのグループ所属が手がかりになるかもしれません。

1.3: これは幸運です。このユーザーが委任（delegate）できるアクセス先のマシンはドメインコントローラー（DC）です。次に、このサービスにアクセスする際になりすます（impersonate）のに適したユーザーを見つけましょう。以下の PowerShell コマンドで Domain Admins グループのメンバーを列挙できます：

Get-ADGroup ‘Domain Admins’ | Get-ADGroupMember

‘KevinJ’ アカウントが Domain Admins のメンバーであることが分かりました。これで、constrained delegation を悪用するために必要なピースはすべて揃いました。

ステップ 2. アクセスの獲得

Kekeo のようなツールを使うことで、制約付き委任（constrained delegation）が設定されたアカウントのチケット グラント チケット（TGT）を要求し、なりすましたいアカウントのチケット グラント サービス要求を実行したうえで、対象サービスにアクセスできます。

なお、現時点では対象ホストの C$ 管理共有にアクセスできていない点に注意してください：

2.1. Kekeo を使って、“notadmin” アカウントのパスワード ハッシュを使用し、TGT を要求します：

2.2. TGT が手に入ったので、“notadmin” アカウントが制限されている対象サービスに対して、なりすましたいアカウントの TGS 要求を実行します：

2.3. Mimikatzに戻ることで、 Pass the Ticket を使って、対象ホスト上の CIFS サービスにアクセスできます：

ご覧のとおり、チケットをインポートすると、ドメイン コントローラー上の C$ 管理共有に移動できます。つまり、NTDS.dit ファイルのコピーを盗み、オフラインでユーザー パスワードを解読しようとする可能性があります。

委任（Delegation）ベースの攻撃への対策

委任（delegation）に関連する攻撃への防御における重要な手法の1つは、委任してはならない機密アカウントを Protected Users グループに入れるか、Active Directory Users and Computers の［アカウント］タブで「Account is sensitive and cannot be delegated」チェックボックスをオンにすることです：

より広範な保護のために、Netwrix Active Directory Security Solution も検討してください。無制限の委任（unconstrained）と制限付きの委任（constrained）がどこで設定されているか、また制限されている特定のサービス アカウントが何かを明確に把握できる包括的なレポートを提供します。この情報を活用することで、リスクを低減し、環境をより効果的に保護できます。さらに、巧妙な脅威を容易に検知し、対応を自動化して、その影響を軽減することも可能です。

よくある質問(FAQ)

制約付き委任（constrained delegation）攻撃とは何ですか？

制約付き委任（constrained delegation）攻撃とは、攻撃者がサービスアカウントに付与された権限を悪用して、標的のシステムやサービスへの不正アクセスを取得するタイプのサイバー攻撃です。サービスアカウントを侵害する、またはサービス間の Kerberos トラフィックを傍受して操作することで、攻撃者はユーザーになりすまし、サービスアカウントがアクセスを許可されている他のサービスに対して不正アクセスを行うことができます。この種の攻撃は、無制約の委任（unconstrained delegation）攻撃よりも実行が難しい場合がありますが、それでもネットワークセキュリティに対する深刻な脅威です。

制約付き委任（constrained delegation）と無制約の委任（unconstrained delegation）とは何ですか？

制約付き委任（constrained delegation）と無制約の委任（unconstrained delegation）は、Kerberos 認証プロトコルを設定して、サービスがユーザーになりすまして他のサービスにアクセスできるようにするための 2 つの方法です。無制約の委任では、サービスがユーザーになりすまして Active Directory ドメイン内のあらゆる別のサービスにアクセスできます。一方、制約付き委任では、ユーザーの代わりにサービスがアクセスできるサービスがどれかを指定することで、委任の範囲を制限します。

無制限の委任（unconstrained delegation）とはどういう意味ですか？

無制限の委任（unconstrained delegation）とは、サービスがユーザーになりすまして（impersonate）Active Directory ドメイン内の他のあらゆるサービスにアクセスできるようにする Kerberos の委任設定です。この種の委任は、攻撃者がネットワーク内で横方向に移動し、機密データやシステムへのアクセスを得るために悪用される可能性があります。

無制限の委任（unconstrained delegation）が良くないのはなぜですか？

無制限の委任（unconstrained delegation）は、攻撃者がネットワーク内で横方向に移動して、機密データやシステムへのアクセスを得られる可能性があるため、良くないとされています。その代わりに、委任の範囲を制限し、攻撃が成功するリスクを下げられる制約付きの委任（constrained delegation）を使用することが推奨されます。