[AD Hacking] 0x01 - Understanding Active Directory

Introduction to Active Directory

In simple terms, Active Directory (or AD) is a way to centralize the management and administration of Windows environments. A trick to remember its goal is to rethink how it is called, and why it is a Directory. As described by Microsoft: “A directory is a hierarchical structure that stores information about objects on the network”. And that’s exactly what these type of environments do, allow to store, manage and use information over the objects inside a network.

The main service in use here is Active Directory Domain Services (or AD DS), which allows us to put the network objects, such as users, machines, security groups and organizational units, under a common administration, denominated Domain (Windows Domain). This Domain is run and served on the network on the Domain Controller (DC) machine.

It’s with the implementation of these environments that big companies, for example, manage to properly handle the administration of hundreds of users, computers and security privileges/policies across multiple locations.

AD Objects

Everything inside Active Directory is treated as an object. Here are the main types of objects we find:

• Users: these are one of the objects known as security principals (can be authenticated by the domain and assigned privileges over resources). They have a unique identifier called a Security Identifier (SID) and can be assigned to various security groups. Users can log in to the domain and access resources based on their permissions.

• Machines: These are computer accounts in the domain, also considered security principals. Each computer/machine joined to the domain has its own account (with format <MACHINE_NAME>$), allowing for centralized management and security policies. The passwords for these accounts are automatically rotated out and generally have 120 random characters.

• Security Groups: These are collections of users, computers, and other groups that can be managed as a single unit. They are also considered security principals, and simplify administration by allowing permissions to be assigned to groups rather than individual users. Although custom groups can be created to suit specific organizational needs, there are many already pre-created by default, you can check them out by opening this dropdown.

  • Domain Admins: Users of this group have administrative privileges over the entire domain. By default, they can administer any computer on the domain, including the DCs.
  • Server Operators: Users in this group can administer Domain Controllers. They cannot change any administrative group memberships.
  • Backup Operators: Users in this group are allowed to access any file, ignoring their permissions. They are used to perform backups of data on computers.
  • Account Operators: Users in this group can create or modify other accounts in the domain.
  • Domain Users: Includes all existing user accounts in the domain.
  • Domain Computers: Includes all existing computers in the domain.
  • Domain Controllers: Includes all existing DCs on the domain.

• Organizational Units (OUs): These are containers within the Active Directory structure used to organize and manage groups of objects like users, computers, and groups. OUs provide a way to apply policies and delegate administrative control to specific sections of the directory. They can be nested, allowing for a hierarchical organization that mirrors the structure of a company or organization. One resource can only be in one OU.

• Group Policy Objects (GPOs): These are collections of settings that define the working environment for groups of users and computers. GPOs can control a wide range of settings, including security policies, software installation, and desktop configurations. They are linked to OUs, sites, or domains and are applied hierarchically. GPOs play a crucial role in maintaining consistency and security across the Active Directory environment.

Trees, Forests and Trusts

When the size of the environment escalates, or a company divides itself in multiple countries/locations for example, multiple Domains might be necessary, in order to segregate responsibilities, but maintain a connection between them if necessary.

Imagine that we initially have a domain named company.local, but now we need to create new domains for our European and US branches. For that, we could create one called eu.company.local and another called us.company.local. These three domains together would form a tree structure, with company.local as the parent domain and eu.company.local and us.company.local as the child domain. This hierarchical arrangement is what we call a Tree. By doing that, we can segregate the administration and access, allowing the IT team of each location to have complete control over their branch’s domain, but not to the entirety of the environment.

But after some years, imagine that we decide to acquire another company, or create a new separate company in our group. Now we’ll probably want to create a different domain or even a different tree, but with full separation, even with a different namespace, not just a “subdomain”. Even so, we still want them to be able to talk for specific things, so we create a Forest. Forests allow for even greater scalability and flexibility in managing complex organizational structures across different geographical locations or business units.

Now, with that structure established, we need to configure the connection and permissions between the trees or forests we setup, this is where Trusts come in. Trusts are essentially relationships established between domains, trees, or forests that allow users in one domain to access resources in another.

There are different types of trust relationships:

• Directional one-way trust relationships: where users from domain A can access resources in domain B, but not vice versa;
• Directional two-way trust relationships: where users from both domains can access resources in the other.
• Transitive trust relationships: where trust is extended not only between two directly connected domains but also to other domains in the trust chain. For example, if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A implicitly trusts Domain C. This type of trust is common within forests.

Authentication Methods

Active Directory (AD) is designed to facilitate secure authentication and authorization within a network environment. The primary authentication methods in AD include NetNTLM (NTLMv2), Kerberos, and certificate-based authentication, each serving different use cases and security needs. Understanding these methods is critical to identifying potential vulnerabilities and defending against attacks. Let’s explore these methods and their respective authentication flows.

NTLM

NTLM, often referred to as NTLMv2, is an older but still prevalent challenge-response authentication protocol. Although Microsoft has largely replaced NTLM with Kerberos in modern networks, NTLM remains in use for backward compatibility and in scenarios where Kerberos is unavailable, such as in workgroup environments or cross-forest authentication when no trust relationship is established.

NTLMv2 Authentication Flow

NTLMv2 uses a challenge-response mechanism that avoids transmitting passwords directly across the network. Here’s how it works:

1. Authentication Request: The client sends an authentication request to the server.
2. NTLM Challenge: The server responds with a random challenge (nonce).
3. NTLM Response: The client hashes the challenge along with its password hash using HMAC-MD5, forming a response.
4. The server forwards the client’s response to a Domain Controller (DC) for verification.
5. Server Verification: The DC compares the client’s response against its own calculation based on the stored password hash. If they match, authentication is successful.

While NTLMv2 offers improvements over the earlier NTLMv1, it is vulnerable to various attacks, such as relay attacks and credential forwarding, making it less secure than modern alternatives like Kerberos.

Kerberos

Kerberos is the default and recommended authentication protocol in Active Directory environments. It is based on symmetric key cryptography and designed to allow secure and efficient authentication across a distributed network. Unlike NTLM, which requires multiple communications with the Domain Controller, Kerberos employs a ticket-based system, reducing the need for constant network traffic between clients and the DC.

Kerberos Authentication Flow

The Kerberos protocol relies on a trusted third party — the Key Distribution Center (KDC), which is housed on the Domain Controller. The process involves two main phases: authentication and ticket-granting.

1. Authentication Request (AS-REQ): The client sends an Authentication Service Request (AS-REQ) to the KDC, requesting access to a particular service. The AS-REQ contains the client’s username and a timestamp encrypted with the client’s hashed password.
2. Ticket Granting Ticket (AS-REP): The KDC verifies the credentials and, if valid, issues a Ticket Granting Ticket (TGT) to the client. This TGT is encrypted with the KDC’s secret key and contains a session key for future communication, which is encrypted with the user hash. When the client receives the response, it decrypts and stores the session key.

3. Service Request (TGS-REQ): When the client needs access to a specific resource (e.g., a file share or application), it presents the TGT to the KDC in a Ticket Granting Service Request (TGS-REQ), requesting a service ticket for the desired resource (SPN). The TGS-REQ contains the client’s username and a timestamp encrypted again, but this time with the session key stored in step 2.
4. Service Ticket (TGS-REP): The KDC decrypts the TGT, gets the session key, and tries to decrypt the user data with it, therefore confirming its validity. Then, the KDC responds with a service ticket (TGS), encrypted with the target service’s secret key, which contains a session key shared between the client and the service. This shared key is also sent alongside the TGS, encrypted with the session key recovered in step 2.

5. Access Request: The client then sends the service ticket to the target service to prove its identity. The service decrypts the ticket using its own hash, and tries to decrypt the account data using the service session key inside the TGS, providing access if it works.

Kerberos is highly secure and efficient due to its reduced reliance on the Domain Controller for each interaction. However, it has its own potential vulnerabilities, such as Pass-the-Ticket and Silver Ticket attacks, which involve intercepting and reusing session tickets.

Also, you may notice that when getting a TGS, because this ticket is encrypted using the target account’s password hash, it is susceptible to bruteforce attacks (this is a big part of Kerberoasting attacks).

For more details on how this process works and the data sent in each step, this article explains in a lot of detail:

• https://www.tarlogic.com/blog/how-kerberos-works/

Certificates

Certificate-based authentication is commonly used in conjunction with Active Directory Certificate Services (AD CS). In this model, a user or device proves its identity using a digital certificate rather than a password (asymmetric encryption instead of symmetric).

The following subsection explains the basics of the certificate issuance process. For a fully detailed perspective, consult the dedicated Active Directory Certificate Services (AD CS) article.

Certificate Issuance Process

The first step in using certificate-based authentication is obtaining a valid certificate, which involves a process known as certificate enrollment. This process generally follows these key steps:

1. Key Pair Generation: The client (user or device) generates a pair of cryptographic keys: a private key and a public key. The private key is kept secret on the client machine, while the public key will be part of the certificate issued by the CA.
2. Certificate Signing Request (CSR): The client sends an authenticated Certificate Signing Request (CSR) to the Certificate Authority (CA), which is responsible for issuing certificates. The CSR contains the public key and other identity information (e.g., username, email, device name), but never the private key. This ensures that the private key remains securely on the client side and is not exposed during the request process.
3. CA Verification: The CA, typically a component of AD CS in a Windows environment, verifies the identity of the requestor, ensuring that they are entitled to a certificate. This verification can involve checking user credentials, group memberships, or other policies defined by the organization.
4. Certificate Issuance: After verification, the CA generates a digital certificate that includes the client’s public key, identity details, and a digital signature from the CA. The digital signature is what binds the public key to the client’s identity and is essential for the trustworthiness of the certificate.
5. Certificate Installation: The client receives the issued certificate and installs it on the device or within the user’s profile. This certificate can now be used to authenticate to services within the domain.

The issued certificate serves as the client’s proof of identity, and can be used with Kerberos Authentication using PKINIT.

Details on how PKINIT works can be read in the Kerberos PKINIT article.