Trust Issues

In addition to the well-known dangerous misconfigurations of AD, a number of attack vectors have begun to be addressed in recent years that target AD DS but use a different AD – AD Certificate Services (AD CS; Microsoft's implementation of an enterprise PKI). The first systematic discussion of AD CS vulnerabilities that lead to the compromise of AD DS is mentioned in an article [3] that references a whitepaper by Will Schroeder and Lee Christensen from 2021. The attack techniques described there have since been refined and extended multiple times and should make clear to every security admin the serious potential for trouble. Before you decide on the optimal PKI strategy for your organization, you need to be aware of the PKI-based attack vectors and the techniques you can use to mitigate the effect of enterprise PKI on your AD security.

Every PKI is based on trust relationships. Threats from the certificate services are based on two ways of abusing these relationships: (1) Kerberos in Windows accepting certificates as a valid authentication method, and (2) certificate types not directly ensuring successful Kerberos authentication, but still enabling communication relationships. Both smart cards and Windows Hello are based on the first mechanism, and the sub-protocol used is Public Key Cryptography for Initial Authentication (PKINIT).

That said, the Key Distribution Center (KDC) on a DC does not trust every certificate authority (CA) that can be traced back to the trusted roots of the DC for the validation of smart card certificates. Instead, it uses a special NTAuth certificate store (Figure 1). An enterprise CA automatically registers in the store at install time, irrespective of whether or not the organization intends to issue authentication-capable certificates from this PKI. In other words, attacks on a root CA can point an attacker to certificates that are valid for Kerberos and issued to highly privileged identities such as admin accounts, DCs, or even entire domains (which means that even unidirectional trust relationships can be compromised).

Figure 1: Kerberos only accepts certificates for authentication whose issuing CA can be found in the NTAuth container.

The second type of threat is not as serious but is more difficult to handle. These scenarios primarily involve server certificates that allow an attacker to spoof an HTTPS page without leading to certificate messages in the applications. Of course, computer certificates that are valid for 802.1X authentication can also give the attacker access to networks on which the targets reside.

Both problems are exacerbated because the Microsoft PKI makes it very easy to create a situation in which a user who is not particularly highly privileged can request and receive certificate types that are of interest to attackers and can also freely define the subject name of these certificates. This scenario would enable the attacker to issue a smart card certificate for the domain admin and proceed to hijack the domain. If the attacker's target lies behind a web portal that requires the password of an authorized user for entry, the attacker could have an HTTPS certificate issued for the corresponding URL and then spoof DNS for direct user access to a web server that they control.

Operating PKI the Right Way

For a secure PKI design (which can also involve getting rid of your internal PKI), defining who can apply for certificates, which procedures they can use to do so, and to what extent the applicants can be trusted is important:

• If you do not use certificate-based authentication in Kerberos (strongly recommended), remove your PKI's certificates from the NTAuth container. You can add the certificates again later if needed.
• Treat PKI as a Tier 0 system and regulate admin access accordingly. Incidentally, this applies regardless of whether you use the Microsoft PKI (AD CS) or another product.
• In a multilevel PKI, all CAs need to be assigned to Tier 0.
• Use CA restrictions to channel how certificates are issued. If required, provide separate CAs for smart card certificates and other types, such as web server certificates.
• Operating multiple PKI trees with separate root CAs for different applications is also a useful option.
• Do not install PKI web services just because you think you might need them. If you do need them, configure them in a way that is fit for their purposes. Nobody should need the outdated Certificate Services Web Enrollment service today because it is based on ActiveX controls.
• Only Tier 0 administrators should be able to request smart card certificates. If a smart card is required for lower tier admins or normal users, use an enrollment agent instead of giving users permission to request these certificates. If you have no other option, make sure an administrator has to approve the smart card certificates, regardless of who the original requester is.
• Be sure to use the TameMyCerts policy module with your Microsoft PKI, so you will be able to define binding rules on the addresses and identities that your certificates can contain.
• Use deterministic Online Certificate Status Protocol (OCSP) configurations [4] instead of a simple certificate revocation list (CRL), at least for highly sensitive certificates. In this way, certificates issued by the attacker from within the PKI can still be valid, but you can at least catch the case in which the attacker has obtained the private key of an issuing CA and signs certificates without the PKI.

If your organization does not yet have a clearly formulated strategy for dealing with certificates, a safer alternative is not to operate an internal PKI and to purchase HTTPS certificates for web applications from a public certification authority. You will need either a publicly resolvable domain name (which also belongs to you) or a split-horizon DNS configuration that resolves public names to private IP addresses when internal DNS servers are queried.

Manage Configurations Cleanly

Many of the measures that will make your AD significantly more secure are not rooted in AD itself, but in the infrastructure that surrounds it, including Windows servers with the DC role. Because the attacker's first contact with the environment is either via an endpoint or an externally published application server, you can already significantly reduce your environment's attack surface by deploying the following on these machines:

• Up-to-date, managed and intelligent anti-malware
• Process whitelisting – ideally Windows Defender Application Control or at least AppLocker
• Restricted administrative permissions to prevent regular interactive logins with admin privileges and Internet access from within administrative sessions
• Credential Guard

Firewalls help make lateral movement and escalation more difficult. You also need to configure them with a whitelist – only what is explicitly permitted is possible. You can set up initial obstacles with some very simple firewall rules such that:

• Clients are not allowed to communicate with each other, irrespective of the protocol, unless you are one of the few organizations that have integrated Windows Update Delivery Optimization into your management. In combination with the Local Administrator Password Solution (LAPS), this setup virtually eliminates lateral movement.
• Access to management networks for hardware and virtualization management, network devices, storage, and climate and power control is only permitted from selected devices, but never from client or printer networks. If you want to be on the safe side, set up a jump host in the network segments and secure access to it with MFA – in the simplest case with a remote desktop gateway.
• Management protocols (e.g., Windows Remote Management, WinRM, and Windows Management Instrumentation,WMI, and now increasingly also SSH on infrastructure servers) are only accessible from a small number of explicitly specified management and monitoring machines.

When choosing monitoring and management applications, rely on agent-based products whose agents establish connections from the managed devices to the management system and not vice versa. The fewer incoming communication relationships required for your systems to work correctly, the better.

Define binding rules on who can edit group policies and, above all, who can link them to OUs with highly privileged objects (DCs, Tier 0 admins), domains, and AD sites. Unfortunately, the Group Policy Management console that comes with AD is not very cooperative if you try to restrict the permissions too far. Consider either placing all group policy management in Tier 0 or using a third-party product for Group Policy Object (GPO) management that allows effective delegation.

Use BitLocker on DCs wherever you have a serious risk of hard disks being stolen – whether a physical server or a virtual disk image on centralized storage. Of course, BitLocker only has the potential to increase the security of your DCs if the DC is stolen in this way and does not automatically unlock itself when booting up, which in your day-to-day admin work, rules out unattended restarts of your DCs. You might want to consider using the BitLocker Network Unlock key protector for this reason.

Disable all unnecessary services on highly privileged systems. Unfortunately, Microsoft no longer provides its own recommendations and has not done so since Server 2019; therefore, you have to rely on your own experience, information from the community, and trial and error. In any case, you will want to deactivate the print spooler services on your Tier 0 systems permanently (Figure 2). If you set up shared printers in your AD, you will find that the print queue objects are then no longer deleted automatically. However, this is a very small price to pay for an important security feature.

Figure 2: Group Policy Preferences is the best option for deactivating services.

Even after you have created and rolled out a configuration for both your AD forest and the machines in it, your work is not done. From now on you need to monitor the status continuously to detect and remedy deviations from the defined configuration (configuration drift) at an early stage. Depending on which AD and configuration management technologies are established in your organization, you can rely on monitoring, Desired State Configuration, infrastructure-as-code, or other techniques. The important thing is that you identify deviations and react to them.