Resource-based Constrained Delegation
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Basics of Resource-based Constrained Delegation
これは基本的なConstrained Delegationに似ていますが、サービスに対して任意のユーザーを偽装する権限をオブジェクトに与えるのではなく、リソースベースの制約付き委任はそのオブジェクトに対して任意のユーザーを偽装できる者を設定します。
この場合、制約されたオブジェクトには、任意の他のユーザーを偽装できるユーザーの名前を持つ属性 msDS-AllowedToActOnBehalfOfOtherIdentity が存在します。
この制約付き委任と他の委任との重要な違いは、マシンアカウントに対する書き込み権限 (GenericAll/GenericWrite/WriteDacl/WriteProperty/etc) を持つ任意のユーザーが msDS-AllowedToActOnBehalfOfOtherIdentity を設定できることです(他の委任の形式ではドメイン管理者の特権が必要でした)。
New Concepts
制約付き委任では、ユーザーの userAccountControl 値内の TrustedToAuthForDelegation
フラグが S4U2Self を実行するために必要であると述べられていました。しかし、それは完全に真実ではありません。
実際には、その値がなくても、サービス(SPNを持つ)であれば任意のユーザーに対して S4U2Self を実行できますが、TrustedToAuthForDelegation
を持っている場合、返される TGS は Forwardable になります。もしそのフラグを持っていない場合、返される TGS は Forwardable ではありません。
ただし、S4U2Proxy で使用される TGS が Forwardable でない場合、基本的な制約付き委任を悪用しようとしても機能しません。しかし、リソースベースの制約付き委任を悪用しようとしている場合は、機能します(これは脆弱性ではなく、機能のようです)。
Attack structure
コンピュータアカウントに対して書き込み同等の権限を持っている場合、そのマシンで特権アクセスを取得できます。
攻撃者がすでに被害者コンピュータに対して書き込み同等の権限を持っていると仮定します。
攻撃者はSPNを持つアカウントを侵害するか、作成します(“Service A”)。特に、特別な権限を持たないAdmin User は最大10個のコンピュータオブジェクト(MachineAccountQuota)を作成し、SPNを設定できます。したがって、攻撃者はコンピュータオブジェクトを作成し、SPNを設定することができます。
攻撃者は被害者コンピュータ(ServiceB)に対する書き込み権限を悪用して、リソースベースの制約付き委任を構成し、ServiceAがその被害者コンピュータ(ServiceB)に対して任意のユーザーを偽装できるようにします。
攻撃者はRubeusを使用して、特権アクセスを持つユーザーのためにService AからService Bへの完全なS4U攻撃(S4U2SelfおよびS4U2Proxy)を実行します。
S4U2Self(侵害または作成されたアカウントのSPNから):私に対するAdministratorのTGSを要求します(Forwardableではありません)。
S4U2Proxy:前のステップのForwardableでないTGSを使用して、被害者ホストに対するAdministratorのTGSを要求します。
ForwardableでないTGSを使用している場合でも、リソースベースの制約付き委任を悪用しているため、機能します。
攻撃者はパス・ザ・チケットを行い、ユーザーを偽装して被害者ServiceBにアクセスします。
ドメインの MachineAccountQuota を確認するには、次のコマンドを使用できます:
攻撃
コンピュータオブジェクトの作成
powermadを使用して、ドメイン内にコンピュータオブジェクトを作成できます:
リソースベースの制約付き委任の構成
activedirectory PowerShellモジュールを使用
PowerViewの使用
完全なS4U攻撃の実行
まず最初に、パスワード123456
で新しいコンピュータオブジェクトを作成したので、そのパスワードのハッシュが必要です:
これは、そのアカウントのRC4およびAESハッシュを印刷します。 さて、攻撃を実行できます:
あなたはRubeusの/altservice
パラメータを使用して、一度尋ねるだけでより多くのチケットを生成できます:
ユーザーには「委任できない」という属性があります。この属性がTrueに設定されているユーザーを偽装することはできません。このプロパティはbloodhound内で確認できます。
アクセス
最後のコマンドラインは、完全なS4U攻撃を実行し、管理者から被害者ホストのメモリにTGSを注入します。 この例では、管理者からCIFS**サービスのTGSが要求されたため、**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が実行されていない場合)
作成されたfakecomputerが脆弱なサーバーに対する権限を失っており、それを戻す必要がある。
参考文献
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated