Active Directoryに対するRBCD攻撃の対策の話 - ラック・セキュリティごった煮ブログ

デジタルペンテスト部でペネトレーションテストを担当している小松奈央です。

Active Directoryに対する攻撃手法に、Resource-based Constrained Delegation（以下、RBCD）攻撃というものがあります。この攻撃手法は原理が分かりづらく、私自身対策方法について勘違いしている部分がありました。

「机上で考えていたRBCD攻撃の対策方法が、実際に案件でRBCD攻撃を行う中で不十分であると気づいた」といったことがあったので、その内容を踏まえてRBCD攻撃の対策方法について本記事で解説します。（解説は必要ないからRBCD攻撃の対策だけ完結に知りたい！という方はこちらをご確認ください。）

RBCD攻撃の原理を正しく理解している技術者からすると当たり前の内容ではありますが、情シス担当者など実際にセキュリティ対策を実施する方の参考になれば幸いです。（なお、本記事でも原理については解説しないため、詳しく知りたい方は参考文献をご確認ください。）

注意：本投稿で記述した手法を用いてトラブルなどが発生した場合、当社は一切の責任を負いかねます。また、本情報の悪用はしないでください。

RBCD（Resource-based Constrained Delegation）攻撃とは
RBCD攻撃の手順
RBCD攻撃の前提条件
RBCD攻撃に対する対策方法
おわりに
参考文献

RBCD（Resource-based Constrained Delegation）攻撃とは

RBCD攻撃とは、攻撃者がターゲットとなるActive Directoryへ侵入後、他の端末への侵入範囲拡大や、ドメインにおける権限昇格を行うための攻撃手法の1つです。これはActive Directoryにおける「Resource-based Constrained Delegation（リソースベースの制約付き委任）」と呼ばれる機能を悪用します。

learn.microsoft.com

本来は特定のサービスへアクセスする権限を委任するための仕組みであり、フロントエンドサービスとバックエンドサービスがそれぞれ異なるドメインに属しているなどのドメインをまたいで制約付き委任を行いたい場合に用いられます。

これを実現するためには、委任先ホストにおけるmsDS-AllowedToActOnBehalfOfOtherIdentity属性に対して委任元ホストを登録する必要があります。しかし、これにドメイン管理者権限は必要なく、委任先ホストのmsDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込み権限を持つユーザアカウントであれば可能です。

以下のアクセス制御設定が有効になっている場合に、msDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込みが可能です。

Write all properties
Write account restrictions
Write msDS-AllowedToActOnBehalfOfOtherIdentity
など

特にWrite account restrictionsについては、端末をドメインに参加させる際、参加させたユーザアカウントに自動的に付与されるため、注意が必要です。

まとめると、攻撃者が特定の端末におけるmsDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込み権限を持つユーザアカウントを侵害した場合に、RBCD攻撃によってその端末へ侵入される可能性があります。

RBCD攻撃の手順

具体的な攻撃手順について調べてみると、多くのサイトにおいて以下のような流れとなっています。

侵害済みのアカウントにおいて、msDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込み権限が付与されているコンピュータアカウントを探す
ドメインにおけるms-ds-machineaccountquotaの値を確認する
任意のパスワードを設定した新しいコンピュータアカウントを作成する
（手順1）で見つけた侵入対象となる端末のコンピュータアカウントのmsDS-AllowedToActOnBehalfOfOtherIdentity属性に、（手順3）で作成したコンピュータアカウントを登録する
侵入対象端末における、悪用したいサービスのKerberosチケットを要求、取得する
取得したKerberosチケットを使って、侵入対象端末におけるサービスを悪用し、侵入する

ここでは、（手順2）と（手順3）に注目します。 ms-ds-machineaccountquotaとは、ドメインユーザが端末をドメインに参加させることのできる（≒コンピュータアカウントを新規作成できる）台数を指定する設定値です。そのため、（手順2）でms-ds-machineaccountquotaの値を確認し、この値が1以上であればドメインユーザがコンピュータアカウントを新規作成することができます¹。なお、この値にはデフォルトで10が設定されているため、デフォルトの環境では一般ユーザが端末を10台まで参加させることが可能であり、実際にこの設定で運用されている環境が多い印象です。

私はこの時点で、RBCD攻撃の前提条件として新しいコンピュータアカウントを作成できる必要があり、ms-ds-machineaccountquotaの値が1以上であることが必須だと思っていました。そのため、ms-ds-machineaccountquotaの値を0にするなどによってドメインユーザがコンピュータアカウントを新規作成できないように制限することで、RBCD攻撃の対策になると勘違いをしていました。実際には軽減策として有効ではあるものの、この策のみではRBCD攻撃が成立してしまう場合があります。

そもそも、なぜRBCD攻撃においてコンピュータアカウントを新規作成しているかというと、（手順5）で悪用したいサービスのKerberosチケットを要求するために、委任元となるコンピュータアカウントのパスワードハッシュ値が必要だからです。逆に言えば、何かしらの方法によって任意のコンピュータアカウントのパスワードハッシュ値を入手できていれば、コンピュータアカウントの新規作成は必要ないということになります。

多くのサイトにおいて、手順としてコンピュータアカウントの新規作成を紹介している理由としては、デフォルトの設定でコンピュータアカウントの新規作成が可能であり、コンピュータアカウントのパスワードハッシュ値を入手するよりも攻撃の難易度が低いからかと推察しています。確かに、コンピュータアカウントのパスワードハッシュ値を入手するためには、Windows 10以前の端末でローカル管理者権限昇格するなどの別のハードルがありますが、代替手段としては十分有効です。

RBCD攻撃の前提条件

上記を踏まえて、RBCD攻撃が成立するための前提条件を整理すると以下のようになります。

ドメインコントローラのバージョンがWindows Server 2012以上²
侵入したい端末のコンピュータアカウントのmsDS-AllowedToActOnBehalfOfOtherIdentity属性に書き込み権限のあるユーザアカウントの侵害
コンピュータアカウントの新規作成、または任意のコンピュータアカウントのパスワードハッシュ値の入手

RBCD攻撃に対する対策方法

RBCD攻撃に対する対策方法を記載します。以下のいずれかを実施するだけでも軽減策になりますが、可能であればいずれも実施することが望ましいです。

1. `msDS-AllowedToActOnBehalfOfOtherIdentity`属性への書き込み権限の確認

任意のコンピュータアカウントに対するmsDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込み権限が付与されたユーザアカウントを調査し、適切な権限設定がされているか確認します。

特定のサーバにおいて、本来権限の必要ない一般ユーザアカウントに対するWrite account restrictionsが付与されているなど、意図していない権限設定になっている場合は最小権限の原則に則り権限を削除します。

アクセス制御設定の確認方法は以下のとおりです。

ドメインコントローラ上でADSI Editを開く
確認したいコンピュータアカウントを右クリックし、Propertiesを開く
SecurityタブのGroup or user names:から確認したいユーザアカウントを選択する
Permissions for Everyoneでアクセス制御設定が適切か確認する

すべての端末を一度に確認するのは大変なので、重要なサーバから少しずつ確認するのが良いと思います。

2. 特権アカウントの保護

意図的にWrite account restrictionsなどの特権を付与しているアカウントに関しては、弱いパスワードが使用されていないか確認した上で適切に保護する必要があります。

特権アカウントが不正に利用されていないか、監視を強化することも有効です。

3. 一般ドメインユーザにおけるコンピュータアカウント作成の制限

業務要件にもよりますが、可能であればms-ds-machineaccountquotaの値を0にするなどによって、一般ドメインユーザが端末をドメインに参加できない（コンピュータアカウントの作成ができない）よう制限することが望ましいです。この場合、新規端末はシステム管理者側で専用アカウントを用いてドメイン参加させる運用になると思います。

なお、このような運用にすることで、専用アカウント以外のアカウントによって作成されたコンピュータアカウントはアノマリな事象となり検知することができます。非管理者アカウントを用いて端末をドメインに参加させた場合、コンピュータアカウントのms-ds-CreatorSid属性に作成したアカウントのSIDが登録されます。 ms-ds-CreatorSid属性に専用アカウント以外のSIDが登録されている場合、攻撃者によって不正に作成されたコンピュータアカウントである可能性があります。

コンピュータアカウントのms-ds-CreatorSid属性はActiveDirectory Moduleによって検索することができます。

PS C:\> Get-ADComputer -Properties ms-ds-CreatorSid -Filter {ms-ds-CreatorSid -ne "$Null"}


DistinguishedName : CN=WIN10-WS01,CN=Computers,DC=ad,DC=example,DC=local
DNSHostName       : WIN10-WS01.ad.example.local
Enabled           : True
ms-ds-CreatorSid  : S-1-5-21-4086492092-3119007261-1599046534-1104
Name              : WIN10-WS01
ObjectClass       : computer
ObjectGUID        : ac628873-fa76-4e28-b729-0b6d68bfde2b
SamAccountName    : WIN10-WS01$
SID               : S-1-5-21-4086492092-3119007261-1599046534-1108
UserPrincipalName :

DistinguishedName : CN=WIN10-WS02,CN=Computers,DC=ad,DC=example,DC=local
DNSHostName       : WIN10-WS02.ad.example.local
Enabled           : True
ms-ds-CreatorSid  : S-1-5-21-4086492092-3119007261-1599046534-1104
Name              : WIN10-WS02
ObjectClass       : computer
ObjectGUID        : 71d2abbf-63f8-4f86-9c33-bd8a37bea797
SamAccountName    : WIN10-WS02$
SID               : S-1-5-21-4086492092-3119007261-1599046534-1109
UserPrincipalName :

4. コンピュータアカウントの保護

前述のとおり、コンピュータアカウントの新規作成を制限したとしてもRBCD攻撃が成立する場合があります。

RBCD攻撃に限った話ではありませんが、コンピュータアカウントのパスワードハッシュ値が窃取されないよう（ローカル管理者権限を奪取されないよう）、端末に最新のセキュリティ更新プログラムを適用したり、Credential Guardを有効にしたりすることも重要です。

learn.microsoft.com

おわりに

本記事では、RBCD攻撃の対策方法について解説しました。本記事が少しでも社内ネットワークにおけるセキュリティレベル向上のお役に立てば幸いです。

余談ですが、実際のペネトレーションテスト案件でも、RBCD攻撃に対して脆弱な環境を見かけます。 msDS-AllowedToActOnBehalfOfOtherIdentity属性への書き込みといった設定変更が少なからず発生するため、実際に悪用するかどうかはお客様との調整次第ですが、実際にRBCD攻撃によってドメイン管理者権限を奪取できた事例もあるため、注意が必要です。