Preventing “Certified Pre-Owned” Attacks, using RPC-Firewall, LDAP-Firewall and Network Segmentation

Certified Pre-Owned Attacks 

Active Directory Certificate Services (AD CS) is a critical Windows Server role that manages the Public Key Infrastructure (PKI) for issuing and maintaining digital certificates within an organization's domain environment. This system enables organizations to encrypt data, digitally sign files, and authenticate the identities of users and devices using certificates. The AD CS (among other functions) is the entity in charge of issuing signed certificates using a secret private key. These keys are used in a wide range of security applications, such as message signing, encryption and authentication. 

If an attacker finds a way to forge certificates, they can use this power to become practically any account in the domain and create a whole range of persistence mechanisms. Unfortunately, such attacks do exist, and  were first widely publicized by the thorough work of @harmj0y and @tifkin_ in their paper: Certified Pre-Owned (Abusing Active Directory Certificate Services). Because of the large number of attack vectors described in the paper, the following identifiers were given to make it easier to organize and refer to these attacks:  

• THEFT#1..5 Techniques for dumping user / machine certificates and even NTLM hashes. These certificates can be used for authentication as the “stolen” account. 
• PERSIST#1..3 Maintaining persistence via requested certificates which can be used for authentication. 
• ESC#1..8 Techniques for requesting certificates that may grant more privileges to the requesting account. 
• DPERSIST#1..3 Forging certificates that allow persistence. 

The Problem with Existing Mitigations 

Unfortunately, mitigating or even detecting such attacks is far from trivial. The SpecterOps team also published a list of suggested prevention and detection mechanisms in their paper: 

While all of the above are great suggestions, they are far from simple to implement. For example, PREVENT3 requires someone to enumerate all certificates and “…remove unused templates from publication on every CA in the environment to lower the attack surface and opportunities for accidental misconfiguration." Another example is PREVENT4 which requires the user to manually change a setting for each certificate template that allows SAN specification. If you’re someone who’s not intimately familiar with Certificate Authorities (CAs), you may find these tasks daunting. Not to mention that, over time, CA configurations could change and new CA vulnerabilities could pop up – how would you address those?  

Mitigating CA Attacks with Prevention Engineering  

Prevention Engineering is a security approach we champion at Zero Networks. We prioritize prevention mechanisms that protect workloads from attacks over the network (as protecting an already compromised workload is a losing endeavor) and ignore detection approaches that create alert fatigue. In simple terms, if you can’t stop an attack, it may not be worth even investing in detection logic.  

When we apply this approach to AD CS attacks, we end up with the conclusion that we shouldn’t focus on THEFT#1..5 attacks, as they are very had to prevent, and not even trivial to detect, as those attacks:  

1. Don’t happen over the network, instead they occur locally inside an already compromised workload. 
2. Require an intrusive agent on every workload, which is hard to deploy and maintain in large environments.  
3. An agent will need to perform a complicated inspection of cryptographic APIs in real time and block these API calls if they are part of a THEFT attack.  

These requirements are a big ask for any organization and can prove very challenging to implement. Identifying potentially malicious API calls is a complicated cat-and-mouse game, in which defenders have the disadvantage, especially when bypassing EDRs is a global pen-tester sport.   

However, the remaining attacks can (and should!) be prevented. Once we understand the protocols used for each attack, it's clear that there are a limited number of protocols used to interact with the CA service, and each can be mitigated with the appropriate prevention mechanism:  
 

Preventions in Practice 

The number of prevention and detection mechanisms in the published paper is 14. However, there are only 3 prevention mechanisms required to address these known attacks (and potentially even much more, unknown attacks). Let us examine how to apply each of these preventions and demonstrate how attacks are being stopped by each prevention mechanism. 

1. Network Segmentation 

Zero Networks Network Segmentation can be used to block, or even to MFA the web interface ports. This ensures only sanctioned users are allowed to interact with the certificate enrollment service. This prevents rogue clients from trying to access the web interface, as it is blocked, and they can’t pass the MFA challenge even if they steal sanctioned users’ credentials! 

Even when performing NTLM relay attacks against the CA’s HTTP interface, the MFA rule will prevent an attacker from completing the relay attack, as described in the following diagram: 

1. Attacker forces / hijacks NTLM authentication flow 
2. Attacker replays NTLM authentication against CA HTTP port: this gets blocked 
3. MFA challenge appears to the attacker (which they can’t bypass) 

In the below demo, we can see how segmented CA server with MFA protection for its HTTP/S ports, thwarts an attack, as the attacker – even if with possession of an administrative account – cannot pass the MFA challenge:  

2. RPC Firewall 

RPC stands for Remote Procedure Call. It is an underlying mechanism utilized by many windows services, for both local and remote communications. Because RPC must be accessible on the most sensitive servers, such as Domain Controllers, it exposes a huge number of RPC functions for attacks and potential vulnerabilities. To address RPC attacks we created the RPC Firewall, which is available as an open-source package or as an add-on in our product (this version is a bit more advanced and avialable only to Zero customers). 

In the case of certificate services, remote DCOM or RPC calls can be used to perform various certificate related operations. As most organizations don’t use these RPC interfaces at all, or only should enable certificate operations from sanctioned hosts, the RPC Firewall can be used to block any CA RPC / DCOM based attack.  

In the below demo, we see how using tools like certreq, certsrv.msc, and Certify, are all blocked by the RPC-Firewall: