滥用 Active Directory 证书服务

滥用 Active Directory 证书服务 (AD CS) 已成为我们内部网络评估方法的主要内容。事实上，我记不起过去两年或更长时间里做过的任何内部评估没有以某种方式出现过 ADCS 滥用。

Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_INCONSISTENT_KEY_PURPOSE(Certificate cannot be used for PKINIT client authentication)Got error while trying to request TGT: Kerberos SessionError: KDC_ERROR_CLIENT_NOT_TRUSTED(Reserved for PKINIT)Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)

虽然忽略这些错误消息并转到下一个工具或概念很容易，但我还是决定进一步调查。我想在我的测试 Active Directory 实验室中复制确切的错误消息，这将使我深入了解导致这些消息的原因以及它们代表什么。

在这篇博文中，我将分享我从测试 AD 实验室中收集到的见解。它将从 AD CS 证书请求序列的基本概述开始，然后转向 PKINIT 身份验证过程。在建立基础之后，它将展示上述错误消息可能如何发生的具体场景。

对 AD CS 的基础理解：快速 101 简介

AD CS 是一种服务器角色，充当 Microsoft 的公钥基础结构 (PKI) 实现。正如预期的那样，它与 Active Directory 紧密集成。它支持颁发证书，证书是 X.509 格式的数字签名电子文档，可用于身份验证（这是我们在这篇博文中关注的重点领域）。

这可能会产生误导，但上面最后一句话暗示了 AD CS 实际工作方式的两个独立过程：

1. 有一个生成证书的过程，通常是证书模板和请求进入的地方。
2. 对于已颁发的证书，有一个单独的身份验证过程 - 这就是 PKINIT 身份验证发生的地方。

证书颁发

在 Will Schroeder 和 Lee Christensen 的原始 AD CS 白皮书中，他们分享了下面的图表，展示了如何完成生成证书的过程：

当域用户或计算机想要生成新的 AD CS 证书时。它首先创建一个公钥-私钥对，并将公钥与其他详细信息（例如证书的主题和证书模板名称）一起放在证书签名请求 (CSR) 消息中。然后他们将 CSR 发送到 CA 服务器。然后，CA 服务器检查是否允许他们请求证书。如果允许，它会通过查找证书模板 AD 对象来确定是否颁发证书。如果允许，CA 将使用其私钥生成并签署证书，并将其返回给用户/计算机。

根据上述描述，CA 根据收到的 CSR 执行两项初始检查：

1. 它检查用户或计算机是否可以申请证书——这通常通过向“pipecert”RPC 端点发出 SMB 身份验证请求来完成。
2. 它根据证书模板的属性检查用户或计算机是否被允许接收证书 - 这通常称为策略模块检查。

与上述第一步相关的错误消息通常比较容易发现。以下是请求 CSR 但提供的用户凭据错误的示例：

请注意错误输出中 pipecert RCP 端点如何与失败的 SMB 连接错误一起列出。

在最新版本的 certipy 中，有关第二步的错误消息也非常冗长。该工具最近进行了更新，以表明模板不允许请求证书：

在上述情况下，ESC1 证书模板的权限被修改为不允许注册，如下所示：

注意：旧版本的 Certipy 或其他工具（例如 Certi）仍将上述问题称为策略模块错误。无论如何，它最终与证书模板上设置的权限有关。

虽然上述错误与证书颁发有关，但必须记住这只是 AD CS 流程中的第一步。当证书正确颁发后，下一步将是身份验证。

PKI 认证

Active Directory 在很大程度上依赖 Kerberos 进行身份验证。当用户提供有效凭证时，将发出票证授予票证 (TGT)，之后可能会根据域用户或计算机想要访问的服务发出票证授予服务票证 (TGS)。

2006 年之前，基于证书的身份验证并未直接集成到 Windows 环境中使用的 Kerberos 身份验证协议中。相反，其他身份验证机制（即 SSL/TLS）与 Kerberos 一起使用来支持基于证书的身份验证。用户将智能卡插入连接到计算机的读卡器中，操作系统将使用智能卡上存储的证书进行身份验证。

注意：基于 AD CS 的证书与 Windows 环境中的智能卡身份验证同义。因此，在使用 AD CS 时，经常会看到对智能卡的引用。

随着 2006 年RFC 4556的发布，基于证书的身份验证直接集成到 Kerberos 身份验证协议中。RFC 4556（通常称为 PKINIT）允许客户端使用其 X.509 证书获取 Kerberos 票证，从而在 Windows 身份验证框架内实现基于证书的身份验证，而无需依赖 SSL/TLS 或智能卡等单独机制。

PKINIT 依赖于预先存在的 Kerberos 概念，即预身份验证。请求 TGT（称为 AS-REQ 请求）的用户不会在请求中提供其实际密码。相反，请求中会引入一个时间戳，并使用其密码进行加密。KDC 可以通过使用用户的 NTLM 哈希建立自己的时间戳来确认是否提供了合法密码。如果时间戳匹配，则表示用户提供了正确的密码，并返回 AS-REP 响应。

注意：加密的时间戳存储在 AS-REQ 的特定部分中；称为 PA-DATA 部分。您可能还记得在博客文章的开头看到过对此的引用。稍后我们将在 AD CS 错误条件之一中重新讨论这一点！

AD CS（或 PKI）身份验证利用了相同的概念。它不使用用户密码加密时间戳，而是使用属于所选证书的私钥。由于 KDC 和 CA 服务器可以访问证书的公钥，因此它可以验证所用证书的合法性。

从现在开始，其他一切都保持不变。用户或计算机将拥有一个有效的 TGT，可用于请求 TGS 票证。证书在 TGT 的生命周期内不再使用，并且通常在需要证书私钥之前将保持 7 天有效。

现在对 PKINIT 有了基本的了解。重要的是要了解，滥用 AD CS 证书时遇到的许多错误情况最终都与上述序列有关。KDC 构成身份验证序列的主要部分并执行多项检查。这些包括：

1. 检查客户端是否正在使用为其用途而颁发的证书。由于证书可以有不同的用途，KDC 必须确保证书可用于身份验证（通常称为基于客户端或服务器的身份验证）。
2. 检查证书主体和证书本身是否受信任。这通常是通过验证域帐户是否存在于 Active Directory 中并咨询 CA 服务器以检查其是否知道正在使用的证书来完成的。CA 服务器还会验证证书是否由其注册的 CA 之一颁发。

巧合的是，博客文章开头简要分享的错误消息与 KDC 正在执行的一项或多项检查有关。但在继续之前，让我们先探索一下每条错误消息，以更好地了解它代表什么以及为什么会发生。

探索 PKINIT 错误消息

错误＃1：关键目的不一致

如上一节所述，KDC 必须检查用户或计算机出示的证书是否用于其预期用途。

滥用 AD CS 时，我们通常希望从 KDC 获取有效的 TGT。这意味着我们正在发起身份验证尝试。根据目标的性质，这将保证对域用户帐户进行客户端身份验证或对计算机帐户进行服务器身份验证。

在以下示例中，我们尝试滥用基于 ESC1 的证书模板。我们首先使用 certipy 工具向 CA 服务器提交 CSR：

在上述情况下，提供的用户凭据是正确的，并且用户具有证书模板的注册权限。更不用说，它拥有提供备用主题名称 (SAN) 的权限。

值得注意的是，证书模板 (ESC1) 已配置为仅用于客户端身份验证：

考虑到上述情况，我们可以验证所颁发的证书确实仅具有列出的单一用途：

现在的问题是，当我们尝试使用颁发的证书对域控制器进行身份验证时会发生什么？在下面的场景中，我们选择使用证书对域管理员帐户 (PLAKadministrator) 进行身份验证。这将被归类为颁发证书的有效客户端身份验证尝试。因此，我们可以获得域帐户的有效 TGT 并获取其关联的 NTLM 哈希。

现在，您可能会说，如果我们改为使用 DC 计算机帐户进行身份验证，会发生什么情况？这难道不属于服务器身份验证吗？答案是否定的。无论我们使用用户帐户还是计算机帐户，它仍然是客户端身份验证。因此，如果使用计算机帐户，该序列仍可成功运行：

嗯……有趣。现在让我们考虑一个场景，其中证书模板已被修改为仅允许服务器身份验证：

我们的原始证书用于客户端身份验证；因此，当 KDC 检查证书的用途时，我们现在应该会发生冲突...坐稳了！

等一下！证书被接受了，但我们仍然收到了 NTLM 哈希。嗯，有人应该打电话给微软申请 CVE 吗？也许不需要。

由于证书具有以下属性，因此我们的证书仍然被接受。目前，证书仍然显示客户端身份验证的目的：

KDC 仅检查扩展密钥用法 (EKU) 是否与证书的用途相符。它没有检查证书模板及其应用策略。事实上，证书并未表明其源自哪个模板。

注意：即使证书中没有计算机帐户，我也复制了该序列。我还尝试重新启动 AD CS 服务和整个 DC 控制器。我仍然能够获取哈希值，如上所示。

KDC 能够限制此使用的唯一方法是联系 CA 服务器以检查证书是从哪个模板颁发的以及该模板允许的用途：

根据微软的文档，上述检查似乎并不是最重要的考虑因素。相反，它指出，当证书模板发生更改时，管理员有责任撤销错误的证书。在这种情况下，我只是扮演了一个不知情的管理员的角色，并没有执行撤销步骤——事实上，这在现实世界中不会发生，对吧？但是，我离题了。

如果我们放弃上述怪异情况，那么如果我们根据更新的（仅服务器身份验证）模板生成新证书会发生什么？首先，新生成的证书的 EKU 不同：

尝试使用此新证书进行身份验证时，KDC 正确检测到 EKU 不需要客户端身份验证。因此，它拒绝使用该证书：

请注意 KDC 或 Kerberos 错误消息如何表明我们的证书被用于错误的用途。更重要的是，KDC 报告该证书不能用于客户端身份验证。

这就引出了 AD CS 滥用的一个重要问题：我们作为 ESC1 序列的一部分生成的证书必须在其 EKU 中具有客户端身份验证。没有它，我们将无法向 KDC 进行身份验证，也无法生成我们需要的 TGT 和 TGS。

错误 #2：客户端不受信任

AD CS 滥用期间遇到的另一个常见错误是 KDC 消息表明客户端不可信 (KDC_ERROR_CLIENT_NOT_TRUSTED)。

DC 定期从 Active Directory 同步受信任的 CA，并将其指纹存储在 HKEY_LOCAL_MACHINESOFTWAREMicrosoftEnterpriseCertificatesNTAuthCertificates 的本地注册表项中。如果同步失败，KDC 可能会持有不同的受信任 CA 集合。这种不匹配可能会导致出现“客户端不受信任”错误消息。

我在最近的内部评估中遇到的另一种可能性是，当您拥有多个 KDC 和不同的 CA 时——想象一下大型组织中不同的林信任。DC 可能不会信任所有 CA。例如，DC 可能配置为仅信任其本地域的 CA，而不信任其他林中的所有其他 CA。因此，您可以颁发有效证书，但只能向少数本地 DC 进行身份验证。

由于复制本地多林 AD 实验室相当棘手，因此我将选择使用更非常规方法来说明“客户端不受信任”错误消息。首先，我将像往常一样生成证书：

注意：我将 ESC1 证书模板切换回支持客户端身份验证。

接下来，我们将使用 Rogan 的Apostille应用程序来模拟颁发的证书 - 我们本质上是将证书的属性克隆到新的自签名证书中：

生成克隆证书后，我们使用 OpenSSL 将 PEM 格式的证书和密钥转换回 PFX：

在此阶段，我们拥有有效域用户帐户的客户端身份验证证书。但是，这是我们颁发的，而不是官方信任的 CA。因此，如果我们在身份验证尝试中使用它，KDC 应该会拒绝它：

如上所示，KDC 将我们的证书颁发者与其本地 NTAuth 存储进行比较。由于该证书是自签名的，因此 NTAuth 存储显然没有 CA 指纹，因此身份验证尝试被拒绝。

与上一节探讨的第一个错误消息类似，此“客户端不受信任”消息也包含一些含义。虽然我们可能能够生成有效证书，但这并不意味着所有 DC 都会自动信任它。这主要取决于 DC 信任的 CA 子集。这些子集在多林环境中可能非常棘手，因为一个林可能不信任另一个林中的 CA。甚至可能（正如我所见）林内的 DC 在其受信任的 CA 方面也存在差异。

Certipy 确实有一个“ca”命令，可以深入了解受信任的 CA。但是，它通常会尝试提取 Active Directory 的受信任 CA，而不是单个 DC 允许的 CA。我在这里可能错了，但我发现验证单个 DC 的唯一方法是直接登录它们并浏览注册表。

错误 #3：不支持 PADATA 类型

我们将要探讨的下一个错误极为常见，并且在几次内部和红队评估中困扰了我，最明显的是 PADATA 错误。

如果我们回顾一下博文开头的 AD CS 介绍部分，我们了解到基于证书 (PKI) 的身份验证依赖于 Kerberos AS-REQ 请求中时间戳的加密。此加密时间戳存储在 AS-REQ 请求的 PADATA 中。

作为参考，我将重新发布之前显示的图像：

在尝试使用有效证书进行身份验证时，KDC 返回的 PADATA 错误消息通常非常令人困惑，甚至完全具有误导性：

Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)

该错误消息可能让人认为 AS-REQ 请求的 PADATA 部分发生了错误。虽然这可能是真的（在极少数情况下），但它实际上表明 KDC 和 CA 之间的交互存在问题。

正在尝试智能卡登录，但找不到正确的证书。

发生此问题的原因可能是查询了错误的证书颁发机构 (CA) 或无法联系正确的 CA 以获取域控制器的域控制器或域控制器身份验证证书。

当域控制器没有安装智能卡证书（域控制器或域控制器身份验证模板）时，也会发生这种情况。

为了更好地理解 PADATA 错误的原因，首先了解证书颁发流程非常重要：

请参阅步骤 4，了解 CA 服务器如何使用自己的私钥对生成的证书进行签名。此签名要求CA 服务器持有有效证书。它不会验证或与 DC 的证书（如果有）交互。

让我们探讨以下场景。在我的 AD 实验室中，我有一个 DC，它的域控制器和 CA 证书已于 3 月 27 日到期：

4月8日，我请求AD CS服务根据ESC1证书模板颁发新证书：

在上面的截图中，请注意，即使环境持有的证书已过期，CA 服务器仍然会颁发证书。嗯，这似乎很奇怪——也许这里存在另一个 CVE？也许不是……

虽然现在已经颁发了有效的客户端身份验证证书，但更紧迫的问题是它是否仍然可以使用。让我们在以域管理员帐户身份请求 TGT 时将此证书传递给 KDC：

啊哈。尽管我们有一个有效的证书，但 KDC 拒绝了它并返回了可怕的 PADATA 错误。返回此错误是因为 KDC 检查以确保它持有有效的域控制器或域控制器身份验证证书。但是，在这种情况下，证书已经过期，无法使用。

侧边栏：无需 KDC 交互的 PKI 身份验证

长期以来，安全研究人员认为 PADATA 错误代表着攻击链的结束。由于 KDC 无法访问有效的域控制器或域控制器身份验证证书，因此所有 PKI 身份验证都将失败。然而，这并不完全正确。

作为 Kerberos 预认证序列的一部分，KDC 被联系。虽然这构成了现代 PKI 认证流程，但这并不是 Windows 上唯一可行的方式。在 RFC 4556 之前，Windows 上的 PKI 认证涉及其他服务，即 SSL/TLS。在探索这些服务时，SSL/TLS 服务（特别是 Schannel）不涉及 KDC。因此，一种载体诞生了（现在称为 Pass-the-Cert），通过该载体仍然可以进行 PKI 认证。

如何滥用 Schannel 服务：

屏幕截图显示对 DC 的身份验证尝试成功，并且我们现在在域管理员的上下文中运行。请记住，此处使用的证书与上面的 PADATA 错误演示中使用的证书完全相同。

在运行上述传递证书攻击时，CA 和 DC 均未持有有效证书。由于 Schannel 服务被滥用，因此直接针对 DC 的 LDAPS 服务进行身份验证。LDAPS 服务仅验证证书的 SAN 是否为有效域帐户；否则，不会执行进一步验证。

这种方法的缺点是，DC 必须安装域控制器或域控制器身份验证证书 — 无论其有效性如何。此外，您只能获得 LDAPS 访问权限，这意味着在模拟域管理员帐户时只能引发一组有限的交互。

原文始发于微信公众号（TtTeam）：滥用 Active Directory 证书服务