ADCS Abuse Methods
Well we installed the ADCS in previous blog. Now we can come to the security side of it. But first we need to understand the background of the ADCS little bit.
What the hell is ADCS and Why?
The Active Directory Certificate Service (ADCS) is responsible from management of certificates with Public Key Infrastructure (PKI) in Active Directory environment. It allows us to issue x509 certificates over Certificate Templates to work with smart card logins, email encryption, VPN authentication, code signing, protecting service-to-service communication and more.
In this blog we will go trough ADCS abuse mechs. Mostly we will be using such a “goat” tool named certipy by Oliver Lyak.
We need to know few concepts for better understanding:
- Certificate: A digitally signed document/file issued by a Certificate Authority (CA) that defines specific Extended Key Usage (EKU) permissions.
- Certificate Authority (CA): The root of the entire ADCS (Active Directory Certificate Services) system. It manages certificates and signs them using its own private key.
- Certificate Templates: Templates define what a certificate will be used for and what information or configuration is required to generate and issue that certificate.
- Extended Key Usage (EKU): In Active Directory, everything is an object. EKUs define the Object Identifiers (OIDs) for certificate templates, which specify which template will be used for a particular purpose.
- Subject Alternative Names (SAN): It allows users to define identity for certificates including UPN and DNS
- Certificate Signing Request (CSR): The request we send to generate and issue a certificate. It contains the necessary information and triggers the background process that creates the certificate.
- Public Key Cryptography for Initial Authentication in Kerberos (PKINIT): It’s an extension to the Kerberos authentication protocol that allows users to authenticate using public key (certificate-based) credentials instead of just passwords or pre-shared secrets.
In ADCS, the certificate issuance workflow runs quite simply. A user generates a CSR request to get a certificate and sends the request to the ADCS server. The server checks the CSR request, and if everything is fine, it signs the certificate with its own private key and gives it to the client (machine or user). We got a cert!
In this blog series we will be looking at the ADCS misconfigs. You can reach every ESC misconfig with the following links. (Don’t worry — other ESC misconfigs will be coming soon.)