Active Directory Attacks & Defense: Enterprise Penetration Testing

Not sure yet? Here is the full table of contents and the first chapter, exactly as it appears in the book.

Contents

• Chapter 1: Active Directory Architecture Fundamentals
• Chapter 2: Setting Up Your Testing Lab
• Chapter 3: Reconnaissance and Information Gathering
• Chapter 4: Kerberos Authentication Deep Dive
• Chapter 5: Credential Access and Harvesting Techniques
• Chapter 6: Pass-the-Hash and Pass-the-Ticket Attacks
• Chapter 7: Kerberoasting Service Account Attacks
• Chapter 8: AS-REP Roasting and Pre-Authentication Bypass
• Chapter 9: Golden and Silver Ticket Attacks
• Chapter 10: ACL Abuse and Privilege Escalation
• Chapter 11: Group Policy Exploitation Techniques
• Chapter 12: Unconstrained and Constrained Delegation Attacks
• Chapter 13: Domain Trust Exploitation and Lateral Movement
• Chapter 14: Certificate Services Attacks and ADCS Vulnerabilities
• Chapter 15: NTLM Relay and Authentication Coercion
• Chapter 16: Persistence Mechanisms in Active Directory
• Chapter 17: Detection Engineering for AD Attacks
• Chapter 18: Hardening and Securing Your AD Environment

18 chapters in the complete book.

Chapter 1: Active Directory Architecture Fundamentals

Active Directory has been the backbone of enterprise identity management for over two decades, and it shows no signs of disappearing. If you’re reading this book, you likely understand that AD is simultaneously one of the most powerful and most vulnerable components in modern corporate networks. Before we dive into attacks and defenses, we need to establish a solid foundation of how Active Directory actually works, not just the marketing brochures, but the real technical architecture that makes it both indispensable and exploitable.

The truth is, Active Directory wasn’t designed with today’s threat landscape in mind. Microsoft introduced AD with Windows 2000, at a time when the primary security concerns were very different from what we face now. Design decisions made then created an architecture that prioritizes functionality, compatibility, and convenience over security. These decisions have cascaded into the security gaps that penetration testers exploit daily and that defenders struggle to close without breaking critical business functions.

Understanding AD architecture isn’t just academic knowledge: it’s the foundation that determines whether you’ll successfully compromise a domain or effectively defend it. Every attack vector we’ll explore later stems from architectural choices Microsoft made decades ago. Every defense strategy must work within these constraints. Let’s build that understanding from the ground up.

The Hierarchical Structure: Domains, Trees, and Forests

Active Directory organizes resources in a hierarchical structure that mirrors how organizations think about their business units and geographic locations. At its core, AD is a distributed database that stores information about users, computers, groups, and other objects. This database is organized into logical containers that provide both structure and security boundaries.

A domain is the fundamental administrative and security boundary in Active Directory. Think of it as a namespace (like CORPORATE.LOCAL) that contains a set of objects sharing a common database and security policies. Every object in that domain has a unique identity, and authentication happens within the domain’s context. From a security perspective, this matters: a domain represents a trust boundary where a single compromise can potentially affect everything within it.

Each domain has at least one domain controller, though production environments typically run multiple DCs for redundancy and load balancing. These domain controllers hold writable copies of the Active Directory database for their domain, and they replicate changes between each other. This replication model is both a strength and a weakness, it ensures availability but also means that compromising one DC gives an attacker access to replicate the entire domain database, including password hashes.

When multiple domains share a contiguous namespace, they form a tree. For example, CORPORATE.LOCAL might be the root domain, with SALES.CORPORATE.LOCAL and ENGINEERING.CORPORATE.LOCAL as child domains. These child domains automatically establish two-way transitive trust relationships with their parent, meaning users in SALES can potentially access resources in ENGINEERING without additional configuration. From an attacker’s perspective, these trusts are highways for lateral movement.

A forest is the ultimate security boundary in Active Directory. It represents one or more domain trees that share a common schema, configuration, and global catalog. The forest root domain is special, it contains enterprise-wide administrative groups like Enterprise Admins and Schema Admins. Compromise these groups, and you’ve compromised every domain in the forest. This is why penetration testers often focus on escalating privileges to the forest root, even if they initially breach a subsidiary domain.

The forest boundary matters because trusts within it are automatic and transitive. If Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A implicitly trusts Domain C. This transitivity creates attack paths that aren’t always obvious to administrators but are immediately visible to tools like BloodHound, which maps these relationships to identify privilege escalation routes.

Organizational Units: Structure Without Security

Within domains, administrators organize objects into Organizational Units, or OUs. OUs are containers that provide a way to structure objects and apply Group Policy settings, but here’s the critical distinction many security professionals miss: OUs are not security boundaries. They’re administrative containers that help with delegation and policy application, but they don’t provide isolation in the way domains do.

This distinction matters enormously in both attack and defense scenarios. An administrator might create separate OUs for different departments and delegate management of those OUs to different teams, believing this creates security separation. In reality, a Domain Admin has full control over all OUs in a domain, regardless of delegation. An attacker who compromises a Domain Admin account doesn’t care about your carefully crafted OU structure, they have the keys to everything.

OUs are most useful for applying Group Policy Objects, which define settings for users and computers within that OU. These policies can enforce security configurations, deploy software, and control user environments. Penetration testers frequently look for misconfigured Group Policies that might reveal sensitive information, grant excessive permissions, or contain cached credentials. Defenders use GPOs to enforce security baselines, deploy security software, and restrict user capabilities.

The OU structure also affects how administrators delegate permissions. You might grant a help desk team the ability to reset passwords for users in a specific OU, for instance. However, these delegations require careful management, overly permissive delegations create privilege escalation opportunities. An attacker with limited permissions in one OU might leverage those rights to modify ACLs, change group memberships, or otherwise escalate their privileges.

Trust Relationships: The Fabric of AD Compromise

Trust relationships are the mechanism by which different domains and forests establish authentication pathways. Understanding trusts is absolutely critical for both attackers and defenders, because they define how privilege escalation works across domain boundaries.

Within a forest, trusts are automatic, two-way, and transitive. When you add a child domain to a forest, it automatically trusts its parent, and the parent trusts it. Because these trusts are transitive, trust flows through the entire forest. This design prioritizes usability (users can seamlessly access resources across the organization) but it also means that compromising one domain can lead to compromise of the entire forest.

Forests can also establish trusts with other forests. These external trusts are explicitly configured and can be either one-way or two-way. In a one-way trust where Forest A trusts Forest B, users in Forest B can access resources in Forest A, but not vice versa. Administrators often think this provides security, if we only trust them, they can’t attack us, right? Wrong. Trust relationships don’t determine attack direction; they determine authentication flow. An attacker in Forest A can still target Forest B through various means, and that one-way trust might actually provide a path into Forest A for a skilled adversary.

The most dangerous trust configurations from a security perspective are often the oldest ones: trusts established years ago for a specific business need that no longer exists but was never removed. These legacy trusts create unexpected attack paths. Tools like PowerView and BloodHound excel at discovering and mapping trust relationships, showing attackers exactly how to pivot from their initial foothold to high-value targets across trust boundaries.

Forest trusts use a mechanism called Selective Authentication by default in modern AD deployments, which requires explicitly granting users from the trusted forest permission to authenticate to servers in the trusting forest. However, many organizations disable this feature because it requires more administrative overhead, defaulting to Forest-wide Authentication where any user from the trusted forest can authenticate anywhere in the trusting forest. This single configuration choice can determine whether a compromise stays contained or spreads across the entire enterprise.

Domain Controllers: The Crown Jewels

Domain controllers are the servers that authenticate users, enforce security policies, and manage the Active Directory database. In any AD environment, they are the ultimate target for attackers because they hold the keys to the kingdom.

Each domain controller maintains a writable copy of the Active Directory database, which includes password hashes for all users in the domain. These hashes are stored in a file called NTDS.dit, which is the single most valuable target in any AD environment. If an attacker gains local administrator access to a domain controller, they can extract this database and obtain every user’s password hash. From there, they can crack passwords offline, use pass-the-hash attacks, or create golden tickets that grant unlimited access to the domain.

Domain controllers also hold the Kerberos keys for the domain, including the KRBTGT account hash. This special account encrypts Kerberos Ticket Granting Tickets, and its compromise allows an attacker to forge authentication tickets for any user, including Domain Admins. These golden ticket attacks are particularly insidious because they persist even after password resets, only resetting the KRBTGT account itself (twice, due to replication) will invalidate forged tickets.

Most environments run multiple domain controllers per domain for redundancy. These DCs replicate changes between each other using the Active Directory replication protocol. This replication happens over RPC by default, using a sophisticated change notification system that ensures all DCs converge to the same state. However, replication creates another attack opportunity: DCSync. An attacker with replication privileges can impersonate a domain controller and request password hashes from another DC, extracting credentials without ever touching the NTDS.dit file.

Read-only domain controllers, or RODCs, were introduced to address scenarios where physical security of the DC couldn’t be guaranteed, think branch offices. RODCs maintain a read-only copy of the Active Directory database and don’t store passwords by default. They’re designed to limit the damage from physical compromise. However, RODCs introduce their own complexity and are often misconfigured in ways that reduce their security benefit. Many organizations deploy them, assume they’re secure, and don’t implement the additional controls needed to actually leverage their advantages.

The Protocol Trinity: LDAP, Kerberos, and DNS

Active Directory relies on three core protocols that work together to provide directory services and authentication. Understanding these protocols is essential because each one presents attack opportunities and requires specific defensive measures.

LDAP, the Lightweight Directory Access Protocol, is how clients query and modify Active Directory. When an application needs to look up user information, verify group membership, or search for computers, it uses LDAP. The protocol operates on port 389 for unencrypted traffic and port 636 for LDAPS (LDAP over SSL). Here’s a critical security issue: LDAP by default doesn’t require encryption or signing, which means attackers can intercept LDAP traffic to capture credentials or perform relay attacks.

LDAP queries are powerful and flexible, using a filter syntax that allows complex searches. Attackers use LDAP extensively during reconnaissance to enumerate users, groups, computers, and organizational structure. Tools like ldapsearch and PowerView make it trivial to extract vast amounts of information from Active Directory through LDAP. Many organizations don’t realize how much information authenticated users can access by default. An attacker with a single low-privileged account can map the entire domain structure, identify administrators, and discover service accounts that might be vulnerable to Kerberoasting attacks.

Kerberos is the authentication protocol in Active Directory, replacing the older NTLM protocol. When you understand Kerberos, you understand why so many AD attacks work the way they do. The basic Kerberos flow involves three parties: the client, the service the client wants to access, and the Key Distribution Center (the domain controller). The client requests a Ticket Granting Ticket from the KDC, then uses that TGT to request Service Tickets for specific resources.

This design has several security implications. First, Kerberos tickets include authorization data about the user, including group memberships. Attackers can request Service Tickets for any service principal name in the domain, and these tickets are encrypted with the service account’s password hash. If that service account has a weak password, an attacker can perform a Kerberoasting attack, extracting the ticket and cracking it offline to recover the password.

Kerberos also relies on time synchronization. Tickets have timestamps, and if a client’s clock is more than five minutes off from the domain controller, authentication fails. This seems like a small detail, but it matters for detecting certain attacks. Golden ticket attacks, where an attacker forges a TGT using the KRBTGT hash, can include unrealistic ticket lifetimes, like ten years. Defenders can detect these by looking for unusual ticket lifetimes.

DNS is the third critical protocol, and it’s often overlooked in AD security discussions. Active Directory is deeply integrated with DNS: domain controllers register service locator records that clients use to find authentication services. When a computer boots up and needs to authenticate, it performs DNS queries to locate domain controllers. When a user tries to access a file share, their computer queries DNS to resolve the server name.

This DNS dependency creates attack opportunities. An attacker who can poison DNS responses can redirect authentication traffic to malicious servers, potentially capturing credentials. DNS-based attacks like WPAD spoofing and LLMNR/NBT-NS poisoning exploit this dependency. Additionally, many organizations allow dynamic DNS updates without proper security, enabling attackers to register malicious records that facilitate man-in-the-middle attacks.

The Replication Architecture and Security Implications

Active Directory replication ensures that all domain controllers maintain synchronized copies of the directory database. Understanding replication matters because it affects both availability and security in ways that aren’t immediately obvious.

Replication in AD is multi-master, meaning any domain controller can accept writes. When an administrator creates a user on DC1, that change replicates to DC2, DC3, and all other DCs in the domain. This design maximizes availability, if one DC goes down, others continue handling authentication. It also means that compromising any single domain controller gives an attacker access to the entire domain database.

Replication happens at the attribute level, not the object level. When someone changes a user’s phone number, AD only replicates that specific attribute change, not the entire user object. This granular approach reduces replication traffic but introduces complexity in conflict resolution. If two administrators simultaneously change different attributes on the same user, both changes replicate and merge. If they change the same attribute, AD has rules to determine which change wins, generally, the last write wins, but version numbers and timestamps determine the outcome.

The replication topology is managed automatically by the Knowledge Consistency Checker, which creates connection objects between domain controllers. In a site with multiple DCs, you’ll see a ring topology where each DC replicates with at least two others, ensuring redundancy. Between sites, replication happens according to site link schedules, which administrators configure based on WAN bandwidth and cost.

From a security perspective, replication creates several concerns. Replication traffic contains sensitive data, including password hashes during full synchronizations. This traffic should be protected, but in many environments, replication happens over the network without additional encryption beyond what Kerberos provides. Second, the DCSync attack exploits replication permissions. By default, domain controllers can request replication of any object, including the KRBTGT account and Domain Admin users. If an attacker gains replication permissions (either by compromising a DC or by exploiting excessive permissions) they can extract all domain credentials remotely.

Authentication Flow and Attack Surface

The authentication flow in Active Directory involves multiple steps, each of which presents potential attack opportunities. A typical authentication starts when a user enters their username and password at the Windows login screen. The local system constructs an authentication request, locates a domain controller through DNS, and sends the credentials.

What happens next depends on the protocol negotiated. If NTLM is used, the password is hashed locally, and that hash is sent to the domain controller for verification. NTLM is an older protocol that Microsoft has been trying to deprecate for years, but it persists in many environments for compatibility. NTLM is vulnerable to relay attacks, where an attacker intercepts the authentication handshake and forwards it to another service, authenticating as the victim user.

If Kerberos is negotiated, the client requests a TGT from the domain controller. This TGT is encrypted with the user’s password-derived key, so only the legitimate user can decrypt it. The client then uses this TGT to request Service Tickets for resources they want to access. Each Service Ticket is encrypted with the target service’s password hash and includes authorization data about the user.

This flow seems secure in theory, but the details create vulnerabilities. Kerberos pre-authentication can be disabled on a per-user basis, allowing attackers to request TGTs for any user without knowing their password, these requests include encrypted data that can be cracked offline. This is called AS-REP Roasting. Service Tickets are encrypted with service account hashes, enabling Kerberoasting. The TGT itself can be extracted from memory and used for pass-the-ticket attacks.

Cached credentials complicate the picture further. When a user logs into a domain-joined computer, Windows caches their credentials locally so they can still log in if the computer can’t reach a domain controller. These cached credentials are stored in the local Security Account Manager database and the LSA Secrets. An attacker with local administrator privileges can extract these and use them for lateral movement.

Why Active Directory Security Is Challenging

Active Directory’s security challenges stem from fundamental design decisions that prioritize functionality and backward compatibility over security. Microsoft has made numerous security improvements over the years (NTLM v2, Kerberos armoring, Protected Users group, Credential Guard) but the core architecture remains largely unchanged since Windows 2000.

The biggest challenge is that security and usability are often in direct conflict in AD environments. Disabling NTLM would eliminate relay attacks, but it breaks legacy applications. Implementing least privilege would reduce attack surface, but requires extensive documentation of application dependencies and frequent administrative overhead. Enforcing SMB signing would prevent many attacks, but requires careful testing to avoid breaking file shares.

Many security issues in AD are actually features working as designed. Domain Admins need full control over all computers in the domain: that’s not a vulnerability, it’s a requirement. Service accounts need to be able to authenticate across the network. Kerberoasting exploits this necessary functionality. Domain controllers replicate password hashes. DCSync abuses this required mechanism.

This creates a difficult situation for defenders. You can’t simply patch away Active Directory vulnerabilities because they’re often inherent in the architecture. Instead, you must implement defense-in-depth strategies that assume compromise will happen and focus on detection, containment, and reducing blast radius. Many attack techniques aren’t exploiting bugs, they’re leveraging features.

The path forward requires understanding both how attacks work and why the architecture enables them. In the following chapters, we’ll dive deep into specific attack techniques, examining exactly how they exploit AD architecture. We’ll then explore defensive strategies that work within the architectural constraints, building layers of security that make an attacker’s job harder at every step.

Active Directory isn’t going away anytime soon, despite predictions about the cloud killing on-premises infrastructure. Even organizations moving to Azure AD maintain hybrid configurations with on-premises Active Directory. Understanding AD architecture isn’t just about defending legacy systems: it’s about understanding the foundation that modern enterprise identity still builds upon. Whether you’re attacking or defending Active Directory, this architectural knowledge is what separates script kiddies from skilled professionals.

As we move forward, keep this architecture in mind. Every attack we discuss exploits some aspect of domains, trusts, protocols, or authentication flows covered here. Every defense must work within these constraints. Active Directory security is a chess game, and you’ve just learned how the pieces move. Now let’s learn how to play.

… and that is just the beginning. The complete book continues from here, instant download, DRM-free, yours to keep.