ADCS攻击面挖掘与利用（上） | 高级攻防02

在BlackHat21中，Specterops发布了Active Directory Certificate Services利用白皮书。尽管ADCS并不是默认安装，但在大型企业域中通常被广泛部署。

本文分为上下两篇，结合实战，讲述如何在域环境中利用ADCS手法拿下域控，哪些对象ACL可用于更好的权限维持，并涉及ADCS的基础架构、攻击面、后利用等。

1 技术背景

1.证书服务

首先介绍一下PKI公钥基础结构。

在PKI(公钥基础结构)中，数字证书用于将公密钥对的公钥与其所有者的身份相关联。为了验证数字证书中公开的身份，所有者需要使用私钥来响应质询，只有他才能访问。

Microsoft提供了一个完全集成到Windows生态系统中的公钥基础结构(PKI)解决方案，用于公钥加密、身份管理、证书分发、证书撤销和证书管理。

启用后，会识别注册证书的用户，以便以后进行身份验证或撤销证书，即Active Directory Certificate Services (ADCS)。

再来看一下ADCS关键术语。

• 根证书颁发机构 (Root Certification Authority)
• 证书基于信任链，安装的第一个证书颁发机构将是根CA，它是我们信任链中的起始。
• 从属CA(Subordinate CA)
• 从属CA是信任链中的子节点，通常比根CA低一级。
• 颁发CA(Issuing CA)
• 颁发CA属于从属CA，它向端点（例如用户、服务器和客户端）颁发证书，并非所有从属CA都需要颁发CA。
• 独立CA(Standalone CA)
• 通常定义是在未加入域的服务器上运行的CA。
• 企业CA(Enterprise CA)
• 通常定义是加入域并与Active Directory域服务集成的CA。
• 电子证书(Digital Certificate)
• 用户身份的电子证明，由Certificate Authority发放（通常遵循X.509标准）。
• AIA(Authority Information Access)
• 权威信息访问(AIA)应用于CA颁发的证书，用于指向此证书颁发者所在的位置引导检查该证书的吊销情况。
• CDP(CRL Distribution Point)
• 包含有关CRL位置的信息，例如URL (Web Server)或 LDAP路径(Active Directory)。
• CRL(Certificate Revocation List)
• CRL是已被撤销的证书列表，客户端使用CRL来验证提供的证书是否有效。

接下来介绍ADCS服务架构。

微软官方ADCS服务架构中的两层PKI环境部署结构示例如下：

ORCA1：首先使用本地管理员部署单机离线的根CA，配置AIA及CRL，导出根CA证书和CRL文件。

由于根CA需要嵌入到所有验证证书的设备中，所以出于安全考虑，根CA通常与客户端之间做网络隔离或关机且不在域内，因为一旦根CA遭到管理员误操作或黑客攻击，需要替换所有嵌入设备中的根CA证书，成本极高。

为了验证由根CA颁发的证书，需要使CRL验证可用于所有端点，为此将在从属CA(APP1)上安装一个Web服务器来托管验证内容。根CA机器使用频率很低，仅当需要进行添加另一个从属/颁发CA、更新CA或更改CRL。

APP1：用于端点注册的从属CA，通常完成以下关键配置：

将根CA证书放入Active Directory的配置容器中，这样允许域客户端计算机自动信任根CA证书，不需要在组策略中分发该证书。

在离线ORCA1上申请APP1的CA证书后，利用传输设备将根CA证书和CRL文件放入APP1的本地存储中，使APP1对根CA证书和根CA CRL的迅速直接信任。

部署Web Server以分发证书和CRL，设置CDP及AIA。

再看一下LDAP属性。

ADCS在LDAP容器中进行了相关属性定义：

CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=，

Certificate templates

ADCS 的大部分利用面集中在证书模板中，存储为：

CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= ，

其objectClass为pKICertificateTemplate，以下为证书的字段：

• 常规设置：证书的有效期；
• 请求处理：证书的目的和导出私钥要求；
• 加密：要使用的加密服务提供程序 (CSP) 和最小密钥大小；
• Extensions：要包含在证书中的X509v3扩展列表；
• 主题名称：来自请求中用户提供的值，或来自请求证书的域主体身份；
• 发布要求：是否需要“CA证书管理员”批准才能通过证书申请；
• 安全描述符：证书模板的ACL，包括拥有注册模板所需的扩展权限。

证书模板颁发首先需要在CA的certtmpl.msc进行模板配置，随后在certsrv.msc进行证书模板的发布。在Extensions中证书模板对象的EKU(pKIExtendedKeyUsage)属性包含一个数组，其内容为模板中已启用的OID (Object Identifiers)。

这些自定义应用程序策略(EKU oid)会影响证书的用途，以下 oid的添加才可以让证书用于Kerberos身份认证。

Enterprise NTAuth store

NtAuthCertificates包含所有CA的证书列表，不在内的CA无法处理用户身份验证证书的申请。

向NTAuth发布/添加证书：certutil –dspublish –f IssuingCaFileName.cer NTAuthCA；

要查看NTAuth中的所有证书：certutil –viewstore –enterprise NTAuth；

要删除 NTAuth中的证书：certutil –viewdelstore –enterprise NTAuth。

域内机器在注册表中有一份缓存：

HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates

当组策略开启“自动注册证书”，等组策略更新时才会更新本地缓存。

Certification Authorities & AIA

Certification Authorities容器对应根CA的证书存储。当有新的颁发CA安装时，它的证书则会自动放到AIA容器中。

来自他们容器的所有证书同样会作为组策略处理的一部分传播到每个网络连通的客户端，当同步出现问题的话，KDC认证会抛KDC_ERR_PADATA_TYPE_NOSUPP报错。

Certificate Revocation List

前面在PKI服务架构中提到了，证书吊销列表(CRL)是由颁发相应证书的CA发布的已吊销证书列表，将证书与CRL进行比较是确定证书是否有效的一种方法。

CN=<CA name>,CN=<ADCS server>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=

通常证书由序列号标识，CRL除了吊销证书的序列号之外，还包含每个证书的吊销原因和证书被吊销的时间。

2. 证书注册

先来看看证书注册流程。

ADCS 认证体系中的证书注册流程大致如下：

• 客户端创建公钥/私钥对；
• 将公钥与其他信息 (如证书的主题和证书模板名称) 一起放在证书签名请求 (CSR) 消息中，并使用私钥签署；
• CA首先判断用户是否允许进行证书申请，证书模板是否存在以及判断请求内容是否符合证书模板；
• 通过审核后，CA生成含有客户端公钥的证书并使用自己的私钥来签署；
• 签署完的证书可以进行查看并使用。

再来看看证书注册方式。首先，证书颁发机构Web注册。

在部署CA时勾选证书颁发机构Web注册，即可在"http://CA-Computer/certsrv"身份认证后进行证书申请。

然后是客户端GUI注册。

域内机器可以使用certmgr.msc (用户证书)、certlm.msc (计算机证书) 、GUI请求证书。

接下来是命令行注册。

域内机器可以通过certreq.exe或Powershell：Get-Certificate申请证书，后面有使用示例。

最后是DCOM调用。

基于DCOM的证书注册遵循MS-WCCE协议进行证书请求，目前大多数C#、python、Powershell的ADCS利用工具都按照 WCCE进行证书请求。

聊聊证书注册权限。在Active Directory中权限控制是基于访问控制模型的，其包含两个基本部分：

• 访问令牌，其中包含有关登录用户的信息；
• 安全描述符，其中包含保护安全对象的安全信息。

在ADCS中使用两种安全性定义注册权限 (主体可以请求证书) ，一个在证书模板AD对象上，另一个在企业CA本身上。在颁发CA机器上使用certtmpl.msc可查看所有证书模板，通过安全扩展可以对证书模板的用户访问权限查看。

可以在颁发CA机器上使用certsrv.msc，查看CA对于用户的访问权限设置。

2 证书使用

1. 证书认证

Kerberos认证：

Kerberos是域环境中主要的认证协议，其认证流程大致如下：

AS_REQ：client用client_hash、时间戳向KDC进行身份验证；

AS_REP：KDC检查client_hash与时间戳，如果正确则返回client由krbtgt哈希加密的TGT票据和PAC等相关信息；

TGS_REQ：client向KDC请求TGS票据，出示其TGT 票据和请求的SPN；

TGS_REP：KDC如果识别出SPN ，则将该服务账户的 NTLM哈希加密生成的ST票据返回给client；

AP_REQ：client使用ST请求对应服务，将PAC传递给服务进行检查。服务通过PAC查看用户的SID和用户组等并与自身的ACL进行对比，如果不满足则作为适当的RPC状态代码返回；

AP_REP：服务器验证AP-REQ，如果验证成功则发送 AP-REP，客户端和服务端通过中途生成的Session key等信息通过加解密转换验证对方身份。

PKINIT认证：

在RFC 4556中定义了PKINIT为Kerberos的扩展协议，可通过X.509证书用来获取Kerberos票据(TGT)。

PKINIT与Kerberos差别主要在AS阶段：

PKINIT AS_REQ：发d送内容包含证书，私钥进行签名。KDC使用公钥对数字签名进行校验，确认后返回使用证书公钥加密的TGT并且消息是使用KDC私钥签名；

PKINIT AS_REP：客户端使用KDC公钥进行签名校验，随后使用证书私钥解密成功拿到TGT。

详细的协议流程规范

"http://pike.lysator.liu.se/docs/ietf/rfc/45/rfc4556.xml"

NTLM凭据：

在2016年，通过证书获取NTLM的功能就被集成在kekeo和mimikatz中，核心在于当使用证书进行PKCA扩展协议认证的时候，返回的PAC中包含了NTLM票据

即使用户密码改了，通过证书随时可以拿到NTLM。获取能用来进行Kerberos身份认证的证书需要满足以下几个条件。

首先是证书模板OID：

前面我们提到了，目前已知应用程序策略(oid)只有包含了Client Authentication、PKINIT Client Authentication、Smart Card Logon、Any Purpose、SubCA时，对应的证书才能充当PKINIT身份认证凭据。

然后是证书请求权限：

• 用户拥有向CA申请证书的权限；
• 用户拥有证书模板申请证书的权限。

2. 证书获取

导出机器证书：

通过certlm.msc图形化或certutil.exe进行证书导出。

当私钥设置为不允许导出的时候，利用Mimikatz的crypto::capi命令可以patch当前进程中的capi，从而利用Crypto APIs导出含有私钥的证书。

导出用户证书：

通过certmgr.msc图形化或certutil.exe进行用户证书导出。

遇到私钥限制同样可尝试crypto::capi导出证书。

本地检索证书：

在实战中会遇到证书、私钥文件就在文件夹内并不需要导出的情况，其后缀文件主要有以下几种：

可结合自身需求通过开源工具或自研武器，来满足检索文件后缀的需求。