Why do default Active Directory settings make privilege escalation easier for attackers with basic domain access?

Default settings can give authenticated users the ability to create computer accounts and attach service principal names. That matters because a new account can become the foothold for Kerberos abuse and delegated ticket manipulation. When write access exists on those attributes, an attacker can turn a low-risk creation privilege into a path toward higher access across the domain.

Why default Active Directory permissions are so exploitable

Active Directory is designed to be usable out of the box, and that convenience creates a security gap when organisations leave defaults untouched. The core issue is not that every authenticated user is powerful, but that some baseline rights, delegation paths, and writable directory attributes can be chained into abuse when an attacker already has basic domain access.

Default rights often look harmless in isolation. The problem is that Active Directory is a relationship-heavy system, so a low-value permission can become a control-plane primitive once it is combined with Kerberos, delegation, or object ownership. Attackers do not need an admin banner to matter, only a path that lets them convert standard user access into a more trusted directory object or authentication artefact.

A practical example is the ability to create computer accounts or modify attributes that influence Kerberos trust. Those actions can be used to establish a foothold that is easier to weaponise than a normal user account, especially when the environment still permits broad self-service provisioning or weakly governed write access. That is why hardening efforts usually focus on reducing default privilege and removing unnecessary delegation surfaces, not just locking down administrators.

How basic domain access becomes privilege escalation

The escalation path usually depends on abusing directory features that were intended for administration or automation. One common pattern is turning write access to an account or attribute into an authentication or delegation advantage, then using that advantage to obtain service-level access, impersonation rights, or additional tickets. MITRE ATT&CK Enterprise Matrix is a useful lens for mapping those steps to credential access, privilege escalation, and lateral movement techniques.

The same logic explains why default computer-account creation limits matter. If an attacker can create or influence a machine object, they may be able to shape Kerberos behaviour, exploit delegation assumptions, or place themselves in a position where ticket-based abuse becomes possible. The directory does not have to be “broken” globally, it only has to expose one permissive edge that can be extended.

Default settings are also risky because they often persist across teams and time. The account that originally needed broad directory write permissions for a deployment or integration may no longer need them, but the access remains. That creates an escalation path for anyone who compromises a standard domain user, because the attacker inherits the same stale assumptions the business has stopped noticing.

Why this is an access-governance problem, not just an attack technique

What makes this issue persist is that directory privilege is frequently managed as a one-time setup rather than a living control. If teams do not continuously review who can create objects, write service principal names, modify delegation-related attributes, or alter group-linked permissions, then attacker opportunity stays embedded in the baseline. Active Directory and Entra ID Hardening Guide covers the controls that matter most here, including tiering, privileged groups, delegation and attack-path reduction.

This is also where least privilege needs to be operational, not theoretical. Domain users should not retain broad rights simply because they are “standard,” and service or automation accounts should be separated from interactive user patterns wherever possible. Privileged Access Management Guide is relevant because the same overexposure that affects human admins also affects service and workload access when standing privilege is left in place.

For mature environments, the goal is to shrink the number of directory actions that are self-service by default. If a normal user can create or modify something that changes authentication trust, delegation scope, or execution path, then the setting deserves review as a privilege boundary, not as a convenience feature.

Risk and Threat Considerations

Default Active Directory settings are attractive to attackers because they turn ordinary domain access into a set of reusable control points. Once one of those control points affects computer objects, delegation, or Kerberos-related attributes, the attacker can move from one low-privilege foothold to broader directory abuse without needing an immediate admin compromise.

Failure mechanism: Excessive default write or creation rights let an attacker create or alter directory objects in ways that influence authentication and delegation, then leverage that trust path for ticket abuse, impersonation, or lateral movement.

Impact: A single standard user compromise can escalate into broader domain exposure, making containment harder and increasing the chance of persistence, privilege spread, and follow-on compromise across systems that trust Active Directory.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1078 — Valid Accounts	Basic domain access abuse relies on valid directory accounts and reuse of existing trust.
	T1484 — Domain Policy Modification	Directory write access can alter trust or control behavior in the domain.
Recommendation — Map low-privilege account abuse to valid-account paths and hunt for privilege escalation and lateral movement. Monitor and restrict domain object changes that can alter authentication, delegation, or trust.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	The question centers on excess default rights that enable escalation.
	IA-5 — Authenticator Management	Kerberos abuse and ticket manipulation depend on credential and authenticator handling.
Recommendation — Reduce default directory rights to the minimum required and review delegated access regularly. Protect and rotate authenticators and related directory secrets that can be leveraged for escalation.
ISO/IEC 27001:2022	A.5.15 — Access control	Default AD permissions are an access-control problem requiring explicit restriction.
	A.8.2 — Privileged access rights	The issue is the misuse of elevated directory rights and delegation paths.
Recommendation — Define and enforce directory access rules based on business need, not default convenience. Review and limit privileged directory rights, including delegated permissions and special write access.

Practitioner Guidance

What to verify: Check which authenticated users can create computer accounts, write service principal names, modify delegation-related attributes, or inherit rights through delegated OUs. If the answer depends on “default” rather than a deliberate business need, treat it as a control gap.

Decision rule: If a permission can change an object that participates in authentication, ticketing, or delegation, review it as privilege exposure, not as routine directory hygiene. If it is only needed for provisioning, scope it tightly and make it time-bound.

Common mistake: Teams often harden the domain admins path while leaving lower-tier default rights untouched. That misses the attacker’s preferred route, which is usually the easiest valid path rather than the most obviously privileged one.

Practitioner takeaway: The important question is not whether a setting looks administrative, it is whether a standard user can use it to reshape trust. If yes, it belongs in the same hardening and review process as any other privilege boundary.