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.
Basic Certificate Authority information
#Display verbose CA info. Takes a minute Certutil.exe -tcainfo
Verbose Certificate Authority information
# 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.
#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
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.
# 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.
|P1||Enable Certificate Authority logging|
|P2||Implement defence-in-depth secure architecture||
|P2||Securely configure Certificate Authority settings||
|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.
#The 127 value can enable CA logging. certutil.exe -setreg CA\AuditFilter 127
Cmdline returns AuditFilter as active and logging everything
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
#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
# 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.
#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.
#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.
#show enrolled templates certutil.exe -TCAInfo
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
#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
(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.
#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:
#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.
|Low||Certificate Template – any activity should be treated as suspicious||
|Low||Certificate Authority Events – any unscheduled activity should be investigated||
|Low||Certificate Authority Events - requests generate a lot of noise, but baselining will allow abnormal to stand out.||
|High||Certificate Authentications - to get beyond the noise, these Kerberos and Schannel must be filtered by the contents of the message fields.||
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: