Top 10 Active Directory Security Risks and How to Fix Them

Active Directory still decides who can sign in to what in most enterprises, so an attacker who controls it controls every user and system it manages. The joint Five Eyes guidance led by the Australian Signals Directorate, Detecting and mitigating Active Directory compromises, puts it plainly: AD's "pivotal role in authentication and authorisation makes it a valuable target for malicious actors", and it documents 17 techniques used against it. Almost all of them succeed because of misconfiguration that builds up over years: too many administrators, old protocols left on, weak service account passwords and defaults nobody changed. This list ranks ten Active Directory security risks by our judgement of how often they appear in assessments and how far they let an attacker go, with the ATT&CK v20 technique, the first fix, the events to watch and the deep-dive guide for each. It is for directory engineers, identity and security architects and anyone running an Active Directory risk assessment. For the full hardening programme, see the Active Directory and Entra ID Hardening Guide.

The Top 10 at a glance

1. Privileged group sprawl and hidden administrative rights
2. Privileged credentials exposed on lower-tier systems
3. Kerberoastable and AS-REP roastable accounts
4. Weak Kerberos encryption and a stale KRBTGT key
5. Unconstrained delegation and coerced authentication
6. Shared local administrator passwords
7. Misconfigured Active Directory Certificate Services
8. Legacy authentication protocols and unsigned traffic
9. Insecure defaults: open machine joins, SYSVOL secrets and weak password policy
10. Unprotected Tier 0 beyond the domain controllers

1. Privileged group sprawl and hidden administrative rights

The risk: Microsoft notes that three built-in groups "have the highest privileges in Active Directory by default: Enterprise Admins, Domain Admins, and Administrators", but its privileged security level also covers Schema Admins, Account Operators, Backup Operators, Print Operators, Server Operators, Group Policy Creator Owners and any custom group delegated to run the directory. Over time these fill with permanent members, nested groups and service accounts, and further rights hide in object permissions (GenericAll, WriteDacl, WriteOwner, rights to reset passwords or edit group membership) granted for a project years ago.

Why it matters: every member and every account with a path to those groups is a domain takeover waiting for one stolen password (T1078.002 Domain Accounts). Attackers who gain a foothold add themselves to a privileged group (T1098.007 Additional Local or Domain Groups).

The fix: follow Microsoft's own priorities to "Eliminate permanent membership in highly privileged groups" and "Implement controls to grant temporary membership in privileged groups when needed". Keep Domain Admins and Enterprise Admins empty except for break-glass accounts, move routine work to narrowly delegated groups, and map ACL-based paths to Tier 0 with a graph-based attack path tool, removing the edges nobody can justify. See the Identity Attack Paths Guide.

Detect: alert on events 4728, 4732 and 4756 (member added to a security-enabled global, local or universal group) for every Tier 0 group, and on 5136 for permission changes to the domain head, AdminSDHolder and Tier 0 objects.

2. Privileged credentials exposed on lower-tier systems

The risk: domain administrators sign in to workstations, member servers, jump boxes and management consoles with the same account they use on domain controllers. Microsoft lists "Signing into privileged accounts on unsecured computers" and browsing while signed in to a privileged account among the risky behaviours behind credential theft.

Why it matters: once an admin has logged on, their credential material sits in memory on that host. An attacker who compromises any workstation dumps it (T1003.001 LSASS Memory) and replays it (T1550.002 Pass the Hash, T1550.003 Pass the Ticket) to reach Tier 0 without cracking anything.

The fix: give administrators separate accounts per tier, block Tier 0 accounts from signing in to Tier 1 and Tier 2 hosts with the "Deny log on" user rights or authentication policy silos, and require privileged access workstations for directory administration. Add Tier 0 accounts to the Protected Users group after a pilot: members cannot authenticate with NTLM, cannot use DES or RC4 in Kerberos pre-authentication, cannot be delegated, and their ticket-granting tickets last four hours. Microsoft warns never to add service or computer accounts, and to test before adding existing Domain Admins. See the Tiered Administration and Enterprise Access Model Guide.

Detect: event 4624 for Tier 0 accounts on any host that is not a domain controller or privileged access workstation, and 4648 (logon with explicit credentials) from workstations.

3. Kerberoastable and AS-REP roastable accounts

The risk: user accounts with a service principal name (SPN) and a human-chosen password, often years old and often in privileged groups, plus accounts with Kerberos pre-authentication turned off.

Why it matters: any domain user can request a service ticket for an SPN and crack it offline (T1558.003 Kerberoasting); accounts without pre-authentication hand out crackable material to anyone who asks (T1558.004 AS-REP Roasting). No failed logons are generated, so lockout policy does not help.

The fix: the Five Eyes guidance says to minimise user objects with SPNs, convert them to group managed service accounts, which have "a 120-character password" rotated automatically, and where that is not possible use a password of at least 30 characters and keep SPN accounts out of privileged groups. Require pre-authentication on every user object. See the Group Managed Service Accounts (gMSA) Guide.

Detect: event 4769 with ticket encryption type 0x17 (RC4) and ticket options 0x40800000 or 0x40810000; 4738 and 5136 when an SPN is added or pre-authentication is disabled; 4768 requests for accounts without pre-authentication. A honeypot SPN account that nothing legitimate uses gives a high-fidelity alert.

4. Weak Kerberos encryption and a stale KRBTGT key

The risk: RC4 still allowed for accounts and services, accounts with only RC4 keys, and a KRBTGT password that has not changed since the domain was built. Computer account passwords that have stopped rotating create the same problem for individual servers.

Why it matters: RC4 tickets are faster to crack and RC4 keys are derived from the NT hash. An attacker who obtains the KRBTGT key can forge ticket-granting tickets for any account (T1558.001 Golden Ticket); a service or computer key allows forged service tickets to that host (T1558.002 Silver Ticket). Forged tickets survive user password resets.

The fix: set msDS-SupportedEncryptionTypes to AES for service accounts and plan RC4 removal domain-wide after auditing which clients still request it. The Five Eyes guidance says to change the KRBTGT password "every 12 months, or when the domain has been compromised", and on compromise to change it twice, allowing replication between resets. It also recommends changing all computer object passwords, including domain controllers, every 30 days. See the Kerberos Security Guide.

Detect: correlate 4768 and 4769 on domain controllers: a 4769 with no matching 4768 can indicate a forged ticket, and a 4769 using RC4 where AES is the default is suspicious. For silver tickets, compare 4624 with 4627 group membership on the target host.

5. Unconstrained delegation and coerced authentication

The risk: servers and accounts trusted for unconstrained delegation (the TRUSTED_FOR_DELEGATION flag), often legacy application or print servers, combined with services such as the Print Spooler running on domain controllers.

Why it matters: any account that authenticates to an unconstrained delegation host leaves a forwardable ticket there. An attacker who controls that host can force a domain controller to authenticate to it (T1187 Forced Authentication), capture the DC's ticket and use it (T1550.003) to replicate the directory.

The fix: remove unconstrained delegation and use resource-based constrained delegation instead, mark privileged accounts "sensitive and cannot be delegated", add them to Protected Users, and disable the Print Spooler service on domain controllers, all as the Five Eyes guidance recommends. See the Kerberos Delegation Security Guide.

Detect: 4624 and 4770 (ticket renewed) involving delegation hosts, 4688 process creation and PowerShell 4103 and 4104 on those hosts; schedule a weekly query for any object newly flagged for unconstrained delegation.

6. Shared local administrator passwords

The risk: the built-in local Administrator account has the same password on every workstation or server built from one image.

Why it matters: one compromised machine gives the hash for all of them (T1078.003 Local Accounts, T1550.002). Microsoft notes that local administrator accounts "often share the same password across many devices, which bad actors can exploit to move laterally".

The fix: deploy Windows LAPS, which rotates and backs up each device's local administrator password to Active Directory or Entra ID (not both), supports encryption of passwords stored in AD, and can manage the Directory Services Restore Mode password on domain controllers. Avoid legacy emulation mode, which stores passwords in clear text. Restrict who can read the password attribute and audit reads. See the Local Administrator Password Solution (LAPS) Guide.

Detect: 4624 logon type 3 with a local account across many hosts in a short window, and reads of the LAPS password attribute by accounts outside the help desk and server teams.

7. Misconfigured Active Directory Certificate Services

The risk: certificate templates that let the requester supply the subject, broad enrolment or template write rights, the EDITF_ATTRIBUTESUBJECTALTNAME2 flag on a CA, and certification authorities managed like ordinary member servers.

Why it matters: a low-privileged user can request a certificate that authenticates as a domain administrator (T1649 Steal or Forge Authentication Certificates), and a stolen CA private key lets an attacker mint certificates for anyone (the Five Eyes "Golden Certificate"). Certificates keep working after password resets.

The fix: remove the "Enrolee Supplies Subject" flag, restrict template write permissions, make sure EDITF_ATTRIBUTESUBJECTALTNAME2 is not set, require CA manager approval for templates that allow a subject alternative name, remove authentication EKUs where they are not needed, protect CA keys with a hardware security module, and treat CAs as Tier 0. See the AD CS Security Guide.

Detect: CA events 4886 and 4887 (certificate requested and issued), 4899 and 4900 (template changes), 4768 with pre-authentication type 16 (certificate logon) for privileged accounts, and CAPI2 event 70 for private key export.

8. Legacy authentication protocols and unsigned traffic

The risk: NTLMv1 still accepted, NTLM used where Kerberos would work, LDAP signing and channel binding not enforced on domain controllers, SMB signing optional, and LLMNR and NetBIOS name resolution switched on across the network.

Why it matters: an attacker on the network answers broadcast name queries, captures authentication attempts and relays them to LDAP, SMB or web services that do not require signing (T1557.001 Name Resolution Poisoning and SMB Relay). NTLM also makes password spraying easier (T1110.003).

The fix: the Five Eyes guidance says to disable NTLM, and where it must remain, to enable LDAP channel binding, Extended Protection for Authentication and SMB signing. In Group Policy that means "Domain controller: LDAP server signing requirements", "Domain controller: LDAP server channel binding token requirements", "Microsoft network server: Digitally sign communications (always)", turning off multicast name resolution, and removing NTLMv1 through the LAN Manager authentication level. Disable SMBv1 on domain controllers. See the Lateral Movement Guide.

Detect: Directory Service event 2889 lists clients making unsigned LDAP binds and is the inventory you need before enforcing signing; 4624 with an NTLM V1 package name; 4625 and 4771 (failure code 0x18) spikes across many accounts for spraying.

9. Insecure defaults: open machine joins, SYSVOL secrets and weak password policy

The risk: ms-DS-MachineAccountQuota left at its default of 10, so any user can create computer accounts; old Group Policy Preferences files in SYSVOL holding encrypted cpassword values that anyone can decrypt (T1552.006); Group Policy objects writable by non-Tier 0 groups (T1484.001 Group Policy Modification); dormant accounts; and short passwords without lockout.

Why it matters: each is a free first step. A created computer account is a foothold for delegation and relay attacks, a GPP password is often a local or service admin, and whoever can edit a GPO linked to domain controllers can run code on them.

The fix: set ms-DS-MachineAccountQuota to 0 and delegate domain joins to a named group; remove every cpassword from SYSVOL and confirm KB2962486 (MS14-025) is installed; restrict GPO edit rights on Tier 0 GPOs to Tier 0 admins. The Five Eyes guidance recommends a 15-character minimum for single-factor user passwords, 30 characters for local administrator, service and break-glass accounts, and lockout after five failed attempts except for break-glass accounts. CIS Safeguard 5.3 adds disabling dormant accounts after 45 days of inactivity. See the Password Spraying and Credential Stuffing Defence Guide.

Detect: 4741 (computer account created) by non-admin users; 5136 on groupPolicyContainer objects; and, because the Five Eyes guidance says there is no effective way to detect SYSVOL searches, a canary GPP password for an account that should never log on.

10. Unprotected Tier 0 beyond the domain controllers

The risk: accounts other than domain controllers holding replication rights (Replicating Directory Changes and Replicating Directory Changes All), domain controller backups stored where server or backup admins can read them, and Entra Connect, AD FS, backup and management servers run as ordinary Tier 1 systems.

Why it matters: replication rights let an attacker pull every password hash over the network (T1003.006 DCSync); a backup or snapshot gives ntds.dit offline (T1003.003 NTDS). Hybrid servers bridge into the cloud (T1556.007 Hybrid Identity): in the Storm-0501 hybrid cloud attacks, stolen Entra Connect sync credentials carried ransomware operators into Entra ID. Stolen hashes also have a long tail, as the Cisco Active Directory credentials leak showed when hashes from a 2022 breach were republished in 2025.

The fix: minimise accounts with replication rights and review them at least every 12 months, as the Five Eyes guidance advises; encrypt and restrict domain controller backups; run nothing but AD services on DCs; and give Entra Connect, AD FS, CAs, PAM vaults and any agent-based management tool that reaches DCs the same Tier 0 controls. For AD FS the guidance adds a dedicated gMSA, LAPS and rotating token-signing and encryption certificates every 12 months. See the Credential Dumping Guide.

Detect: event 4662 with the replication GUIDs from a source that is not a domain controller; 4656 and 4663 on ntds.dit and 8222 (shadow copy created); AD FS events 307 and 510 for configuration changes and 1200 and 1202 gaps for forged SAML tokens.

Mapping to ATT&CK, the Five Eyes guidance and CIS Controls

In NIST SP 800-53 terms, risks 1 and 2 sit under AC-6 Least Privilege, especially AC-6(5) Privileged Accounts and AC-6(7) Review of User Privileges, and in NIST CSF 2.0 under PR.AA-05. Where a cell says no direct safeguard, the risk is a directory configuration issue that CIS covers only through general secure configuration, so use the Five Eyes mitigations as the standard.

Where to start

If you can do only three things this quarter: empty Domain Admins and Enterprise Admins of standing members and stop Tier 0 accounts signing in to lower tiers (risks 1 and 2), convert or re-password every account with an SPN and enable pre-authentication everywhere (risk 3), and deploy Windows LAPS to every endpoint and server (risk 6). Then work through the rest in this order:

1. Assess (weeks 1 to 4): export membership of every privileged group, ACL paths to Tier 0, SPN accounts, delegation flags, the MachineAccountQuota value, SYSVOL cpassword files, replication rights and certificate template settings. This is your Active Directory risk assessment baseline.
2. Quick wins (weeks 2 to 8): MachineAccountQuota to 0, cpassword removal, Print Spooler off on DCs, unconstrained delegation removed from anything that is not a DC, template fixes in AD CS.
3. Audit before enforcing (months 2 to 4): turn on NTLM auditing and collect event 2889 for unsigned LDAP binds, pilot Protected Users with a few Tier 0 admins, and fix or exempt the clients that break. Keep the previous GPO version linked but disabled so you can roll back in minutes.
4. Enforce (months 4 to 9): LDAP signing and channel binding, SMB signing, NTLMv1 removal, AES-only service accounts, authentication policy silos for Tier 0. Change one setting per change window so a failure points to one cause.
5. Sustain: reset KRBTGT twice on a yearly schedule, review replication and privileged group membership at least yearly, and rehearse forest recovery. See the Identity Recovery Guide.

Small organisations with one domain can usually finish the quick wins in a month and should lean on built-in tooling. Large or multi-forest estates should treat each forest trust as a boundary to assess, and add identity threat detection for the events above. See the ITDR Guide. Track five numbers monthly: standing members of Tier 0 groups (target only break-glass accounts), user accounts with SPNs not using gMSA or a 30-plus character password, objects with unconstrained delegation outside DCs (target zero), endpoints and servers without LAPS (target zero), and clients still making unsigned LDAP binds.

Standards and references

• ASD, CISA, NSA and partners: Detecting and mitigating Active Directory compromises
• Microsoft: Best practices for securing Active Directory
• Microsoft: Privileged access security levels
• Microsoft: Protected Users security group
• Microsoft: What is Windows LAPS?
• MITRE ATT&CK: Credential Access tactic
• CIS: Controls Assessment Specification, Control 5 Account Management

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Service Account Security Guide · Privileged Access Management Guide · Identity Security Maturity Model