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在任何特定情况下是否有用。
1、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即可。
本文翻译自： https:// blog.netspi.com/machine accountquota-is-useful-sometimes/ 如若转载，请注明原文地址： https://www. 4hou.com/penetration/17 435.html 更多内容请关注“嘶吼专业版”——Pro4hou
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
