Why Active Directory ?

Active Directory (AD) is a directory service for Windows-based network environments. It provides a distributed, hierarchical structure that facilitates centralized management of organizational resources, including users, computers, groups, network devices, file shares, group policies, and trusts.

AD delivers authentication and authorization within a Windows domain and is integral to enterprise infrastructure. However, it is inherently backward-compatible, which often results in configurations that are not secure by default. This, combined with its complexity, makes AD environments highly susceptible to misconfiguration and exploitation.

Security Considerations and Common Weaknesses

One of AD's core vulnerabilities is its accessibility. By default, standard domain user accounts—with no elevated privileges—can read a significant portion of the directory. This read access includes critical data such as user objects, group memberships, and domain trust relationships. As a result, adversaries can perform reconnaissance and identify attack paths using minimal access.

A properly secured Active Directory implementation is crucial. Misconfigurations, excessive privileges, and poor segmentation allow attackers to move laterally and vertically within the domain. A defense-in-depth strategy, least privilege access control, and segmentation are essential to mitigate risk.

One example of an AD-related vulnerability is the noPac attack, disclosed in December 2021. This exploit chain demonstrated how a standard user could escalate privileges using a combination of misconfigurations and flaws in the AD environment.

Scalability and Real-World Usage

Active Directory is highly scalable, capable of supporting millions of objects per domain. Organizations can create additional domains to support growth and organizational segmentation. Due to its flexibility and manageability, AD remains the dominant directory service globally.

Approximately 95% of Fortune 500 companies use Active Directory. This prevalence makes AD a prime target for adversaries, particularly those deploying ransomware or other large-scale attack campaigns.

Such attacks demonstrate the critical need for security professionals to understand AD's structure and behavior. Even standard user accounts can be exploited to gain domain-wide control if proper safeguards are not in place.

History of Active Directory

LDAP, the foundation of Active Directory, was first introduced in RFCs as early as 1971. Active Directory was predated by the X.500 organizational unit concept, which was the earliest version of all directory systems created by Novell and Lotus and released in 1993 as Novell Directory Services.

Active Directory was first introduced in the mid-1990s but did not become part of the Windows operating system until the release of Windows Server 2000. Microsoft first attempted to provide directory services in 1990 with the release of Windows NT 3.0. This operating system combined features of the LAN Manager protocol and the OS/2 operating systems, which Microsoft initially created in collaboration with IBM, led by Ed Iacobucci—who also led the design of IBM DOS and later co-founded Citrix Systems.

The NT operating system evolved throughout the 1990s, adapting protocols such as LDAP and Kerberos alongside Microsoft's proprietary elements. The first beta release of Active Directory was made available in 1997.

Major Milestones and Enhancements

The release of Windows Server 2003 introduced extended functionality, improved administration capabilities, and added the Forest feature. This allowed system administrators to create "containers" for separate domains, users, computers, and other objects, grouped under a common structure for better management and segmentation.

Active Directory Federation Services (ADFS) was introduced in Windows Server 2008 to enable Single Sign-On (SSO) capabilities across systems and applications. ADFS streamlined user access by allowing authentication across different applications without requiring separate logins, even outside the local area network (LAN).

ADFS uses a claims-based Access Control Authorization model. In this model, user identity is represented by a set of claims, which are packaged into a security token by the identity provider. This approach enhances security and interoperability across organizational boundaries.

With the release of Windows Server 2016, additional improvements were introduced, such as the capability to migrate Active Directory environments to the cloud and enhanced security mechanisms. Notable among these were features like Group Managed Service Accounts (gMSA), which provide a secure way to run automated tasks, applications, and services.

gMSA is often recommended as a mitigation against the Kerberoasting attack, a technique frequently used by attackers to extract service account credentials from AD environments.

Cloud Integration and Continued Evolution

In 2016, Microsoft further emphasized cloud integration with the release of Azure AD Connect. This tool facilitates synchronization between on-premises Active Directory and Microsoft Office 365, offering a unified Single Sign-On experience for hybrid environments.

Despite these advancements, Active Directory continues to suffer from misconfigurations. From its introduction in 2000 through the present, new vulnerabilities are regularly discovered—not only within AD itself, but also in interconnected technologies like Microsoft Exchange.

As security researchers uncover flaws, organizations must prioritize patching and configuration management. Penetration testers are often tasked with identifying these weaknesses before adversaries can exploit them.

Ubiquity and Real-World Relevance

As previously mentioned, 95% of Fortune 500 companies run Active Directory. Microsoft holds a near-monopoly in the directory services market. While cloud and hybrid deployments are becoming more common, on-premises AD is still deeply entrenched in most enterprises.

In network penetration testing engagements, encountering Active Directory in some capacity is virtually guaranteed. Therefore, developing a robust understanding of its architecture and attack surface is essential for successful engagements and meaningful remediation guidance.

Attacks & Tools Timeline

Active Directory has been a major area of focus for security researchers for the past decade. Beginning around 2014, a significant surge in tools and academic research began to shape the current understanding of AD security. This period led to the discovery of numerous common attack techniques, many of which remain widely used and relevant to this day.

The timeline presented below outlines some of the most impactful attacks and vulnerabilities uncovered by leading security researchers, as well as the release of essential tools that have become staples in the penetration testing field. Despite the age of many of these methods, Active Directory—along with its cloud-based counterpart Azure AD—continues to present a large and complex attack surface.

Structure

Active Directory (AD) is a directory service for Windows network environments. It is a distributed, hierarchical structure that allows for centralized management of an organization's resources, including users, computers, groups, network devices and file shares, group policies, servers and workstations, and trusts.

AD provides authentication and authorization functions within a Windows domain environment. A directory service such as Active Directory Domain Services (AD DS) enables organizations to store directory data and make it available to both standard users and administrators across the network.

AD DS stores essential identity information such as usernames and passwords and enforces access control by managing the rights and permissions required by users to access these resources. First released with Windows Server 2000, Active Directory has since become a core component of enterprise infrastructure but is increasingly targeted due to its complexity and frequent misconfigurations.

Security Challenges and Misconfigurations

Active Directory is designed with backward compatibility in mind, meaning that many features are not secure by default. In large environments, AD is difficult to configure and manage securely, increasing the risk of vulnerabilities.

Flaws and misconfigurations in AD are frequently exploited to gain initial access, move laterally and vertically across a network, and escalate privileges. Once compromised, AD can provide unauthorized access to protected resources, including databases, shared files, source code repositories, and more.

AD functions as a large directory database accessible by all users within the domain, regardless of their privilege level. A standard user account, even without administrative privileges, can enumerate a wide range of objects within the AD structure.

Objects Exposed to Basic Domain Users

The following information is commonly accessible to unauthenticated or minimally privileged users in an AD environment:

Active Directory Structure

Active Directory is organized into a hierarchical tree structure. At the top of the hierarchy is the forest, which acts as a security boundary and contains one or more domains. Each domain may, in turn, contain child domains, forming a nested structure.

A forest represents the outermost boundary of security and administrative authority. It contains all the domains and defines the scope within which trust relationships and policy enforcement exist.

A domain is a logical grouping of AD objects, such as users, groups, and computers. Domains enforce policies and access permissions for their contained objects.

Domains include built-in Organizational Units (OUs) like Users, Computers, and Domain Controllers. Administrators can create custom OUs as needed. OUs can contain both AD objects and additional sub-OUs, enabling granular assignment of group policies and delegation of administrative tasks.

At a high level, an Active Directory (AD) structure can be visualized hierarchically. The following example illustrates a simplified tree structure of a fictional AD environment:

INLANEFREIGHT.LOCAL/
├── ADMIN.INLANEFREIGHT.LOCAL
│   ├── GPOs
│   └── OU
│       └── EMPLOYEES
│           ├── COMPUTERS
│           │   └── FILE01
│           ├── GROUPS
│           │   └── HQ Staff
│           └── USERS
│               └── barbara.jones
├── CORP.INLANEFREIGHT.LOCAL
└── DEV.INLANEFREIGHT.LOCAL

In this example, INLANEFREIGHT.LOCAL represents the root domain. It contains multiple child domains such as ADMIN.INLANEFREIGHT.LOCAL, CORP.INLANEFREIGHT.LOCAL, and DEV.INLANEFREIGHT.LOCAL. These subdomains may represent different organizational units, departments, or geographic locations. Each domain manages its own objects including users, groups, organizational units (OUs), and Group Policy Objects (GPOs).

Creating distinct domains within a forest is common practice in larger organizations. For enterprises that grow through mergers or acquisitions, it is often more efficient to establish a trust relationship with another domain or forest than to recreate all user accounts and objects within a single domain. However, this practice introduces potential security risks if the trust relationships are not configured and managed properly.

Inter-Forest Trusts and Security Implications

In environments with multiple forests, such as INLANEFREIGHT.LOCAL and FREIGHTLOGISTICS.LOCAL, bidirectional trust relationships can be established to allow cross-forest authentication and resource access. This setup enables users in one forest to access resources in the other, provided that permissions and trust paths are properly defined.

It is important to understand that even though a bidirectional trust exists between the root domains, this does not imply that all subdomains automatically trust one another. For example, a user in admin.dev.freightlogistics.local would not, by default, be able to authenticate to machines within the wh.corp.inlanefreight.local domain. A separate trust relationship would need to be explicitly configured to permit such access.

Improperly scoped or overly permissive trust relationships can become significant attack vectors. Attackers who compromise a user or machine in one domain may attempt to pivot into a trusted domain or forest, especially in cases where misconfigured or excessive trust settings allow for such traversal.

Terminology

Before exploring advanced concepts, it is essential to understand the core terminology used in Active Directory environments. This section outlines foundational terms that will be referenced throughout this and related modules.

Objects

In Active Directory (AD), the term "object" refers to any resource present within the AD environment. This includes organizational units (OUs), users, computers, printers, groups, domain controllers, and more.

Users

User objects represent individual users within the organization's AD environment. These are leaf objects, meaning they cannot contain any other objects. Similar to mailboxes in Microsoft Exchange, user objects are security principals and therefore possess both a Security Identifier (SID) and a Globally Unique Identifier (GUID). They contain numerous attributes, such as display name, last login time, password last set date, email address, account description, manager, address, among others. An AD environment can theoretically support over 800 different attributes per user, although only a subset is typically populated. Due to the privileges user accounts may provide, even low-privileged user accounts can be a critical target for attackers aiming to enumerate the entire domain or forest.

Contacts

Contact objects are used to represent external users. These are informational-only, non-security principal objects and do not have a SID—only a GUID. Typical attributes include first name, last name, email address, and telephone number. Contacts are used in scenarios such as representing third-party vendors or customers.

Printers

Printer objects represent printers accessible within the AD network. Like contacts, printers are leaf objects and not security principals, having only a GUID. Attributes of printer objects include printer name, driver details, port number, and other relevant metadata.

Computers

Computer objects represent workstations or servers joined to the AD network. They are leaf objects but are also considered security principals, and thus have both a SID and a GUID. Computer accounts are valuable targets for attackers, especially if they can escalate to NT AUTHORITY\SYSTEM, which has privileges similar to or greater than a standard domain user. These accounts can perform many domain enumeration tasks.

Shared Folders

Shared folder objects reference shared directories located on specific systems within the AD environment. These are not security principals and only have a GUID. Access control to shared folders can vary significantly—from being publicly accessible to strictly restricted. Common attributes include the folder name, physical path, and access control settings.

Groups

Group objects serve as containers for other objects such as users, computers, and other groups. Groups are security principals with both a SID and a GUID. They are primarily used to manage access to AD resources efficiently. Instead of assigning permissions individually, users can inherit permissions through group membership. AD also supports nested groups, where a group is a member of another group. This configuration can lead to complex permission inheritance chains, which tools like BloodHound can help to audit and visualize. Common group attributes include group name, description, membership list, and parent group associations.

Organizational Units (OUs)

OUs are containers used by administrators to logically organize AD objects. They enable administrative delegation and policy management without requiring full domain administrative rights. For example, an OU structure could allow Help Desk staff to reset passwords within a specific department but not company-wide. Group Policy Objects (GPOs) can be linked to OUs to enforce specific configurations like password policies. OU attributes include its name, linked policies, security permissions, and the objects it contains.

Domain

A domain is the foundational structure of an Active Directory network. It contains all AD objects and governs them using domain-level policies and a separate database. Default domain policies (such as password policy) can be customized, and additional policies can be created to enforce restrictions like command-line access or drive mapping. Domains encapsulate all authentication and policy enforcement within a boundary.

Domain Controllers

Domain Controllers (DCs) are the central authority within an AD domain. They manage authentication requests, validate credentials, enforce security policies, and store directory information for all objects. DCs are critical to the functionality and security of the entire AD infrastructure.

Sites

Sites in Active Directory represent collections of IP subnets connected by high-speed links. Their primary purpose is to optimize replication traffic between domain controllers, ensuring efficient data synchronization across geographically distributed environments.

Built-in

The Built-in container holds default security groups that are automatically created when an AD domain is initialized. These groups are predefined and serve common administrative roles and functions within the domain.

Foreign Security Principals (FSPs)

Foreign Security Principals are objects created to represent users, computers, or groups from trusted external forests. They are automatically generated when a foreign object is added to a local group. Each FSP acts as a placeholder that holds the foreign object's SID, allowing the domain to recognize and resolve it through the established trust relationship. These objects reside within the ForeignSecurityPrincipals container and have distinguished names like cn=ForeignSecurityPrincipals,dc=domain,dc=local.

Functionality

Active Directory includes five Flexible Single Master Operation (FSMO) roles, each responsible for specific critical tasks that ensure consistency and proper functioning across the AD environment. These roles may be assigned to designated domain controllers (DCs) and are essential for authentication, authorization, and directory integrity.

FSMO Roles

Misconfiguration or failure of FSMO roles may lead to authentication and authorization problems throughout the domain.

Domain and Forest Functional Levels

Functional levels in Active Directory determine which features are available within a domain or forest, and which versions of Windows Server can operate as domain controllers. Raising the functional level enables new capabilities but requires all DCs to be running compatible versions of Windows Server.

Domain Functional Levels

No new functional level was introduced with Windows Server 2019. However, Windows Server 2008 functional level is the minimum required to integrate Server 2019 domain controllers. Additionally, DFS Replication (DFS-R) must be used for SYSVOL replication in such environments.

Forest Functional Levels

Trusts

A trust allows user authentication and resource access across domains or forests. It links authentication systems and can be either transitive or non-transitive, and one-way or two-way, depending on access requirements and administrative intent.

Trust relationships can be transitive, allowing access through nested trusts, or non-transitive, restricting access to only the directly trusted domain. Trusts may also be one-way or bidirectional. In a one-way trust, only the trusted domain's users can access the trusting domain's resources. Improperly configured trusts can introduce serious security risks, particularly when established hastily during mergers and acquisitions. It is not uncommon to exploit misconfigured trusts for attacks such as Kerberoasting to gain privileged access across domains.

While Windows operating systems use a variety of protocols to communicate, Active Directory specifically requires the Lightweight Directory Access Protocol (LDAP), Microsoft's version of Kerberos, DNS for authentication and communication, and MSRPC, which is the Microsoft implementation of Remote Procedure Call (RPC), an interprocess communication technique used for client-server model-based applications.

Kerberos

Kerberos has been the default authentication protocol for domain accounts since Windows 2000. Kerberos is an open standard and allows for interoperability with other systems using the same standard. When a user logs into their PC, Kerberos is used to authenticate them via mutual authentication, where both the user and the server verify their identity. Kerberos is a stateless authentication protocol based on tickets instead of transmitting user passwords over the network.

As part of Active Directory Domain Services (AD DS), Domain Controllers include a Kerberos Key Distribution Center (KDC) that issues tickets. When a user initiates a login request to a system, the client requests a ticket from the KDC, encrypting the request with the user's password. If the KDC can decrypt the request (AS-REQ) using the user's password, it creates a Ticket Granting Ticket (TGT) and transmits it to the client.

The client then presents its TGT to a Domain Controller to request a Ticket Granting Service (TGS) ticket, which is encrypted using the service's NTLM password hash. Finally, the client requests access to the desired service by presenting the TGS to the target application or service, which decrypts it with its own password hash. If all steps are completed successfully, the user is granted access to the resource.

Kerberos authentication effectively decouples users' credentials from their requests to consumable resources, ensuring that passwords are not transmitted over the network (e.g., accessing an internal SharePoint intranet site). The Kerberos Key Distribution Center (KDC) does not retain previous transactions. Instead, the Ticket Granting Service (TGS) relies on the validity of the TGT. If a user holds a valid TGT, it is assumed they have already been authenticated.

Kerberos Authentication Process

1. When a user logs in, their password is used to encrypt a timestamp, which is sent to the Key Distribution Center (KDC) to verify authentication integrity. If successful, the KDC issues a Ticket Granting Ticket (TGT), encrypted with the krbtgt account's secret key. This TGT is later used to request service tickets for accessing resources.
2. The KDC verifies the Authentication Service Request (AS-REQ), validates user credentials, and returns the TGT to the user.
3. The user presents the TGT in a Ticket Granting Service Request (TGS-REQ) to request a service ticket for a specific service. If the TGT is valid, the KDC creates and returns a TGS ticket.
4. The TGS is encrypted using the NTLM password hash of the target service or computer account. This ticket is sent to the user in the TGS-REP.
5. The user sends the TGS to the target service as an Application Request (AP-REQ). If the ticket is valid, access is granted.

The Kerberos protocol uses port 88 (TCP and UDP). When enumerating an Active Directory environment, Domain Controllers can often be identified by scanning for open port 88 using tools such as nmap.

DNS

Active Directory Domain Services (AD DS) uses DNS to allow clients—such as workstations, servers, and other systems communicating with the domain—to locate Domain Controllers. DNS is also used for communication between Domain Controllers hosting directory services.

DNS resolves hostnames to IP addresses and is used across both internal networks and the internet. Private internal networks leverage Active Directory DNS namespaces to facilitate communication between servers, clients, and peers. AD maintains a DNS-based database of services in the form of Service (SRV) records, which allow clients to locate needed services like file servers, printers, or Domain Controllers.

Dynamic DNS (DDNS) automatically updates entries in the DNS database when a system's IP address changes. This automation prevents the need for manual entry, which can be time-consuming and error-prone. If DNS records are incorrect or missing, clients may be unable to locate and communicate with target hosts.

When a client joins the network, it queries DNS to locate a Domain Controller. The client retrieves the SRV record from the DNS database and uses the Domain Controller's hostname to resolve its IP address. DNS uses both UDP and TCP port 53. By default, UDP is used; however, if the communication fails or the DNS message exceeds 512 bytes, DNS will fall back to TCP.

Forward DNS Lookup

A forward DNS lookup allows us to resolve the IP address of a given domain. For example, we can retrieve the IP address of the Domain Controller for INLANEFREIGHT.LOCAL using nslookup:

PS C:\htb> nslookup INLANEFREIGHT.LOCAL

Server:  172.16.6.5
Address:  172.16.6.5

Name:    INLANEFREIGHT.LOCAL
Address:  172.16.6.5

Reverse DNS Lookup

A reverse DNS lookup allows us to resolve the DNS name of a host given its IP address:

PS C:\htb> nslookup 172.16.6.5

Server:  172.16.6.5
Address:  172.16.6.5

Name:    ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
Address:  172.16.6.5

Finding IP Address of a Host

We can also resolve a host's IP address using its name (with or without its Fully Qualified Domain Name):

PS C:\htb> nslookup ACADEMY-EA-DC01

Server:   172.16.6.5
Address:  172.16.6.5

Name:    ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
Address:  172.16.6.5

LDAP

Active Directory supports the Lightweight Directory Access Protocol (LDAP) for directory lookups. LDAP is an open-source, cross-platform protocol used to authenticate against various directory services, including AD. The latest version of LDAP is LDAPv3, defined in RFC 4511.

LDAP uses TCP port 389, while LDAP over SSL (LDAPS) uses TCP port 636. A firm understanding of LDAP in AD environments is essential for both attackers and defenders.

AD stores user credentials and security data, such as passwords, and shares this information with other devices across the network. LDAP acts as the query language that applications use to retrieve data from directory services. In simple terms, LDAP is how systems in the environment "speak" to AD.

An LDAP session begins with a connection to an LDAP server, also referred to as a Directory System Agent. In AD environments, Domain Controllers listen for incoming LDAP requests, including those related to authentication.

The relationship between AD and LDAP is similar to that of Apache and HTTP: just as Apache is a web server using the HTTP protocol, Active Directory is a directory server using the LDAP protocol.

While uncommon, some organizations may use LDAP without Active Directory, typically employing alternatives such as OpenLDAP servers.

AD LDAP Authentication

LDAP authentication in AD is based on a BIND operation, which sets the authentication state for an LDAP session. There are two main types of LDAP authentication:

• Simple Authentication: This method includes anonymous, unauthenticated, and username/password authentication. The client sends a BIND request with a username and password to authenticate against the LDAP server.
• SASL Authentication: The Simple Authentication and Security Layer (SASL) framework integrates with external authentication mechanisms such as Kerberos. The LDAP server sends an LDAP message to the authentication service, which initiates a challenge-response sequence that results in either successful or failed authentication. SASL improves security by decoupling authentication from the application protocol.

Important: By default, LDAP messages are transmitted in cleartext. This means credentials and queries can be intercepted by attackers monitoring internal traffic. It is recommended to use TLS encryption (LDAPS) or other secure transport methods to protect LDAP communications.

MSRPC

MSRPC (Microsoft Remote Procedure Call) is Microsoft’s implementation of the Remote Procedure Call (RPC) protocol, which enables interprocess communication across a network. It is widely used in Windows systems for enabling client-server communication. Within Active Directory environments, MSRPC provides access to key services via four major RPC interfaces.

NTLM

In addition to Kerberos and LDAP, Active Directory supports other authentication protocols, including LM, NTLM, NTLMv1, and NTLMv2. LM and NTLM refer to password hashing formats, while NTLMv1 and NTLMv2 are authentication protocols that utilize those hashes. Understanding the distinction between hash types and authentication protocols is critical in assessing security exposure.

Hash/Protocol Comparison

LM (LAN Manager) Hash were introduced in 1987 and are now deprecated due to weak encryption. Passwords are limited to 14 uppercase characters and split into two 7-character chunks before being hashed using DES. The resulting LM hash is vulnerable to brute-force attacks using tools like Hashcat. LM hashes are stored in the SAM or NTDS.dit databases. They can be disabled via Group Policy. An LM hash looks like:

299bd128c1101fd6

NTLM (NT Hash)

NTLM is a challenge-response protocol. It uses three message types: NEGOTIATE_MESSAGE, CHALLENGE_MESSAGE, and AUTHENTICATE_MESSAGE. The NT hash is computed using MD4 on the UTF-16LE encoded password:

MD4(UTF-16-LE(password))

NTLM hashes are vulnerable to brute-force attacks and pass-the-hash attacks. An NT hash example:

b4b9b02e6f09a9bd760f388b67351e2b

NTLM Hash Example Breakdown

Rachel:500:aad3c435b514a4eeaad3b935b51304fe:e46b9e548fa0d122de7f59fb6d48eaa2:::

• Rachel – Username
• 500 – RID (Administrator account)
• aad3c435b514a4ee... – LM hash (empty if LM is disabled)
• e46b9e548fa0d122... – NT hash (usable for cracking or pass-the-hash)

Pass-the-Hash Example

crackmapexec smb 10.129.41.19 -u rachel -H e46b9e548fa0d122de7f59fb6d48eaa2

NTLMv1

NTLMv1 uses challenge-response with LM/NT hashes. It's vulnerable to relay attacks and offline cracking. Notably, these hashes cannot be used in pass-the-hash attacks.

C = 8-byte challenge
response = DES(K1, C) | DES(K2, C) | DES(K3, C)

NTLMv1 hash example:

u4-netntlm::kNS:338d08f8e26de9330000000000000000:9526fb8c23a90751cdd619b6cea56474:cb8086049ec4736c

NTLMv2

Introduced in Windows NT 4.0 SP4, NTLMv2 enhances security by using HMAC-MD5 and includes server and client challenges, timestamps, and domain data.

SC = server challenge, CC = client challenge
LMv2 = HMAC-MD5(v2-Hash, SC, CC)
NTv2 = HMAC-MD5(v2-Hash, SC, CC*)

NTLMv2 hash example:

admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c783031...

Domain Cached Credentials (MSCache2)

When a domain-joined host cannot contact a Domain Controller, it uses Domain Cached Credentials (DCC). These credentials are stored in the Windows registry:

HKEY_LOCAL_MACHINE\SECURITY\Cache

DCC hashes cannot be used in pass-the-hash attacks and are difficult to crack even with high-performance cracking rigs. Example MSCache2 hash:

$DCC2$10240#bjones#e4e938d12fe5974dc42a90120bd9c90f

User and Machine Accounts

User accounts are created on both local systems (not joined to AD) and in Active Directory to allow a person or a service to log on and access resources based on their assigned rights. When a user logs in, the system verifies the password and creates an access token containing the user’s identity and group memberships. This token is used whenever the user interacts with a process or requests access to a resource.

Users can be added to groups, which simplify access control management by allowing administrators to assign permissions to a group rather than to individual users. Group membership makes it easier to grant, audit, and revoke access in a scalable way.

Provisioning of Accounts

Every user in an AD environment typically has at least one user account. Admins, Help Desk staff, or service users may have multiple accounts based on role. In large organizations, it is common to see hundreds of deactivated accounts (former employees, contractors, interns). These are often stored in dedicated OUs like FORMER EMPLOYEES and are kept for auditing purposes.

Default Local Accounts

Local accounts exist only on a specific host and can only access resources on that host. Their rights are managed individually or through local group membership. These are the default local accounts on a Windows system:

Domain Users

Domain users are granted permissions through Active Directory to access resources such as file shares, printers, and applications. These accounts can log in to any domain-joined system, and their access is governed by Group Policy and AD configurations.

One special account is the KRBTGT account, used by the Kerberos Key Distribution Center (KDC). If compromised, it can be abused for attacks like Golden Ticket, granting persistent and unrestricted access to the domain.

User Naming Attributes in Active Directory

Example: Get-ADUser Query

PS C:\htb> Get-ADUser -Identity htb-student

DistinguishedName : CN=htb student,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
Enabled           : True
GivenName         : htb
Name              : htb student
ObjectClass       : user
ObjectGUID        : aa799587-c641-4c23-a2f7-75850b4dd7e3
SamAccountName    : htb-student
SID               : S-1-5-21-3842939050-3880317879-2865463114-1111
Surname           : student
UserPrincipalName : htb-student@INLANEFREIGHT.LOCAL

Domain-Joined vs Non-Domain-Joined Hosts

Domain-Joined Machines

Domain-joined hosts are centrally managed via Active Directory. Group Policies apply automatically, and users can access resources across the domain. This is the standard in enterprise environments.

Non-Domain-Joined Machines

These hosts operate in standalone or workgroup configurations. Users and policies are local to the host. This setup is typical for home or small office systems and lacks centralized control.

Access with SYSTEM Context

SYSTEM-level access on a domain-joined host provides capabilities equivalent to a standard domain user. Attackers who gain SYSTEM privileges on a domain host can access a wide range of domain resources and enumerate AD without needing valid credentials. This access is often underestimated but is a powerful pivot point in domain attacks.

Groups

After user accounts, groups are a fundamental object class in Active Directory. They simplify the assignment of access rights to multiple users and are a common target for attackers due to their potential to grant excessive or misconfigured privileges. Groups can be used to organize users by role or function and manage access to resources more efficiently. Organizations often create both built-in and custom groups, which may grow in complexity and size over time, necessitating regular auditing.

Groups vs Organizational Units (OUs)

Groups are primarily used to assign permissions to access resources, whereas Organizational Units (OUs) are used to apply Group Policy Objects (GPOs) and delegate administrative control. While OUs help in structural organization, groups help in access control and resource assignment.

Types of Groups

Groups can contain users, computers, and other groups. They simplify permission assignments. For instance, instead of assigning access to 50 individual users, a group can be created to manage permissions centrally.

Group Type and Scope

When creating a group, administrators must define its type and scope. The two group types are:

• Security Groups: Used to assign permissions and user rights.
• Distribution Groups: Used to send emails (e.g., via Exchange). Cannot be used for permissions.

Group Scopes

Group scope determines how and where the group can be used within the AD forest:

• Domain Local: Can assign permissions to resources in the same domain. Can include users from other domains. Cannot be nested in Global Groups.
• Global: Can include only objects from its domain, but can be assigned permissions in any domain.
• Universal: Can include users from any domain and assign permissions across the entire forest. Stored in the Global Catalog and subject to forest-wide replication.

Group Scope Management Example

PS C:\htb> Get-ADGroup -Filter * | select samaccountname, groupscope

samaccountname                           groupscope
--------------                           ----------
Administrators                          DomainLocal
Users                                   DomainLocal
Guests                                  DomainLocal
Print Operators                         DomainLocal
Backup Operators                        DomainLocal
Replicator                              DomainLocal
Remote Desktop Users                    DomainLocal
Network Configuration Operators         DomainLocal
Distributed COM Users                   DomainLocal
IIS_IUSRS                               DomainLocal
Cryptographic Operators                 DomainLocal
Event Log Readers                       DomainLocal
Certificate Service DCOM Access         DomainLocal
RDS Remote Access Servers               DomainLocal
RDS Endpoint Servers                    DomainLocal
RDS Management Servers                  DomainLocal
Hyper-V Administrators                  DomainLocal
Access Control Assistance Operators     DomainLocal
Remote Management Users                 DomainLocal
Storage Replica Administrators          DomainLocal
Domain Computers                             Global
Domain Controllers                           Global
Schema Admins                             Universal
Enterprise Admins                         Universal
Cert Publishers                         DomainLocal
Domain Admins                                Global
Domain Users                                 Global
Domain Guests                                Global

Scope Conversion Rules

• A Global Group can be converted to Universal only if it's not a member of another Global Group.
• A Domain Local Group can be converted to Universal only if it doesn’t contain other Domain Local Groups.
• A Universal Group can be converted to Domain Local with no restrictions.
• A Universal Group can be converted to Global only if it contains no other Universal Groups.

Built-in vs Custom Groups

AD includes many built-in security groups with a Domain Local scope. These groups typically cannot be nested and are used for administrative purposes (e.g., Domain Admins, Administrators). Organizations often create additional custom groups for managing access to specific resources or roles.

Nested Group Membership

Groups can be nested within one another. This allows a user to inherit permissions indirectly. While convenient, it can result in unintended privilege escalation. Tools like BloodHound are useful for analyzing nested relationships and identifying hidden access paths.

Important Group Attributes

Understanding group configuration and scope is critical for system administrators and penetration testers alike. Misconfigured group memberships and excessive privileges are common attack vectors during assessments. Regular auditing and visualization tools (like BloodHound) help mitigate these risks and improve domain security posture.

Rights and Privileges

Rights and privileges form the core of Active Directory security. Rights typically relate to object access (e.g., read a file), while privileges refer to system-level actions (e.g., shut down a machine). In AD, both can be granted directly or via group membership. Mismanagement often leads to abuse and privilege escalation.

Built-in AD Groups

Active Directory includes numerous default security groups that provide predefined privileges. Misconfigured or excessively permissive group membership is a common vector for escalation.

PS C:\htb> Get-ADGroup -Identity "Server Operators" -Properties *

User Rights Assignment

Windows uses User Rights Assignment to define privileges. These are managed via GPOs and can be exploited for privilege escalation. Example: assigning SeDebugPrivilege allows credential dumping.

Viewing a User's Privileges

PS C:\htb> whoami /priv

Use whoami /priv to view the privileges available in the current session. Rights differ between standard and elevated sessions due to User Account Control (UAC). Only elevated sessions expose all privileges.

Security

Active Directory is designed around centralized management and wide-scale resource accessibility, which inherently prioritizes Availability and, to a degree, Confidentiality. However, this makes AD insecure by design if deployed without proper hardening. Many security measures are not enabled by default and require explicit configuration. This section outlines general hardening recommendations to reduce risk and improve AD security posture, aligned with the principles of the CIA Triad: Confidentiality, Integrity, and Availability.

General Active Directory Hardening Measures

Microsoft Local Administrator Password Solution (LAPS)

LAPS randomizes and rotates local administrator passwords on Windows hosts, mitigating lateral movement risks. Passwords can be set to rotate on fixed intervals (e.g., every 12 or 24 hours). LAPS integrates with AD and stores passwords securely as attributes. While effective, it should be combined with broader hardening strategies.

Audit Policy Settings (Logging and Monitoring)

Effective monitoring is essential to detect anomalies and potential attacks. Organizations should configure auditing to log critical events such as object creation/modification, password changes, unauthorized access attempts, and suspicious authentication behavior (e.g., password spraying or Kerberos ticket abuse).

Group Policy Security Settings

Group Policy Objects (GPOs) allow administrators to apply security policies to users and computers at the OU level. Common policies include:

• Account Policies: Password complexity, account lockout, and Kerberos settings.
• Local Policies: User rights assignments, security auditing, and system restrictions.
• Software Restriction Policies: Controls on allowed software execution.
• Application Control Policies: Enforce executable restrictions via AppLocker.
• Advanced Audit Policy Configuration: Auditing of sensitive operations and access events.

Patch and Update Management (WSUS/SCCM)

Timely patching is critical. Windows Server Update Services (WSUS) can automate patch deployment. System Center Configuration Manager (SCCM) extends WSUS with enhanced visibility and control. Manual patching is error-prone and slow, increasing the risk of unpatched vulnerabilities in the environment.

Group Managed Service Accounts (gMSA)

gMSAs are domain-managed accounts designed for services and scheduled tasks. They provide automatically rotating 120-character passwords and eliminate the need for password knowledge or manual management. gMSAs are suitable for multi-host services and improve credential hygiene.

Security Groups

Security groups simplify access control management by assigning permissions collectively. Default groups such as Domain Admins, Account Operators, and Backup Operators are created during AD setup. Proper use of groups ensures scalable and maintainable access policies.

Account Separation

Administrators should use separate accounts for administrative and non-administrative tasks. For example, sjones for daily use and sjones_adm for privileged operations. This limits exposure in case of endpoint compromise and prevents unnecessary exposure of privileged credentials.

Password Complexity, Passphrases, and MFA

Enforcing long passphrases or random complex passwords mitigates cracking risks. Complexity requirements alone are insufficient. Password filters should disallow weak patterns (e.g., "Welcome1", month names). Minimum length should be 12+ characters, especially for privileged accounts. Multi-factor authentication (MFA), particularly for RDP access, is highly recommended to prevent lateral movement.

Limiting Domain Admin Account Usage

Domain Admin accounts must only be used on Domain Controllers. Using them on endpoints, jump hosts, or application servers increases credential theft risk. Limiting their usage reduces attack surface and memory exposure of sensitive credentials.

Periodic Review of Stale Accounts and Objects

Inactive accounts, especially privileged ones, pose significant risk. Organizations must periodically audit and disable/remove unused user, computer, or service accounts, particularly those with weak legacy configurations or passwords.

Permission and Access Auditing

Regular reviews of group memberships, file share access, and administrative rights are essential. Excessive Domain Admins or Enterprise Admins increase risk. Audits should identify and reduce overprivileged users and misconfigured access controls.

Audit Policies and Logging

Robust auditing is required for visibility into AD operations. Organizations should use Microsoft’s Audit Policy Recommendations to detect anomalous activity like Kerberoasting, enumeration, or brute force attempts. Logging is key to post-incident investigation and active threat detection.

Restricted Groups via Group Policy

Restricted Groups allow enforcement of specific group memberships. For example, local Administrators can be limited to Domain Admins and the built-in Administrator account. This prevents privilege escalation through unauthorized group additions.

Server Role Segmentation

Critical systems like Domain Controllers must not host unnecessary roles (e.g., IIS, Exchange, web applications). Role separation limits the impact of exploitation and ensures proper compartmentalization of services across infrastructure.

Restricting Local Admin and RDP Rights

Local administrator access must be tightly controlled. The use of Domain Users as local admins is a severe misconfiguration. Attackers can escalate privileges or access sensitive data by compromising low-privileged accounts with local admin rights. Similarly, RDP access must be restricted to essential users only.

Examining Group Policy

Group Policy is a powerful feature in Windows that allows administrators to configure and enforce a wide range of settings across user and computer accounts in a domain environment. It supports centralized management of operating system configurations, application behavior, and security posture across an enterprise network. While highly effective for defensive measures, Group Policy can also be leveraged by attackers to escalate privileges and maintain persistence.

Group Policy Objects (GPOs)

A Group Policy Object (GPO) is a virtual collection of policy settings that can be applied to users, computers, or groups via linkage to domains, sites, or organizational units (OUs). GPOs are uniquely identified by a GUID and can include hundreds of configurable settings. Examples include screen lock timeouts, application restrictions, password policy enforcement, logon banners, audit configurations, and remote access management. GPOs are critical for standardizing and securing system configurations at scale.

Example GPO Applications

• Enforcing separate password policies for users, service accounts, and administrators.
• Disabling USB and other removable storage device access.
• Setting screen savers with required password protection.
• Blocking access to administrative tools like cmd.exe and PowerShell.
• Configuring system-wide audit policies and event logging.
• Deploying approved software across the network.
• Restricting software installation and script execution.
• Displaying legal consent banners on login.
• Disallowing LAN Manager (LM) hash usage in the domain.
• Running scripts during user logon/logoff or system startup/shutdown.

Password Complexity Example (Default AD Policy)

In a default Windows Server 2008 AD installation, the password policy enforces:

• Minimum of 7 characters.
• Inclusion of at least 3 of the following categories: uppercase, lowercase, numbers, and special characters.

GPO Order of Precedence

GPOs are processed in the following order, where the last applied policy takes precedence and may override previous settings:

Default GPOs and Enforced Settings

The Default Domain Policy and Default Domain Controllers Policy are created automatically during AD setup. They are used to enforce baseline domain-wide and DC-specific security settings. A GPO marked as Enforced will not be overridden by lower-level policies. Block Inheritance can be set on an OU to prevent higher-level GPOs from applying. However, Enforced GPOs will override this block.

GPO Link Order and Precedence

When multiple GPOs are linked to a single OU, the link order determines processing precedence. The GPO with the lowest link order number (e.g., 1) is applied last and therefore has the highest precedence. This allows fine-tuning of policy application and helps manage potential conflicts.

Group Policy Refresh Intervals

By default, GPOs are refreshed every 90 minutes on user and computer accounts with a random offset of up to ±30 minutes. Domain controllers refresh every 5 minutes. Settings can be forced using gpupdate /force or configured via Group Policy settings: Computer Configuration → Policies → Administrative Templates → System → Group Policy.

Security Considerations and GPO Abuse

GPOs can be abused by attackers with write permissions to inject malicious settings, escalate privileges, and maintain persistence. Common abuse scenarios include:

• Adding user accounts to privileged groups via scripts.
• Deploying malicious software or scheduled tasks via GPO.
• Granting local administrator rights to compromised accounts.
• Enabling or disabling key security settings (e.g., disabling antivirus or firewall).

BloodHound is a powerful tool for identifying GPO attack paths. It can reveal misconfigurations where standard users can modify GPOs due to excessive permissions inherited through nested group membership. This is a critical security risk and a common target during privilege escalation in AD environments.