How to Minimize Your Active Directory Attack Surface

When newly installed, Active Directory’s (AD) default configuration is designed to be easy to use. As a result, attackers can exploit AD to take over your entire network with relative ease. Here’s what you can do to further protect your organization by reducing your Active Directory attack surface.

This article is sponsored by Semperis.

Securing beyond the default settings to reduce Active Directory attack surface

Active Directory is a Microsoft Windows directory service that was first introduced in Windows 2000 towards the end of 1999. It allows IT administrators to manage users, computers, printers, data, and other resources of an organization’s overall network.

However, because of its popularity and integration throughout the enterprise, it is a prime target for attackers, threat actors, and cybercriminals. If a bad guy can gain access to your AD, they could potentially access all of your user accounts, applications, databases, and other business information.

Microsoft typically touts how they’ve made its ‘default, out-of-box’ configurations more secure over the years, especially for reducing Active Directory attack surface. So why should you make your fresh install of AD more secure? Because hackers can utilize the out-of-the-box AD defaults and discover easily exploitable ingresses in a standard configuration. Therefore, it is vital to review your AD configuration and update it to match your organization’s security and compliance guidelines.

CISA / NSA issues guidance on common cybersecurity misconfigurations

CISA and the NSA have issued guidance on addressing the most common cybersecurity misconfiguration in large government organizations. These misconfigurations impact many organizations and pose systemic weaknesses. This includes most of the top configuration issues with Windows Server and, you guessed it, AD.

The guidance provides mitigations and recommendations for IT pros, software developers, and software manufacturers to address AD misconfigurations. The guidance aligns with the CISA and NIST-developed Cross-Sector Cybersecurity Performance Goals (CPGs) and the secure-by-design and secure-by-default development principles.

The most important recommendation is that organizations test and validate their security controls and programs against the most common threat behaviors mapped to a specific framework – the MITRE ATT&CK Enterprise framework.

Consider Server Core installation option for DCs to reduce your Active Directory attack surface

One of the most effective methods to reduce your Active Directory attack surface is to install Windows Server using the Server Core option during Windows Setup. Server Core includes only a command-line interface with an extremely limited GUI. Removing the entire Desktop Experience from Windows Server makes it more secure – there are countless ingress points that will no longer exist.

IT pros either log in to the server and use the command line or PowerShell interfaces, or they can use remote access tools to manage and configure the server. The Remote Server Administration Tools (RSAT) and Windows Admin Center are the best tools when it comes to being efficient and not logging in to your domain controllers (DCs) at all.

Let me show you an example of the Windows Admin Center. The image below is the main page showing the servers I have set up for management.

Let me click on the ‘ws16-fs01-core.reinders.local‘ server.

This shows you all the top-level details. Although WS16-FS01-Core is currently being used as a fileserver, I can add the AD Domain Services role to the server to make it function as a DC using the ‘Roles & Features‘ link on the left.

This process will let you remotely install the AD DS role and join it to your AD domain or create a new domain or child domain.

Again, using the Server Core install option for Windows Server reduces your Active Directory attack surface. And, as a reminder, Microsoft recommends you install the Server Core option unless you need the desktop environment.

Apply Microsoft’s recommended domain controller security baselines to reduce Active Directory attack surface

Microsoft provides a good deal of documentation on how to secure your domain controllers. The high-level topics include physical security, current operating systems, and specific security configuration changes you can make. Let me elaborate a bit on these.

Physical security of Active Directory domain controllers

Regarding physical security, the most stringent controls are to keep physical servers running the domain controller role in isolated and locked cabinets in your data centers. I will cover the virtual server options in the next topic below.

Running an up-to-date version of Windows Server

Microsoft recommends that you use the latest version of Windows Server to run the domain controller (AD DS) role. Today, that is Windows Server 2022. And a reminder – Windows Server 2012 and Windows Server 2012 R2 are now out of support. It is critical that you use Extended Security Updates (ESUs) if you run those versions of Windows Server for Active Directory.

Baseline security configurations

You can use Group Policy Objects (GPOs) to secure more of the ‘software-based’ aspects of security. Restricting Remote Desktop Protocol (RDP) access to your DCs is vital. Blocking Internet access on your domain controllers is also very important.

During an Active Directory security assessment, the use of Internet Explorer on DCs by IT Pros to browse the Internet was found in the thousands. Browsing the Internet on an infected intranet from one of the most powerful computers in a Windows infrastructure, using a highly privileged domain account, presents an extraordinary risk to an organization’s security. In short, don’t do it. Implement GPOs to restrict web browsers from launching on DCs, or if you must use a browser due to application requirements, update to Microsoft Edge and restrict internet access.

Enable virtualization-based security

Another method you can use to secure your (virtual) Active Directory environment is to enable virtualization-based security (VBS). Microsoft Virtualization-Based Security (VBS) is a security feature that uses hardware virtualization and the Windows hypervisor (Hyper-V) to create an isolated virtual environment that becomes the be-all, end-all source of trust of the OS.

This isolated environment is protected from the rest of the operating system, including the kernel, and it is used to host security solutions such as Credential Guard, Device Guard, and Hypervisor-Protected Code Integrity (HVCI).

Here I am showing you the Group Policies that you can use to create a new GPO and link it to your ‘Domain Controllers’ Active Directory Organizational Unit (OU). Device Guard uses VBS to verify that only signed drivers can be loaded. This helps to prevent malware from loading unsigned drivers that could be used to compromise the system.

Hypervisor-Protected Code Integrity (HVCI) uses VBS to prevent malware from injecting malicious code into the kernel. This helps to protect the Windows kernel from attack and makes it more complicated for unwanted code to infect or compromise the system.

Domain controller patch management

Although it may seem counterintuitive, you should patch domain controllers and other critical infrastructure components separately from your general Windows infrastructure. By separating patch and systems management for domain controllers from the general population, you can reduce the amount of software installed on domain controllers, in addition to tightly controlling their management.

Also, don’t install Windows patches directly on domain controllers. Use an enterprise patch management solution, like Windows Server Update Services (WSUS) to push patches. The less you do ‘on’ your DCs, the better.

What is KRBTGT and why you should reset the account password

The KRBTGT account is a default disabled account in Active Directory that is created when a new domain is created. It is a service account for the Key Distribution Center (KDC) service. The KRBTGT account is used in conjunction with the Kerberos authentication scheme to sign all Kerberos tickets for validation.

I recommend you reset the password of the KRBTGT account periodically to prevent attackers from using compromised passwords to create Kerberos tickets and gain unauthorized access to your domain. The reset process should be performed on all writable domain controllers in the domain every month or quarter. Semperis’ own Jorge De Almeida Pinto maintains a popular script to minimize the effort needed to reset the KRBTGT password.

With Kerberos, attackers stealing a user password can potentially use it to further spread through the network – but with the NTLM hash of the KRBTGT account,  they will have the ability to forge new tickets. This will enable them to execute a Kerberos Golden Ticket attack.

Managing privileged Active Directory groups: Enterprise Admins, Domain Admins, and Schema Admins

The Enterprise Admins, Domain Admins, and Schema Admins groups in Active Directory are extremely powerful. Administrative accounts in these groups need to be carefully monitored. A user account in these groups can perform almost any task in Active Directory including creating a child domain, modifying the security settings via Group Policy, and many other scary items. I highly recommend restricting the membership of these groups via Group Policy. Let me show you how.

• In Group Policy Management, create a new GPO at your Domain Controllers container (Organizational Unit, or OU).

• Browse to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Restricted Groups.

• Right-click in the empty white space on the right and click Add Group…

• Click the Browse button and find ‘Enterprise Admins‘.

In this instance, we are done. As you can see, there are no members – this is precisely how yours should be, too. Every 15 minutes on all domain controllers in your domain, this group will be cleaned out, automatically – do the same for Schema Admins and potentially Domain Admins.

Monitoring protected accounts and groups in Active Directory: AdminSDHolder and SDProp

Thankfully Active Directory offers built-in auditing capabilities like ‘AdminSDHolder’ and ‘SDProp’ to assist you in monitoring protected accounts and groups. AdminSDHolder and its AD worker code are used by DCs to protect high-privilege accounts from modification.

Let me show you again how we can utilize a Group Policy Object (GPO) to handle this contingency.

1. Create a new GPO for your Domain Controllers OU and browse to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies.
2. Enable the following audit policies:
   1. Audit Security Group Management
   2. Audit Directory Service Access
3. Right-click Audit Security Group Management and click Properties.
4. Select Success and Failure for these items:
   1. Security Group Management
   2. Distribution Group Management
5. Right-click Audit Directory Service Access and click Properties.
6. Select Success and Failure for:
   1. Detailed Directory Service Replication.
   2. Directory Service Changes.

And you are done.

Scan for common Active Directory misconfiguration

There are several tools available to scan AD for security misconfigurations that could increase your Active Directory attack surface. A popular tool is called Purple Knight. It’s a security assessment tool that can help identify and explain how to fix security issues and vulnerabilities in Active Directory.

Purple Knight, along with Forest Druid, can help organizations identify the following issues with AD, Azure AD, and Okta using 150+ security indicators:

• AD, Azure AD (now called Entra ID), and Okta security audit
• Indicators of exposure and indicators of compromise
• Fix AD, Azure AD (now Entra ID), and Okta security threats that attackers can exploit.
• AD security posture over time.

Adopt a tiered-administration model

A tiered administration model is a recommended method to protect your critical AD user accounts. This model involves categorizing your IT assets into tiers based on their severity, criticality, and security boundaries.

As an example, Tier 0 is designated as the highest level including privileged accounts and groups, domain controllers, and other domains that have the most reach into your environment.

Tier 1 includes C-level user accounts and accounts that have administrative access to servers that are joined to the domain (for example, application service accounts). Tier 2 covers the remaining users in your organization. Adopting this method to segregate user accounts reduces the risk of unauthorized logins by limiting access between tiers. For instance, only accounts in Tier 0 could connect to a domain controller.

Following this method will also greatly assist you in your compliance requirements and it will increase your overall score during security audits.

Conclusion

Reducing the Active Directory attack surface is critical to protect your organization’s sensitive data and systems from unauthorized access. To achieve this, it’s important to adopt a ‘best practices’, tried and true, dynamic AD security strategy that goes beyond the default settings.

Best practices include reviewing and amending default security settings, monitoring privileged accounts, implementing least privilege access, and auditing and monitoring Active Directory changes. Additionally, it’s recommended to use a tiered administration model to protect privileged AD credentials and limit access to lower-tiered staff.

Finally, you can scan for common AD misconfigurations using Purple Knight, a security assessment scanner that can help you identify and fix security issues in AD.