Active Directory Certificate Services (ADCS) is a Public Key Infrastructure (PKI) that can be installed for use with a Microsoft Active Directory Domain to assist in authentication, authorization, encryption and more using certificates. Certificates are files that are generated using public and private keys and can be entries in a certificate chain, or hierarchical relationship to other certificates leading all the way up to the root certification authority. We regularly use certificates to encrypt traffic as we view websites, and our browsers are configured to trust certificates that have been issued via reputable certification authorities such as DigiCert and GlobalSign. These certificates are purchased by the website owners and registered with the certificate authority to prove ownership of the domain. Not only can these certificates be used to encrypt the traffic while using the site, but they can assure users that the site they are viewing is legitimate.
So why use ADCS?
Well, its free and works nicely with the way that Active Directory (AD) domains are set up and used. For instance, if we have an AD domain called “hwah.local”, we have configured a private domain and not necessarily one that can “resolve” (or point to a certain IP Address) when removed from the network which hosts the AD components (Domain controller, DNS, etc). While we could purchase certificates to work with domain services this could be expensive and difficult to manage given that resources such as computers, users, and services in a local domain may change rapidly. ADCS gives us an opportunity to “roll our own” PKI and control certificates at a local level, with very little administrative overhead. Also, because it is built with AD Domains in mind, there are built in mechanisms to create certificates for objects such as users, computers, services, and SSL/TLS encryption for internal websites.
So why shouldn’t we use ADCS?
Well, its not really a matter of we shouldn’t use ADCS to create certificates internally but rather that we potentially open up our domain to vulnerabilities by improperly configuring certificates. We shouldn’t use ADCS in a production environment if we are unsure about the permissions we give to certificates, the encryption methods used, enrollment requirements, and certificate revocation/validation. I became interested in ADCS by working on some penetration testing challenges on the ethical hacking training site Hackthebox (https://www.hackthebox.com). Following a tutorial to complete the challenge, it instructed me through steps to request a certificate as an unprivileged user, alter the subject name of the certificate and VIOLA, escalate privileges to Domain Administrator by requesting a Ticket Granting Service (TGS) kerberos ticket using the certificate. This ticket could then be passed back to the Domain Controller to impersonate the Domain Administrator! I thought, wow, this must be a very difficult mistake to make when configuring a certificate. However, fast forward a few months and I found myself experimenting with creating certificates in a lab domain and I found that the ability to allow the user to specify the subject name in the certificate template wizard was front and center!I could see how someone is in a rush or frustrated with getting the certificate to work could select this option. This led me to Specter Ops’ whitepaper titled Certified Pre-Owned: Abusing Active Directory Certificate Services (https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf) which was presented at Black Hat 2021, which details in depth security research pertaining to ADCS.
So, why did I want to make a lab for specifically ADCS?
I began to think of ideas of how and why an organization would use ADCS and how these uses could either increase or decrease security of the domain. I instantly realized that documentation of usage of ADCS certificates is lacking beyond setting up the Certification Authorities (CAs) and using ADCS for computer certificates or to encrypt Internet Information Services (IIS) web server traffic. I wanted to create an environment from the ground up and incorporate certificates into other areas such as creating IPSec tunnels, generating certificates for non domain devices such as routers, authenticating and authorizing Windows applications such as Remote Desktop and WinRm, and more. I also wanted to practice the penetration testing side of ADCS, so alongside creating a domains I decided to use a preconfigured, and intentionally vulnerable, domain scenario created by Orange Cyberdefense called Game of Active Directory (https://github.com/Orange-Cyberdefense/GOAD). This would allow me to research how vulnerabilities in ADCS configurations could lead to other vulnerabilities in in AD.
Join me in the next few posts as I set up the lab!
Hackers With a heart 