Written by: Matthew Burns
My last blog post was about the many misconfigurations that could affect Microsoft Active Directory Certificate Services (AD CS). In this blog post I wanted to dive deeper into the misconfiguration I see most often during internal penetration tests. The misconfiguration in question is when Web Enrollment is enabled on a domain’s AD CS server (see Figure 1 below). The output in Figure 1 can be generated using the Certify/Certipy find command discussed in my previous blog post.
Figure 1: Certipy Certificate Service Enumeration Sample
What is Web Enrollment?
Web Enrollment is a service that can be installed on an AD CS server to allow users and computers in an Active Directory domain to request a certificate through an interactive web page. Specifically, Web Enrollment services allow users and computers to request certificates via the hypertext transfer protocol (HTTP). Web Enrollment services can be used to provide users in separate forests or users not in the domain the ability to request certificates from one centralized certificate server. A sample web enrollment page can be viewed below in Figure 2.
Figure 2: Web Enrollment Sample Page
How Can Web Enrollment Services be Abused?
Web Enrollment deployed using standard default configurations is vulnerable for two reasons. First, HTTP supports New Technology LAN Manager (NTLM) authentication, which is not inherently bad. However, HTTP does not support any form of NTLM authentication protection, such as signing. This means that an attacker can send authentication data to the web enrollment HTTP endpoint without the need for verification. This makes the web enrollment endpoint vulnerable to an NTLM relay attack.
Secondly, the AD CS server, by default, comes with multiple certificate templates enabled that allow for machine accounts, including domain controllers, to generate client authentication certificates. These authentication certificates can then be used for authentication in the domain. The default templates in question are the Machine and DomainController templates.
This means an attacker could impersonate any machine in the domain if they are able to coerce authentication from that machine, relay the authentication data to the web enrollment endpoint, and a default template is enabled. Sadly, there is an unpatched vulnerability in Microsoft based systems that makes coercing authentication from any machine possible.
How to Utilize a Domain User for Guaranteed Domain Compromise
While web enrollment could be abused to go from no domain access to domain admin access if the right hash is relayed, there is an even scarier attack path with web enrollment services. If an attacker has domain user credentials, web enrollment is enabled, and there is a vulnerable certificate template enabled, then the attacker will always be able to escalate their privileges to domain administrator. This is thanks to an unpatched vulnerability from Microsoft dubbed PetitPotam.
My colleague wrote a blog post on PetitPotam that goes more in depth on the vulnerability, but PetitPotam allows any domain user to coerce the authentication from any active computer account in the domain including domain controllers. This means that an attacker, with a domain user account, can always request the domain controller’s machine account hash. The domain controller hash can then be relayed to the web enrollment endpoint to request a certificate for the domain controller using the default DomainController template. Certipy can be used to perform this attack see Figure 3 below.
Figure 3: Certipy Relay
This certificate can then be used as another form of authentication in Active Directory. The attacker can use Certipy or another tool to generate a ticket-granting ticket (TGT) via Kerberos authentication. This TGT can be turned into an NT-hash, which is equivalent to the plaintext password for Active Directory Authentication (see Figure 4 below).
Figure 4: Certipy Auth
The risk associated with access to the domain controller machine account is that the domain controller machine account has domain replication privileges through the DSGetNCChanges function in Active Directory. This is known as a DCSync attack and allows an attacker to request a domain controller for the NT-hashes of all users in an Active Directory domain. With all the NT-hashes for the domain an attacker can impersonate any user including domain admins.
How can this be fixed?
The good thing is that, if your organization does not need this service, then web enrollment can be simply turned off. In the case your organization does require web enrollment services there are multiple steps that can be taken to harden the service. Firstly, NTLM authentication can be denied on the certificate server or at the IIS server level. Secondly, the HTTPS (Hypertext Transfer Protocol over SSL) can also be enabled with extended protection on the web enrollment endpoint.
Additionally, detective controls can also be implemented to generate alerts for this type of attack. Organizations should investigate if a similar detection can be implemented into their own monitoring tools. Finally, any organization with an AD CS server should treat this server as a tier 0 asset like a domain controller. Only administrators should have access to the certificate server and the server should be on a separate network segmented from standard user traffic.
