Microsoft Security Advisory for ADCS exploit – ADV210003

PKI Solutions Logo

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:

  1. Disabling NTLM for Active Directory. The most thorough but potentially large undertaking in an environment due to potential known or unknown compatibility issues.
  2. Disabling NTLM for servers running ADCS
  3. Disabling NTLM for the ADCS Web Enrollment and CES/CEP web application pools.
  4. 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.

About ThePKIGuy

President & Founder at PKI Solutions, Leading PKI Cybersecurity Subject Matter Expert, Author, Speaker, Trainer, Microsoft Certified Master.

12 Comments

  1. Prashant Rajput on July 27, 2021 at 1:25 am

    Thanks for useful article and looing forward the script

  2. Darren Davis on July 27, 2021 at 7:23 am

    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.

    • ThePKIGuy on July 28, 2021 at 7:37 am

      Good point. We will be adding this and others to our Advanced Assessments to review with enterprises.

  3. Joern on August 2, 2021 at 4:13 am

    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

    • ThePKIGuy on August 2, 2021 at 7:13 am

      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.

      • Abhishek on August 2, 2021 at 2:37 pm

        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.

        • Abhishek on August 2, 2021 at 2:49 pm

          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.

          • ThePKIGuy on August 3, 2021 at 12:04 pm

            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.



  4. Grant on August 2, 2021 at 8:07 am

    I’d like to know when your script is ready, please.

    Thanks

  5. Artem Borodai on August 10, 2021 at 3:08 am

    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!

    • ThePKIGuy on August 18, 2021 at 9:49 am

      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.

  6. Daniel on August 11, 2021 at 10:48 pm

    Thanks for the useful guide. I also want to know when it`s online!

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.