デジタルペンテスト部でペネトレーションテストを担当している小松奈央です。
2019年にActive Directoryにおけるリソースベースの制約付き委任（Resource-Based Constrained Delegation; RBCD）を悪用する攻撃手法（以下、RBCD攻撃）が発表されて以降、弊社ペネトレーションテストサービスではRBCD攻撃に対して脆弱な環境を決して少なくない件数発見し、お客様にご報告してきました。
そこで本記事では、RBCD攻撃が成立する環境を作り込んでしまう原因となる、不適切な運用パターンについて解説します。
なお、本記事ではRBCD攻撃の原理や具体的な攻撃方法については解説しません。詳しく知りたい方は参考文献をご確認ください。 また、RBCD攻撃の対策方法については、以前書いた以下の記事で解説しています。こちらも合わせてご確認ください。
免責事項
当記事の内容は教育・学習およびセキュリティの向上目的で執筆されており、サイバー攻撃行為を推奨するものではありません。
第三者が所有する資産に管理者の許可なく攻撃行為を行うと各種の法律に抵触する可能性があります。
当記事の内容を使用して起こるいかなる損害や損失に対し、当社は一切責任を負いません。
RBCD攻撃とは
RBCD攻撃とは、攻撃者がターゲットとなるActive Directory環境へ侵入後、他の端末への横展開や、ドメイン内での権限昇格を行うための攻撃手法の1つです。 これはActive Directoryにおける「リソースベースの制約付き委任（Resource-Based Constrained Delegation; RBCD）」と呼ばれる機能を悪用します。
本来は特定のサービスへアクセスする権限を委任するための仕組みであり、フロントエンドサービスとバックエンドサービスがそれぞれ異なるドメインに属しているなどといったドメインをまたいで委任を行いたい場合などに用いられます。
これを実現するためには、委任先ホストにおけるmsDS-AllowedToActOnBehalfOfOtherIdentity属性に対して委任元ホストを登録する必要があります。
これにより、委任元ホストの権限で任意のユーザとして委任先ホストのサービスへアクセスできるようになり、攻撃者はこれを悪用して委任先ホストへの侵入を試みます。
RBCD攻撃の問題は、これらの操作にドメイン管理者権限を必要としない点にあり、委任先ホストのmsDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込み権限を持つユーザアカウントであれば委任元ホストの登録が可能です。
つまり、攻撃者が特定の端末におけるmsDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込み権限を持つユーザアカウントを侵害した場合に、RBCD攻撃によってその端末へ侵入される可能性があります。
RBCD攻撃に対して脆弱な環境の例
それでは、実際のペネトレーションテストでも検出されるRBCD攻撃に対して脆弱な環境の例を見ていきましょう。
以下の図は、弊社検証環境上にRBCD攻撃に対して脆弱な環境を再現し、BloodHound1というツールを用いてActive Directory上のオブジェクトを可視化したものです。
ここではCypherクエリによる検索機能を利用し、「Domain UsersグループがWriteAccountRestrictions権限2（上述したmsDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込み権限が含まれる）を持つドメインコンピュータを表示する」という条件でオブジェクトを表示しています。
この図からは、Domain Usersグループが5つのコンピュータオブジェクトに対してWriteAccountRestrictions権限を持っていることがわかります。
この検証環境は6台のホストで構成されているため伝わりづらいですが、実際の環境でもDomain UsersグループがActive Directory上のほぼすべてのコンピュータオブジェクト（環境の規模によっては数千から数万程度）に対してWriteAccountRestrictions権限を持っていることがあります。
そして、Domain Usersグループにはすべてのドメインユーザが所属しているため、このような環境ではすべてのドメインユーザが、ほぼすべてのドメインコンピュータに対して侵入できる可能性3があり、非常に危険な状態にあると言えます。
RBCD攻撃に対して脆弱になる不適切な運用パターン
なぜこのような環境が生まれるのか、その要因となる運用方法について解説します。
前提として、WriteAccountRestrictions権限が意図せず付与されている場合、端末をドメインに参加させる際の運用方法が原因である可能性が考えられます。
技術的な理解のしやすさから、まずはRBCD攻撃の影響が限定的な2つの運用パターン①と②について説明し、最後に上述したRBCD攻撃に対して最も脆弱な環境を運用パターン③で説明します。
運用パターン①
まず、最もシンプルな運用として、ユーザが自身のアカウントを用いて自分で端末をドメインに参加させるパターンを考えてみます。
この場合、参加させた端末のコンピュータオブジェクトに対するWriteAccountRestrictions権限が、端末参加時に使用したユーザのアカウントに付与されます。
環境全体としては、以下の図のようにそれぞれの端末に対してドメイン参加時に使用したアカウントがWriteAccountRestrictions権限を持っている状態になります。
この運用方法は、各端末のキッティング作業をそれぞれのユーザが行うことになるほか、ユーザが自由に端末を持ち込みドメインに参加させられる可能性があります。
そのため、規模の大きい企業ほど現実的ではなく、実際に採用されていることは少ないと考えられますが、WriteAccountRestrictions権限が付与される状況のイメージがつきやすいと思います。
RBCD攻撃による影響という観点では、攻撃者によってあるユーザアカウントが侵害された場合、そのユーザアカウントを用いてドメインに参加させた端末に限って横展開される可能性があり、影響の程度は横展開先端末の機密性／重要性に依存します。
運用パターン②
次に、キッティング担当者がドメイン参加専用のアカウントを用いて端末をドメインに参加させるパターンを考えます。
この場合、以下の図のようにすべての端末に対してドメイン参加専用のアカウントがWriteAccountRestrictions権限を持っている状態になります。
この運用方法は、最小権限の原則に則ってドメイン参加専用アカウントに必要最低限の権限のみを与えておくことで、ドメイン管理者アカウントのような高権限アカウントを使用することなく端末をドメインに参加させることができます。 また、一般ユーザのアカウントからドメイン参加に必要な権限（コンピュータオブジェクトを作成する権限など）を削除できるため、ユーザが勝手に端末を持ち込みドメインに参加させるといった事象を防ぐことができます。 これらの理由から、この運用方法を採用している企業は少なくないと考えられます。
一方で、ドメイン参加専用アカウントが攻撃者に乗っ取られてしまった場合、多数の端末に対してRBCD攻撃が成立してしまう可能性があります。 そのため、ドメイン参加専用アカウントには、ドメイン管理者アカウントと同等レベルの保護や監視が求められます。
運用パターン③
運用パターン①と②の場合、Active Directory上のコンピュータオブジェクトは端末のドメイン参加と同時に作成されます。 そのため、コンピュータオブジェクトがドメイン参加によって作成された後に、適切なOU（Organizational Unit）に配置し直す必要があります。
このような手間を省くためなどの理由から、あらかじめActive Directory上にコンピュータオブジェクトを作成しておき、後から実端末とコンピュータオブジェクトを紐づける運用を行っている場合があります。 事前にコンピュータオブジェクトを作成し適切なOUに配置しておくことで、端末がドメインに参加するのと同時に適切なグループポリシーを適用することができます。
しかし、この運用には大きな注意点があります。
以下の図は、ドメインコントローラのADUC（Active Directory Users and Computers）からコンピュータオブジェクトを新規作成する際の画像です。
図のように、コンピュータオブジェクトを作成する際は「User or group」にドメインユーザかドメイングループを指定する必要があります。 これは、端末をドメインに参加させる際に使用するアカウントを指定するものであり、ここで指定したアカウントのみがこのコンピュータオブジェクトに紐づける端末をドメインに参加させることが可能となります。
「User or group」にはデフォルトでDomain Adminsが設定されていることから、初期設定のままではDomain Adminsに所属するアカウントしか端末をドメインに参加させられません。
そのため、Active Directoryの管理者と実際に端末をドメインに参加させるキッティング担当者が異なる場合など、ドメイン管理者アカウント以外のアカウントでドメイン参加を行いたい場合には、「User or group」の設定を変更し、ドメイン参加時に使用するアカウントを明示的に指定する必要があります。
このとき、「User or group」にDomain UsersやAuthenticated Usersなどのグループを指定した場合を見てみましょう。
以下の図は、「User or group」にDomain Usersを指定して作成したコンピュータオブジェクトのアクセス制御リスト（Access Control List; ACL）です。
Domain UsersグループにWriteAccountRestrictions権限が付与されていることが確認できます。
このように、あらかじめコンピュータオブジェクトを作成しておく運用において、ドメイン参加時に使用するアカウントにDomain UsersやAuthenticated Usersなどのグループを指定している場合、上述したすべてのドメインユーザが、ほぼすべてのドメインコンピュータに対して侵入できる可能性がある環境が作り込まれてしまい、非常に危険な状態となります。
このような状況を避けるためには、運用パターン②のようにドメイン参加に必要な最小権限のみを割り当てたドメイン参加専用アカウントを作成しておき、コンピュータオブジェクトを作成する際の「User or group」にはドメイン参加専用アカウントを指定することが重要です。
なお、この場合においても、ドメイン参加専用アカウントが攻撃者に乗っ取られてしまった場合は、多数の端末に対してRBCD攻撃が成立してしまう可能性があります。 ドメイン参加専用アカウントの保護や監視はドメイン管理者アカウントと同等レベルに強化してください。
おわりに
本記事では、RBCD攻撃に対して脆弱な環境が作り込まれる要因となる運用方法について解説しました。
RBCD攻撃は、その原理が複雑で理解しずらいことから、存在や対策が見落とされやすいと感じています。 本記事が少しでも社内ネットワークにおけるセキュリティレベル向上のお役に立てば幸いです。
参考文献
- Another Word on Delegation
- Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory
- BloodHoundの説明や使い方は過去のブログ記事「新しく生まれ変わったBloodHound Community Editionを使ってみた - ラック・セキュリティごった煮ブログ」で解説しています。興味のある方は、こちらも読んでいただけると嬉しいです。↩
-
本記事では、ドメイン参加時の運用方法について解説するため、ドメイン参加時に付与される
WriteAccountRestrictions権限にのみ言及しています。一方で、RBCD攻撃自体はコンピュータオブジェクトに対する書き込み権限があれば成立することが知られており、WriteAccountRestrictions権限だけでなく、GenericWrite権限やWriteDacl権限など複数の権限が対象となる点にご留意ください。↩ -
RBCD攻撃には、
msDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込み権限以外にも「ドメインコントローラのOSバージョンがWindows Server 2012以上」や「既知のパスワード（またはNTLMハッシュ）を持つコンピュータアカウントの入手」といったいくつかの前提条件があります。またこれらの条件を満たしていたとしても、現在は使われていない（実端末が存在しない）コンピュータオブジェクトであったり、侵入に必要なポート（445/TCPなど）が開いていないなどの理由により、悪用には至らないケースもあります。↩
