域渗透技术解析：Roasting AS-REP

去年11月，我发表了一篇名为 "没有 Mimikatz 的 Kerberoast 攻击利用" 的文章，详细介绍了 PowerView 和 Tim Medin 提出的 Kerberoasting 攻击 的最新研究进展。这使我开始更仔细地研究 Kerberos。 几周前，我的同事 Lee Christensen 发现 Exumbra Operations 的Geoff Janjua做了一个有趣的演讲，题为" 武器化 Kerberos 协议漏洞（Kerberos Party Tricks: Weaponizing Kerberos Protocol Flaws） "， 幻灯片和 工具 包可以在这里找到 。Geoff提到的一个有趣的地方，也是他编写的基于 Python 的"Party Trick"工具包执行的地方，就是滥用不需要 Kerberos 预身份验证的用户帐户。

最近，我对这个话题进行了更深入的研究，并想与大家分享我所学到的和开发出的一些东西。这篇文章将给出一些我们正在滥用Kerberos的详细背景和具体的问题是什么，如何轻松地列举出不需要预身份认证的账户，如何在这些情况下提取可破解的哈希，以及最后如何有效地破解这些检索到的哈希。还有一个相关的PowerShell工具包， ASREPRoast ，可以在GitHub上找到。

tl;dr ——如果你可以枚举Windows域中不需要Kerberos预身份认证的任何帐户，那么你现在就可以轻松地为这些帐户请求一条加密信息，并有效地离线破解这些账户的哈希，从而拿到用户的明文密码。

注意: 这并不是什么开创性的东西，显然也没有 Kerberoast 攻击那么有用，因为账户必须明确设置 DONT_REQ_PREAUTH 让其易受攻击—— 你仍然依赖于密码复杂性较弱这个弱点来实施攻击。 然而，这种设置在某些环境中仍然存在，我们只是不确定这种情况发生的频率，因为它不是我们以前通常要寻找的东西。我们的猜测是，它可能是为较老的帐户而启用的，特别是与Unix相关的帐户。 如果你碰巧在"野外"发现了它，我们很乐意收到你的来信;)(在推特上 @harmj0y 或者发邮件给[email protected])。

如果你拿到的目标用户拥有GenericWrite/GenericAll权限，你就可以恶意修改他们的userAccountControl属性以使其不需要预身份验证。之后使用ASREPRoast，重置这个属性的值;)

背景

我不打算详细介绍Kerberos的所有方面，因为像 肖恩 · 梅特卡夫 这样的人已经在这方面 做了大量的工作 。 如果像AS-REQ 和 AS-REP这样的术语对你来说是完全陌生的，那么我建议你先阅读 肖恩的文章 ，以便了解一些基本的背景知识。 我们在这篇文章中关注的是 Kerberos 预身份认证 这个方面。

在Windows Kerberos环境中的正常操作下，当你为给定用户启动TGT请求(Kerberos AS-REQ，消息类型为10)时，必须提供用该用户的密钥或密码加密的时间戳。 这种结构是PA-ENC-TIMESTAMP，嵌入到AS-REQ的PA-DATA (预授权数据)中——这两种结构在 RFC4 120的第60页 都有详细的描述，并在Kerberos版本5中进行了介绍。KDC 之后会解密时间戳，以验证创建AS-REQ的主体是否真的是该用户，然后返回AS-REP并继续执行正常的身份验证过程。

注意: 对于任何不正确的PA-ENC-TIMESTAMP尝试，KDC确实增加了badpwdcount属性，因此我们不能使用这种方法来在线爆破帐户密码: (

Kerberos预身份验证的原因是为了防止离线密码猜测。AS-REP票证本身使用的是服务密钥(在本例中是 krbtgt hash)加密，而AS-REP"加密部分"则使用客户机的密钥(即我们发送 AS-REQ 的用户的密钥)进行签名。如果没有启用预身份认证，攻击者可以向任何没有要求预身份认证的用户发送AS-REQ，并收到一些加密数据块，这些加密的数据可以进行离线破解从而泄露目标用户的明文密码。

这是人们 早就知道的事情 ，毕竟，它是在 Kerberos 中实现预身份认证 的原因 ！ 在现代Windows环境中，所有用户帐户都需要Kerberos预身份认证，但有趣的是，默认情况下Windows尝试 AS-REQ和AS-REP交换，而不是首先进行身份认证，让我们回到在第二次提交时提供加密的时间戳:

我不知道为什么会发生这种行为？！

@munmap 在 推特上 指出，这种行为是由于客户端事先不知道支持的ETYPES， RFC6113的2.2章节 中明确详细说明了这一点。

然而，Windows 提供了一种通过修改 useraccountcontrol 手动禁用对特定帐户进行保护的方法:

如果你已经是一个经过身份验证的用户(但在其他方面没有特权) ，你可以使用LDAP过滤器轻松地枚举该域中具有此设置的用户(userAccountControl:1.2.840.113556.1.4.803:=4194304)。 PowerView 的Get-DomainUser已经使用  -PreauthNotRequired  参数实现了这个功能:

所以现在我们知道了问题所在，以及如何识别易受攻击的用户。 虽然十多年来已经出现了对Kerberos交换中的AS-REQ的PA-ENC-TIMESTAMP组件进行暴力破解的方式(哈希格式甚至在 Hashcat 已经存在， -m 7500/ ‘Kerberos 5 AS-REQ Pre-Auth’ ) ，但我所见过的唯一攻击RC4的工具集是  Geoff 的 Python 工具包 。 我们需要一些基于Windows的工具，这些工具也不需要机器上的管理特权来允许我们在攻击工作流程中保持灵活性。 我们还希望有一种更快的方法来破解这些哈希。

ASREPRoast

我的第一个希望是在 .NET 中找到一些已经公开的类似于 Kerberoast 攻击方法 的AS-REP原始字节。我花了一段时间寻找相关的.NET方法，希望有某个方法能够访问AS-REP的原始字节响应，但不幸出现。虽然我不能确定这是否是不可能做到的，但我的直觉告诉我这可能是一个非常有深度的抽象层，我们无法轻易到达。即使.NET有这样的方法，我们仍然有一个难题要解决，因为现代 Windows Kerberos环境在AS-REP中默认使用AES256-CTS-HMAC-SHA1-96进行加密，而不是用更快的ARCFOUR-HMAC-MD5/RC4方法。RC4-HMAC的破解速度要快得多，所以如果可能的话，我们更喜欢它。

我最后采用的方法是手工构造AS-REQ以控制必要的参数，并解析KDC的AS-REP响应以确定成功或失败并提取加密数据。 这里有另一个障碍——Kerberos使用的是ASN. 1进行编码结构。.NET没有内置的编码器或解码器。幸运的是，有一个 开源的 C# 版本 的 Bouncy Castle 加密库，其特点之一是具有强大的ASN. 1编码和解码能力。

不幸的是，我没有时间给出一个完整的ASN. 1使用教程，但是我将分享一些在开发这个工具时帮助我的几个点。 对于AS-REQ 我们所关心的规范在 RFC1510的第55页 和 RFC4120的第74页 已经列出。 Benjamin Delpy 也在他的 Kekeo 项目 中记录了所有这些ASN. 1结构。 下面是结构描述:

AS-REQ ::=         [APPLICATION 10] KDC-REQ
KDC-REQ ::=        SEQUENCE {
           pvno[1]               INTEGER,
           msg-type[2]           INTEGER,
           padata[3]             SEQUENCE OF PA-DATA OPTIONAL,
           req-body[4]           KDC-REQ-BODY
}
PA-DATA ::=        SEQUENCE {
           padata-type[1]        INTEGER,
           padata-value[2]       OCTET STRING,
                         -- might be encoded AP-REQ
}
KDC-REQ-BODY ::=   SEQUENCE {
            kdc-options[0]       KDCOptions,
            cname[1]             PrincipalName OPTIONAL,
                         -- Used only in AS-REQ
            realm[2]             Realm, -- Server's realm
                         -- Also client's in AS-REQ
            sname[3]             PrincipalName OPTIONAL,
            from[4]              KerberosTime OPTIONAL,
            till[5]              KerberosTime,
            rtime[6]             KerberosTime OPTIONAL,
            nonce[7]             INTEGER,
            etype[8]             SEQUENCE OF INTEGER, -- EncryptionType,
                         -- in preference order
            addresses[9]         HostAddresses OPTIONAL,
            enc-authorization-data[10]   EncryptedData OPTIONAL,
                         -- Encrypted AuthorizationData encoding
            additional-tickets[11]       SEQUENCE OF Ticket OPTIONAL
}

另一件对我帮助很大的事情是Wireshark中合法的Kerberos交换数据，导出Kerberos数据包字节，并使用这个 JavaScript ASN. 1解码器 执行数据可视化:

接下来要说的内容在下一部分尤其有帮助，那就是学习如何通过PowerShell使用Bouncy Castle来构建一个正确的通过ASN. 1编码的AS-REQ。但经过几次努力，我终于找到了New-ASReq， 它接受一个用户名或域名称，构建正确嵌套的组件，并返回请求的原始字节 。

因为我们是自己手动开发的，所以我们可以包含或省略任何我们想要的内容。 因此，我们可以只包含ARCFOUR-HMAC-MD5加密类型，而不是所有支持的加密类型。 在 RFC4757  中详细解释了这种类型及其在Windows Kerberos身份认证中的使用。特别好的是， 第3章节 中包含了算法的不同用途的消息类型。虽然AS-REP票证使用的是类型2，和TGS-REP票证一样(即 kerberoast攻击) ，但响应的这个组件是用服务密钥加密的，在这种情况下，服务密钥是krbtgt哈希，因此不可破解。 然而，AS-REP的加密部分，也就是我们可以"降级"到RC4-HMAC的部分，使用了相同的算法，但消息类型为8。 这将在本文稍后的“破解哈希”章节中进行阐述。

在 ASREPRoast 中的第二个函数Get-ASREPHash通过封装New-ASReq为特定用户或域生成适当的AS-REQ，枚举指定域的域控制器， 发送精心构造设计的AS-REQ ，并接收响应字节。Bouncy Castle用于解码响应，检查它是 KRB-ERROR 响应还是正确的 AS-REP 。 如果请求成功，我们可以 提取出使用指定用户的哈希加密的RC4-HMAC的enc-part部分 ，并以一种可读性良好的格式返回:

在 ASREPRoast 中最后一个有用的功能是 Invoke-ASREPRoast 。 如果在Windows Kerberos 环境中从经过身份验证但没有特权的域用户的上下文中运行，该函数将首先使用LDAP过滤器(userAccountControl: 1.2.840.113556.1.4.803:4194304)枚举在其用户帐户控制设置中设置了"不需要Kerberos预身份验证"的所有用户。对于每个返回的用户，Get-ASREPHash会返回一个可破解的哈希:

破解哈希

我们已经现在有了一个很好的RC4-HMAC AS-REP哈希数据集，其中的每一个都使用相应的用户密码进行加密。我们现在应该能够执行Kerberost攻击离线破解这些哈希(John the Ripper 中的 krb5tgs 格式) ，但是请记住，尽管使用了与现有的TGS-REP格式相同的算法和方法，但是这里的 消息类型是8而不是2 。

不幸的是，现有的插件无法工作，不过幸运的是，我们所要做的就是将 这一行 改为8而不是2， 删除一些特定的TGS ASN. 1加速版本 ，并改变格式命名。 我有一个包含了 修改过版本的 krb5_asrep_fmt_plug.c插件的ASREPRoast project项目 。 只需将其放入 Magnumripper 的源文件夹，运行正常的构建指令，就可以破解ASREPRoast.ps1输出的加密数据:

我相信以 类似的方式 修改Hashcat中现有的TGS-REP格式应该也很简单，但我还没有尝试过。并且，因为与Kerberoast攻击中krb5tgs的格式使用了相同的算法，只是在关键内容上进行了调整，所以性能应该与现有的模块差不了太多。

最后的想法

正如我在一开始提到的，本文所阐述的攻击方法显然不如 Kerberoast 攻击 有用，因为帐户必须明确设置了 DONT_REQ_PREAUTH 才能利用，你仍然依赖于密码复杂性较弱这个弱点来实施攻击。 然而，这种设置有时会出现在某些环境中，通常是由于向后兼容性的原因造成的，并且我们认为至少在某些情况下，这种攻击的利用工具在操作方面上是有用的。

防御方面，这里阐述的与防御Kerberoast攻击相同的保护措施也适用于这种类型的帐户，特别是对这些类型的帐户设置很长的密码，并在异常主机为该帐户发送AS-REP时发出警报。此外，审计哪些帐户具有这种设置，使用 PowerView (Get-DomainUser-preauthnotrewell)或其他带有(userAccountControl: 1.2.840.113556.1.4.803:4194304)过滤器的LDAP工具集就可以轻易做到这一点。仔细考虑是否真的需要这种设置的帐户。

防御方面, @munmap 建议研究 Kerberos FAST 预身份认证 或 用于Kerberos (PKINIT)初始身份验证的公钥加密 。