那些从未听过的高危用户权限

[[182348]]

前言

我发现Windows用户权限非常有趣。独立于计算机/域对象DACL，用户权限主要负责“通过什么方式可以让特定的用户登录到一个特定的系统 ”，它被组策略中的用户权限分配所管理。我最近利用Get-ProcessTokenPrivilege函数中将枚举到的特权整合到PowerUp，尤其是特殊的权限。

SeEnableDelegationPrivilege

SeEnableDelegationPrivilege被我忽略了。这项权限负责一个用户帐户是否可以“允许计算机和用户帐户被信任为委派”，我忽略了它的权限是因为规定的文档：“没有任何理由将此用户权限分配给成员服务器上的任何人和属于域的工作站，因为它在这些上下文中没有意义; 它仅与域控制器和独立计算机相关。“所以这个权利适用于域，而不是本地域加入的机器。

我们一开始都认为这个权限只负责TRUSTED_FOR_DELEGATION和TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION标志的修改-这将建立一个漂亮的攻击。不幸的是，对我们的攻击者，看来这种权限也控制msDS-AllowedToDelegateTo属性的修改，它包含受限制的委派目标。

如果我们没有SeEnableDelegationPrivilege 权限，我们就不能修改授权特定的用户帐户控制设置,也不能修改目标msDS-AllowedToDelegateTo 字段(即使我们有对象的完全控制权)：

现在的问题是：我们如何确定哪些用户在域中拥有这项权限?由于SeEnableDelegationPrivilege仅适用于域控制器本身，我们需要检查应用于域控制器的任何组策略对象是否修改了给定DC的用户权限分配。在大多数情况下，这将是“默认域控制器策略”(GUID={6AC1786C-016F-11D2-945F-00C04FB984F9})。这也正是 Get-DomainPolicy -Source DC PowerView函数所做的：

因此，默认情况下，只有BUILTIN\Administrators(即域管理员/企业管理员等)的成员才有权修改这些授权设置。但是，如果我们可以编辑这个GPO或者应用于域控制器的任意一个GPO会发生什么?

为什么关心

在给予足够的权限下,有一百万种方法开启Active Directory后门。Sean Metcalf把这些叫作“Sneaky Active Directory Persistence Tricks”。其中的一些涉及到ACL后门，这些我在过去已经介绍过一些。其他的方法可能需要恶意修改的组策略。还有一些可能涉及修改用户对象。SeEnableDelegationPrivilege 的这种方法比以上所说的都高明。

如果我们在域中控制了一个拥有SeEnableDelegationPrivilege权限的对象，这表明对象在域中的任何用户对象上都有GenericAll/GenericWrite权限，我们可以无限期的,随意攻击域。

由于在默认域控制器GPO上提升域权限或编辑权限只需几分钟，你可以对给定的GPO进行单一的修改来实现这个后门。这GPO位于\\DOMAIN\sysvol\testlab.local\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf 。通过将任何用户SID或用户名添加到[Privilege Rights]节的SeEnableDelegationPrivilege行中，当用户/当前电脑的DC重启或刷新其组策略时,设置就会生效：

如果恶意用户在域中拥有任意用户的完整的权限，我们可以修改用户的msDS-AllowedToDelegateTo的值为我们想要攻击的任何目标。如果需要，我们还可以修改TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION UAC标志。在这种情况下，让我们利用ldap/DOMAIN_CONTROLLER来随意使用DCSyncing：

如果恶意用户对任何目标受害都有GenericAll权限，那么我们甚至不必知道受害用户的密码。我们可以使用Set-DomainUserPassword将密码强制重置为一个已知值，然后执行asktgt.exe/s4u.exe攻击流。

很显然，从防守端，我们可以通过PowerView或其他方式来了解哪些用户在域控制器中拥有SeEnableDelegationPrivilege特权。这个权限会赋予用户完整的域控制权，这是一个伟大的“微妙”的权限，但是可以很简单的检测(如果你知道你在找什么)出AD后门。有明显的方法，你可以破坏域控制器中已经被赋予的SYSTEM权限，在未来几周,我会详细介绍检测特定DACL修改的方法，但是,在组策略中审查这些应用是一个好的开始。