ACTIVE DIRECTORY CERTIFICATE SERVICE – DEFENSIVE GUIDANCE

1. Identifying exposure

If Active Directory Certificate Service is in your environment, it is important to precisely investigate how these new techniques pose a threat to your domain.

As of July 2021, there are two toolkits that you can use to evaluate if an environment is vulnerable to certificate abuse. Baseline Certificate Authority configuration overview

1.1. Do I have a Certificate Authority?

If you have Certificate Services enabled in your Active Directory, you likely have a Certificate Authority server. This server is key to Active Directory Certificate Service orchestration.

1.2 Gather Certificate Authority

You can collect useful information through cerutil.exe on any domain joined endpoint, you do not have to run this on the Certificate Authority itself.

CMD

certutil.exe

Basic Certificate Authority information

CMD

#Display verbose CA info. Takes a minute
Certutil.exe -tcainfo

Verbose Certificate Authority information

On a Certificate Authority machine itself, we can leverage the registry to get an overview of configuration information about the Certificate Service. There is additional, granular information that can be gathered here that does not appear in the above results.

POWERSHELL

# To be run on CA machine
# Get CA name
(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration").Active
# Pass it as variable and then get more info 
$CAName = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration").Active;
Get-Itemproperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\$CAName”

Granular Certificate Authority configuration detail

1.2 Exposure assessment: “Am I vulnerable?”

Organisations can initiate a cursory audit of susceptibility to certificate abuse in their environment. This script offers the answer: ‘no / yes and how bad?’. This script can be run from any endpoint that is connected to the domain. JUMPSEC advise to run the script as a high privilege user on an endpoint.

POWERSHELL

#To be run from domain joined machine
#Confirm you are happy with the domain name, and then pass as variable
(Get-WmiObject -Class win32_computersystem).domain
$DomainName = (Get-WmiObject -Class win32_computersystem).domain
#Transfer the PS1 and check it
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/RemiEscourrou/Invoke-Leghorn/main/Invoke-Leghorn.ps1" -OutFile ".\Invoke-Leghorn.ps1"
Read-Host -Prompt "Script is from a third party source. Please manually review before execution. Press any key to exit this warning"
#Import it
Import-Module .\Invoke-Leghorn.ps1
#Begin transcript mode. This will allow to save results, as Out-File doesn’t work with this script
$ErrorActionPreference="SilentlyContinue"
Stop-Transcript | out-null
$ErrorActionPreference = "Continue"
Start-Transcript -path .\certificate_service_audit.txt -append
#Deploy it, using domain name. Run once normally, and then run again verbose. 
Invoke-Leghorn -Domain $DomainName
#wait till above finished
Invoke-Leghorn -Domain $DomainName -verbose
#End transcript mode
Stop-Transcript
#Collect the certificate_service_audit.txt of results, ensure it has collected both results.

Output that details Certificate Authority names and possible vulnerability status

Results will offer vulnerable certificate template names and the short reason it is considered vulnerable.

For example, in the extract of results below we can see that SuperInsecureTemplate has been named as a vulnerable template as it can be modified by non-admin users across the domain.

Moreover, the Certificate Authority server named JUMPSEC-McCerty-CA is too permissive in the breadth of users it will allow to make requests.

Results detail where the Certificate Service infrastructure is vulnerable

1.3 Susceptibility audit: “Where am I vulnerable?”

This script offers far more granular information than the above. It leverages the Microsoft official PKI PowerShell modules, with amendments by SpecterOps to audit. JUMPSEC have further amended the usage for easier deployment.

This should be run as a highly privileged user that has full permissions in Active Directory Certificate Service – running as Enterprise Admin is an acceptable shortcut method. It is best to run this on a Certificate Authority server.

POWERSHELL

# Run from CA machine as a high integrity process
# Install necessary features
Get-WindowsCapability -Online -Name “Rsat.*” | where Name -match “CertificateServices|ActiveDIrectory” | Add-WindowsCapability -Online
# Get the zip for PSPKIAudit 
# https://github.com/GhostPack/PSPKIAudit/archive/refs/heads/main.zip
Read-Host -Prompt "Script is from a third party source. Please manually review before execution. Press any key to exit this warning"
# Unzip 
Expand-Archive .\PSPKIAudit-main.zip
# Move to directory.Should be in same directory as .psm1 and .psd1
cd "PSPKIAudit-main\PSPKIAudit-main"
# Prepare the modules
Get-ChildItem -Recurse | Unblock-File -verbose
# Import it. If fails, make sure you’re in the right directory
Import-Module .\PSPKIAudit.psm1 -verbose
# Gather variables
$CAName = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration").Active;
$CAHost = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\$CAName").CAServerName;
Write-host "$CAHost\$CAName"
# Deploy PSPKIAudit. This option will audit misconfigs and report back vulns
Invoke-PKIAudit -CAComputerName $CAHost -CAName $CAName 
#optional final flag -verbose

#To better understand results, see Readme page - https://github.com/GhostPack/PSPKIAudit

First half of results

Second half of results, including how and where misconfigurations have caused insecurity

2. How can organisations protect, detect, and respond to the techniques?

The recommended scripts will have signposted specific machines and Active Directory Certificate Service configurations that are vulnerable and require hardening.

JUMPSEC has summarised and refined SpecterOps’ guidance on how to proactively defend against the imminent threat that Active Directory Certificate Service exposures will present. The time required to implement these controls will vary. To assist remediation activity, JUMPSEC has prioritised activities according to their contributions to hardening the domain and building broader cyber resilience.

Priority	Description	Actions
P1	Enable Certificate Authority logging
P2	Implement defence-in-depth secure architecture	Move to tiered system, with a Root and Subordinate Certificate Authority Evaluate previous Microsoft guidance on centralising a Certificate Authority infrastructure to serve multiple domains/forests Certificate Authority machines must now be treated as Tier 0 assets (like a Domain Controller) Disaster recovery plans should be revised to consider Certificate Authority
P2	Securely configure Certificate Authority settings	Essential Disabling Subject Alternative Name (SANs) Restricting Enrolment Agents Review certificate templates and settings Control Active Directory Certificate Service HTTP endpoints. Turn off, where possible Enhanced protection Control access to templates with over permissive Enhanced Key Usage Control certificate-based authentication Isolate and protect certificate’s private keys
P3	Identify and monitor relevant Event IDs
P3	Plan for a potential Active Directory Certificate Service compromise

2.1 Enable Certificate Authority logging

This is the number one priority, to action immediately.

For various reasons, Active Directory Certificate Service does not enable logs by default, which will prevent your SOC, SIEM, or other monitoring solution from detecting malicious activity. To resolve this, Certificate Authorities’ must have their logs enabled.

To enable logging, you can do this via certutil.exe.

CMD

#The 127 value can enable CA logging. 
certutil.exe -setreg CA\AuditFilter 127

Cmdline returns AuditFilter as active and logging everything

If you would prefer to use a GUI, utilise certsrv.msc in cmd or search in Start. Right-click on the Certificate Authority, properties and then click under the Auditing tab and enable every single event to audit.

GUI alternative to above cmdline

2.2 Implementing defence-in-depth secure architecture

2.2.1 Implementing tiered architecture for Certificate Authorities

Microsoft’s security guidance for Active Directory Certificate Service is to use a tiered architecture of Certificate Authorities. By utilising a subordinate Certificate Authority, an endpoint will not receive a certificate directly from the root Certificate Authority. Microsoft guidance suggests that root Certificate Authorities are air gapped, and never domain-joined. This is to ensure that an adversary cannot compromise the root certificates or private keys.

2.2.2 Subordinate Certificate Authority defences

By segregating the root Certificate Authority server and tiering an inferior subordinate Authority the risk is significantly reduced. However an adversary can still take advantage of the subordinate Authority. Therefore we must harden the defences surrounding a Subordinate Certificate Authority. One method is to set up Certificate Authority Constraints. The issuing rules can restrict many things, the most important being restricting certificates issued with Enhanced Key Usage.

2.2.3 Cross-forest management

Previous guidance advised having a single certificate infrastructure that could serve multiple domains. The latest guidance advises that administrators set up a centralised Active Directory Certificate Service location (a resource forest). This centralised location will provide enrolment services for the domains (account forests). For cross-forest enrolment, administrators can publish the Root Certificate Authority from the centralised resource forest to the account forests and add the enterprise Certificate Authority certificates from the resource forest to specific objects in the account forest (the specific objects being NTAuthCertificates and AIA containers).

2.2.4 Certificate Authority machines are now a Tier 0 Asset

Certificate Authority servers must now be given the same treatment as a Domain Controller. Administrators likely already appreciate the sensitivity that an Authority system requires, but it is worth explicitly categorising the level of risk management that must be applied, often referred to as ‘Tier 0’.

As defined by NCSC, Tier 0 encompassess “the root of trust that other administration relies upon”. If a Tier 0 asset is compromised, an adversary will be able to gain access to the interconnected components that other tiers are built on. The NCSC explicitly names “infrastructure used to generate cryptographic material which other components rely on” as an example of a Tier 0 system related to Active Directory Certificate Service.

A Tier 0 Certificate Authority server must have restricted access for authentication, and ideally it should be protected with trust-based obstacles – for example, Privileged Access Management or (if in Azure Active Directory) Privilege Identity Management. Disaster recovery plans must also consider how a Tier 0 system like a Certificate Authority can be managed in an emergency. Contingency plans should be revised, given that compromise of a Certificate Authority instigates a ‘cascading failure’ of security across an entire organisation. Both Subordinate and Root Certificate Authorities must be given Tier 0 treatment.

2.3 Securely configure Certificate Authority settings

There are ‘quick-wins’ in the defensive strategy for Active Directory Certificate Service. Various settings must be amended on all of the various Certificate Authorities (Root, Subordinate, Enterprise)

2.3.1 Turn off Subjective Alternate Name (SAN)

By default, a Certificate Authority ignores SAN entries in a certificate request. If your environment has enabled SAN extensions it is advised where possible to turn off this optional feature.

To do this, the below PowerShell must be run on every Certificate Authority.

First, you can collect the status of the SAN via PowerShell registry. These may claim they are disabled here, but it’s worth going through the process of disabling SAN nonetheless

POWERSHELL

#Check SAN status via pwsh

$CAName = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration").Active;

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\$CAName\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy" | select-object SubjectAltName* | Format-list

SAN config status

Second, you can disable the SAN extension via certutil.exe

POWERSHELL

# Collect CA Hostname and CA Name, and save as variables.
$CAName = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration").Active;
$CAHost = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\$CAName").CAServerName;
Write-host "$CAHost\$CAName"

# Then,leverage certutil.exe. You can run the below in pwsh to maintain the set variable
& certutil.exe -config "$CAHost\$CAName" -getreg "policy\EditFlags"

# the flag we are looking is -EDITF_ATTRIBUTESUBJECTALTNAME2
# disable the flag if above returns as present

& certutil.exe -config "$CAHost\$CAName" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

EDITF_ATTRIBUTESUBJECTALTNAME2 is the dangerous config setting that we are to disable

SAN can be disabled in other places too. This involves some registry manipulation on every Domain Controller in the environment.

POWERSHELL

#Check if UseSubjectAltName exists. May not show up here
Get-ChildItem -recurse -path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc\"

Get-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Kdc” -Name “UseSubjectAltName”

#disable SAN
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Kdc” -Name “UseSubjectAltName” -Value ‘0’ -verbose

#same for Schannel, reg may be empty as it is not switched on by default
# We are looking for CertificateMappingMethods
 Get-ChildItem -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\" 

#if CertificateMappingMethods is present, change it’s value
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\” -Name “CertificateMappingMethods” -Value ‘1’ -verbose # or -value 2

Registry manipulation to neutralise SAN threat to Domain Controllers

2.3.2 Securing SAN if you choose to keep it

JUMPSEC has discussed why a SAN extension is a liability in an Active Directory Certificate Service environment, and current evidence suggests disabling the extension is appropriate. However, this may not be suitable for some organisations that need SAN extensions.

To configure SAN to reduce the risk, run certtmpl.msc, go to the certificate template, and right-click for properties on certificates that allow domain authentication.

Under Issuance Requirements, enable manager approvals.

GUI method to restrict certificate template enrolment

2.3.3 Restrict enrolment agents

Some administrators may have leveraged enrolment agents. It is important to restrict which principles can act as enrolment agents, and the certificate templates and users that those agents can enrol.

You can get to this setting via certsrv.msc by right-clicking on the Certificate Authority and navigating to > properties, > Enrolment Agents.

GUI method to further restrict enrolment permissions

2.3.4 Restrict Certificate Authority Permissions

It is important to audit the permissions, privileges, and various forms of access existing on a Certificate Authority machine. certsrv.msc can be leveraged again here. On the Certificate Authority right-click on properties, and go into the security tab. Here you will be able to restrict permissions to ensure that only specific administrative groups have full control.

GUI method to harden Certificate Authority permissions and access

2.3.5 Review certificate templates and settings

Existing, published certificate templates should be reviewed and evaluated. If a template isn’t in use, please decommission it on every Certificate Authority.

To show published templates, administrators can issue the following command.

CMD

#Run this command, and scroll down to show enrolled templates
certutil.exe -TCAInfo 

#show template permissions. Very verbose
certutil.exe -v -dsTemplate

Results of certificate templates that exist in your environment

2.3.6 Restricting over permissive EKUs

Enhanced Key Usage (EKUs) is an extension that dictates how a certificate’s public key can be used. Specific OIDs have specific numbers that exist for different purposes (client authentication, server authentication, securing email, for example).

An example of what an EKU looks like.

A template may have an EKU that is over permissive. To collect your EKU OID numbers you can run.

CMD

#show enrolled templates
certutil.exe -TCAInfo

It is easiest to remediate this via Certification Authority Management Tools GUI. Start certsrv.msc, click the dropdown under your Certificate Authority. Right-click under Certificate Template, and then manage. Under the extensions tab, a template may contain All Purpose, Certificate Request Agent, or Null (subordinate Certificate Authority).

It is important to restrict the enrolment of these certificates to privileged groups only which you can administer under the security tab (we have shown how to do this in previous sections).

GUI method to manage certificate templates

Restrict enrolment to particular groups where EKU’s are over permissive.

2.3.7 Control Certificate authentication

Earlier, we discussed the relationship that Active Directory Certificate Service has with Kerberos and authentication. It is prudent to remove all certificates from the NTAuthCertificate object. This assumes however smart card authentication is not in use and the network does not require certificate authentication.

To view the certs in the NTAuthCert container, run the following from a domain-elevated prompt

CMD

#Check if you have any NTAuthCerts. It is entirely possible this will all be empty
certutil.exe -store -? | findstr "CN=NTAuth"

#or this more verbose option
certutil -ds -v NtAuthCertificates

Returns NTAuthCertificate object in LDAP

Verbose details of NTAuthCertificate’s contents

To simplify the output, here is a powershell query that simply returns the cert names that exist in the NTAuthCert store.

POWERSHELL

(Get-ItemProperty -path "HKLM:\Software\Microsoft\EnterpriseCertificates\NTAuth\certificates\*").PsChildname

Simplified results to just collect names of NTAuthCertificate certificates.

Identified certificates can be deleted if you run the following commands from an Enterprise Admin prompt.

CMD

#delete certificates from NTAuth store

certutil.exe -viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=?cACertificate?base?objectclass=certificationAuthority"

Deleting the certificates in the NTAuth container can also be achieved through the GUI.

Start PKIView.msc and ignore any errors. Right-click on Enterprise PKI, and select Manage Active Directory Containers.

Select a particular certificate to be deleted in this container.

GUI method to manage NTAuthCertifcate object

Removing the contents of the container

2.3.8 Isolate and protect Certificate Authority private keys

Protecting private keys is a crucial part of public-key infrastructure control. Data Protection API (DPAPI) is a control that encrypts the key on the endpoint, using the local computer account credentials. DPAPI can protect Certificate Authority private keys at a ‘hardware’ level.

It is possible for an adversary to abuse DPAPI’s backup functionality to retrieve protected objects. It is advised that organisations enable Credential Guard and Trusted Platform Module (TPM), the latter of which cryptographically affirms (to the inquiring Certificate Authority) that the private key is ‘trusted’. TPM must be initialised at a BIOS level.

Credential Guard can then be issued at a registry level with PowerShell:

POWERSHELL

#check your specific use cases. Our guidance may not be compatible with your organisation: https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage

#Enable virtualisation portion of security
new-itemproperty -Path "HKLM:\System\CurrentControlSet\Control\DeviceGuard" -Name "EnableVirtualizationBasedSecurity" -value '1' -PropertyType 'DWORD' -Force
new-itemproperty -Path "HKLM:\System\CurrentControlSet\Control\DeviceGuard" -Name "RequirePlatformSecurityFeatures" -value '3' -PropertyType 'DWORD' -Force

#Enable Cred Guard portion
new-itemproperty -Path "HKLM:\System\CurrentControlSet\Control\LSA" -Name "LsaCfgFlags" -value '1' -PropertyType 'DWORD' -Force 

#Confirm Credential Guard is enabled
Get-ComputerInfo | select DeviceGuardSecurityServicesConfigured

Hardware-level hardening confirmation

2.3.9 Control Active Directory Certificate Service HTTP

Certificate Authority systems can be interacted with through (internal) web pages, hosted by IIS. This web service allows common tasks like requesting, submitting, and retrieving certificates. Adversaries can leverage the web service of Active Directory Certificate Service and relay credentials (NTLM hashes) to achieve exploitation as part of the attack path.

Where possible, the web service of the Certificate Authority system should be turned off.

If the web service is mission critical and will not be disabled, there are steps to secure it.

One option is to enforce HTTPS access.

Another is to disable NTLM authentication in the certificate web service.

Search and start IIS Manager, and pick your Certificate Authority server.
Follow the dropdown from the Certificate Authority server, down to sites and then default web site.
Follow the drop-down again to CertSrv, and click it
On the right hand side, click into authentication
Right-click on Windows Authentication, and select Providers
Remove the default NTLM and Negotiate Providers.
Add Negotiate:Kerberos as a provider

Finding IIS manager

Choosing your Certificate Authority’s CertSrv

Click on the Authentication icon

Under Windows Auth, click on Providers

Harden authentication mechanisms

2.4 Identify and monitor relevant Event IDs

Once Active Directory Certificate Service is exploited in the wild, the security community will have better guidance for which events to monitor and how, to facilitate precise and reliable detection of malicious activity. For now, these event IDs will enable noise to be filtered out and normal activity to be baselined.

Complexity	Description	Actions
Low	Certificate Template – any activity should be treated as suspicious	4989: Brand new certificate template loaded. 4899: Existing certificate template has been modified. This can catch an adversaries' exploitation attempts as templates will rarely be legitimately modified. This event can fail to log and so cannot be exclusively relied upon. 4900: Security permissions of a template have been changed AND template has been enrolled.
Low	Certificate Authority Events – any unscheduled activity should be investigated	4882: Spawned when security permissions modified for the Certificate Service. 4890: Spawned when certificate manager settings modified for the Certificate Service. 4892: Spawned when any property of the Certificate Service is modified. 4876 & 4877: Spawned from Certificate Authority when backup has started and finished, respectively. 5601, 5061, &5059: Child-events of above backup. Indicates interaction with key storage provider.
Low	Certificate Authority Events - requests generate a lot of noise, but baselining will allow abnormal to stand out.	4886: Spawned from the Certificate Authority when it receives a certificate request 4887: A certificate request was approved, and a certificate is issued by the Certificate Authority. 4889: A certificate request has not yet been approved. Decision pending on administrator. 4888: A certificate request has been denied. This may note adversaries’ failed attempts.
High	Certificate Authentications - to get beyond the noise, these Kerberos and Schannel must be filtered by the contents of the message fields.	4768:Spawned from a Domain Controller when a TGT is requested. If certificate-based authentication, the event’s sub-fields will contain “certificate Information”. 4769:For Schannel, spawned from a Domain Controller when service ticket requested. 4889: A certificate request has not yet been approved. Decision pending on administrator. 4648:Explicit credentials log. Will contain user identity attached with certificate.

2.5 Plan for a potential compromise

Incident response and disaster recovery plans must assume that an adversary could weaponise all certificates across the Active Directory, and therefore would have unending, unlimited persistence to the network.

Should a Certificate Authority machine ever be compromised, the entire Active Directory Certificate Service infrastructure can no longer be trusted. The entire infrastructure must be taken offline; every existing certificate object (certificate, certificate template, private keys) must be scrubbed from existence.

An under-considered factor is the importance of account privileges during an incident investigation. Ensuring that an account is appropriately permissioned to remove certificates is vital to ensure readiness to respond in an incident scenario.

As mentioned previously, disaster recovery plans must also consider how a Tier 0 system like a Certificate Authority can be managed in an emergency. Contingency plans should be revised, given that compromise of a Certificate Authority instigates a ‘cascading failure’ of security across an entire organisation. Both Subordinate and Root Certificate Authorities must be given Tier 0 treatment.

It is tempting to utilise Enterprise Administrator in an emergency to give permissions quickly. However an adversary may be able to steal credentials of the Enterprise Administrator if used during an incident. Therefore, an inferior, burnable account should be used – preferably with full permissions over Active Directory Certificate Service but nothing else across the Active Directory. This account should be decommissioned afterwards.

Microsoft detail greater granularity of what to do, step-by-step, to restore trust in Active Directory Certificate Service after a compromise here.

3. Next steps

JUMPSEC encourages organisations to ensure that their Active Directory configuration is suitably robust ahead of the likely increase in adversarial attention to Active Directory in the face of SpecterOps’ research.

Broader configuration issues outside of Active Directory Certificate Service are also likely to surface with this additional scrutiny. Therefore, organisations that use this research as the catalyst for a broader review of the resilience of their Active Directory environment will be best prepared for what comes next.

JUMPSEC advises that all organisations using Active Directory Certificate Service look to implement the remediations advised in this document.

The guidance provided is designed to be implemented without third-party assistance; however, should you require additional advice or support, please reach out to us using the contact form on the webpage.

This is a live article and as such will be continually updated as the recommendations are refined and improved as new information surfaces. Follow JUMPSEC’s live guidance @JumpsecLabs.

Article written by Dray Agha, Security Researcher | Any questions, comments, or criticisms please drop me a line on:

Twitter, Github, or Email