{
	"id": "becbcd76-04eb-494a-96df-77d86c791504",
	"created_at": "2026-04-06T00:11:13.938236Z",
	"updated_at": "2026-04-10T13:12:54.602293Z",
	"deleted_at": null,
	"sha1_hash": "c71c389b8aad475c0c9e858f832f8124af40fdd9",
	"title": "Certified Pre-Owned",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4738545,
	"plain_text": "Certified Pre-Owned\r\nBy Will Schroeder\r\nPublished: 2021-06-17 · Archived: 2026-04-05 16:13:02 UTC\r\nL;DR Active Directory Certificate Services has a lot of attack potential! Check out our whitepaper “Certified\r\nPre-Owned: Abusing Active Directory Certificate Services” for complete details. We’re also presenting this\r\nmaterial at Black Hat USA 2021.\r\n[EDIT 06/22/21] — We’ve updated some of the details for ESC1 and ESC2 in this post which will be shortly\r\nupdated in the whitepaper.\r\nFor the past several months, we (Will Schroeder and Lee Christensen) have been diving into the security of Active\r\nDirectory Certificate Services (AD CS). While several aspects of Active Directory have received thorough\r\nattention from a security perspective, Active Directory Certificate Services has been relatively overlooked. AD CS\r\nis Microsoft’s PKI implementation that provides everything from encrypting file systems, to digital signatures, to\r\nuser authentication (a large focus of our research), and more. While AD CS is not installed by default for Active\r\nDirectory environments, from our experience in enterprise environments it is widely deployed, and the security\r\nramifications of misconfigured certificate service instances are enormous.\r\nToday we’re releasing the results of our research so far (there is still much to look at, and we know we have\r\nmissed things) in the form of an extensive whitepaper and a defensive PowerShell toolkit for auditing these issues.\r\nThe toolkit is heavily defensive focused, but we will also release two offensive tools in ~45 days at Black Hat, as\r\nwe believe that the issues described in the paper are severe and widespread enough to warrant a delay in the\r\noffensive tool release. The whitepaper also contains substantial preventative and detective guidance.\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 1 of 22\n\nWhitepaper — “Certified Pre-Owned: Abusing Active Directory Certificate Services”\r\nDefensive Toolkit — PSPKIAudit (based on PSPKI)\r\nOffensive Toolkit —(code will be pushed at Black Hat, preemptive IOCs/Yara rules are currently\r\nlive) Certify and ForgeCert\r\nAD CS and its security implications are complicated, and we highly recommend reading the whitepaper for\r\ncomplete context. This post is a brief summary of the paper, and we will release a number of additional posts in\r\nthe coming weeks and months to highlight elements of the research.\r\nSo why care about this? Certificate abuse can grant an attacker:\r\nOf note, nearly every environment with AD CS that we’ve examined for domain escalation misconfigurations has\r\nbeen vulnerable. It’s hard for us to overstate what a big deal these issues are.\r\nSidenote: because of the number of attacks we ended up documenting in this research, we have tagged each attack\r\nwith an ID (e.g., ESC2) as well as each defense (e.g., DETECT3). This is for ease of mapping of attacks to\r\nappropriate defenses in the whitepaper.\r\nActive Directory Certificate Services Crash Course\r\nCommon Terms and Acronyms\r\nThere are a lot of terms and acronyms we’re going to be using throughout this post (and paper), so here’s a quick\r\nbreakdown of a few for reference:\r\nPKI (Public Key Infrastructure) — a system to manage certificates/public key encryption\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 2 of 22\n\nAD CS (Active Directory Certificate Services) — Microsoft’s PKI implementation\r\nCA (Certificate Authority) — PKI server that issues certificates\r\nEnterprise CA — CA integrated with AD (as opposed to a standalone CA), offers certificate templates\r\nCertificate Template — a collection of settings and policies that defines the contents of a certificate issued by an\r\nenterprise CA\r\nCSR (Certificate Signing Request) — a message sent to a CA to request a signed certificate\r\nEKU (Extended/Enhanced Key Usage) — one or more object identifiers (OIDs) that define how a certificate can\r\nbe used\r\nOverview\r\nAD CS is a server role that functions as Microsoft’s public key infrastructure PKI implementation. As expected, it\r\nintegrates tightly with Active Directory and enables the issuing of certificates, which are X.509-formatted digitally\r\nsigned electronic documents that can be used for encryption, message signing, and/or authentication (our research\r\nfocus).\r\nThe information included in a certificate binds an identity (the subject) to a public/private key pair. An application\r\ncan then use the key pair in operations as proof of the identity of the user. Certificate Authorities (CAs) are\r\nresponsible for issuing certificates.\r\nAt a high level, clients generate a public-private key pair, and the public key is placed in a certificate signing\r\nrequest (CSR) message along with other details such as the subject of the certificate and the certificate template\r\nname. Clients then send the CSR to the Enterprise CA server. The CA server then checks if the client is allowed to\r\nrequest certificates. If so, it determines if it will issue a certificate by looking up the certificate template AD object\r\n(more on these shortly) specified in the CSR. The CA will check if the certificate template AD object’s\r\npermissions allow the authenticating account to obtain a certificate. If so, the CA generates a certificate using the\r\n“blueprint” settings defined by the certificate template (e.g., EKUs, cryptography settings, issuance requirements,\r\netc.) and using the other information supplied in the CSR if allowed by the certificate’s template settings. The CA\r\nsigns the certificate using its private key and then returns it to the client.\r\nThat’s a lot of text. So here’s a graphic:\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 3 of 22\n\nCertificate Templates\r\nAD CS Enterprise CAs issue certificates with settings defined by AD objects known as certificate templates.\r\nThese templates are collections of enrollment policies and predefined certificate settings and contain things like\r\n“How long is this certificate valid for?”, “What is the certificate used for?”, “How is the subject\r\nspecified?”, “Who is allowed to request a certificate?”, and a myriad of other settings:\r\nThe pKIExtendedKeyUsage attribute on an AD certificate template object contains an array of object identifiers\r\n(OIDs) enabled for the template. These EKU object identifiers affect what the certificate can be used for (PKI\r\nSolutions has a breakdown of the EKU OIDs available from Microsoft). Our research focused on EKUs that,\r\nwhen present in a certificate, permit authentication to Active Directory. We originally thought that only the “Client\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 4 of 22\n\nAuthentication“ OID (1.3.6.1.5.5.7.3.2) enabled this; however, our research also found that the following OID\r\nscenarios can enable certificate-based authentication:\r\n*The 1.3.6.1.5.2.3.4 OID is not present in AD CS deployments by default and needs to be added manually, but it\r\ndoes work for client authentication.\r\nTemplates also have a number of other interesting settings which we explore in depth in the whitepaper. The paper\r\nalso covers template “Issuance Requirements” which can function as preventative controls, which we will briefly\r\ntouch on in this post.\r\nSubject Alternative Names\r\nA Subject Alternative Name (SAN) is an extension that allows additional identities to be bound to a certificate\r\nbeyond just the subject of the certificate. For example, if a web server hosts content for multiple domains, each\r\napplicable domain could be included in the SAN so that the web server only needs a single HTTPS certificate\r\ninstead of one for each domain.\r\nThis is all well and good for HTTPS certificates, but when combined with certificates that allow domain\r\nauthentication, a dangerous scenario can arise. By default during certificate-based authentication, certificates are\r\nmapped to Active Directory accounts based on a user principal name (UPN) specified in the SAN. So, if an\r\nattacker can specify an arbitrary SAN when requesting a certificate that enables domain authentication, and the\r\nCA creates and signs a certificate using the attacker-supplied SAN, the attacker can become any user in the\r\ndomain! Domain escalation scenarios can result from various AD CS template misconfigurations that allow\r\nunprivileged users to supply an arbitrary SAN in a certificate enrollment. We’ll cover these situations in\r\nthe Domain Escalation section.\r\nActive Directory Authentication with Certificates\r\nLast year, @_ethicalchaos_ made a PR to Rubeus to implement PKINIT abuse, and covers more details on this in\r\ndepth in their post on attacking smart card based Active Directory networks. This was a missing link for us\r\noffensively, and means that we can now use Rubeus to request a Kerberos ticket granting ticket (TGT) using a\r\ncertificate enabled for domain authentication:\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 5 of 22\n\nThat’s right, we don’t need a physical smart card or the Windows Credential Store to perform this certificate-based Kerberos authentication! Benjamin Delpy’s (@gentilkiwi) Kekeo has supported this for years, but the\r\nRubeus implementation made it more readily usable for our operations.\r\nDuring our research, we also found that some protocols use Schannel — the security package backing SSL/TLS\r\n— to authenticate domain users. LDAPS is a commonly enabled use case. For example, the following screenshot\r\nshows the PowerShell script Get-LdapCurrentUser authenticating to LDAPS using a certificate for authentication\r\nand performing an LDAP whoami to see what account authenticated:\r\nAccount Persistence\r\nIf an Enterprise CA exists, a user (or machine) can request a cert for any template available to them for\r\nenrollment. The whitepaper covers theft of existing certificates, but we’re only going to touch on “active”\r\nmalicious enrollments here. Our goal, in the context of user credential theft, is to request a certificate for a\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 6 of 22\n\ntemplate that allows us to authenticate to Active Directory as that user (or machine). For complete details, see the\r\n“Account Persistence” section in the whitepaper.\r\nThe Certify.exe find /clientauth command will query LDAP for available templates that we can examine for our\r\ndesired criteria:\r\nThis can also be done via PSPKIAudit with Get-AuditCertificateTemplate | ?{$_.HasAuthenticationEku}\r\nIf we have GUI access to a host, we can manually request a certificate through certmgr.msc.\r\nAlternatively, Certify (or certreq.exe) can be used be used for these malicious enrollments:\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 7 of 22\n\nThese issued certificates can then be used with Rubeus to authenticate to Active Directory as this user, for as long\r\nas the certificate is valid. This is an alternative method of long-term credential theft that doesn’t touch LSASS\r\nand can be performed from a non-elevated context!\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 8 of 22\n\nThis also works for machine certificates, which can be combined with S4U2Self to obtain a Kerberos service\r\nticket to any service on the host (e.g., CIFS, HTTP, RPCSS, etc.) as any user. Elad Shamir’s excellent post about\r\nKerberos delegation attacks details this attack scenario.\r\nAnd since certificates are independent authentication material, these certificates will still be usable even if the\r\nuser (or computer) resets their password!\r\nDomain Escalation\r\nWhile there isn’t anything necessarily inherently insecure about AD CS (except for ESC8 as detailed below), it is\r\nsurprisingly easy to misconfigure its various elements, resulting in ways for unelevated users to escalate in the\r\ndomain. We’ll briefly cover the main sets of misconfigurations, but again, see the whitepaper for complete details.\r\nMisconfigured Certificate Templates — ESC1\r\nIn order to abuse this misconfiguration, the following conditions must be met:\r\nThe Enterprise CA grants low-privileged users enrollment rights. The Enterprise CA’s configuration must\r\npermit low-privileged users the ability to request certificates. See the “Background — Certificate Enrollment” in\r\nthe whitepaper paper for more details.\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 9 of 22\n\nManager approval is disabled. This setting necessitates that a user with certificate manager permissions review\r\nand approve the requested certificate before the certificate is issued. See the “Background — Certificate\r\nEnrollment — Issuance Requirements’ section in the whitepaper paper for more details.\r\nNo authorized signatures are required. This setting requires any CSR to be signed by an existing authorized\r\ncertificate. See the “Background — Certificate Enrollment — Issuance Requirements” section in the whitepaper\r\nfor more details.\r\nAn overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Having certificate enrollment rights allows a low-privileged attacker to request and obtain a\r\ncertificate based on the template. Enrollment rights are granted via the certificate template AD object’s security\r\ndescriptor.\r\nThe certificate template defines EKUs that enable authentication. Applicable EKUs include Client\r\nAuthentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID\r\n1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), or no EKU (SubCA).\r\nThe certificate template allows requesters to specify a subjectAltName (SAN) in the CSR. If a requester can\r\nspecify the SAN in a CSR, the requester can request a certificate as anyone (e.g., a domain admin user). The\r\ncertificate template’s AD object specifies if the requester can specify the SAN in its mspki-certificate-name-flag property. The mspki-certificate-name-flag property is a bitmask and if\r\nthe CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is present, a requester can specify the SAN. This is\r\nsurfaced as the “Supply in request” option in the “Subject Name” tab in certtmpl.msc.\r\nMisconfigured Certificate Templates — ESC2\r\nIn order to abuse this misconfiguration, the following conditions must be met:\r\nThe Enterprise CA grants low-privileged users enrollment rights. Details are the same as in ESC1.Manager\r\napproval is disabled. Details are the same as in ESC1.\r\nNo authorized signatures are required. Details are the same as in ESC1.\r\nAn overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Details are the same as in ESC1.\r\nThe certificate template defines Any Purpose EKUs or no EKU.\r\n[EDIT 06/22/21]\r\nWhile templates with these EKUs can’t be used to request authentication certificates as other users without the\r\nCT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag being present (i.e., ESC1), an attacker can use them to\r\nauthenticate to AD as the user who requested them and these two EKUs are certainly dangerous on their own.\r\nWe were initially a bit unclear about the capabilities of the Any Purpose and subordinate CA (SubCA) EKUs, but\r\nothers reached out and helped us clarify our understanding. An attacker can use a certificate with the Any\r\nPurpose EKU for (surprise!) any purpose — client authentication, server authentication, code signing, etc. In\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 10 of 22\n\ncontrast, an attacker can use a certificate with no EKUs — a subordinate CA certificate — for any purpose as well\r\nbut could also use it to sign new certificates. As such, using a subordinate CA certificate, an attacker could specify\r\narbitrary EKUs or fields in the new certificates.\r\nHOWEVER, if the subordinate CA is not trusted by the NTAuthCertificates object (which it won’t be by default),\r\nthe attacker cannot create new certificates that will work for domain authentication. Still, the attacker can create\r\nnew certificates with any EKU and arbitrary certificate values, of which there’s plenty the attacker could\r\npotentially abuse (e.g., code signing, server authentication, etc.) and might have large implications for other\r\napplications in the network like SAML, AD FS, or IPSec.\r\nWe feel confident in stating that it’s very bad if an attacker can obtain an Any Purpose or subordinate CA\r\n(SubCA) certificate, regardless of whether it’s trusted by NTAuthCertificates or not.\r\n[/EDIT]\r\nEnrollment Agent Templates — ESC3\r\nIn order to abuse this misconfiguration, the following conditions must be met:\r\nThe Enterprise CA grants low-privileged users enrollment rights. Details are the same as in ESC1.\r\nManager approval is disabled. Details are the same as in ESC1.\r\nNo authorized signatures are required. Details are the same as in ESC1.\r\nAn overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Details are the same as in ESC1.\r\nThe certificate template defines the Certificate Request Agent EKU. The Certificate Request Agent OID\r\n(1.3.6.1.4.1.311.20.2.1) allows for requesting other certificate templates on behalf of other principals.\r\nEnrollment agent restrictions are not implemented on the CA.\r\nThe Certificate Request Agent EKU (OID 1.3.6.1.4.1.311.20.2.1), known as “Enrollment Agent” in Microsoft\r\ndocumentation, allows a principal to enroll for a certificate on behalf of another user. For anyone who enrolls\r\nin such a template, the resulting certificate can be used to co-sign requests on behalf of any user, for any Schema\r\nVersion 1 template or any Schema Version 2+ template that requires the appropriate “Authorized\r\nSignatures/Application Policy” Issuance Requirement. This also assumes that there are no limiting Enrollment\r\nAgent Restrictions on the CA.\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 11 of 22\n\nThe few sentences before this throwback meme might need a bit of clarification. If an attacker is able to enroll in a\r\ntemplate with a “Certificate Request Agent” EKU, they can enroll on behalf of any user for any Version 1\r\ncertificate template, or any Version 2+ template configured to explicitly require this co-signing scenario. Schema\r\nVersion 1 templates don’t implement this type of Issuance Requirement, so all are on the table. Specifically,\r\nthe User and Machine/Computer templates are prime targets as they contain the Client Authentication EKU and\r\nare published by default (though this can be changed), and there are other Version 1 templates that can be\r\nvulnerable if published.\r\nIf a Version 1 template is duplicated for modification, it automatically becomes Schema Version 2 by default,\r\nmeaning a “Certificate Request Agent” template will NOT work unless such an issuance requirement is explicitly\r\nspecified.\r\nA bit confusing? We know. We do our best to break this down in more depth in the whitepaper, but it’s a complex\r\nset of interwoven restrictions.\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 12 of 22\n\nVulnerable Certificate Template Access Control — ESC4\r\nCertificate templates are securable objects in Active Directory, meaning they have a security descriptor that\r\nspecifies which Active Directory principals have specific permissions over the template. For more background on\r\nActive Directory ACLs, see our (other) whitepaper on the subject.\r\nWe say that a template is misconfigured at the access control level if it has Access Control Entries (ACEs) that\r\nallow unintended, or otherwise unprivileged, Active Directory principals to edit sensitive security settings in the\r\ntemplate. That is, if an attacker is able to chain access to a point that they can actively push a misconfiguration to a\r\ntemplate that is not otherwise vulnerable (e.g., by enabling the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT\r\nbit in the mspki-certificate-name-flag property for a template that allows for domain authentication), we end up\r\nwith domain compromise scenarios similar to what we’ve already covered. An example of this we have seen in\r\nmultiple environments is Domain Computers having FullControl or WriteDacl permissions over a certificate\r\ntemplate’s AD object, allowing attackers with access to any AD computer modify the certificate template to a\r\ndangerous state. This is a scenario explored in Christoph Falta’s GitHub repo.\r\nVulnerable PKI Object Access Control — ESC5\r\nWe won’t touch on this one as heavily here, but a number of objects outside of certificate templates and the\r\ncertificate authority itself can have a security impact on the entire AD CS system.\r\nThese possibilities include (but are not limited to):\r\nCA server’s AD computer object (i.e., compromise through RBCD)\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 13 of 22\n\nThe CA server’s RPC/DCOM server\r\nAny descendant AD object or container in the container CN=Public Key\r\nServices,CN=Services,CN=Configuration,DC=\u003cCOMPANY\u003e,DC=\u003cCOM\u003e (e.g., the Certificate Templates\r\ncontainer, Certification Authorities container, the NTAuthCertificates object, the Enrollment Services container,\r\netc.)\r\nEDITF_ATTRIBUTESUBJECTALTNAME2 — ESC6\r\nAnother way to supply arbitrary SANs, described in a CQure Academy post, involves the\r\nEDITF_ATTRIBUTESUBJECTALTNAME2 flag. As Microsoft describes, “If this flag is set on the CA, any\r\nrequest (including when the subject is built from Active Directory®) can have user defined values in the subject\r\nalternative name.” This means that ANY template configured for domain authentication that also allows\r\nunprivileged users to enroll (e.g., the default User template) can be abused to obtain a certificate that allows us to\r\nauthenticate as a domain admin (or any other active user/machine). As this Keyfactor post describes, this setting\r\n“just makes it work”, which is why it’s likely flipped in many environments by sysadmins who don’t fully\r\nunderstand the security implications.\r\nOur normal reaction to seeing this setting in enterprise environments:\r\nVulnerable Certificate Authority Access Control — ESC7\r\nOutside of certificate templates, a certificate authority itself has permissions (accessible through certsrv.msc) that\r\nsecure various CA actions. From a security perspective we care about the ManageCA (aka “CA Administrator”)\r\nand ManageCertificates (aka “Certificate Manager/Officer”) permissions.\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 14 of 22\n\nThe ManageCA permission grants a principal the ability to perform “Administrative” CA actions, including the\r\nmodification of persistent configuration data. This includes the EDITF_ATTRIBUTESUBJECTALTNAME2 flag,\r\nallowing any principal with the ManageCA permission to fixate ESC6. This can be done with PSPKI’s Enable-PolicyModuleFlag cmdlet.\r\nThe ManageCertificates permission allows the principal to approve pending certificate requests, negating the\r\n“Manager Approval” Issuance Requirement/protection. So while it can’t be used on its own to compromise the\r\ndomain, it can function as a protection bypass.\r\nNTLM Relay to AD CS HTTP Endpoints — ESC8\r\nWe cover this in more detail in the “Background — Certificate Enrollment” section of the whitepaper, but AD CS\r\nsupports several HTTP-based enrollment methods via additional server roles that administrators can optionally\r\ninstall:The certificate enrollment web interface, via installing the Certificate Authority Web Enrollment role.\r\nExposed as an IIS-hosted ASP web enrollment application running at http://\u003cADCSSERVER\u003e/certsrv/Certificate\r\nenrollment service (CES), via installing the Certificate Enrollment Web Service role. Works in tandem with the\r\nCertificate Enrollment Policy (CEP) web service, via installing the Certificate Enrollment Policy Web Service role.\r\nDetails in the whitepaper.The network device enrollment service (NDES), via installing the Network Device\r\nEnrollment Servicerole. Exposed as a series of interfaces described in the whitepaper.\r\nThese HTTP-based certificate enrollment interfaces are all vulnerable to NTLM relay attacks. Using NTLM relay,\r\nan attacker can impersonate an inbound-NTLM-authenticating victim user. While impersonating the victim user,\r\nan attacker could access these web interfaces and request a client authentication certificate based on\r\nthe User or Machine certificate templates.\r\nThis attack, like all NTLM relay attacks, requires a victim account to authenticate to an attacker-controlled\r\nmachine. An attacker can coerce authentication by many means, but a simple technique is to coerce a machine\r\naccount to authenticate to the attacker’s host using the MS-RPRN RpcRemoteFindFirstPrinterChangeNotification(Ex) methods using a tool like SpoolSample or Dementor.\r\nThe attacker can then use NTLM relay to impersonate the machine account and request a client authentication\r\ncertificate (e.g., the default Machine/Computer template) as the victim machine account. If the victim machine\r\naccount can perform privileged actions such as domain replication (e.g., domain controllers or Exchange servers),\r\nthe attacker could use this certificate to compromise the domain. Otherwise, the attacker could logon as the victim\r\nmachine account and use S4U2Self as previously described to access the victim machine’s host OS.Note: Newer\r\nOS’es have patched the MS-RPRN coerced authentication “feature”. However, almost every environment we\r\nexamine still has Server 2016 machines running, which are still vulnerable to this. There are other ways to coerce\r\naccounts to authenticate to an attacker as well.\r\nIn summary, if an environment has AD CS installed, along with a vulnerable web enrollment endpoint and at least\r\none certificate template published that allows for domain computer enrollment and client authentication (like the\r\ndefault Machine/Computer template), then an attacker can compromise ANY computer with the spooler service\r\nrunning!\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 15 of 22\n\nThese attack scenarios work because some enrollment HTTP endpoints do not have HTTPS enabled and none of\r\nthem have any NTLM relay protections enabled by default. Organizations should disable these HTTP-based\r\nenrollment server roles if they are not in use. Otherwise, network defenders can disable NTLM authentication\r\nusing GPOs or configuring the associated IIS applications to only accept Kerberos authentication. If organizations\r\ncannot remove the endpoints or outright disable NTLM authentication, they should only allow HTTPS traffic and\r\nconfigure the IIS applications to Extended Protection for Authentication .\r\nThis specific issue was reported to MSRC, along with the other template escalation misconfigurations. The official\r\nresponse was, “We determined your finding is valid but does not meet our bar for a security update release.”\r\nNote: While we have verified that this attack is possible, we are waiting to publicly demonstrate it at our Black\r\nHat talk to help facilitate fixing the issue first.\r\nDomain Persistence\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 16 of 22\n\nActive Directory Enterprise CAs are hooked into the authentication system of AD and the CA root certificate\r\nprivate key is used to sign newly issued certificates. If we stole this private key, would we be able to forge our\r\nown certificates that could be used (without a smart card) to authenticate to Active Directory as anyone in the\r\norganization?\r\nSpoiler: yes. And this has already been possible with Mimikatz/Kekeo for years. I guess we should call these\r\ngolden certificates?\r\nThe certificate exists on the CA server itself, with its private key protected by machine DPAPI if a TPM/HSM is\r\nnot used for hardware-based protection. If the key is not hardware protected, Mimikatz and SharpDPAPI can\r\nextract the CA certificate and private key from the CA:\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 17 of 22\n\nWith this key, you can create and sign new certificates for ANY user and use these forged certificates to\r\nauthenticate to AD for as long as the CA cert is valid (default of 5 years, but often longer). Our\r\ntool ForgeCert (which will be released at Black Hat USA 2021 along with Certify) can perform these forgeries:\r\nOh, and these certs can’t be revoked, since they were never actually issued by the CA itself, as detailed by\r\nBenjamin Delpy:\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 18 of 22\n\nUnfortunately, there isn’t a huge amount of public incident response guidance as far as AD CS. But if a root CA’s\r\nkey is stolen, the entire AD CS system will likely need to be rebuilt, invalidating every issued certificate.\r\nDefensive Advice\r\nNot only are we self-embargoing the offensive tool release for these abuses, but we’ve also spent a large amount\r\nof effort researching both preventative and detective controls for these attacks. Part of the motivation for breaking\r\nout attacks and associated defensive protections with individual identifiers was to make the whitepaper material as\r\ndigestible as possible for defenders.\r\nBesides identifying and mitigating the privilege escalation vulnerabilities, something we want to emphasize from\r\nan incident response perspective is that it is not enough to reset a compromised user’s password and/or reimage\r\ntheir machine. Certificate theft is trivial in most environments given code execution in a user or computer context\r\nand would allow an attacker to authenticate to AD for years — even after the account’s password has been reset.\r\nTherefore, when an account or machine is compromised, incident responders should identify and invalidate any\r\ncertificates associated with the compromised accounts as well. PSPKIAudit’s Get-CertRequest can help perform\r\nthis type of triage.\r\nAs the defenses for these attacks are multi-pronged, at this point we’re recommending defenders study the attacks,\r\nread the extensive “Defensive Guidance” section of the whitepaper, and reference Microsoft’s Securing\r\nPKI documentation. Defenders can also try out the PSPKIAudit’s Invoke-PKIAudit function the\r\nmisconfigurations described in this post:\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 19 of 22\n\nWrap-up\r\nEven months into this research, we believed that there wasn’t necessarily anything inherently insecure about\r\nActive Directory Certificate Services. While the entire system is very dangerous if an organization doesn’t fully\r\nunderstand AD CS or its security implications (as it’s extremely easy to misconfigure) there didn’t appear to be\r\nany “out of the box” vulnerabilities. That said, we have seen a proliferation of the ESC1–7 elevation issues in real\r\nenvironments since we began looking in January 2021. We feel administrators have been given a powerful weapon\r\nwith the safety off for 20 years and there’s been little safety training. An attitude of, “Well, admins should have\r\nknown better” in this scenario, without even providing a way to audit or investigate these issues programmatically\r\nfrom a defensive context, is, well, a position we suppose.\r\nHowever, beyond the template misconfiguration scenarios, the ESC8 relay situation is a serioussecurity issue. We\r\nreported this relay issue to MSRC on May 19th along with all domain escalation scenarios, and received a\r\nresponse on June 8th of “We determined your finding is valid but does not meet our bar for a security update\r\nrelease. We considered that servers with AD CS roles could mitigate this risk with a change in configuration\r\nsettings to enable Extended Protection for Authentication (EPA), per this blog post.” MSRC stated that they also\r\nopened up a bug concerning the template issues and our comments about poor telemetry with the AD CS feature\r\nteam, who may consider additional design changes in a future release.\r\nTo be clear, based on our research, if you are running AD CS with ANY template a domain computer can enroll in\r\nthat also allows domain authentication (e.g., the Machine/Computer template that is available by default), ANY\r\nsystem running the spooler service can be compromised. Based on our extensive experience assessing AD\r\nenvironments, we believe this is very bad. If you find you are vulnerable to this, consider contacting your nearest\r\nMicrosoft representative and question them as to why this insecure default configuration is allowed. As of right\r\nnow, they have no intentions of directly servicing the issue, but said they may fix it at some indeterminate future\r\ndate.\r\nFrom a defensive perspective, you should either immediately enumerate the Web Enrollment interfaces enabled in\r\nyour environment (possible with PSPKIAudit) and then either remove them, disable NTLM authentication to\r\nthem, or enforce HTTPS to them and enable EPA on the IIS server component. For specifics on how to do this,\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 20 of 22\n\nplease see “Defensive Guidance — Harden AD CS HTTP Endpoints — PREVENT8” in the whitepaper. We also\r\nstrongly recommend organizations audit their AD CS architecture and certificate templates and treat CA servers\r\n(including subordinate CAs) as Tier 0 assets with the same protections as Domain Controllers! The “Defensive\r\nGuidance”section of the whitepaper has more information on how to proactively prevent, detect, and respond to\r\nthe attacks we’ve detailed.\r\nYes, we’re working to integrate the escalation paths into BloodHound, but as you can see this whole thing is rather\r\ncomplicated, and we want to get it right. But rest assured, it’s currently under development at the moment and will\r\nbe released in FOSS BloodHound.\r\nAnd finally, as a disclaimer, we are not stating that we know every security issue concerning AD CS. We took our\r\nbest shot in this research, but we are confident that there are additional issues and attacker tradecraft implications\r\nthat we (or others) will find in the coming months, or things we have missed.\r\nAcknowledgements\r\nAs is almost always the case, we’re standing on a number of shoulders with this research. The whitepaper gives a\r\nmore complete treatment of prior work, but as a summary:\r\nBenjamin Delpy for his extensive work on smart cards/certificates with Mimikatz and Kekeo.\r\nPKI Solutions for their excellent posts on PKI in Active Directory, as well as their PSPKI PowerShell module,\r\nwhich our auditing toolkit is based on.\r\nThe “Windows Server 2008 — PKI and Certificate Security” book by Brian Komar.\r\nThe following open technical specifications provided by Microsoft:\r\n[MS-CERSOD]: Certificate Services Protocols Overview\r\n[MS-CRTD]: Certificate Templates Structure\r\n[MS-CSRA]: Certificate Services Remote Administration Protocol\r\n[MS-ICPR]: ICertPassage Remote Protocol\r\n[MS-WCCE]: Windows Client Certificate Enrollment Protocol\r\nChristoph Falta’s GitHub repo which covers some details on attacking certificate templates, including virtual\r\nsmart cards as well as some ideas on ACL based abuses.\r\nCQURE’s “The tale of Enhanced Key (mis)Usage” post which covers some Subject Alternative Name abuses.\r\nKeyfactor’s 2016 post “Hidden Dangers: Certificate Subject Alternative Names (SANs)”\r\n@Elkement’s posts “Sizzle @ hackthebox — Unintended: Getting a Logon Smartcard for the Domain\r\nAdmin!” and “Impersonating a Windows Enterprise Admin with a Certificate: Kerberos PKINIT from Linux”\r\ndetail certificate template misconfigurations.\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 21 of 22\n\nCarl Sörqvist wrote up a detailed, and plausible, scenario for how some of these misconfigurations happen titled\r\n“Supply in the Request Shenanigans”.\r\nCeri Coburn released an excellent post in 2020 on “Attacking Smart Card Based Active Directory Networks”\r\ndetailing some smart card abuse and Rubeus additions.\r\nBrad Hill published a whitepaper titled “Weaknesses and Best Practices of Public Key Kerberos with Smart\r\nCards which provided some good background on Kerberos/PKINIT from a security perspective.\r\nSpecial thanks to Mark Gamache for collaborating with us on parts of this work. He independently discovered\r\nmany of these abuses, reached out to us, and brought many additional details to our attention while we were\r\nperforming this research.\r\nAs always, we tried our best to cite the existing work out there that we came across, but we’re sure we missed\r\nthings.\r\nWhitepaper — “Certified Pre-Owned: Abusing Active Directory Certificate Services”\r\nDefensive Toolkit — PSPKIAudit (based on PSPKI)\r\nOffensive Toolkit —(code will be pushed at Black Hat, preemptive IOCs/Yara rules are currently\r\nlive) Certify and ForgeCert\r\nPost Views: 21,387\r\nSource: https://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nhttps://posts.specterops.io/certified-pre-owned-d95910965cd2\r\nPage 22 of 22",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://posts.specterops.io/certified-pre-owned-d95910965cd2"
	],
	"report_names": [
		"certified-pre-owned-d95910965cd2"
	],
	"threat_actors": [],
	"ts_created_at": 1775434273,
	"ts_updated_at": 1775826774,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c71c389b8aad475c0c9e858f832f8124af40fdd9.pdf",
		"text": "https://archive.orkl.eu/c71c389b8aad475c0c9e858f832f8124af40fdd9.txt",
		"img": "https://archive.orkl.eu/c71c389b8aad475c0c9e858f832f8124af40fdd9.jpg"
	}
}