Huy Kha | Senior Identity & Security Architect

Active Directory (AD) is still at the center of most enterprise environments, and attackers know it. As threats increasingly target identity, AD continues to be a key point of entry and privilege escalation. The problem is, many of the same misconfigurations and oversights show up across different organizations, no matter the size or industry.

After reviewing findings from multiple Active Directory Security Assessments (ADSAs) in 2025, the Semperis Identity Forensics and Incident Response (IFIR) team has seen a clear pattern. Certain risks just keep coming up. Some are well known but go unaddressed, while others are easy to miss without the right tools or visibility.

In this post, I’ll walk through the 10 most common AD risks found in real environments and explain what they are, why they matter, and how attackers take advantage of them.

Risk 1: Tier 0 attack paths opened by misconfigured permissions

During ADSA engagements, one of the most dangerous misconfigurations the IFIR team has observed is when accounts or groups end up with DCSync rights through indirect permissions. This doesn’t mean someone directly assigned the permissions. Instead, for example, an unprivileged account might be part of a group that has full control rights over a privileged account that already has DCSync capabilities.

As a result, an attacker doesn’t need to target the privileged account directly. They can go after the weaker link in the chain and still get access to the same level of control. The misconfiguration usually happens because permissions are delegated too broadly, which leads to an indirect Tier 0 violation (Figure 1).

Figure 1. This scan shows an indicator of exposure (IOE) resulting from a misconfiguration of delegated permissions.

Another example of an attack path that leads to a Tier 0 violation is the compromise of an account with Write permissions on domain controller (DC) objects (Figure 2). This access can be abused to perform a Resource-Based Constrained Delegation (RBCD) attack, allowing the attacker to impersonate high-privilege accounts.

Figure 2. This indicator exposes non-default users or groups that have been given Write access to a DC object.

Risk 2: Overuse of high-privilege built-in AD groups

Older Windows environments often include built-in groups intended for delegated administration across functions such as Account Operators, Server Operators, Backup Operators, and Print Operators. These groups are often overlooked but may still hold high privileges in Active Directory (Figure 3). If these groups are populated, their members can perform actions that lead to privilege escalation and direct access to Tier 0 assets.

Figure 3. This scan scrutinizes AD for legacy high-privilege built-in groups that pose a security risk.

Continued use of legacy built-in groups increases the risk of compromise, especially if the accounts within them are not closely monitored or controlled. Best practices generally recommend that you avoid relying on most built-in groups in AD (e.g., DnsAdmins, DHCP Administrators, Group Policy Creator Owners, Remote Desktop Users) as they often have broad permissions (Figure 4).

Figure 4. This indicator identifies members of common built-in groups that may have broad permissions.

Risk 3: Insecure LAN Manager configuration

NT LAN Manager version 1 (NTLMv1) is a legacy authentication protocol that’s still surprisingly common in some environments—but it shouldn’t be. It uses weak cryptography that makes it easy for attackers to capture and crack authentication traffic (Figure 5). If an attacker gets a machine to authenticate using NTLMv1 (usually with an attack tool like Responder), they can grab the password hash and crack it offline to get the text password.

Figure 5. This Microsoft warning notes awareness of the vulnerability of outdated authentication protocols.

Currently, all Microsoft operating systems support the newer NT LAN Manager version 2. Before enforcing NTLMv2 across the domain, start by enabling NTLM auditing to identify systems or applications still using NTLMv1. Once you’ve reviewed the logs and addressed any legacy dependencies, you can start to configure a domain-wide Group Policy Object (GPO) to set the LAN Manager authentication level to Send NTLMv2 response only. Refuse LM & NTLM (Figure 6). This setting enforces modern authentication and blocks weaker protocols.

Figure 6. Ensure you set security policies to enforce modern authentication protocols.

Risk 4: Insecure ADCS configuration

Our IFIR team notes that misconfigured Active Directory Certificate Services (ADCS) remain an overlooked but high-impact risk in many environments. When certificate templates, enrollment permissions, or web enrollment features are not properly secured, attackers can abuse ADCS to impersonate users, escalate privileges, and gain unauthorized control of sensitive systems.

A common issue is overly permissive certificate templates that allow any authenticated user to enroll for certificates with the Client Authentication EKU. When combined with the ENROLLEE_SUPPLIES_SUBJECT flag, this configuration allows users to specify the subject of the certificate themselves (Figure 7), which can enable low-privileged users to request certificates on behalf of other accounts, including Domain Admins. These certificates can then be used to impersonate those accounts and gain elevated access. This type of misconfiguration is classified as an ESC1.

Figure 7: Misconfigured ADCS certificate templates can enable attackers to request certificates for high-privileged accounts and gain elevated access.

A related risk happens when low-privileged users have the ability to modify certificate templates. Attackers can abuse this vulnerability to introduce insecure settings, such as enabling ENROLLEE_SUPPLIES_SUBJECT, which can turn a previously safe template into one that’s vulnerable to attacks like ESC1 (Figure 8). This type of misconfiguration falls under ESC4.

Figure 8. This security indicator warns that certificate template misconfigurations may pose risks.

Risk 5: Unconstrained delegation

Unconstrained delegation (Figure 9) is dangerous because when a user requests a service ticket on a server with this setting, their ticket-granting ticket (TGT) is included and stays in memory. If an attacker takes over that server, they can grab the TGT and use it to impersonate the user. The risk increases if the Windows Print Spooler service is running on DCs. An attacker can use the printer bug to make a DC authenticate to the compromised server, which leaks the DC’s own TGT and gives the attacker full control.

To reduce the risk, ensure your Tier 0 or equivalent accounts have the Account is sensitive and cannot be delegated option checked, and add them to the Protected Users group.

Figure 9. Setting unconstrained delegation on a server exposes the Kerberos TGT to compromise and abuse.

Risk 6: Unprivileged users can add computer accounts to the domain

In most AD environments, any authenticated user can add up to 10 computers to the domain. It’s a default setting that’s often forgotten. But attackers don’t forget. If they get access to any low-privileged account, they can create a computer object (Figure 10) and use it in attacks that leverage RBCD.

It gets worse when certain certificate templates allow domain computers to enroll and include the Client Authentication EKU with the ENROLLEE_SUPPLIES_SUBJECT flag. That combination opens the door to a classic ESC1 attack, in which the attacker can request a certificate that lets them impersonate another user. If you don’t have a reason to allow users to add machines to the domain, it’s best to set the ms-DS-MachineAccountQuota to 0 and lock that down.

Figure 10. This security indicator is alerting you that you need to ensure users can’t add machines to your domain.

Risk 7: Privileged accounts with SPN configured

Assigning Service Principal Names (SPNs) to privileged user accounts like Domain Admins or other Tier 0 accounts introduces a serious security risk. When a privileged account has an SPN (Figure 11), any authenticated user in the domain can send a Kerberos Ticket-Granting Service (TGS) request for it. The ticket they get is encrypted with the account’s password hash, which means an attacker can extract it and perform a Kerberoasting attack. One common misconfiguration is assigning an MSSQL SPN to the built-in Administrator account (RID 500), which gives attackers a direct Kerberoasting path to one of the most powerful accounts in the domain.

The key issue is that the cracking happens entirely offline. Once the attacker has the ticket, they can perform a brute-force or dictionary attack using tools like hashcat without generating any further traffic or alerts on the DC. Privileged accounts should never have SPNs assigned. If a service needs an SPN, it should run under a separate, low-privileged service account with a strong, managed password.

Figure 11: This scan identifies privileged accounts with defined SPNs.

Risk 8: Stale service accounts still enabled

Service accounts tend to pile up over time. They’re often created for systems that were replaced, one-off scripts, or old projects that no one maintains anymore. The problem is, many of these accounts stay enabled long after they’re no longer needed. Some of them still have elevated permissions or are excluded from regular password policies, which makes them a perfect target for attackers. If one of these forgotten accounts gets compromised, it can be hard to detect. Since no one is actively using it, suspicious activity may go unnoticed.

It’s worth reviewing your service accounts regularly, as Figure 12 shows. If an account hasn’t been used in a long time and no one can justify its purpose, disable it and monitor for any fallout.

Figure 12. Regularly reviewing service accounts and their activity helps ensure unused accounts are purged before they can be compromised.

Risk 9: Lack of Tier 0 enforcement

Implementing a full enterprise tiering model is challenging and often unrealistic. But having a minimal model for Tier 0 systems is non-negotiable.

Tier 0 are the systems that control identity, and if they’re compromised, the rest of the environment falls with them. In most ADSAs, we’ve seen that many organizations have no tiering model in place at all.

If you haven’t established a Tier 0 model yet, now is the time to start. To help with that, Figure 13 shows a list of systems that are commonly treated as Tier 0 in well-secured environments and a model for determining their Tier 0 status.

Figure 13. Understanding, identifying, and protecting Tier 0 assets such as those in this list is essential for enterprise cybersecurity.

Risk 10: Unreliable, un-restorable Active Directory backups

AD is the core of authentication and access across the environment. And yet, one of the most critical gaps we still see in many organizations is the lack of a proper backup strategy for Active Directory.

Some organizations assume that having domain controllers spread across sites is enough, or they rely on general-purpose VM snapshots without validating if those backups can restore AD in a consistent, supported way.

The reality is that if Active Directory goes down and there’s no clean, restorable backup, recovery becomes extremely difficult, especially after a cyberattack.

A reliable AD backup isn’t just a file-level copy or snapshot. Create a trusted, validated backup. Isolate it from the production domain. Protect it from tampering. And test it regularly. Because without it, you’re leaving your most critical infrastructure exposed to irreversible damage.

Semperis snapshot

In a time when cyberattacks are not a matter of if but when, organizations must take steps to ensure resilience before, during, and after a cyber incident.

Start by eliminating common vulnerabilities like these. Then, partner with identity experts and select identity-first tools to help:

  • Strengthen your defenses
  • Proactively establish effective incident response strategies
  • Recover quickly when an incident occurs
  • Reduce your long-term risk

Need to take a deeper look at your identity infrastructure? Tap into our IFIR team’s decades of first-hand knowledge.

Learn more about eliminating Active Directory vulnerabilities