windows 受保护用户安全组风险探索

非常感谢各位大佬的打赏让我在这个寒冷的冬天吃泡面能够加上一个🥚，感恩感恩，同时也会再接再厉给大家比较好的内容

在这篇文章中，将解释什么是受保护用户组，为什么它是一个很好的安全功能，但为什么它对管理员（RID500）用户来说不安全

          

通常的票据利用场景和PtH/OPtH

基本上，我们破坏了一个服务器，转储其SAM数据库和LSASS内存来检索明文凭据或NT散列。我们还可以转储Kerberos门票，以及通常我们可以用来在其他地方连接的任何其他材料：    

无论是在SAM数据库中还是在LSASS进程的内存中，您都可能会找到NT散列：

在Windows上，拥有NT散列等同于拥有明文密码。如果我们看一下NTLM身份验证协议，我们可以看到挑战是使用用户的NT散列加密的：    

由于我们有NT散列，我们可以在不知道相应的明文密码的情况下加密挑战。

在Kerberos上，它几乎是一样的。Kerberos身份验证协议依赖于四个数据包，即：

1KRB_AS_REQ

1KRB_AS_REP

1KRB_TGS_REQ

1KRB_TGS_REP

过程如下：

重要部分是“使用从用户密码派生的密钥加密的时间戳”。作为用户，我们可以使用可以使用以下算法之一获得的密钥来加密时间戳：

1RC4

1DES

1AES-128

1AES-256    

有趣的是，RC4使用用户的NT散列来加密时间戳。由于我们有有效的NT散列，我们可以加密时间戳并拥有有效的KRB_AS_REQ数据包。使用CrackMapExec框架，我们现在可以使用两种众所周知的攻击连接到远程服务器：

1传递哈希（用于NTLM身份验证协议）：

1OverPass-the-Hash（对于Kerberos身份验证协议）：

这些攻击依赖于这样一个事实，即可以使用NT散列来加密用于验证用户身份的秘密。为了防止这种情况，一种方法是将敏感用户添加到“受保护用户”组中。

受保护用户组

“受保护用户”组是在Windows Server 2012R2中引入的。如果我们看一下MSDN文章，我们可以看到这个组中的用户已经强化了安全选项：

如您所见，NTLM身份验证被禁用，RC4算法无法用于加密Kerberos身份验证的时间戳，最后，Kerberos委托被禁用。让我们测试一下这个。

首先，我将添加一个位于“受保护用户”组中的新域管理员用户（admin2）：    

现在让我们尝试使用NTLM进行身份验证：

正如您所看到的，它不起作用，我们收到“STATUS_ACCOUNT_RESTRICTION”。现在让我们尝试使用Kerberos：

它也不起作用（KDC_ERR_PREAUTH_FAILED）。所以，是的，看起来预期的受保护用户安全功能适用于admin2用户。但它们适用于所有用户吗？

 风险探索

接下来我们去探索一些非常规的方式，在这里我们发现存在了一些不一样的奇怪行为，引起了注意力并探索其可能存在安全风险

1 – RC4 加密票据

当我玩CrackMapExec PR时，我随机尝试使用Kerberos作为WHITEFLAG/管理员帐户进行身份验证，我意识到即使用户在受保护用户组中，它也能正常工作：    

相比之下，NTLM身份验证失败：

这意味着，当涉及到Active Directory域的RID 500用户时，受保护用户组的限制是不完整的。我们无法使用NTLM身份验证协议进行连接，但我们可以使用RC4的Kerberos身份验证协议进行连接。

2 – delegation案例

另一个奇怪的行为与Kerberos delegation有关。通常，当用户在受保护用户组中时，他们不能被委托。在这里，我试图滥用从OCD$到ADCS1$的RBCD委托场景，首先以pu_user（受保护用户）的身份获得服务票证，其次以not_pu_user（不是）。首先，让我们看看delegation：

让我们看看RBCD委托pu_user和not_pu_user之间的区别：

我们清楚地看到了一个区别：受保护的用户不能被委托。但等等，让我们看看RID 500管理员帐户进展如何......    

即使RID 500管理员帐户在受保护用户组中，也可以委托它们。好的，但为什么？

RBCD delegation滥用包括以下两个步骤：

1S4U2Self：向受控帐户请求任意用户的服务票据。

1S4U2Proxy：将服务票据作为任意用户请求到目标机器帐户，使用之前获得的服务票据作为附加票证。

当您试图冒充受保护的用户时，S4U2Self会为您提供没有可转发标志设置的服务票。这就是为什么S4U2Proxy部件因KDC_BADOPTION错误而失败。但是，在冒充RID 500管理员用户时，无论用户是否是受保护用户，都会设置可转发标志：

攻击场景

1 – RC4 加密

使用此错误，我们可以执行特定场景。假设我们有一家名为Sec的虚构公司。两年前，他们在没有注意安全的情况下创建了Active Driectory域名（sec.local）。因此，他们使用域的RID500帐户（WHITEFLAG/管理员）来管理他们的服务器。    

一年前，他们要求进行内部安全评估。渗透攻击人员能够破坏域，并告诉安全团队将所有域管理员用户添加到受保护用户组中。安全团队这样做了，但由于他们没有正确关闭RDP会话，WHITEFLAG/管理员帐户的NT散列仍然存储在LSASS进程的内存中。

今天，您受雇测试他们新强化的Active Directory网络。如果您可以破坏WHITEFLAG/Administrator帐户的RDP会话仍然活跃的服务器，您将能够检索其NT散列。由于不受保护用户限制，因此您将能够使用Kerberos身份验证连接到DC。

这是一个非常具体的场景，但是，它真的很可能会发生！另一件有趣的事情是，Kerberos delegation 也将为这个账户工作。

2 – delegation案例

这里的场景更直截了当。如果每个管理员帐户都在受保护用户中，并且您需要滥用RBCD委托场景（或任何其他Kerberos委托），您只需选择冒充RID 500管理员帐户，它就会起作用！

          

防范

如果我们看一下RID 500管理员帐户的属性，我们可以看到ms-DSSupportedProtocolEncryption值设置为0x0

   

此属性具有十六进制值，表示该帐户启用了哪种类型的身份验证协议。由于该值为0x0，我们可以得出结论，可以使用任何身份验证协议。如果我们将此值设置为24（0x18），这只能启用AES-128和AES-256：

我们将看到，我们仍然可以使用OverPass-the-Hash攻击进行连接。我发现完全禁用RC4的唯一方法是限制整个Active Directory环境，如果服务器/应用程序仍然依赖这种类型的身份验证，这可能是危险的。

为了避免委托技巧，即使RID500帐户在受保护用户中，您也需要勾选“帐户是敏感的，不能委托的”。    

另一个修复方法是简单地禁用RID500域帐户，根据微软文档，该帐户也很危险：

   

原文始发于微信公众号（暴暴的皮卡丘）：windows 受保护用户安全组风险探索