Introduction
Before talking about Kerberoasting, ACL abuse, Shadow Credentials, or any advanced Active Directory attack, one thing must be clear: Active Directory is not a hacking topic, it is an identity system.
Most people fail at AD pentesting because they jump directly into tools without understanding how identity, authentication, and trust actually work inside an enterprise network. This article is written to fix that gap.
This is not a cheat sheet.
This is not a command-based tutorial.
This is a mental model of Active Directory — the same model attackers abuse and defenders try to protect.
What Active Directory Really Is
Active Directory is Microsoft’s centralized identity and access management system. In simple terms, it is the system that answers two fundamental questions across an entire organization:
Who are you?
What are you allowed to do?
When an employee logs into their laptop, accesses a file server, connects to a database, or opens an internal application, Active Directory is almost always involved in that decision. AD is not limited to Windows logins. It quietly controls access across servers, applications, file shares, printers, VPNs, and even cloud services in hybrid environments.
A common beginner mistake is to think of Active Directory as “just users and passwords”. In reality, passwords are only one small part of a much larger identity system.
The Logical Structure of Active Directory
::contentReference[oaicite:1]{index=1}
Active Directory is organized in layers, and each layer represents a different scope of trust and administration.
At the top is the forest. A forest is the highest security boundary in Active Directory. Everything inside a forest implicitly trusts everything else inside the same forest. In many organizations, there is only one forest, but large enterprises and merged companies may have multiple forests connected by trust relationships.
Inside a forest are one or more domains. A domain is an administrative boundary. Users, computers, and policies belong to a domain. When people refer to something like corp.local or company.internal, they are referring to an Active Directory domain.
Within domains, objects are often organized into Organizational Units, commonly called OUs. OUs are not security boundaries. They exist to organize objects and apply policies. For example, HR computers might live in one OU, IT computers in another, and servers in a separate OU. This structure becomes extremely important later when we talk about Group Policy abuse.
Understanding this hierarchy is critical, because attackers do not “hack a domain controller” first. They move through identity relationships inside this structure.
Domain Controllers and the AD Database
A Domain Controller, often called a DC, is a server that holds a copy of the Active Directory database and provides authentication services.
The AD database contains every object in the domain: users, groups, computers, permissions, and relationships. This database is replicated across domain controllers to ensure availability and consistency.
From an attacker’s point of view, the Domain Controller is not valuable because it is a server. It is valuable because it is the source of truth for identity. Whoever can influence what the Domain Controller believes about identities effectively controls the domain.
This is why many advanced AD attacks do not require malware, exploits, or file drops. They manipulate identity data instead.
Users, Groups, and Computer Accounts
In Active Directory, users represent people or services. Groups represent collections of identities. Computers are also identities.
This is one of the most important concepts to understand: machines authenticate just like users. A domain-joined computer has its own account and its own password. This design enables secure communication between machines, but it also creates opportunities for attackers later in an engagement.
Groups are how access is actually granted. Users rarely receive permissions directly. Instead, users become members of groups, and those groups are granted access to resources. This design simplifies administration, but it also means that group membership is power.
When attackers escalate privileges in AD, they are often manipulating group memberships or abusing permissions that allow them to do so indirectly.
Authentication vs Authorization
Many people confuse authentication and authorization, but they are not the same thing.
Authentication answers the question of identity. It answers “Who are you?”
Authorization answers the question of access. It answers “What are you allowed to do?”
Active Directory first authenticates an identity using Kerberos or NTLM. After authentication succeeds, authorization decisions are made based on group memberships and permissions.
This distinction matters because an attacker can be fully authenticated as a valid user and still have very limited access. Most AD attacks are about changing authorization, not authentication.
Kerberos: How Authentication Works
::contentReference[oaicite:2]{index=2}
Kerberos is the default authentication protocol used in Active Directory. Unlike older protocols, Kerberos does not send passwords across the network repeatedly. Instead, it relies on tickets.
When a user logs in, the Domain Controller issues a Ticket Granting Ticket, commonly called a TGT. This ticket proves the user’s identity for a limited time. When the user tries to access a service, such as a file server or database, the user presents the TGT and receives a service-specific ticket.
This ticket-based design improves security and performance, but it also introduces unique attack surfaces. Kerberoasting exists purely because of how Kerberos service tickets are designed and encrypted.
Without understanding Kerberos at this level, Kerberoasting feels like magic. With this understanding, it feels inevitable.
LDAP: How AD Stores and Queries Information
::contentReference[oaicite:3]{index=3}
LDAP, the Lightweight Directory Access Protocol, is how Active Directory stores and retrieves information.
Whenever tools enumerate users, groups, computers, or permissions, they are not “hacking” anything. They are performing LDAP queries. LDAP is designed to be readable by authenticated users because applications need to find users, groups, and attributes.
This openness is necessary for AD to function, but it also means attackers can learn a lot about an environment without triggering alerts. Enumeration is not exploitation. It is simply asking the directory questions.
Group Policy and Centralized Control
Group Policy Objects, or GPOs, define how systems behave inside a domain. They control password policies, security settings, startup scripts, software installation, and more.
GPOs are applied based on where an object lives in the AD hierarchy. A single GPO can affect hundreds or thousands of machines. This makes GPOs one of the most powerful features in Active Directory.
From a defensive perspective, GPOs enforce consistency. From an attacker’s perspective, they represent centralized authority. Any weakness in GPO permissions can have massive impact, which is why GPO abuse appears later in advanced AD attacks.
Permissions and Access Control Lists
Every object in Active Directory has an Access Control List, or ACL. ACLs define who can read, modify, or control an object.
These permissions are far more granular than most administrators realize. It is possible for a user to have permission to modify a group, reset a password, or change an attribute without being an administrator.
Many of the most powerful AD attacks are not exploits. They are permission abuse. Attackers find unexpected write permissions and chain them together to reach high-value targets.
This is why modern AD attacks are often described as graph problems rather than vulnerability problems.
Trust Relationships
Active Directory trusts allow identities from one domain or forest to access resources in another. Trusts are essential for business operations, especially during mergers or multi-domain environments.
However, trusts also expand the attack surface. A compromised domain does not exist in isolation if trusts are in place. Attackers can abuse trust relationships to move laterally across domains and even forests.
Many real-world breaches become catastrophic because trust relationships were assumed to be safe without continuous monitoring.
Active Directory as an Identity Graph
The most accurate way to understand Active Directory is as an identity graph. Users, groups, computers, and permissions form nodes and edges in a massive graph.
Attacks are not about breaking one node. They are about finding a path. Each small permission, each group membership, and each trust relationship becomes a stepping stone.
Tools like BloodHound visualize this graph, but the underlying concept exists whether you use tools or not. Once you understand AD as a graph, advanced attacks start to make sense.
Why This Foundation Matters
If you skip these fundamentals, advanced topics like Kerberoasting, Shadow Credentials, or AD CS exploitation will feel like isolated tricks. With this foundation, they feel like logical consequences of design decisions.
Active Directory is not insecure by accident. It is complex by necessity. Attackers succeed when complexity outpaces visibility and operational discipline.
Closing Thoughts
Active Directory is the backbone of enterprise identity. Every advanced AD attack abuses something that already exists by design: trust, delegation, permissions, or authentication flows.
Before learning how to break Active Directory, you must understand how it works when it is functioning correctly. That understanding is what separates real security engineers from tool operators.
In the next article, we will build directly on this foundation and explore Kerberoasting, an attack that exists not because of a vulnerability, but because of how Kerberos and service accounts are designed.
Understanding AD makes attacks predictable.
Predictable attacks are preventable.