At CRSP we help customers to recover from different types of cyber security incidents. This means that we help more or less with wherever help is needed (from hardening AD and AAD, to restoring Exchange). However, there are some things which are crucial to not getting re-compromised and therefore we don't let our customers come online without: Securing and hardening Active Directory and all kinds of Azure resources.
During the last 1.5 years some papers and articles drew attention to risky misconfiguration of Active Directory Certificate Services (ADCS) and its potential for Active Directory (and Azure) dominance. Therefore, an essential part of our Compromise Recovery engagements deals with introducing unpopular measures like using PAWs (Privileged Access Workstations) or stopping unverified enrollment of certificates allowing custom subjects. The latter involves reviewing certificate template configuration and security settings in Active Directory. Please note that certificate templates are not the only aspect of securing ADCS, but the one we want to focus on in this article.
Certificate templates and Registration Authorities
In short, certificate templates in Active Directory define which information an acceptable certificate request must include, how the request and the subject and/or Subject Alternative Names (SANs) are verified, and which accounts are allowed to request a certificate.
ITU-T X.509 recommendations define the role of a Registration Authority (RA) to complete the task of "identification and authentication of the subject of a public-key certificate to be issued by that certification authority".
ADCS preferably delegates the RA tasks to Active Directory but also provides an interface for so-called "custom Policy Modules", which allow to introduce an individual ruleset for certificate request verification, like block- or whitelists of subjects, comparison of subjects with DNS etc. Custom Policy Modules are available from third-party vendors, published on GitHub and of course you can create your own. Finally, you can verify subject and SANs in certificate requests manually.
Whatever you decide for, you MUST ensure that subject and SANs of every certificate request are verified properly before being issued.
Wondering what the excitement is about?
Find an example of a combination of settings which allows domain dominance as soon as a single computer gets compromised in your forest below (assuming that a custom Policy Module is not in place):
With the above configuration of a certificate template and the CA published to the NTAuth Store in Active Directory, an attacker could simply request and enroll a certificate with a Domain Admin's or some VIP's User Principal Name as a SAN and immediately use the certificate to logon to Active Directory in the security context of this account.
|
The NTAuth store is an object in the Services partition of AD. CA certificates which are trustworthy for AD authentication are published to the NTAuth object and from there replicated to the Enterprise certificate store on all members of the AD Forest.
Smart card authentication or Windows Hello for Business (Key Trust or Certificate Trust) only work with the issuing CA certificate published to NTAuth. |
Improving your manual verification experience
During Compromise Recovery, we typically don't have time to evaluate and acquire custom Certificate Policy modules from third-party vendors. As a quick and cheap alternative we enforce manual verification of pending certificate requests. Customers complained - with good reason – ADCS do not provide a handy tool to complete this task. As described above, it is crucial to precisely verify subject and SANs of certificate request submitted for an offline template. Find more details about certificate template security settings at https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/d....
This problem is now solved because my colleague Andreas Luy published a beautiful little tool on GitHub: GitHub - Bulgwei/CertMangement: Little Front End for ADCS to submit/retrieve/Issue and deny certific...
Some notes on the tool:
- It is natively written in PowerShell. So, it could be easily enhanced or modified to fit to the necessities needed.
- It only uses functionalities which are available on every modern Windows™ OS (CERTUTIL/CERTREQ).
- The tool supports separation of the following CA-specific roles: “CA Administrators” and “Certificate Managers”.
- To use all features, you need "Manage CA" and "Issue and Manage Certificates" permissions – please note that this is NOT recommended, instead you should always split permissions.
- The tool can be used to remotely connect to an Active Directory integrated CA (CA must not be restricted to deny remote administration) or locally on the CA computer.
- It allows you to submit existing certificate requests (including ones which do not yet include certificate template information. This type of certificate request is typically created by some non-Windows operating systems or appliances). Please keep in mind that the account running the tool must have "Enroll" permission on the selected certificate template.
- When it comes to handling of certificate requests, the tool has several options:
- Display all issued certificates submitted by the account running the tool during a defined number of days and retrieve the certificate in DER and base64 format.
- Display all issued certificates submitted by ANY account during a defined number of days and retrieve the certificate in DER and base64 format.
And finally, the "killer feature": The one-stop option to fully review certificate requests and finally issue or deny it:
One-stop verification of subject and SAN(s) of pending certificate requests:
We hope you enjoy the tool, and it makes your process of submitting and verifying certificate requests easier!