域内攻防之委派攻击

概念

委派是大型网络中经常部署的应用模式,给多跳认证带来了很大的便利,与此同时也带来了很大的安全隐患。利用委派,攻击者可结合其他漏洞进行组合攻击,导致攻击者可以获取本地管理员甚至域管理员权限,还可以制作深度隐藏的后门。

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

如图所示 用户white0123\test以Kerberos身份验证访问 Web服务器请求下载文件 但是真正的文件在后台的文件服务器上。于是,web服务器的服务账号模拟域用户white0123\test 以Kerberos协议继续认证到后台文件服务器。后台服务器将文件返回给web服务器,web服务器将文件返回给域用户white0123\test。这样就完成了一个委派的流程。

image-20231207135833290

在域中,只有主机账户和服务账户才具有委派属性。

  • 主机账户就是活动目录Computers中的计算机,也可以称为机器账户。

  • 服务账户就是域内用户账户的一种类型,是将服务运行起来并加入域时所用的账户。

    例如:SQLServer在安装时会在域内自动注册服务账户SQLServiceAccount,也可以将域用户通过注册SPN变为服务账户。

委派的分类

委派的主要有三个分类

  • 非约束性委派
  • 约束性委派
  • 基于资源的约束性委派

非约束性委派

在Windows Server2000首次发布Active Directory时,Microsoft就提供了一种简单的机制来支持用户通过Kerberos向Web Server进 行身份验证并需要代表该用户更新后端数据库服务器上的记录的方案,这就是最早的非约束性委派。对于非约束性委派 (Unconstrained Delegation),服务账号可以获取被委派用户的TGT,并将TGT缓存到LSASS进程中,从而服务账号可使用该TGT, 模拟该用户访问任意服务。非约束委派的设置需要SeEnableDelegation 特权,该特权通常仅授予域管理员 。

  • 配置了非约束性委派属性的机器账号的userAccountControl 属性有个Flag位 WORKSTATION_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION,其对应的数是0x81000=528384。
  • 配置了非约束性委派属性的服务账号的userAccountControl 属性有个Flag位 NORMAL_ACCOUNT | TRUSTED_FOR_DELEGATION, 其对应的数是0x80200=524800。

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

1、 利用powersploit中的powerview

Import-Module .\PowerView.ps1;

查询非约束委派的主机 Get-NetComputer -Unconstrained -Domain yokan.com

查询非约束委派的服务账号 Get-NetUser -Unconstrained -Domain yokan.com | select name

2、 利用ADFind

查找域中配置非约束委派的用户

AdFind.exe -b "DC=yokan,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

查找域中配置非约束委派的主机

AdFind.exe -b "DC=yokan,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

3、 ldapsearch

非约束性委派大致流程

user访serverA,于是向DC发起认证,DC会检查serverA的机器账号的属性,如果是非约束委派的话,会把用户的TGT放在ST票据中并一起发送给serverA,这样serverA在验证ST票据的同时也获取到了用户的TGT,并把TGT储存在自己的lsass进程中以备下次重用,从而serverA就可以使用这个TGT,来模拟这个user访问任何服务

img

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

结合打印机漏洞攻击

上面的攻击手段 需要域管主动连接配置了非约束性委派的主机,才能从主机上获得域管理员的TGT。实战中有点鸡肋。我们可以结合打印机服务漏洞来强制域控连接配置了非约束性委派的主机,也能从该主机上抓到域控制器账户的TGT,且不需要域管理员进行交互。

复现文章参考

https://mp.weixin.qq.com/s/1sR0wTyJFf5UnuPjtJ-DWw

约束性委派

由于非约束性委派的不安全性,微软在Windows Server 2003中发布了约束性委派。同时,为了在Kerberos协议层面对约束性委派的支持,微软扩展了两个子协议 S4u2Self(Service for User to Self) 和 S4u2Proxy (Service for User to Proxy ),这两个扩展都允许服务代表用户从KDC请求票证。S4U2self可以代表自身请求针对其自身的Kerberos服务票据(ST1);S4U2proxy可以以用户的名义请求其它服务的ST2,约束委派就是限制了S4U2proxy扩展的范围, 只能模拟该用户访问特定的服务。配置了约束性委派账户的msDS- AllowedToDelegateTo属性会指定对哪个SPN进行委派。约束委派的设置需要 SeEnableDelegation 特权,该特权通常仅授予域管理员。

约束性委派的分类

约束性委派有两种:一种是仅使用Kerberos,也就是不能进行协议转换;另一种是使用任何身份验证协议,也就是能进行协议转换。

仅使用Kerberos

配置了仅使用Kerberos约束性委派的机器账户和服务账户的userAccountControl属性和正常账户一样,但是其msDS-AllowedToDelegateTo属性会有允许被委派服务的SPN。

使用任何身份验证协议
  • 配置了任何身份验证协议约束性委派的机器账户的userAccountControl属性有个FLAG位 WORKSTATION_TRUST_ACCOUNT | TRUETED_TO_AUTHENTICATE_FOR_DELEGATION,其对应的数是0x1001000=16781312
  • 配置了任何身份验证协议约束性委派的机器账户的userAccountControl属性有个FLAG位 NORMAL_ACCOUNT | TRUETED_TO_AUTHENTICATE_FOR_DELEGATION,其对应的数是0x1001000=16777728

约束性委派的流程

user访问serviceA,向DC发起kerberos认证,域控返回user的TGT和ST1票据,user使用ST1票据对serviceA进行访问

如果配置了serviceA到serviceB的约束委派,则serviceA能使用S4U2Proxy协议将用户发给自己的可转发的ST1票据以用户的身份发给DC。

域控返回serviceA一个用来访问serviceB的ST2票据,这样serviceA就能以用户的身份对serviceB发起访问。

img

由于服务用户只能获取某个用户(或主机)的服务的ST1而非TGT,所以只能模拟用户访问特定的服务,但是如果能拿到约束委派用户(或主机)的密码或者Hash,就可以伪造S4U的请求,伪装成服务用户以任意用户的权限申请访问指定服务的ST2

约束性委派的攻击流程

在拿到一台主机的时候 通过抓取到本机用户的账号密码 可以向KDC认证中心申请一个可转发的TGT,然后服务账号可用域管的身份申请一个可转发的ST 服务账号用上一步的可转发的ST以域管身份向KDC申请访问特定服务的ST。导入上一步获得的以域管身份访问的特定服务的ST可成功访问域控。

基于资源的约束性委派

传统的委派,在设置的过程中其实都是需要SeEnableDelegation特权,而这个特权需要域管理员才能设置。相对于传统的委派,基于资源的约束委派它不需要域管理员设置,而是机器本身

基于资源的约束性委派允许资源配置受信任的帐户委派给他们。基于资源的约束性委派只能在运行Windows Server 2012和Windows Server 2012 R2及以上的域控制器上配置,但可以在混合模式林中应用。配置了基于资源的约束性委派账户的msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为被允许委派账号的SID,并且委派属性这里没有任何值。

img

约束委派和基于资源的约束委派的区别

前者:通过服务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转发此ST票据去请求访问服务B的可转发的ST服务票据,那么我们就可以模拟任意用户访问服务B了。这里可以以普通域用户的身份去创建机器账号作为服务A。

基于资源的约束性委派的优势

1、委派的权限授予给了拥有资源的后端,而不再是前端

2、约束性委派不能跨域进行委派,基于资源的约束性委派可以跨域和林

3、不再需要域管理员权限设置委派,只需拥有在计算机对象上编辑msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限,也就是拥有**’将域机器加入域’域用户和机器自身**的权限。

基于资源的约束性委派利用条件

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

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

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

补充:

1.如果导入powerview后执行以下命令后有回显,证明win7主机配置了基于资源的约束性委派。

Get-DomainComputer win7 -Properties msds-allowedtoactonbehalfofotheridentity

2.查找将win主机拉入域内的人的sid,其实就是查找这台主机的mS-DS-CreatorSID值:

AdFind.exe -b "DC=yokan,DC=com" -f "(&(samAccountType=805306369))" cn mS-DS-CreatorSID

基于资源的约束性委派流程

img

基于资源的约束性委派利用

这里偷了个懒 参考复现过程

https://forum.butian.net/share/1591

参考链接

https://www.cnblogs.com/yokan/p/16164761.html

https://www.cnblogs.com/xiaozi/p/17072605.html

https://mp.weixin.qq.com/s/1sR0wTyJFf5UnuPjtJ-DWw

https://www.bilibili.com/video/BV1564y1Y7HF/?spm_id_from=333.337.search-card.all.click

https://forum.butian.net/share/1591

https://mp.weixin.qq.com/s/GdmnlsKJJXhElA4GuwxTKQ