简介

经过几个月的开发和质量测试，我们很自豪地宣布BloodHound 3.0 正式发布！ 在这个版本中，包括了3个新的攻击原语，GUI 和 SharpHound 的一些性能改进，以及对 Neo4j 4.0的支持。

对那些直接或间接为本次发布做出重大贡献的人表示感谢： Tim McGuffin (@NotMedic), Michael Grafnetter (@MGrafnetter), Will Schroeder (@harmj0y), Lee Christensen (@tifkin_), Sean Metcalf (@PyroTek3), Dirk-jan Mollema (@_dirkjan), 以及 Mark Gamache (@markgamacheNerd)。

这是一个大版本的发布，意味着我们将在这个版本中引入打破兼容性的特性—— SharpHound2和你的 BloodHound 2.x 数据库将与 BloodHound 3.0不兼容，因此请确保你使用的是最新的 SharpHound。 BloodHound 3.0与 Neo4j 4.0兼容，节点现在是通过它们的 SID 唯一标识的而不是名称。

新的攻击原语

在 BloodHound 3.0中，包括了三个新的攻击原语: GMSA 控制、 OU 控制和 SID 历史记录。 默认情况下，任何经过域身份验证的用户都可以读取与这些新攻击原语相关的配置，并且每个攻击原语都可以使用实用工具进行处理。 攻击者可以根据这些攻击原语找到新的攻击路径，从而找到以前未被发现的能够拿到 DA 权限 (或者不管你的目标是什么) 的攻击路径，而防御者可以使用 BloodHound 来审计和补救相同的攻击路径。

以下是每个新的攻击原语的工作原理:

新攻击原语: GMSA 控制

组管理服务帐户(GMSA)是活动目录中的特殊服务帐户，它解决了许多关于最小特权和凭证安全的问题。 GMSA 的密码由域控制器管理，每30天自动更改一次(默认情况下) ，由128个字符组成(可以理解为: 你不可能猜出来)。

GMSA 的关键在于管理员需要指定允许谁读取 GMSA 的明文密码。 例如，假设我们的用户 Dwight Hohnstein 可以读取 SQL GMSA 的密码。 在 BloodHound 的图形用户界面中，你可以看到从 Dwight 到 SQL 计算机的攻击路径：

如果我们能够进入 DHOHNSTEIN 用户的上下文，我们就可以检索 GMSA-SQL01的明文密码，然后横向移动到 SQL01.CONTOSO.LOCAL。 已经有一些工具可以检索出 GMSA 密码，但是没有一个可以让你保持完全的内存驻留。 出于这个原因，Rohan 创建了 GMSAPasswordReader，它利用了一个 C# 中的功能，可以读取 GMSA 的密码。 下面是使用 GMSAPassword.exe 和 Cobalt Strike 的 execute-assembly 函数来检索 GMSA-SQL01的 NT 哈希的示例：

现在，通过使用 GMSA 帐户密码的 NT 哈希，你可以模拟用户(例如，使用 overpass-the-hash) ，然后从侧面移动到 SQL01.CONTOSO.LOCAL。

有关 GMSA 的更多信息，请参阅 Michael Grafnetter 的发表的这篇优秀的文章。

新攻击原语: OU 控制

AD 管理员经常会在 OU 上定义 ACE，这些 ACE 适用于 OU 本身或 OU 及其派生的对象，但不适用于派生的用户、组和计算机对象。 在过去，我们已经看到了通过与 OU 链接的 GPO 对象来控制 OU，以及将恶意的 GPO 链接到你所控制的 OU 的可能性。 这有几个问题，最关键的是，你需要能够在一台恶意的 GP 服务器上正确地托管你的恶意 GP 文件—— 到目前为止通过命令行的方式已被证明要完成攻击相当困难。 然后它像一吨砖块一样砸向我们: 通过控制 OU ，你可以将 ACE 推送到 OU 上，然后将 ACE 继承到 OU 派生的对象！

例如，假设 Justin Bui 完全控制了我们的 Workstation Admins OU，其中包含 Josh Prager 的 user 对象：

这里的攻击相当简单: 从 JBUI 的上下文中，我们可以向 Workstation Admins OU 添加一个新的 ACE，这个 ACE 将继承到 JPRAGER。 这是由 PowerView 的一个叫做 New-ADObjectAccessControlEntry 的 cmdlet 实现的，作者是 Lee Christensen (@tifkin_)。 一旦新的 ACE 就位，我们就可以从 JBUI 的上下文中滥用 JPRAGER 用户，就像我们在 BloodHound 1.3 ACL 更新后所做的那样: 重置他的密码，或者进行目标明确的 kerberos 煅烧攻击。

当你将 ACE 应用于 OU 并将其设置为向下继承到子对象时，你可以选择将其应用于所有对象、某个类的对象，甚至可以控制它是否应用于 OU 的直接子对象或所有子对象。 有关如何在 OU 上执行通用或特定于某个对象的 ACE 的完整示例，请参阅 BloodHound GUI 中的边缘帮助模式:

新攻击原始: SID 历史

最后，我们还将 SID 历史作为一个新的攻击原语包含在 BloodHound 3.0中。 作为一个红队成员，你可能首先会想到滥用 SID 历史功能的黄金票证，但实际上我们看到的是用户、计算机和组，它们已经在其 AD 对象的 SIDHistory 参数中列出了 SID。 当一个对象从一个活动目录域迁移到另一个域时，可以合法地填充这些参数——目的是为了维护该主体所拥有的权限和特权，新的域中的对象将包含该主体所属的任何组的 SID。

例如，假设 Josiah Massari 的用户对象从 FABRIKAM 域迁移到 CONTOSO 域。 在 FABRIKAM 域，Josiah 属于工作站管理员组（Workstation Admins），它拥有 FABRIKAM 所有工作站的本地管理权限。 在 CONTOSO 域中，Josiah 的用户对象将包含 FABRIKAM 中 Workstation Admins 组的 SID。 现在，每当 Josiah 在企业中进行身份验证时，他的 kerberos 票证将在票证的 PAC 的 ExtraSIDs 部分包含该组的 SID，从而授予他该组所拥有的所有相同的权限和特权。

总结起来就是一句话: Josiah 实际上仍然是 FABRIKAM Workstation Admins 组的成员，尽管他的用户对象不再属于那个组。 更多有关的详细信息，请看 Sean Metcalf 的精彩博文: Sneaky Active Directory Persistence #14: SID History。

在BloodHound 图形用户界面中，上面的情况是这样的：

这里的滥用方式是相当简单的。 事实上，你可以简单地认为“HasSIDHistory”就是你已经认为的“MemberOf”的边缘。 从 JMASSARI 上下文中，你将对 FABRIKAM 域中的两个工作站拥有管理权限。

这里有一个极其重要的警告: 如果 CONTOSO 和 FABRIKAM 域之间的域信任强制执行 SID 过滤，这种攻击将不起作用，因为 JMASSARI 的 kerberos 票证 PAC 的 ExtraSIDs 部分中的 SID 将被 FABRIKAM 域忽略。 有关 SID 过滤的更多信息，请参阅 Will Schroeder 的优秀博客文章“攻击域信任指南”。

性能改进

我们在两个主要的方面做了很大的性能改进: 使用 SharpHound 收集数据，使用 BloodHound GUI 导入数据。 在 SharpHound 方面，你应该可以看到 LDAP 收集的速度大约提高了25% 到30% 。 主机收集稍微慢一点，但有了一个更好的准确性权衡。 与前一版本相比，尝试将主机解析为正确值的检查次数比前一个版本显著增加。。

在数据导入方面，Rohan 已经完全重新构建了 JSON 解析和导入逻辑，因此将文件拖放到 GUI 中将非常非常快。

如果有足够的兴趣，Rohan 将在未来的博客文章中描述他是如何实现这些速度改进的技术细节，以及从主机获取信息的更新方法。

质量改进

在 GUI 如何处理特别吃内存的查询和GUI如何处理具有许多节点和边的图形呈现方面有两个主要的变化。

首先，每当你点击 BloodHound GUI 中的一个节点时，该节点的信息标签就会填充并开始显示关于该对象的各种信息：

其中一些查询对于数据库来说非常容易处理，比如从用户节点获取“password last set”日期和时间，或者甚至获取用户已经分组授予管理权限的计算机数量。 但是其中一些查询实际上非常吃内存，尤其是当你开始处理超过一定规模的数据库时(比如说，超过30000个节点)。 具体地说，任何使用 shortestPath() 的情况中，如果开始节点或结束节点可以是图中的任何其他节点(而不是特定节点) ，都会给数据库带来大量的运算工作。

以前，每次单击用户节点时，我们都会启动3个这样的查询: 派生的本地管理权限、传递对象控制器和传递对象控制器。 我们并没有删除这些查询，我们只是改变了默认的行为，现在你可以点击一个“play”按钮来启动这个查询，而不是每次你点击一个用户节点(并在数据库上投入大量的工作)都会运行这些查询：

其次，BloodHound GUI 的一个大问题是渲染由数百个节点和边组成的非常大的图。 这是因为我们依赖于免费和开源的图形渲染库——所有这些库都被限制用 CPU 而不是 GPU 来渲染图形布局。 当然，GPU 在渲染图形方面的数量级要比 CPU 快，因此这是我们目前必须解决的一个限制，而不是必须解决的。

我们的解决方案是拦截 neo4j 返回的数据，确定数据量是否可能导致 GUI 挂起很长时间，然后让用户选择如何继续：

点击“Cancel”会完全按照你的想法去做。 “Save Data”将为你提供一个通用的对话窗口，你可以在这个窗口中以 JSON 格式保存原始图形数据。 “Draw Graph”将继续像通常一样尝试渲染边和节点。

总结

我们希望你能喜欢 BloodHound 3.0的这个版本，它提高了性能，增加了新的攻击原语，并且提高了质量。 请记住: 这是一个主要版本，你还必须使用 SharpHound 的最新版本: SharpHound3。 我们真诚地感谢 BloodHound Slack 频道中使用测试版的每一个人，感谢他们帮助我们测试所有的组件。 我们还要再次感谢 Tim McGuffin (@NotMedic), Michael Grafnetter (@MGrafnetter), Will Schroeder (@harmj0y), Lee Christensen (@tifkin_), Sean Metcalf (@PyroTek3), Dirk-jan Mollema (@_dirkjan), 以及 Mark Gamache (@markgamacheNerd)，感谢他们对本次发布的直接和间接的贡献。 谢谢！

本文翻译自：https://posts.specterops.io/introducing-bloodhound-3-0-c00e77ff0aa6如若转载，请注明原文地址：