SpecterOps recently released an offensive security research paper that details techniques enabling an adversary to abuse insecure functionality in Active Directory Certificate Service.
SpecterOps reports that abusing the legitimate functionality of Active Directory Certificate Service will allow an adversary to forge the elements of a certificate to authenticate as any user or administrator in Active Directory.
The techniques grant an attacker with prior access to the internal network a trivial means of bypassing domain controls and otherwise secure configurations to achieve administrative control of the environment. This presents a trivial method of achieving a full-scale domain compromise, a catastrophic event for any organisation, whereby an adversary could theoretically achieve unending, unlimited persistence to the network. This would be disastrous for any victim, granting an attacker the ability to freely conduct broader attacks against critical systems and information, and require the full-scale rebuild of any affected domains to recover from the compromise.
In response, JUMPSEC released defensive guidance translating the defensive application of this offensive research, to pre-emptively defend our clients from these techniques before exploitation is observed in the wild. To do this, we utilised our Active Directory lab and attempted to harden the service to reduce the risk of compromise and limit the ability for an attacker to cause harm.
JUMPSEC has examined SpecterOps’ research and compiled guidance to prepare the defences and harden the configurations of an environment before adversaries have the opportunity for exploitation. We are extremely grateful to the research published by SpecterOps, and as always, we are a firm supporter of offensive security research and its role in improving the security baseline for organisations.
Why is this development so significant?
Active Directory is the primary repository responsible for authentication and authorisation services for users and devices. This is achieved by creating a series of user roles and associated permissions that govern the actions that a given user account can perform on a specific system. It is often integrated with other single sign-on solutions to extend its reach to services running on non-Microsoft platforms.
Active Directory is frequently abused by attackers due to its highly pivotal nature. Its functionality has grown significantly over time, managing a widening array of services and corresponding user roles, permissions, and accounts, while its implementation with Windows has grown in complexity. Therefore, the risk of misconfigurations, insecure practices, or unintended interactions rendering the service vulnerable to compromise is significantly increased due to the broad attack surface.
The vulnerable system is Active Directory Certificate Service, Microsoft’s implementation of public-key infrastructure (PKI) that integrates with existing Active Directory implementations, underpinning the cryptography in encrypting file systems, digital signatures, user authentication, and more. Since Windows 2000, the Certificate Service has existed as an optional, configurable element of an Active Directory deployment. While the service is not shipped as default, it is usually enabled by administrators.
Research has demonstrated that most Certificate Services are set up with insecure configurations. This is not a consequence of technical inability but a knowledge gap: many administrators of Active Directory Certificate Service did not and do not realise that adjusting a configuration can create a security risk that an adversary can take advantage of in a live client environment.
SpecterOps have evidenced that Certificate Authorities are poor arbiters because they can be forced to consider additional evidence that may be tampered with: Subject Alternate Names (SAN).
A SAN is an optional extension for a certificate. It allows additional identities to be associated with the certificate. In the Windows environment, a SAN is an extension to the certificate. It can convey a lot of information and of particular interest is the ability for the SAN to convey a user principal name. This is a legitimate function of SAN and certificates. SpecterOps have highlighted that the SAN is incapable of security sanitisation and that an adversary can arbitrarily ‘add’ an identity here.
An adversary can poison the SAN extension by suppling a Domain Administrator’s details in that SAN field which gets bundled in the certificate request. In return, the Certificate Authority server receives this request and judges it as authentic. The adversary is then gifted a signed certificate, allowing them to authenticate across the Active Directory as a Domain Administrator.
The techniques researched by SpecterOps are unique in that they are more likely to punish organisations that have looked to implement more security-conscious configurations of Active Directory beyond a default deployment. As a result, many less mature organisations will not have enabled the Certificate Service, which typically facilitates a more robust approach to authentication and trust.
What is the risk?
The techniques grant an attacker with prior access to the internal network a trivial means of bypassing domain controls and otherwise secure configurations to achieve administrative control of the environment, enabling further malicious activities to be launched against the network from this privileged position.
Adversary breaches the perimeter and compromises a low-privilege user
Adversary utilises a modified NTLM rely to access the web management page for AD CS
A poisoned certificate request is sent and returned, with a SAN extension with an attached identity for high-privileged user
The signed certificate can then be leveraged by Rubeus
Rubeus is able to weaponise this forged, signed certificate to gain ticket-granting-ticket (TGT) for Kerberos
The TGT can be leveraged in Mimikatz to impersonate and gain command execution as Domain Administrator
Figure: Path an adversary can take to exploit the Certificate Service
The new techniques introduce a reliable method of compromising robust Active Directory configurations which have been hardened against typical methods of compromise.
The visual below details a potential adversarial approach to domain compromise, highlighting two common attack paths alongside the newer explored Active Directory Certificate Service attack. The paths have been defined at a high level and replicate offensive tactics, techniques and procedures observed in the wild.
Figure: Example paths an adversary can take to a full domain compromise
Whilst Kerberos-based attacks are the more prevalent type of attack encountered in this context, these typically require a number of pre-requisite criteria to be met. They can be effectively countered through the best practice configuration of accounts to restrict service and user access to the minimum level of access to carry out their task, and the application of strong encryption types.
In contrast, the new technique presents a trivial method for an attacker to compromise previously hardened environments that are thought to be secure, posing a particular risk to organisations who have previously invested in hardening their Active Directory environment with additional security controls. Adversaries leveraging other misconfigurations or vulnerabilities who can gain access to the internal network can trivially achieve domain compromise against Active Directory environments with the Certificate Service enabled.
Figure: JUMPSEC’s lab was configured with a decade-long certificate.
What is the impact of a successful attack?
Resilient domain control
Stealing certificates offers an adversary persistence beyond password reset or Kerberos ticket changes. This is a total compromise from which it is impossible to recover without a complete rebuild of the Active Directory environment.
01
Indefinite persistence
An adversary who steals the Certificate Authority’s certificate gains a unique capability: they will have a valid persistence method for as long as the certificate is valid. For administrative purposes, certificates are usually signed to have expiration dates long into the future. This means that, for example, a certificate that doesn’t expire until 2031 will allow an adversary certificate-based persistence to your Active Directory until 2031.
02
Trivial lateral movement and privilege escalation
An attacker can achieve full domain compromise in just a few steps, with greater reliability and fewer dependencies, compared to pre-existing techniques.
03
Total Forest compromise
The attack can quickly and easily scale to complete compromise of Active Directory, across all domains that are not segregated. In some instances, an adversary does not need to do anything ‘extra’ to achieve inter-domain compromise.
04
Previous Microsoft documentation guided administrators to set up a centralised certificate distributor. This architectural guidance once served to aid administrators, as maintaining a ‘singular’ public-key infrastructure across an organisation was easier. However, this certificate architecture now aids adversaries, not administrators. Centralised Certificate Authority machine(s) may have been established as intentional bridges across discrete domains. A compromised certificate and private key could give the adversary total control over all domains in the forest.
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.
To assist remediation activity, JUMPSEC has prioritised activities according to their contributions to hardening the domain and building broader cyber resilience.
In-depth implementation guidance is provided in our Labs article.
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
P3
Securely configure Certificate Authority settings
- 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
P4
Identify and monitor relevant Event IDs
P5
Plan for a potential Active Directory Certificate Service compromise
Organisation-wide initiatives to reduce the risk posed by compromise
It is vital that organisations prepare for a potential compromise, given the severity of the risk. 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.
Organisations should review their incident readiness and response plans to ensure they will be effective in the context of a full Active Directory compromise, to minimise impact and accelerate recovery.
Microsoft detail greater granularity of what to do, step-by-step, to restore trust in Active Directory Certificate Service after a compromise here.