域渗透技巧：MachineAccountQuota的利用

MachineAccountQuota （ MAQ ）是一个域级别的属性，默认情况下允许非特权用户将最多 10 台计算机连接到 Active Directory （ AD ）域。我第一次接触 MAQ 是在我作为网络管理员的时候。当时我被分配了一个将远程主机加入 AD 的任务。在添加了十台计算机后，当我再次尝试添加新机器时弹出了下面的错误消息：

搜索错误消息后，我发现了 ms-DS-MachineAccountQuota 这个页面。网页显示的细节信息与我提供的无特权 AD 访问是一致的。我联系了一位管理员并解释了情况。他不熟悉如何增加我帐户的配额。相反，他为我提供了一个域管理员帐户来继续完成我的工作。

Powermad

2017 年末，我发布了 Powermad ，它是一个衍生自 LDAP 域加入 数据包捕获的 PowerShell 函数集合的工具。在挖掘数据包之后，我确定了创建机器帐户对象的单一加密 LDAP 添加操作。以下是未加密状态下 LDAP 添加操作的示例：

开发 Powermad 时我的主要动机是在渗透测试过程中更容易地使用 MAQ 。在过去，我曾见过渗透测试人员通过将完整的 Windows 操作系统附加到域来利用 MAQ 。我希望能够只添加一个已知密码的机器帐户（也称为计算机帐户），而不是仅以这种方式使用 MAQ 。

那么 MachineAccountQuota 到底有用吗？

自从我第一次开始研究 Powermad 以来，我已经学到了很多关于 MAQ 的知识，而不仅仅是默认的只能添加 10 个主机的限制。最近，我从 Elad Shamir ， Harmj0y 和 Dirk-jan 的 一些精彩博客文章中学到了更多 的 东西 ，其中一些文章也提到了 MAQ 。

总的来说，我得出的结论是 MachineAccountQuota 非常有用 ……

… 当然，只是有时候。

在这篇博文中，我将作为攻击者通过 10 条规则来处理 MAQ 。我仅仅以向 AD 中添加计算机帐户而不是附加完整的 Windows 系统的角度编写了这些规则。稍后，我将一些规则应用于 MAQ + Kerberos 的无约束委托用例。最后，我将解决针对 MAQ 相关漏洞的攻击方法。

规则是什么？

我把我对 MAQ 的了解分解为 10 条规则。希望你可以使用这些规则来确定 MAQ 在任何特定情况下是否有用。

允许非特权用户将机器帐户对象添加到域。 默认情况下，非特权用户可以创建 10 个计算机帐户。

你无需执行任何特殊操作即可调用MAQ。你只需尝试使用尚未直接授予域加入权限的帐户添加计算机帐户。

创建者帐户的SID存储在ms-DS-CreatorSID属性中。仅当创建者不是管理员或未被授予添加计算机帐户的权限时，AD才会填充此属性。

AD 还使用 ms-DS-CreatorSID 来计算针对 MAQ 的当前计数。从渗透测试角度来看，请记住该属性指向了创建者帐户，即使嵌套的 MAQ 用法也是如此。因此，使用通过 MAQ 创建的计算机帐户不能完全屏蔽创建者帐户。

如果防御人员意识到了 ms-DS-CreatorSID 属性，那么他们很可能已经禁用了 MAQ 。

通过 MAQ 创建的计算机帐户将放入 “ 域计算机 ” 组。在 Domain Computers 组被授予额外权限的情况下，要重点注意此权限还可以通过 MAQ 扩展到非特权用户。例如，你可能会在本地 Administrators 组中找到列出的域计算机。

甚至在域管理员组内找到。

作为此规则的略微扩展，请注意根据计算机帐户名称的部分自动将计算机放置在 OU 和组中。你可以通过 MAQ 利用这个自动化过程。

创建者帐户被授予对某些计算机帐户对象属性的写访问权。通常，这包括以下属性：

· 帐户已禁用

· 描述

· 显示名称

· DNSHOSTNAME

· ServicePrincipalName

· userParameters

· userAccountControl

· msDS-AdditionalDnsHostName

· msDS-AllowedToActOnBehalfOfOtherIdentity

· samAccountName

· 你可以根据需要修改这些属性。

但是，某些属性的允许值仍需要验证。

计算机帐户本身具有对其某些属性的写访问权。该列表包含 msDS-SupportedEncryptionTypes 属性，该属性可能会对协商过程的 Kerberos 加密方法产生影响。现代 Windows 操作系统版本将在加入域的过程中将此属性设置为 28 。  

添加计算机帐户时，会严格验证属性。基本上，属性值需要完全匹配。如果它们不匹配，则会添加失败，例如下面是一个 samAccountName 的不正确示例。   奇怪的是，在添加计算机帐户后，一些验证规则会变的宽松。

samAccountName 可以改变为已经存在于一个域的任何不匹配的 samAccountName 。更改此属性有助于将渗透活动与合法流量混合，例如通过剥离 “$” 字符或匹配正在使用的帐户命名约定。有趣的是， samAccountName 甚至可以在允许模仿任何现有域帐户的空间中结束。

以下是伪造的 “ 管理员 ” 帐户在实际操作中的显示方式。

请注意，更改 samAccountName 不会更改实际的计算机帐户对象名称。因此，你可以使用与命名约定混合的计算机帐户对象，同时还具有完全不同的 samAccountName 。

添加计算机帐户会创建 4 个 SPN 。该列表包括以下内容：

·HOST / MachineAccountName

· HOST / MachineAccountName.domain.name

· RestrictedKrbHost / MachineAccountName

· RestrictedKrbhost / MachineAccountName.domain.name

例如，以下是 'test.inveigh.net' 计算机帐户的默认 SPN 列表。

添加计算机帐户后，可以使用任何通过验证的 SPN 附加或替换列表。   如果修改 samAccountName ， DnsHostname 或 msDS-AdditionalDnsHostName 属性， SPN 列表将自动使用新值进行更新。默认的 SPN 确实涵盖了很多用例。因此，你并不总是需要修改列表。如果需要有关 SPN 的更多信息， Sean Metcalf  在 AdSecurity 上 提供了非常完整的 列表， 其中包含有关 Host 和 RestrictedKrbHost 的详细信息。

计算机帐户没有本地登录的权限。但 是，通过直接运行或通过使用了 “runas / netlonly” 命令接受凭证的工具，机器帐户就可以在命令行中正常工作。任务可以包括 枚举 ， 添加 DNS 记录 ，或者几乎任何适用于用户帐户的非 GUI 操作。  

通过MAQ添加的计算机帐户无法由非特权创建者帐户删除。 要在使用 MAQ 后彻底清除 AD ，你需要提升域权限或将任务传递给你的客户端。但是，你可以使用非特权创建者帐户禁用该帐户。  

MachineAccountQuota 的实际应用

让我们采用上述规则并将其应用于已经拿到权限并且具有 SeEnableDelegationPrivilege 的 AD 帐户。如规则 4 中所述，即使帐户具有对属性的写访问权限，写入尝试仍然需要进行验证。

但是，如果你碰巧使用了正确的权限（例如 SeEnableDelegationPrivilege ） 拿到某个帐户，事情会变得有趣。

在这种情况下，我们可以使用 'INVEIGH \ kevin' 帐户以及 MAQ 来创建和配置能够执行 Kerberos 无约束委派的计算机帐户对象。这可以非常方便的消除寻找现有合适的 AD 对象以利用 SeEnableDelegationPrivilege 的要求。基本上，我们可以通过 MAQ 来做到这一点。

请注意，这是其中一种情况，如果可以的话，只需使用你自己的 Windows 系统加入域就可以使事情变得更加容易。如果你确实采用了这种方法，那么你只需在计算机帐户对象上启用无约束委派，并像在被入侵的系统上一样利用它。另外，当我们只使用机器帐户时，该过程仍然非常易于管理。

Kerberos 无约束委派设置

对于这种情况，我们假设我们在随机的一台 Windows 域系统上具有非特权访问权限，并且还拿到了一个具有 SeEnableDelegationPrivilege 权限的帐户。

以下是设置攻击的步骤：

1、使用 SeEnableDelegationPrivilege 帐户通过 MAQ 添加计算机帐户。  

2、通过将 userAccountControl 属性设置为 528384 来启用无约束委派。  

3、（可选）设置 msDS-SupportedEncryptionTypes 属性以使用计算机帐户的凭据设置所需的 Kerberos 加密类型。  

4、（可选）添加与 SPN 相匹配和对应的 DNS 记录，并指向拿到的 Windows 系统。这通常可以通过 动态更新或 LDAP 来完成。这个操作是可选的，因为使用默认 SPN ， Kerberos 还可以从其他名称解析方法（如 LLMNR / NBNS ）触发。  

Kerberos 无约束委派攻击

有了上述内容，我们接下来需要弄清楚如何获取到已经拿到的主机所需的帐户流量。对于第一步，我们将使用 tifkin 的打印机错误 来获取域控制器计算机帐户以通过 SMB 连接到我们的系统。此外，我们将使用 Inveigh 的 dev Branch 版本 。通过数据包嗅探，此版本可以获取 SMB Kerberos TGT 流量并尝试输出 kirbi 文件，以便与 Mimikatz 和 Rubeus 等 工具 一起使用。

对于 Inveigh ，我们需要使用无约束委派帐户的 AES256 哈希或带有 Kerberos salt 的 PSCredential 对象作为用户名。下面显示的是使用 Powermad 的 Get-KerberosAESKey 函数生成正确的 AES256 哈希的过程。

注意， Inveigh 目前仅支持 AES256 Kerberos 解密。

由于我们想要使用我们的无约束委托机帐户的 SPN ，我们需要让目标连接到正确的主机名。在这个例子中，我将使用 Dirk-jan 最近发布的 Krbrelayx 工具包中的 printerbug 脚本。

到这一步时，让我们退后一步，重新审视这些 SPN 。首先，我们在拿到的系统上以 SYSTEM 权限运行了 SMB 服务器。这意味着 SMB 服务器将使用系统的计算机帐户凭据解密 Kerberos 票证。如果我们故意让 SPN 不匹配并尝试使用在不同 SPN 下加密的数据执行 Kerberos 身份验证，则 SMB 身份验证将失败。但是， SMB 服务器在客户端发送 AP-REQ  之后 才会拒绝认证尝试。

更重要的是，对于这种情况， SMB 服务器将在收到 TGT 后拒绝连接。因此，如果我们可以通过数据包嗅探获取 Kerberos 流量，我们可以使用我们拥有的机器帐户凭据解密所需的数据。

请注意，使用 SPN 不匹配技巧可能会触发来自客户端的多次 Kerberos 身份验证尝试。我将 Inveigh 设置为默认情况下每个用户仅输出 2 个 kirbi 文件。 Inveigh 会将其余的存储在内存中，以便通过 Get-Inveigh 进行访问。

现在我们有域控制器的 kirbi TGT ，我们可以将它传递给 Mimikatz 并尝试执行 dcsync 。

在另一个演示中，我使用 Inveigh 来捕获 SMB 上的域管理员的 TGT 。

接下来，我使用 Rubeus 处理 kirbi 文件。

作为最后一个例子，下面是 Inveigh 通过 HTTP 捕获 TGT 。

在理想情况下， HTTP 可以不需要对受感染系统的本地管理员进行访问。

最后，上面的 Kerberos 无约束委托技术也适用于新的 krbrelayx 工具包。

关于 SeEnableDelegationPrivilege + MAQ 我想说的最后一句话是，由于缺少对 msDS-AllowedToDelegateTo 的写访问权限，因此完全设置标准 的约束 委派通常是不可行的。

防御 MachineAccountQuota

我相信 MAQ 只是人们缺乏足够的安全意识的默认设置之一。我猜测公司很少真正需要默认的 MAQ 设置，甚至根本不需要它。要禁用 MAQ ，只需 将计数设置为 0 。如果确实需要允许非特权用户添加主机到域中，那么更好的方法是将权限委派给特定组。请注意，此博客文章中列出的大部分内容也适用于具有委派域加入权限的受感染帐户。

防守者还可以留意两件事：

· 已填充的 ms-DS-CreatorSID 属性

· 未更改密码的计算机帐户

结论

与大多数事情一样， MachineAccountQuota 的使用情况也是有情境性的。对于测试人员来说，这对你的渗透技巧来说是值得考虑的。最近由 Elad Shamir 等研究人员发布的技术使这一点变得更加明显。对于防御者，我建议只禁用 MachineAccountQuota 即可。