無制限の委任

無制限の委任は、深刻なサイバーセキュリティ上のリスクを意味します。Active Directory の委任コントロールが、AD 環境内のユーザーおよびコンピューター オブジェクトに適用されている点を悪用するための手順を取ることで、攻撃者は横方向に移動し、さらにドメインを支配することさえ可能になります。

この記事では、この攻撃分野（unconstrained delegation：非制約の委任）を掘り下げ、セキュリティチームや管理者がこのセキュリティリスクを軽減するための効果的な戦略を紹介します。

unconstrained delegation（非制約の委任）とは何ですか？

委任（Delegation）により、ユーザーまたはコンピューターが別のアカウントになりすまして、リソース（バックエンドのデータベースサーバーなど）にアクセスできるようになります。委任にはいくつかの実用的な用途があり、Microsoftはこの記事でそれらを解説します。

ユーザーまたはコンピューターアカウントの「委任（Delegation）」タブを使用すると、unconstrained delegation（非制約の委任）またはconstrained delegation（制約付きの委任）を設定できます。

• 「Trust this computer for delegation to any service (Kerberos delegation only),」を選択すると、unconstrained（非制約）
• また、特定の Service Principal Names (SPNs) を指定することで、ユーザーまたはコンピューターがなりすませるサービスを制限することもできます。これは 制約付き 委任です。

もう一つの選択肢として リソースベースの制約付き委任（RBCD）があります。これは、リソースにアクセスするアカウントではなく、リソース側で委任を構成する方式です。RBCD は Windows PowerShell を使ってセットアップできます。

無制約の委任（unconstrained delegation）のリスクは何ですか？

無制約の委任（unconstrained delegation）には、いくつかの攻撃が仕掛けられます。なかには harmj0y のこのブログ記事で取り上げられているものもあり Sean Metcalf が他の手口を説明しています。いくつか見てみましょう。

例 1：無制約の委任（unconstrained delegation）を悪用して AD フォレスト全体を侵害する

セキュリティ研究者は、 あるフォレスト内で無制限委任（unconstrained delegation）を有効にしたマシンを攻撃者が侵害すると、別のフォレストとその中のすべてのドメインを侵害できる ことを示しています。双方向の信頼（two-way trust）が設定されている場合、攻撃者は MS-RPRN のプリンタの不具合（printer bug）を利用して、DC（ドメイン コントローラー）が認証情報を攻撃者へ送り返すように仕向けることができ、その結果として DCSync を使って信頼されたドメインを侵害できます。たとえば、会社が小規模な会社を買収し、そのドメインを自社のドメインに参加させたとします。このとき、小さな環境内のシステムを侵害した攻撃者は、自社の会社全体のフォレストを乗っ取る可能性があります。これは間違いなく良くありません。

この不具合の修正を提供するために、KB article が公開されました。また、Windows Server 2012 以降にはこれを防ぐためのセキュリティ設定がありますが、デフォルトでは 有効になっていない可能性があります。

例 2：無制限委任（unconstrained delegation）を悪用して横方向への移動を可能にする

別のシナリオです。あるコンピューターで無制限委任（unconstrained delegation）が有効になっていると、そのコンピューターにアカウントが接続するたびに、Key Distribution Center（KDC）から発行されたチケット授与チケット（ticket-granting ticket、TGT）が、後でそのコンピューターが利用できるようにメモリに保存されます。もしそのマシンが侵害されると、攻撃者はその TGT を取得して悪用し、大きな被害を与えることができます。特に、その TGT が権限の非常に高いユーザーのものである場合はなおさらです。

たとえば、Domain Admin が共有フォルダーにアクセスすることで、Common Internet File System（CIFS）経由で特定のコンピューターにアクセスすると仮定します。無制限委任（unconstrained delegation）が有効になっていない場合、メモリに保存されるのはチケット授与サーバー（ticket-granting server、TGS）のみです。このチケットではローカル マシン上の CIFS サービスにしかアクセスできないため、攻撃者はそれを使って横方向への移動（lateral movement）を行うことはできません。Mimikatz のコマンド sekurlsa::tickets /export を使うと、ユーザーのサービス チケット（TGS）だけが返ってくることが分かります:

ただし、無制限委任（unconstrained delegation）が有効になっている場合、コマンドは管理者アカウントの TGT を返し、攻撃者はそれを Pass-the-Ticket 攻撃で使用して、ドメイン全体を侵害することができます。

システムに接続する任意のユーザーから TGT を収集するために、攻撃者は次の PowerSpoit コマンドを使用できます：

無制限委任（unconstrained delegation）を有効にするために必要な権限

オブジェクトの委任コントロールを管理できるようにするには、ユーザーに次の権限が必要です：

• SeEnableDelegationPrivilege（ユーザー権限）は、ドメイン コントローラーのローカル security policyによって制御され、次の Group Policy setting “Enable computer and user accounts to be trusted for delegation”を通じて管理されます（以下に示すとおり）。
• コンピューターの msDS-AllowedToDelegateTo および userAccountControl 属性を更新できること。ここにこの Group Policy の設定 が保存されます

制約なしの委任（Unconstrained Delegation）を見つける

制約なしの委任（unconstrained delegation）が有効になっている場所を確認するには、次の PowerShell スクリプトを使用できます。すべてのコンピューターのユーザー アカウント制御（UAC）値を確認し、制限なしで委任が有効になっている場所を特定します。

さらに、誰が SeEnableDelegationPrivilege 権限を付与されているかも確認するとよいでしょう。これには、PowerSploit と Get-DomainPolicy コマンドを使用できます。

制約なしの委任（Unconstrained Delegation）によるリスクを低減するためのベストプラクティス

制約のない委任（unconstrained delegation）によるリスクを低減するには、次を推奨します:

• 本当に無制約の委任（unconstrained delegation）が必要かどうかを調査してください。多くの場合、無制約の委任は誤って有効化されており、完全に無効化するか、制約付き委任（constrained delegation）またはリソースベースの制約付き委任（resource-based constrained delegation）に変換できます。 制約付き委任アカウントを侵害された攻撃者は、DC（ドメイン コントローラー）上の任意のサービスに対して、DC 上の任意のユーザーになりすますことができるため、制約付き委任をドメイン コントローラー（DC）に設定することは推奨されません。
• “This account is sensitive and cannot be delegated” オプションを使用して、機密性の高いアカウントが委任に使用されないようにします。
• 特権ユーザーを Protected Users グループに配置します。これにより、委任に悪用されることを防ぎ、認証後に TGT がコンピューターに残らないようにできます。
• 委任されたアカウントのアクティビティを厳密に監視してください。何らかの種類の委任が設定され、使用されているすべてのシステムでは、不審な活動がないか監視する必要があります。

Netwrix はどのように支援できますか？

無制限の委任（Unconstrained delegation）は、悪意のある者が Active Directory 環境にアクセスして持続化（persistence）を作り出すために悪用できる、多数の攻撃ベクトルの1つです。Netwrix Active Directory Security Solution を使えば、次のことができます：

• 不要な委任、過剰な権限、常駐特権（standing privileges）、GPO の誤設定などのセキュリティリスクを特定し、対策（緩和）の優先順位を付けられます。
• IT インフラ全体にわたって安全な設定を確立し、強化された基準（hardened baseline）からの不適切な変更を特定して是正することで、それらを維持できます。
• Kerberoasting、DCSync、dit extraction、Golden Ticket などの高度な脅威を迅速に検知して対応できます。Kerberoasting、 DCSync、 dit extraction および Golden Ticket 攻撃。
• 既知の攻撃への対応を自動化して、被害を最小限に抑えます。
• セキュリティ侵害やその他のインシデントが発生した場合に、Active Directory を迅速に復旧できるようにします。

よくある質問

Active Directory ではどのような委任（デリゲーション）を利用できますか？

組織で利用できる委任（デリゲーション）は 3 種類あります。

• 無制約の委任
• 制約付きの委任
• リソースベースの制約付き委任（RBCD）

リソースベースの制約付き委任（RBCD）とは？

RBCD では、リソースを所有する管理者が、そのリソースへのアクセスを委任できます。

RBCD をどのように構成すればよいですか？

リソース サービスを構成して、ユーザーに代わってアクセスを許可するには、Windows PowerShell のコマンドレット（New-ADComputer, New-ADServiceAccount, New-ADUser, Set-ADComputer, Set-ADServiceAccount および Set-ADUser）を、次のパラメーター PrincipalsAllowedToDelegateToAccount で実行します。