After addressing credentials, privileged access and Kerberos abuse, the next major area attackers rely on is Active Directory object permissions. While credentials and authentication get most of the attention, permissions quietly determine who can change what inside the directory.
In many environments, Active Directory permissions have grown organically over years. Delegations were added to solve specific problems, temporary access became permanent and visibility was slowly lost. The result is often an environment where attackers do not need to steal Domain Admin credentials at all. They simply abuse what is already allowed.
This month focuses on securing Active Directory permissions, controlling who can create computer objects and preventing abuse of DNS records inside the domain.
Why Active Directory permissions matter so much
From an attacker’s perspective, permissions are often more valuable than credentials. Credentials give access, but permissions determine control.
Active Directory permissions define who can reset passwords, modify group memberships, create objects, write attributes and link policies. Misconfigured Access Control Lists and Access Control Entries can allow attackers to escalate privileges, persist access or prepare future attacks without triggering obvious alerts.
What makes this particularly dangerous is that permission abuse usually looks like legitimate administrative activity. No exploit is required. The directory behaves exactly as configured.
Securing Active Directory ACLs and ACEs
Every object in Active Directory is protected by an Access Control List that defines who can read, write or modify it. These Access Control Lists consist of Access Control Entries (ACEs), each defining a specific permission assigned to a user, group, or computer. Over time, these permissions tend to grow complex. Delegations are added to solve practical problems, rarely reviewed, and eventually lose clear ownership.
The risk is that many dangerous permissions do not look dangerous at first glance. They are not obvious Domain Admin rights, but small, specific permissions that can still have a major security impact when abused. From an attacker’s perspective, misconfigured ACLs are often more valuable than stolen credentials.
A common entry point for abuse is excessive permissions on user and group objects. Rights such as password resets, attribute modification or indirect group membership changes are frequently delegated too broadly. With access to these permissions, an attacker can escalate privileges without touching obvious privileged groups.
The same applies to group objects themselves. Write access on intermediate or nested groups is often overlooked, yet it can still provide a path to elevated privileges, especially in environments where group structures have evolved over time.
Service accounts introduce similar risk. To simplify management, teams are often granted write access to these accounts, sometimes including sensitive permissions such as GenericWrite or WriteProperty. These can be abused to manipulate Service Principal Names, enable Kerberos abuse or expose credentials.
Commonly abused permissions
Not all permissions are equally dangerous. In practice, attackers tend to focus on a limited set of highly impactful rights that can be abused for privilege escalation or persistence.
GenericAll
Effectively full control over an object. This includes all possible permissions such as modifying attributes, resetting passwords, changing group memberships, modifying the DACL and owner, and delegating permissions to other principals. The exact impact still depends on the object type (user, group, computer, OU, etc.), but if applied to a user, group or computer object, this is often an immediate path to escalation.
GenericWrite
Allows modification of many (but not necessarily all) writable attributes on an object, depending on the ACL configuration. This is frequently sufficient for abuse. For example, attackers can modify Service Principal Names (SPNs) to perform Kerberoasting or influence authentication behavior. Other writable attributes such as userAccountControl or msDS-KeyCredentialLink (Shadow Credentials) may also enable privilege escalation, persistence, or authentication abuse depending on context.
WriteProperty
More granular than GenericWrite, as it applies to specific attributes or attribute sets rather than the entire object. Despite being more targeted, it can still be highly dangerous depending on which attribute is controlled. Permissions on attributes such as servicePrincipalName, userAccountControl, member, or msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD) can enable targeted privilege escalation, lateral movement, or persistence.
WriteDACL
Allows modification of the ACL itself. In practice, this means an attacker can grant themselves any required permissions, including full control. This is one of the most powerful and commonly abused rights and typically leads to full compromise of the object.
WriteOwner
Allows changing the owner of an object. While ownership alone does not directly grant full control, the owner inherently has the ability to modify the DACL even without explicit WriteDACL permissions. In practice, this results in a reliable two-step escalation that leads to full control of the object.
AddMember / WriteMembers (on groups)
Permissions to modify group membership are frequently underestimated. Typically implemented as WriteProperty on the ‘member’ attribute, this allows adding or removing users from groups. The impact depends on the group and any nested group relationships. When applied to nested or indirectly privileged groups, this can provide a path to privilege escalation without directly interacting with obvious high-value groups.
ResetPassword / ForceChangePassword
Allows setting a new password for a user account without knowledge of the current password (commonly implemented via the “User-Force-Change-Password” extended right). Typically applies to user objects and is often delegated for operational reasons, but highly sensitive if misconfigured. This action may also be logged or monitored in mature environments.
Extended Rights (e.g. “All Extended Rights”)
Extended rights are special control access permissions that allow specific operations on an object. Not all extended rights are equally critical, but some have severe impact. For example, replication rights (e.g. DS-Replication-Get-Changes and DS-Replication-Get-Changes-All) can enable DCSync attacks and lead to full domain compromise. These rights are often overlooked but can have significant security impact depending on the object and context.
Tools such as BloodHound, an Active Directory attack path analysis tool, help visualize how individual permissions can be chained together into full attack paths across the environment
Securing ACLs requires continuous ownership
ACL abuse is difficult to detect because it relies entirely on legitimate directory functionality. From the system’s perspective, the user is simply using permissions that already exist.
Securing ACLs therefore means focusing on the permissions that matter most. Delegation on Tier 0 objects such as domain controllers, privileged groups and critical service accounts should be minimal, clearly justified and regularly reviewed.
Reducing ACL risk is not a one-time exercise, but an ongoing process of ownership, visibility and validation.
Preventing unauthorized computer account creation
In many Active Directory environments, the creation of computer accounts is permitted for low-privileged users through the ms-DS-MachineAccountQuota attribute. This setting determines how many computer accounts a user is allowed to create within the domain.
By default, Microsoft configures ms-DS-MachineAccountQuota with a value of 10, allowing any authenticated domain user to join up to ten computer accounts to the domain without requiring elevated privileges. This default is often left unchanged and is frequently underestimated as a security risk.
From an attacker’s perspective, the ability to create computer objects is highly valuable. Newly created computer accounts can be used for authentication, Kerberos-related abuse, delegation attacks, and in some cases as part of privilege escalation paths. This capability is commonly combined with other weaknesses, such as NTLM or LDAP relay attacks and misconfigured authentication mechanisms, to establish a reliable initial foothold in the environment.
The level of access granted to a standard domain computer account is often overlooked. Computer accounts are able to authenticate to domain services, request Kerberos tickets, and interact with other systems in ways that can be abused. These default permissions can enable lateral movement, credential abuse, and further exploitation.
When combined with additional misconfigurations, this attack path can ultimately lead to data compromise, system compromise, or even full domain compromise. To mitigate this risk, ms-DS-MachineAccountQuota should be reduced to zero or computer account creation should be restricted to a controlled group. In addition, monitoring for unusual or unexpected computer account creation is strongly recommended. The screenshot below shows, using ADSI Edit, that the ms-DS-MachineAccountQuota attribute is configured with its default value of 10. From a security perspective, this value should ideally be reduced to 0 to prevent unauthorized computer account creation.
Protecting against unauthenticated malicious DNS record manipulation
Active Directory–integrated DNS is another frequently overlooked attack surface. DNS records are critical to domain operations, but their security is often assumed rather than verified.
In some environments, DNS zones or records are configured in a way that allows unauthenticated or overly broad write access. This can enable attackers to create or modify DNS records without proper authorization.
From an attacker’s perspective, DNS manipulation is powerful. By adding or modifying records, attackers can redirect traffic, intercept authentication attempts or prepare man-in-the-middle scenarios. Malicious DNS records can also be used to persist access or disrupt normal operations without touching traditional security controls.
Securing DNS requires ensuring that DNS zones are configured for secure dynamic updates only and that permissions on DNS objects are properly restricted. Write access should be limited to systems and accounts that genuinely require it, such as domain controllers and authorized DNS management services.
DNS permissions should be reviewed with the same rigor as Active Directory object permissions. Treating DNS as “just infrastructure” rather than a security-critical component creates blind spots that attackers are happy to exploit.
During assessments, we frequently observe that Dynamic DNS updates are configured insecurely, as illustrated in the screenshot below.
These settings can be found in DNS Manager, under Forward Lookup Zones, within the properties of the active domain zone. It is important to note that the option “Nonsecure and secure” is not secure. Only secure dynamic updates should be permitted to prevent unauthorized or unauthenticated DNS record modifications.
The screenshot below demonstrates the abuse of this configuration. As shown, an attacker is able to use the Metasploit dyn_dns_update module to successfully add a new A record to the DNS zone (in this case: sevenkingdoms.local) without authentication.
The record resilix.sevenkingdoms.local is dynamically registered and mapped to the IP address 192.168.56.128, confirming that the DNS zone allows nonsecure dynamic updates. This behavior enables unauthorized manipulation of DNS records and may be leveraged for traffic interception, spoofing, or lateral movement within the environment.
Why permission abuse often goes unnoticed
Permission abuse rarely triggers alarms because it uses legitimate functionality. Password resets, attribute changes and object creation are normal administrative actions. Without proper baselining and monitoring, malicious changes are difficult to distinguish from routine operations.
Another challenge is complexity. ACLs and ACEs are not easy to reason about at scale. Over time, few people fully understand why certain permissions exist or what removing them might break. As a result, risky permissions persist simply because they are familiar.
What needs to change
The DNS zone configuration must be updated to disallow nonsecure dynamic updates. The current setting “Nonsecure and secure” allows unauthenticated systems to create or modify DNS records, which introduces a significant security risk.
The DNS zone should be configured to allow secure dynamic updates only, ensuring that DNS record creation and modification are limited to authenticated and authorized domain-joined systems. This prevents unauthorized users or systems from injecting malicious DNS records.
Existing DNS records should be reviewed to identify unauthorized or suspicious entries that may have been created due to this configuration. DNS permissions must also be verified to ensure that only intended computer accounts or services are allowed to update their corresponding records.
Applying these changes reduces the risk of DNS spoofing, traffic redirection, credential interception, and lateral movement within the Active Directory environment.
Closing thoughts
Active Directory permissions should be treated as a living security control, not as static configuration. Over time, delegations, object rights and DNS settings tend to accumulate without regular review, creating silent attack paths.
The first priority is visibility. Organizations need a clear overview of who can modify which objects and why. Access Control Lists on users, groups, computers and organizational units should be reviewed, with particular attention to Tier 0 objects such as domain controllers, privileged groups and critical service accounts. Delegations without a clear and current purpose should be removed.
Computer account creation must be explicitly controlled. Leaving the default ms-DS-MachineAccountQuota in place provides attackers with an easy foothold. Reducing this value to zero removes a commonly abused attack vector and prevents unauthorized computer account creation altogether. Monitoring for unexpected computer account creation should be part of standard detection.
DNS must be secured as a core identity component. Active Directory–integrated DNS should allow secure dynamic updates only, and permissions should be restricted to authorized systems. Existing DNS records should be reviewed to detect unauthorized or suspicious entries.
Ownership and regular review are just as important as technical configuration. Permissions, object creation rights and DNS settings should be clearly owned, documented and revisited on a recurring basis. When trust is limited, intentional and visible, attackers lose many of the quiet paths they rely on to move through Active Directory.
Let's Connect
Are you in need of assistance from our Active Directory Experts, or are you left with some questions after reading this blog post? Don't hesitate to fill out the contact form below!