域渗透之Kerberos FAST突破
本章主要讲述了从突破域内kerbero-FAST安全机制以及向AS(Authentication Service)申请服务票据带来的危害性
kerberos认证回顾
- 简单回顾一下kerberos认证的过程,前四步是本文的重点。 1.用户向DC请求TGT 2.KDC返回TGT,该TGT使用密钥加密。 3.用户发送请求向KDC请求服务票据(ST),并携带TGT 4.KDC使用密钥解密并验证TGT,验证无误后返回使用server密码加密的ST。 5.用户使用ST访问服务 6.服务器验证。
如图所示,图的出处来自adsecurity
AS-REP Roasting攻击
- kerberos预认证使kerberos认证的第一步,用于防止爆破,在AS-REP中,KDC返回了客户端TGT和用于访问服务的会话密钥,该会话密钥使用客户端的密码进行加密,假如域内某个用户设置了"不需要kerberos预身份验证",如图所示,攻击者可以指定用户请求票据,从而获得TGT和密钥进行离线爆破。
- AS-REP Roasting攻击演示 1.使用Rubeus进行AS-REP Roasting攻击获得hash。
2.使用john对hash进行离线爆破,如果所示
kerbersting
- kerbersting攻击介绍
在kerberos认证第四步完成后,进行kerberos认证的域用户将会收到service ticket,该票据使用目标服务的NTLM HASH进行加密,加密算法为RC4-HMAC,这时候我们就能使用相同的算法模拟生成ST,对获得的ST进行离线枚举。
- 为了方便下文的理解,我这里不适用Rubeus+kerberoast参数进行kerbersting,而是将kerbersting攻击分成三步
1.查找域内SPN,如图所示
2.利用Adminsitrator申请TGT,如图所示
3.利用TGT申请服务票据,该服务票据用于访问cifs/stu1.jctest.com,票据使用lowuser用户的hash加密。如图所示
4.对票据进行离线爆破,获取lowuser的密码
FAST
回顾完了AS-REP Roasting攻击和kerbersting攻击,接下来讲一下一种域内安全机制-"Flexible Authentication Secure Tunneling",简称为FAST,值得一提的是开启FAST能很好的防御如nopac这类型漏洞,且配置简单,但很多企业并未开启。
- FAST介绍 在Windows-Server-2012中Active Directory开启了新功能FAST,FAST全称 Flexible Authentication Secure Tunneling,即灵活的身份验证隧道,该功能会监听在域服务中,旨在解决kerberos的安全问题,其在客户端和KDC之间提供了受到保护的传输通道,相当于在kerberos认证过程中加"盐",配置FAST后会让强制获得密钥变得困难,下面来测试一下。
- FAST配置
1.在组策略中找到KDC选项,将”KDC支持声明、复合身份认证和kerberos Armoring“选项设置为失败的非armoring身份验证请求,如图所示
2.在kerberos选项中启用“kerberos客户端支持声明、复合身份认证和kerberos Armoring”选项
3.更新组策略gpupdate
- FAST验证:
- 未开启FAST前请求域用户的TGT票据(成功)
- 开启FAST后请求域用户TGT票据(失败)
- 开启FAST后使用TGT请求ST票据(失败)
- 开启FAST后进行 AS-REP Roasting攻击(失败)
这样一来我们就可以发现,我们已经无法再去强制KDC返回对应用户的TGT,假如这个行为被阻拦,很多域内的攻击就无法进行,如票据传递、AS-REP Roasting利用等一系列需要申请TGT的攻击手法。正如上文中提到的kerbersting攻击手法也无法实现,因为该攻击手法需要先申请TGT,再去申请st,最终可以得出结论,FAST的配置,确实使kerberos认证变得更加安全。
FAST绕过
- 最近,研究员Charlie Clark发现了一件有趣的事情,在他发布的文章中指出,在AS-req请求的过程中,将req-body中的sname指定SPN时会返回该服务的ST票据,这一发现也就实现了不通过TGS而是通过AS来申请ST票据,同时他还发现,在开启FAST配置后,机器账户的as_req请求被没有收到保护,接下来我们来试验一下,在开启FAST的情况下使用机器账户向AS认证服务器请求指定SPN的服务票据(ST)
- 使用powermad申请机器用户,如果所示
import-module .\\powermad.ps1 New-MachineAccount -MachineAccount fastbypass -Domain jctest.com -DomainController xxxxxx.jctest.com
2.在开启FAST的情况下使用机器账户申请TGT
我们可以发现,使用机器账号能够在FAST开启的情况下申请TGT,其还是使用传统kerberos认证协议,如图所示
3.然后我们再使用经过Charlie Clark修改后的Rubeus,在发送的过程中将sname指向指定的spn,向AS发送请求使其返回指定的服务票据。只需在使用Rubeus的时候加上/service参数,如图所示
4这是我们发现票据中的servicename已经指向了我们指定的spn,这时候使用该票据进行离线爆破可以发现我们已经获取注册该spn的域用户的密码
5.此时已经验证了,通过修改snmae可以让AS认证服务器返回ST票据,并且使用机器账户可以绕过FAST机制来申请TGT,但是这种绕过存在一定的限制,我们都知道"CVE-2021-42287&42278"漏洞利用需要通过申请机器账户来请求TGT,然后利用TGT去通过s4uself协议申请ST票据,这时候就会发现,即使能绕过FAST申请TGT,但是还是无法去通过s4uself申请ST票据,如图所示
向AS申请服务票据的拓展
- 现在假设一个场景,我们拿下一台域内机器,但是我们没有任何的账号密码,而常规的kerbersoting攻击是需要一个域内任何用户的身份,但是我们只要发现了域内开启了不需要预认证的用户,再利用该用户通过AS认证服务请求ST票据,就可以实现不需要域内用户身份实现kerberosting
- 但还有一个问题就是,申请服务票据,我们得知道域内服务的spn名称,才能指定要申请的服务票据,这个问题在该文章得到解决,作者Sharoglazov指出,在没有SPN名称的情况下进行kerberosting,并且将该功能添加到了impacket下,如图所示
最新的rubeus同样也实现了该功能
- 如此一来,我们就可以从域外实现从配置了不需要域认证的用户进行krberoasting。
1.假如我们现在是一台域外的机器,且没有任何账号密码,但我们知道了域名和域控的IP,使用kerbrute对域内用户进行枚举
2.得到用户列表之后对用户列表进行探测,发现配置了不需要预认证的用户
3.使用rubeus利用connect用户进行kerberoasting攻击,如图所示
4.利用hashcat成功破解出密码
5.查看数据包我们可以看到,每一次as_req请求的cname都是connect,正是配置了不需要预认证的用户。
6.根据Sharoglazov的文章中指出,在kerberos认证的过程中,当向TGS请求服务票据的时候,将TGS-REQ请求的sname值改成SPN所属的账户的samaccountname值,请求并不会发生异常,那么这里的利用AS请求的ST票据也是同理,只要将AS-REQ中的sname值改成SPN所属用户的samaccountname值即可,例如我们的lowuser用户注册了一个spn,如图所示
7.然后在rebeus的请求过程中我们可以发现其将sname改成了lowuser用户对应的samaccountname值。
8.最终实现了,在不知道用户密码和SPN的情况下,通过配置了不需要预认证的用户进行了kerberoasting。
声明:本站所有文章资源内容,如无特殊说明或标注,均为采集网络资源。如若本站内容侵犯了原著者的合法权益,可联系本站删除。