This morning we provided details to our existing support and co-management customers on a recent notice of vulnerability to certain Microsoft ADCS configurations. The exploit involves NTLM and leveraging some ADCS PKI components. Full details can be found here: https://msrc.microsoft.com/update-guide/en-US/vulnerability/ADV210003.
Summary
In environments with NTLM authentication still enabled in Active Directory and when using ADCS Web Enrollment portal (/certsrv) or ADCS CES/CEP (Certificate Enrollment Web Services protocol), an attacker can trick Active Directory into providing NTLM credentials as a domain controller and then self-elevate to Domain or Enterprise Admins. This is essentially an NTLM Relay Attack.
Mitigation
This can be resolved by following recommendations in https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429. These options include:
- Disabling NTLM for Active Directory. The most thorough but potentially large undertaking in an environment due to potential known or unknown compatibility issues.
- Disabling NTLM for servers running ADCS
- Disabling NTLM for the ADCS Web Enrollment and CES/CEP web application pools.
- Enable Extended Protection for ADCS Web Enrollment and CEs/CEP Web application pools.
Considerations
While this attack vector has not been seen as exploited, we suspect it will be due to the ease of elevation. Additionally, when transitioning from NTLM to Kerberos authentication, you should give careful consideration to the URL being used to access the web enrollment website. If you are using a URL other than the hostname, such as a CNAME alias like https://certs/certsrv or https://certs.contoso.com/certsrv these will need to be added as Kerberos SPNs to the server running the website. NTLM did not require this step.
We will be releasing a script shortly to assist in the discovery of your AD and server configuration to indicate which systems and environments are impacted. If you would like to receive notification of that availability, please do let us know.
12 Responses
Thanks for useful article and looing forward the script
The PetitPotam POC for NTLM relay via ADCS web services seems to be based on prior work from SpecterOps whitepaper ‘Certified_Pre-Owned.pdf’ from June 2021 and due to be presented at Blackhat 2021 next week. This is an interesting and scary document detailing a number of know, but little understood, vulnerabilities in a (even slightly) misconfigured ADCS deployment. Certainly worth basing your next risk assessment on.
Good point. We will be adding this and others to our Advanced Assessments to review with enterprises.
I implemented the recommendation from microsoft and blocked NTLM incoming and change the authentication to negotiate:kerberos, but now i always get an RPC error when i request a certificate. What can I do now? I hope you have an Idea
When you switch to Kerberos you need to make sure the url you are using is available as a Kerberos SPN. Are you going to the website via the host name like https://server01/certsrv or using a dns alias like https://certs/certsrv? If the latter you need a SPN for certs.
Will the absence of Kerberos SPN also cause problem if we enable EPA as mitigation step.
https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429
Since most organization may have more than one ADCS servers behind load balancer URL so I guess assigning the load balancer URL Kerberos SPN to a single ADCS server may not be feasible.
Edit: Sorry I forgot that webservers behind load balancer can use a service account instead for SPN registration & Kerberos authentication.
However my question remains if enabling EPA will cause issues if Kerberos SPN is missing.
EPA is the remediation option if you wish to leave NTLM enabled. So if you are waving NTLM and using EPA there are no SPN issues to be concerned with. However if you switch you Kerberos then the SPN issue is still needing to be addressed as EPA does nothing in this scenario.
I’d like to know when your script is ready, please.
Thanks
Question about NDES, it does not have Windows authentication enabled by default but SCEP App pool is using NTLM there . . Is there any possibility to change behavior to Kerberos without disabling NTLM for whole server? Will it even work =)
Did you do any test on NDES site?
Thanks!
Yes, you can disable NTLM just for the web enrollment site and not the entire server. SCEP/NDES were not identified as part of the vulnerability.
Thanks for the useful guide. I also want to know when it`s online!