本章主要讲述了从突破域内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验证：

1. 未开启FAST前请求域用户的TGT票据(成功)

2. 开启FAST后请求域用户TGT票据(失败)

3. 开启FAST后使用TGT请求ST票据(失败)

4. 开启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)

1. 使用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。