跳跳糖
0x00 什么是Kerberoasting
首先，我们来整体了解一下实际用户请求访问域内某个服务时会经过哪些步骤：
1、用户将AS-REQ数据包发送给KDC（Key Distribution Centre，密钥分发中心，此处为域控），进行身份认证。
2、KDC验证用户的凭据，如果凭据有效，则返回TGT（Ticket-Granting Ticket，票据授予票据）。
3、如果用户想通过身份认证，访问某个服务（如CIFS），那么他需要发起（Ticket Granting Service，票据授予服务）请求，请求中包含TGT以及所请求服务的SPN（Service Principal Name，服务主体名称）。
4、如果TGT有效并且没有过期，TGS会创建用于目标服务的一个服务票据。服务票据使用服务账户的凭据进行加密。
5、用户收到包含加密服务票据的TGS响应数据包。
6、最后，服务票据会转发给目标服务，然后使用服务账户的凭据进行解密。
由于服务票据会使用服务账户的哈希进行加密，并且Windows域中任何经过身份验证的用户都可以从TGS处请求服务票据，SPN是服务实例的唯一标识符,Kerberos身份认证过程中使用SPN，将服务实例与服务登录账户相关联，如下图spn为spntesta/test12.com这个spn与账户test关联，也就是说我们只要请求spntesta这个服务票据那么域控就会返回给我们一个test账户的ntlm明文密码哈希加密的服务票据，同时kerberos是支持RC4算法加密密码哈希的，再配合上用户账号本身密码强度不够复杂且位数不长这种情况，导致了攻击者会请求注册了SPN的域账户并且指定票据加密类型来获取RC4加密的服务票据来进行离线暴力破解，这就是kerberoasting。
0x01 Kerberoasting的常规攻击方式
由于Kerberoasting攻击一般都是下面这3个步骤，下面的攻击工具和方式就不全部演示。（https://www.hackingarticles.in/deep-dive-into-kerberoasting-attack/）
1、攻击者在活动目录中搜索带有servicePrincipalName属性的账户。
2、攻击者向域控制器发起请求，请求特定服务的服务票据。
3、随后，攻击者收集服务票据，在离线环境中进行破解，得到服务账户的密码
第一种使用Invoke-Kerberoast.ps1来获取服务票据
可以看到获取到的3个服务票据
第二种使用Rubeus来获取服务票据
0x03 kerberoasting检测
这里先使用klist purge清除当前会话所有票据后再使用rubeus kerberoast 进行攻击。（由于rubeus工具会先进行ldap信息查询获取当前具有spn属性的账户，然后对其spn账户申请服务票据，但是如果当前的会话中已经有了对应spn的服务票据那么将不再申请服务票据，所以这里先klist purge清理一下当前会话票据防止攻击过程只做ldap查询）
192.168.164.135是客户端也就是攻击者所在机器，192.168.164.136是域控。
由于当前会话中已经没有任何票据包括TGT，所以可以看到流量中会有as请求获取TGT票据阶段，流量分为3步：
第一步包含了预身份认证以及TGT票据申请。
第二步主要是请求LDAP服务票据，获取到服务票据后再请求ldap服务查询设置了spn属性的账户。
第三步是请求带有spn属性账户的服务票据由于在测试环境中有3个设置了spn的账户所以有6个包。
第二步中的请求获取ldap服务票据，可以看到客户端支持的加密类型为5种3种AES2种RC4
第二步中域控返回的ldap的服务票据使用的AES加密也就是18，kerberos协议加密类型默认是客户端与服务端协商然后使用双方支持的最高的加密类型进行加密。
这一次在域控上请求的服务票证日志如下0x12也就是10进制18
第二步中使用ldap服务票据去访问ldap服务，查询注册了spn的账户信息
1644日志中可以看到对应的ldap查询语法，sAMAccountType=805306368代表用户对象结合，servicePrincipalName=*查询所有spn，!userAccountControl &2表示查找用户属性为没有被禁用的，整个含义就是查询带有servicePrincipalName属性的用户账户(域内除了用户账户还有机器账户)，排除krbtgt这个账户以及用户被禁用的账户
可以看到rubeus 源代码中查询语法跟日志一致
第三步向域控申请注册了spn的用户账户的服务票据，从下图可以看到请求了spntest服务客户端支持的加密类型同样是5种包含了AES和RC4
但是我们看到域控返回的spntest的服务票据是23加密也就是RC4这就跟理论上不太符合，因为客户端都声明了支持AES加密，协商最高等级加密方式，而这里返回的确是RC4弱加密类型。
通过查询相关资料发现造成这种结果的原因，在11年的文档里面发现了4个因素可以影响客户端与域控之间的加密类型选择（如下图）所以我怀疑存在设置了MSDS-SupportedEncryptionTypes属性
不过这个文档内容目前已经在微软搜索不到了(不知道什么原因)
可以看到这个属性可以指定加密算法
同时域控会在TGS-REP加密部分返回一个PA-DATA结构其中 padata-type 设置为PA-SUPPORTED-ENCTYPES 来显示支持哪些加密
我们查看rubeus源代码可以发现进行kerberoast攻击的时候确实会对用户的MSDS-SupportedEncryptionTypes属性填充为RC4
由于都是在这两个属性都是在加密部分所以我们在正常的kerberos流量中无法看到这两个字段当我们解密了kerberos流量后可以发现确实在攻击流量里面域控的PA-SUPPORTED-ENCTYPES 属性里面不支持AES加密了所以选择了RC4加密服务票据，这也就是为什么客户端支持AES加密结果服务端却返回RC4加密的原因。
windows日志中也只能看到请求成功了使用的 RC4加密的服务票据看不到更多的详情这样单纯靠这个日志会产生大量误报
这种攻击我们可以看到会进行LDAP信息查询，使用RC4加密，以及涉及流量方面的。检测方法可以如下：
1.使用1644日志结合4769日志，大部分kerberosting攻击工具都内置了ldap查询语法我们可用来针对该语法做针对检测，同一个IP进行了1644日志查询后进行了针对查询到的spn账户进行4749服务票据申请。
这个是Invoke-kerberoast的查询语法
但是有些时候攻击者可能ldap查询跟票据申请是分开的或者直接使用setspn自己查询spn信息，查询完后再针对某个用户进行申请服务票据。
2.我们可以设置蜜罐spn账户来诱导攻击者进行服务票据申请。
3.kerberos流量不解密的情况下tgs-req请求中支持多种加密类型包括AES而tgs-rep返回的ST确是RC4的这就非常可疑了。
4.如果我们域内设置有spn的用户账户量大的通常来说使用工具来进行攻击的话短时间一个用户会申请大量的服务票据，这种异常行为UEBA来做应该也是可以的。但是opsec的攻击者会查询完ldap信息后会精准选一些用户来进行单独申请服务票据,通过whenCreated、userAccountControl、pwdLastSet、lastLogon等属性来识别蜜罐账户。
0x04 msDS-SupportedEncryptionTypes属性设置为支持AES
既然RC4加密容易被破解那给用户的msDS-SupportedEncryptionTypes属性设置为AES是否就可以防御了呢？
我们再次使用rubeus kerberoast来进行攻击发现返回的服务票据确实是AES加密的。
但是当我们加上/tgtdeleg参数后我们发现即使用户设置了AES加密但还是返回了可破解的RC4加密的服务票据
这次再从流量上来看客户端支持的加密类型只有RC4了所以服务端也只能返回RC4加密的服务票据
这个是因为使用/tgtdeleg参数后rubeus会获取一个TGT并重新构造一个TGS-REQ请求并在请求中指定只支持RC4加密类型发送给域控。不过由于正常情况下客户端支持的加密类型肯定不只一种，所以像这种流量里面TGS-REQ阶段加密类型只有RC4一种的情况可以直接告警。假如我们给用户msDS-SupportedEncryptionTypes属性设置为AES了，4769日志中请求该spn用户服务票据加密类型为0x17也可以直接告警。
