Broken Access Control Isn’t Just a Web App Problem: An Active Directory Story (OWASP A01:2025)

Disclaimer

All techniques described in this post were performed in an isolated home lab environment (Kali Linux attacker VM against a self-hosted Windows Server 2025 Active Directory domain controller, VMware-hosted) against systems I own and control. This content is for educational purposes only. Unauthorized use of these techniques against systems you do not own or do not have explicit permission to test is illegal.

Why This Matters

Broken Access Control has held the #1 spot on the OWASP Top 10 since 2021, and it kept that position in the 2025 revision — now with Server-Side Request Forgery folded into it, reflecting how blurred the line between service-level and user-level access has become in modern architectures. Most write-ups treat this category as a web application problem: insecure direct object references, missing authorization checks on an API endpoint. But the same root cause — a system granting access it shouldn't — shows up just as often in Active Directory environments, through misconfigured OU permissions, over-permissioned service accounts, and inherited group memberships nobody remembers granting.

This post walks through what Broken Access Control looks like when the "application" is an entire domain.

Lab Setup

• Attacker machine: Kali Linux (VMware)
• Target: Windows Server 2025 domain controller, Active Directory Domain Services with a multi-OU structure and GPO configuration
• Supporting tooling: PingCastle (AD security auditing), ADExplorer/Sysinternals (AD enumeration and snapshot comparison), BloodHound-style attack path reasoning applied manually against the AD structure

Attack Workflow

Phase 1 — Enumerating the Domain

(MITRE ATT&CK: T1087.002 — Account Discovery: Domain Account)

Before touching anything, I enumerated the domain structure using ADExplorer to snapshot the AD database — users, groups, OUs, and their associated ACLs. This step alone, done passively with valid low-privilege credentials, revealed which groups existed, which OUs they were scoped to, and which service accounts were sitting in unusual places (for example, a service account nested inside an OU meant for standard users rather than a dedicated service-account OU).

Phase 2 — Auditing for Access Control Weaknesses

(MITRE ATT&CK: T1069.002 — Permission Groups Discovery: Domain Groups)

Running PingCastle against the domain surfaced several classic access control weaknesses in a single automated pass: excessive permissions granted at the OU level rather than scoped to individual objects, a Group Policy Object linked with broader scope than its intended use case, and a nested group membership chain that quietly granted a low-privilege user indirect membership in a higher-privilege group. None of these were the result of an exploit — they were the result of access control decisions made over time without re-auditing.

Phase 3 — Exploiting the Access Path

(MITRE ATT&CK: T1484.001 — Domain Policy Modification: Group Policy Modification / T1078.002 — Valid Accounts: Domain Accounts)

With the weak link identified — the nested group membership granting indirect elevated access — I authenticated with the low-privilege account and confirmed it inherited permissions on the GPO in question. From there, the same account had write access to a GPO scoped to a broader OU than intended, meaning a low-privilege identity could modify policy that applied to higher-privilege systems. No credentials were stolen or cracked. The access was simply already there, granted by a misconfiguration rather than a vulnerability in the traditional sense.

Phase 4 — Privilege Escalation Through Legitimate Access

(MITRE ATT&CK: T1078 — Valid Accounts)

This is the core lesson of Broken Access Control in an AD context: the attacker doesn't need malware, exploits, or even a phishing email if the access control model itself is wrong. Escalation here happened entirely through legitimate, authenticated actions that the system allowed — because it had been configured to allow them.

Detection

Access control failures like this are notoriously hard to catch with signature-based detection, since every individual action is legitimate. Detection has to focus on anomalous but valid activity:

• Baseline group membership changes — alert on any modification to nested group memberships, especially additions to privileged groups, correlated against change-management records.
• GPO modification alerting — any write to a Group Policy Object, especially from an account that doesn't typically perform administrative changes, is a strong signal worth a dedicated SIEM rule.
• Periodic automated re-auditing — running PingCastle (or an equivalent) on a schedule, not just once, catches configuration drift before it becomes exploitable; feeding its output into a SIEM for trend tracking over time turns a one-off audit into continuous detection.

Remediation

• Enforce least privilege on OU and GPO scoping — permissions and policy links should be scoped as narrowly as the use case allows, not broadly for convenience.
• Regularly audit nested group memberships — indirect privilege escalation through group nesting is one of the most common and most overlooked AD misconfigurations.
• Separate service accounts into dedicated OUs with tightly scoped GPOs, rather than allowing them to inherit policy meant for standard users.
• Deny by default — access control decisions should require explicit justification to grant, not explicit justification to deny.

Prevention

• Threat model the access control graph, not just individual permissions — tools like BloodHound exist because access control in AD is a graph problem; a single permission looks harmless until it's chained with three others.
• Run PingCastle or equivalent audits as part of a recurring change-management cycle, not a one-time hardening exercise.
• Centralize identity and access reviews on a fixed schedule (quarterly is common in mature environments) rather than relying on tribal knowledge of "who has access to what."
• Test access control changes the same way you'd test code changes — a GPO or permission change is a production change and deserves the same scrutiny.

Key Takeaways

• Broken Access Control isn't confined to web applications — the same root cause (a system granting access it shouldn't) applies directly to Active Directory environments.
• Privilege escalation through legitimate, authenticated access is often more dangerous than exploit-based escalation, because it leaves no obvious signature to detect.
• Access control in AD is a graph problem — individual permissions can look safe in isolation while enabling escalation when chained together.
• Detection has to focus on anomalous-but-valid activity: group membership changes, GPO modifications, and configuration drift over time.

What's Next

The next post in this series will cover another OWASP Top 10:2025 category, continuing the same structure of hands-on attack workflow, detection, and remediation used here.