references:
-
https://www.trustedsec.com/blog/i-wanna-go-fast-really-fast-like-kerberos-fast/
- https://syfuhs.net/kerberos-fast-armoring
- https://www.semperis.com/blog/new-attack-paths-as-requested-sts/
简介
提前国庆快乐
炒冷饭，都是别人研究的，我就在这做个笔记
这里的FAST并不是字面意义的fast，而是Flexible Authentication Secure Tunneling的首字母缩写，它的出现主要是为了解决域内用户密码被离线破解的问题，该技术在windows server 2012 R2引入
大家可能都听说过kerberoasting，这个技术主要用于离线爆破服务账户的明文密码，以及asrep-roast，用于离线爆破未开启pre-auth认证的普通用于的明文密码
这两种爆破都基于同一个事实：数据包被用户密码派生出来的哈希加密，并且我们可以控制加密算法为最弱的RC4
对于计算机账户，就不存在这种问题，因为计算机账户的明文密码是很长的一串随机字符串，且复杂度极高，这是我的测试环境中的机器账户的明文密码：
可以看到，相当的复杂，离线爆破是不可能的，就算你真的爆出来了，密码也已经失效了，机器账户默认情况下一个月自动更新一次密码
而启用了FAST之后，在进行kerberos认证的时候，会先使用机器账户从DC获取一个key，使用这个key来保护用户认证阶段的数据，这样即使离线爆破，获得的也只是这个short-term key，更何况你还不一定爆的出来，这种key长度一般都很长
这个特性被称作 FAST armor，顾名思义，它给kerberos的AS（TGS票据申请）阶段装了一层盔甲，不过它只保护用户的AS-REQ，不保护机器账户的AS-REQ，因为它本质上是使用机器账户的TGT去保护用户的TGT获取过程
启用FAST
通过组策略启用
对于域控制器：
对于工作站和成员服务器：
在启用之后，可以使用rubeus检测以下效果：
rubeus.exe asktgt /user:nmd /password:qwe123... /domain:cao.ni.ma /dc:WIN-BTAP0QG1S13.cao.ni.ma /outfile:1.kirbi
如果返回了这个错误，说明配置成功
协议分析
wireshark数据包文件：pcapng
由于rubeus和impacket都不支持kRB5-PADATA-FX-FAST (136)的解密和解析，所以大家就自己看看这个数据包的大致流程就行了，具体细节就不讲了
如果你想要自己测试，需要先清除当前机器账户的票据
新的攻击思路
FAST armor的设计初衷是缓解kerberoasting以及asrep-roast，在启用了FAST之后，这两种攻击方式都会失效，对于前者，因为必须要先获取到一个机器账户的TGT，才能进行TGT或ST的请求，导致攻击无法执行；对于后者，不包含preauth数据的AS-REQ会被KDC拒掉
可以看到，在GetTGT的时候失败了，报错显示KDC的策略拒绝掉了我们的请求
但是按照FAST的设计，计算机账户在申请TGT的时候并不会被保护
exploitph提出了一个想法，能否利用机器账户通过AS-REQ来请求ST，按照设计，AS-REQ是用于请求TGT的，但是如果我们把sname-string由krbtgt/cao.ni.ma改成一个合法的SPN会发生什么事情呢？
对impacket中的相关文件进行修改之后，使用机器账户申请TGT票据
可以看到，正常返回了ldap服务票据
使用_nwodtuhs的describeTicket.py查看该票据：
这样一来，asrep-roast的路被堵死了，但是kerberoasting never die!
exploitph把这个问题提交给了MSFT，那边的回复是经典的by design!