深入探索 AD CS：探索一些常见错误消息

【翻译】Diving into ad cs exploring some common error messages

滥用 Active Directory Certificate Services (AD CS) 已经成为我们内部网络评估方法的主要内容。事实上，我记不起在过去两年或更长时间内进行的内部评估中有哪一次没有以某种方式涉及 ADCS 滥用。

我们都同意，当 AD CS 滥用按预期工作时，效果非常出色。正如 Tinus Green 在他的 BSides 演讲中所述，AD CS 滥用就像是通往山顶的传送卷轴。它使我们能够快速获得对域的高权限访问，并从那里可以针对更有价值的目标。

不幸的是，反过来也是如此。在尝试滥用 AD CS 时，人们经常会遇到错误。证书模板可能与真正的配置错误略有不符，或者用户权限可能不允许某些小步骤。更不用说客户的 Active Directory 环境可能存在复杂的安全解决方案，阻止滥用行为——这里指的是你，Semperis。

像 Certify 和 certipy 这样的工具最近已经发展到提供更具描述性的错误消息。然而，它们仍然有很多不足之处。通常，当你遇到这些工具的错误时，错误原因往往模糊不清。是我输错了众多标志中的一个，还是我的域凭据语法错误，或者我没有正确连接到 CA 服务器？再加上通过 VPN 和 SOCKS 代理进行远程测试的复杂性，你会陷入一个痛苦的世界，试图诊断出了什么问题。

在最近的两次内部评估中，我遇到了几条完全让我困惑的错误消息（见下文）。证书模板没问题，我的域权限符合预期，工具调用方式与我之前使用的一致——或者，简单地说，我复制/粘贴了一个已知有效的命令。那么...为什么我会收到这些错误，它们意味着什么？

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 认证过程。在建立基础后，将展示上述错误消息可能出现的各种场景。

注意：本文展示的大部分研究和博客内容灵感来自 Will Schroeder 和 Lee Christensen 的原始 AD CS 白皮书和最近的博客文章。PKINIT 解释主要归功于 @_ethicalchaos_ 的攻击基于智能卡的 Active Directory 网络博客文章。

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. 检查用户或计算机是否可以请求证书——这通常作为 SMB 认证请求发送到 'pipecert' RPC 端点。
2. 根据证书模板的属性检查用户或计算机是否被允许接收证书——这通常被称为策略模块检查。

与上述第一步相关的错误消息通常相对容易识别。以下是一个例子，其中请求了 CSR，但提供了错误的用户凭据：

注意错误输出中如何列出 pipecert RCP 端点以及失败的 SMB 连接错误。

关于第二步的错误消息在 certipy 的最新版本中也相当详细。该工具最近更新，指示模板不允许请求证书：

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

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

虽然上述错误与证书颁发有关，但重要的是要记住，这只是 AD CS 流程的第一步。当证书正确颁发后，下一步将是认证。

PKI 认证

Active Directory 主要依靠 Kerberos 进行认证。当用户提供有效凭据时，会颁发票据授予票据 (TGT)，之后，根据域用户或计算机想要访问的服务，可能会颁发票据授予服务票据 (TGS)。

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

注意：在 Windows 环境中，基于 AD CS 的证书与智能卡认证是同义词。因此，在使用 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 打电话给 Microsoft？也许不需要。

由于我们的证书仍然具有的属性，它仍然被接受。目前，证书仍然显示客户端认证的目的：

KDC 只检查扩展密钥用法 (EKU) 是否与证书的目的匹配。它没有检查证书模板及其应用策略。实际上，证书并不表明它来自哪个模板。

注意：即使在证书中没有计算机账户的情况下，我也复制了这个序列。我还尝试重启 AD CS 服务和整个 DC 控制器。我仍然能够获取上面显示的哈希值。

KDC 可能限制这种用法的唯一方法是联系 CA 服务器，检查证书是从哪个模板颁发的，以及模板允许什么用途：

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

如果我们忽略上述奇怪现象，如果我们基于更新的（仅服务器认证）模板生成新证书会发生什么？首先，新生成的证书的 EKU 不同：

在尝试使用这个新证书进行认证时，KDC 正确检测到 EKU 不包含客户端认证。因此，它拒绝使用该证书：

注意 KDC 或 Kerberos 错误消息如何指示我们的证书用于错误的目的。更重要的是，KDC 报告证书不能用于客户端认证。

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

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

在 AD CS 滥用过程中遇到的另一个常见错误是 KDC 消息，指示客户端不能被信任 (KDC_ERROR_CLIENT_NOT_TRUSTED)。

在他们最近的 AD CS 博客文章中，Will Schroeder 和 Lee Christensen 解释说，当颁发的证书没有链接到 KDC 信任的 CA 时，通常会出现此错误。

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 允许的内容。我可能在这里是错误的，但我发现验证单个 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 之间交互的问题。

Microsoft 文档中的以下部分有助于澄清这一点：

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

这个问题可能发生是因为查询了错误的证书颁发机构（CA）或无法联系到适当的 CA 以获取域控制器或域控制器身份验证证书。

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

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

请看第 4 步，CA 服务器如何使用自己的私钥签署生成的证书。这种签名要求 CA 服务器持有有效证书。它不验证也不与 DC 的证书（如果有的话）交互。

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

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

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

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

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

补充：无 KDC 交互的 PKI 认证

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

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

在这里，我将使用 PassTheCert 脚本演示 Schannel 服务的滥用：

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

在运行上述 Pass-the-Cert 攻击时，CA 和 DC 都没有持有有效证书。由于滥用了 Schannel 服务，认证直接针对 DC 的 LDAPS 服务进行。LDAPS 服务只验证证书的 SAN 是否为有效的域账户；否则，不执行进一步的验证。

这种方法的注意事项是，DC 必须安装域控制器或域控制器身份验证证书——无论其有效性如何。此外，你只能获得 LDAPS 访问权限，这意着在冒充域管理员账户时只能提出有限的交互集。

注意：我是 PassTheCert 脚本的 LDAP shell 功能的原始作者，但它已经存在于 Impacket 库中。

结论

在执行内部和红队评估时，我们经常遇到错误消息。有时，这些错误直接明了，容易诊断，而其他错误则需要更深入的分析。通常，这种深入分析会揭示新的机会——正如本博客文章所示。

本博客文章简要研究了 AD CS 和一些常见错误。AD CS 继续是现代 Active Directory 攻击的主要因素。了解其内部工作原理以及如何避免某些场景可能仍然非常有益。

正如文章中所见，Certify 和 certify 等工具返回的许多错误消息可以追溯到 Kerberos 预认证（PKINIT）序列。这可能包括使用设置了错误 EKU 的证书或 CA 不受信任的证书。更糟糕的是，你可能遇到可怕的 PADATA 问题，即 DC 没有有效的域控制器证书。

如果你对 AD CS 有进一步的问题，或者对我在这篇博客文章中提到的一些奇怪的 Windows 观察有想法，请通过 DM 联系我。我很乐意讨论这个话题，甚至可能在进一步的 AD CS 攻击上进行合作。

下次再见...祝黑客生活愉快！