search

ly4k / Certipy

Tool for Active Directory Certificate Services enumeration and abuse
MIT License
2.38k stars 327 forks source link

Unable to find named pipes/endpoints #57

Closed jsdhasfedssad closed 2 years ago

jsdhasfedssad commented 2 years ago

Hi. I love your tool but I currently am facing an issue in Certipy 3.0.0. (main). I will describe the issues below but I cannot post any screenshots for obvious reasons.

I client of mine is running ADCS on a Server 2019 machine which is not a domain controller. The web interface is enabled and there are multiple vulnerable custom certificate templates. There are however many restrictions on who can enroll certificates.

When I attempt to abuse ESC1 using a machine account which has enrollment rights via the domain group Domain Computers and a template which is vulernable, the attack first fails with "STSTATUS_OBJECT_NAME_NOT_FOUND" when Certipy attempts to find the required named pipe (cert?). After that the backup feature which attempts to identify dynamic endpoints kicks in but that also fails with "Failed to get dynamic TCP endpoint for CertSvc" and "NoneType object has no attribute 'request'".

What is strange is that abusing ESC8 against the same ADCS server works when authenticating using a DC's machine account I coerce using PetitPotam.py and specifying the template KerberosAuthentication. I get the certificate but when I then attempt to get the matching TGT and NT hash it seems the authentication against the DC fails. I get the error "ERR_CLIENT_NOT_TRUSTED". According to nmap against the same DC, services that requires TLS are configured to use certificates which are issued by the same CA that is configured on the ADCS server so it seems it is not the CA that is not trusted.

Any suggestions? Thanks!

ly4k commented 2 years ago

Hello. First of all, you should make sure that the certificate requests are targeted the CA server and not the domain controller, which might explain the "STSTATUS_OBJECT_NAME_NOT_FOUND". Secondly, it sounds like this is a standalone CA server and not an enterprise CA server, which might explain the "ERR_CLIENT_NOT_TRUSTED". Can you verify or did you resolve the issues?

jsdhasfedssad commented 2 years ago

Hi. Thanks for your reply. Unfortunately I can no longer check or test things since I do not have access to the mentioned infrastructure anymore. However, according to https://serverfault.com/questions/826444/difference-between-microsoft-adcs-standalone-ca-and-enterprise-ca only enterprise CA servers have templates and as I mentioned there were plenty of those. You can also see that the ESC8 attack worked against the same ADCS server.

It is of course obvious to you but I wonder if the web interface is used for all ESCX attacks as it is for the ESC8 attack? Or put in other words, does the ESC8 attack, which worked, require using named pipes? Also, I think it is possible to restrict access to named pipes using ACLs. Could that be a explanation?

ly4k commented 2 years ago

Hello @jsdhasfedssad Sorry for the late reply. I still haven't figured out why this is the case. However, I have implemented web enrollment in the upcoming version of Certipy, such that if web enrollment is enabled (HTTP/HTTPS), then it's possible to abuse ESC1-ESC3 (certificate templates) through that in case RPC is not available.