Rebeus是一个用C#撰写Kerberos 乱用工具箱，最开始是由@gentilkiwi 撰写的 Kekeo 工具箱中的一个端口号，这一工具箱从那以后就在持续发展趋势。要掌握大量有关 Rubeus 的信息内容，请查询"从 Kekeo 到 Rubeus"本文事后的"Rubeus ——Now With More keo"或近期修定的 Rubeus README.md。

我近期对 Rubeus 干了一些改善，在其中包含再次核查了它的 kerberos 完成。 这造成了对 Rubeus 的 Kerberoast 方式的一些改动，也表述了大家以前在这个行业见到的一些"怪异"的个人行为。 因为 kerberos 是一种这般常见的技术性，如今大家早已对它的细微差别拥有更强的了解，因而我觉得深入分析关键点。

假如你没了解 Kerberoast，目前的很多信息内容能够你查看，在其中一些我还在本文的开始做了一些探讨。 假如你对 Kerberos (或 Kerberos)的原理没有一个基础的掌握，那麼本文的绝大多数內容对你而言就沒有什么意义，因此 假如你对这种定义觉得难受得话，我极力推荐你多读一些有关的文章内容。 可是这儿有一个有关 kerberos 实行全过程的简洁明了小结:

1. 攻击者对一个域开展身份认证，随后从域控制器服务器得到 一个票证授于票证(TGT) ，该票证授于票证用以之后的票证请求

2. 攻击者应用她们的 TGT传出服务票证请求(TGS-REQ) 获得特殊方式（sname/host）的 servicePrincipalName (SPN), 比如，MSSqlSvc/SQL.domain.com。此SPN在域中应该是唯一的，而且在客户或电子计算机帐户的servicePrincipalName字段名中申请注册。 在服务票证请求(TGS-REQ)全过程中，攻击者能够特定他们适用的Kerberos加密种类(RC4_HMAC，AES256_CTS_HMAC_SHA1_96这些)。

3. 假如攻击者的 TGT 是合理的，则 DC 将从 TGT 中获取信息内容并添充到服务票证中。 随后，域控制器搜索哪一个帐户在 servicedprincipalname 字段名中申请注册了所请求的 SPN。 服务票证应用申请注册了所规定的 SPN 的帐户的hach开展加密, 并应用了攻击者和服务帐户都适用的最高级的加密密匙。 票证以服务票证回应(TGS-REP)的方式推送回攻击者。

4. 攻击者从 TGS-REP 中获取加密的服务票证。 因为服务票证是用连接到请求 SPN 的帐户的hach加密的，因此 攻击者能够线下破译这一加密块，修复帐户的弱密码。

文中中大家即将提及的三种关键加密密匙种类分别是RC4_HMAC_MD5 (ARCFOUR-HMAC-MD5，在其中帐户的 NTLM 散列函数做为密匙)、 AES128_CTS_HMAC_SHA1_96和 AES256_CTS_HMAC_SHA1_96。 为了更好地简易考虑，我将他们称之为 RC4、 AES128和 AES256。

除此之外，这儿全部的事例全是在 Windows 10手机客户端上运作的，而Server 2012域控制器是一个2012 R2的域作用等级。

Kerberoast 方式

Kerberos 一般 选用二种通用性的方式:

· Kerberos 协议书的一个单独完成，根据联接到互联网上的机器设备应用，或是根据 SOCKS 代理商将精心策划的总流量做为键入。 比如 Meterpreter 或是Impacket。这必须一个域帐户的凭证来实行roasting，由于必须请求一个 TGT 在之后的服务票证请求中应用。

· 在域连接 的服务器上应用内嵌的 Windows 作用(如.NET KerberosRequestorSecurityToken . Net kerberos / requestorsecuritytoken类)请求票证，随后应用Mimikatz 或Rubeus 从当今登陆对话中获取票。此外一种可列举的方式是两年前@machosec 意识到GetRequest() 方式能够用于从 KerberosRequestorSecurityToken 中发掘出服务票证字节数，这代表着我们可以舍弃应用 Mimikatz 来获取票证。 这类方式的另一个优势是，目前客户的 TGT 可用以请求服务票证，这代表着大家不用密文凭据或客户的散列来实行 kerberos 广播节目。

要运用Kerberoast，大家就确实必须 RC4加密种类的服务票证回应，由于这比别的的 AES 加密种类更非常容易被破译。如果我们在攻击者一方完成了协议书，大家就可以挑选在服务票证请求全过程中特定大家只适用 RC4，进而更非常容易破散伙列文件格式。 在服务器端，我以往觉得 KerberosRequestorSecurityToken方式默认设置请求的是 RC4加密的票证，由于一般 回到的就是这个，但事实上"一切正常"票证请求个人行为产生在全部适用的登陆密码都获得适用的状况下能会产生。 那麼为何这类方式一般 会回到 RC4hach呢？

现在是时候迅速绕路了。

msDS-SupportedEncryptionTypes

大家以往探讨过的一个防御力指标值是"加密退级主题活动"。 因为当代域(作用等级在2008及之上)和电子计算机(vista / 2008 )默认设置适用在 Kerberos 互换中应用 AES 密匙，因而在一切 Kerberos 票证授于票证(TGT)请求或服务票证请求中应用 RC4都应该是出现异常的。 瓦莱丽 · 梅特卡夫有一篇名叫"检验 Kerberoast 进攻主题活动"的优秀文章，在其中包含了如何处理 DC 恶性事件来检验这类种类的攻击性行为，虽然他强调"很有可能会出現乱报"。

为何这类方式会出現乱报的难题，这个问题的详细回答也表述了我很多年来见到的一些应用 Kerberoast的"怪异"个人行为。

为了更好地表明这一点，假定大家有一个在其 servicePrincipalName (SPN)特性中申请注册了 MSSQLSvc/SQL.testlab.local 的客户帐户sqlservice 。 我们可以应用

powershell -C ”Add-Type -AssemblyName System.IdentityModel; $Null=New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList ‘MSSQLSvc/SQL.testlab.local”

因此 SPN 请求服务票证。 殊不知，运用于当今登陆对话的結果服务票证特定应用 RC4，虽然请求客户的(harmj0y) TGT 应用的是 AES256。

如前所述，因为种种原因，长期以来我觉得 KerberosRequestorSecurityToken方式尤其必须 RC4。 殊不知，看一下 Wireshark 从手机客户端捕捉的 TGS-REQ (Kerberos 服务票证请求) ，我们可以见到全部适度的加密种类(包含 AES)都被特定为适用: