Active Directory Part 2: Domain Trust

Active Directory (AD) serves as the cornerstone of modern enterprise networks, enabling centralized user management, authentication, and resource access control. However, the complexity and criticality of Active Directory also make it an attractive target for attackers. To safeguard your organization's infrastructure, it's crucial to be aware of the common pitfalls and vulnerabilities that can undermine Active Directory security and adopt effective mitigation strategies.

In this blog series, we will embark on a journey through the intricate landscape of Active Directory, shedding light on the most prevalent pitfalls and vulnerabilities that organizations face. We will explore the potential consequences of these weaknesses and provide practical mitigation techniques to fortify your Active Directory environment against potential attacks.

In the second part of the series, we will discuss domain trust, access control and important risk factors.

Background

After an adversary gains control over a computer or device connected to the Active Directory, the next step is to gather information. The information could be about the system architecture, users in the system or network configuration. Essentially any information that could aid in increasing the attack surface, such as lateral movement or privilege escalation. The aim is to find a path forward that can help the adversary to accomplish their goal. The focus of this blog post is domain trust and access controls, how these concepts should protect you but also how misconfigurations can aid an adversary to do mischief inside your organization.

Firstly, we will discuss domain trust. Domain trust is the establishment of a secure and authenticated relationship between two or more Active Directory domains. It is a trust relationship. It enables users, resources, and services in one domain to interact and share resources with entities in another domain. Domain trust allows for seamless communication, authentication, and resource access across trusted domains.

Domain trust can be unidirectional or bidirectional:

• Unidirectional Trust: In unidirectional trust, one domain (the trusting domain) trusts and allows access to resources for users and resources from another domain (the trusted domain). However, the reverse is not true, meaning the trusted domain does not automatically trust or allow access from the trusting domain.
• Bidirectional Trust: In bidirectional trust, both domains trust each other and allow users and resources from both domains to access resources in the respective trusted domain.

Domain trust provides several benefits within Active Directory environments:

• Resource Access: Users in one domain can access resources (such as files, printers, or applications) in the trusted domain without the need for separate accounts or credentials.
• Single Sign-On: Users can log in with their credentials in their own domain and seamlessly access resources in the trusted domain without having to authenticate again.
• Collaboration: Trusted domains can collaborate more effectively by sharing resources and enabling secure communication between users and services in different domains.
• Centralized Administration: Domain trust allows centralized administration and management of users, groups, and policies across multiple domains, simplifying the management of complex Active Directory

Transitivity of Trusts

The transitivity of trusts is a concept in Active Directory that determines how trust relationships are inherited or propagated across multiple domains within a forest. Understanding transitivity is crucial for managing and configuring trust relationships effectively in complex Active Directory environments. There are two types of trust transitivity: transitive trusts and non-transitive trusts.

In a transitive trust relationship, the trust extends beyond the two directly involved domains to include any trusted domains that are nested within them. This means that if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A implicitly trusts Domain C.

For example, a user in Domain A needs to access a file server in Domain C. Because of the transitive trust, the authentication request from Domain A will be passed through Domain B to Domain C, allowing the user to access the resources in Domain C without needing a direct trust between Domain A and Domain C.

In a non-transitive trust relationship, the trust is limited to the two directly involved domains, and it does not extend to any other domains that might be trusted by the participating domains.

Transitive trusts simplify trust management in large and complex Active Directory forests. When a transitive trust is established between two domains, it automatically includes all trusted domains within those domains. This helps to reduce the administrative overhead of managing individual trust relationships between every pair of domains. It also means that administrators need to consider the transitivity of trusts when designing and configuring the Active Directory structure, especially in scenarios involving multiple domains or forests, to make sure that no excessive trusts are implemented.

The trust chain can be huge if not carefully configured. It only requires one node from one cluster to trust another node from another cluster to create one big family where everyone trusts everyone, and among them is an imposter that will be lost in the crowd.

Forest Trusts

A forest trust establishes secure communication and resource access between two separate Active Directory forests. It allows for authentication and authorization of users, groups, and resources across forests, providing a higher level of integration than traditional domain trusts. Forest trusts are typically used in scenarios where organizations have multiple Active Directory forests and need to facilitate collaboration and resource sharing between them.

Forest Trusts are useful in scenarios such as mergers, acquisitions, or collaborations between organizations with separate Active Directory forests. They provide a secure and controlled way to extend trust relationships beyond individual domains, allowing for efficient resource sharing and user collaboration across distinct organizational units.

Security Risks

While bidirectional trust can provide convenient access to resources across multiple domains, it can also potentially be risky as it increases the network's attack surface. Some examples will be mentioned in the section below.

Increased risk of lateral movement: When two domains have a bidirectional trust, users, and resources in one domain gain access to resources in the other domain. This can allow attackers to leverage compromised user credentials from one domain and then move laterally through the network to other domains, gaining access to their resources as well.

Increased complexity: Bidirectional trust between domains also introduces complexity to the network. It can result in difficulties managing and securing the network, as well as increase the risk of misconfigurations and other vulnerabilities.

Increased risk of data leakage: When two domains have bidirectional trust, it means that data can potentially flow freely between the two domains. This can increase the risk of data leakage, especially if the two domains have different security policies or if one domain is less secure than the other.

Trust chain vulnerabilities: Bidirectional trust relationships can create trust chains that extend beyond the original domains. This can create vulnerabilities if an attacker can compromise a domain trusted by several other domains, potentially gaining access to all resources across those domains.

Using PowerView, running the commands below will display all trusts for the current domain and other reachable domains.

>Get-DomainTrust

In summary, while bidirectional trust can provide convenient access to resources across multiple domains, it is important to carefully consider the security implications and potential risks before establishing such trust relationships. It is recommended to adhere to the principle of least privilege and limit the number of bidirectional trust relationships established in the network.

There are several steps that can be taken to mitigate the risks associated with bidirectional trust in a Windows domain:

1. Implement the principle of least privilege: It is important to limit the permissions granted to users and resources in trusted domains to only those necessary to perform their tasks. This can help reduce the risk of lateral movement and other security breaches.
2. Limit the number of trust relationships: Minimize the number of bidirectional trust relationships established between domains to reduce network complexity and make relations easier to manage and secure.
3. Regularly review and update trust relationships: Regularly review and update trust relationships to ensure they are still necessary and appropriate. This can help identify and remove any unnecessary or outdated trust relationships that may increase the risk of security breaches.

Access Control Lists

While domain trust focuses on the trust relationship between different Active Directory domains, access control lists (ACLs) in Active Directory define and control permissions for objects within a domain. An ACL is a collection of access control entries (ACEs) that specify who can perform certain actions (such as read, write, delete, or modify) on Active Directory objects like users, groups, computers, or organizational units (OUs).

Each object in Active Directory has its own ACL, which determines the level of access that users or groups have to that object. The ACL is associated with the object and is evaluated when a user attempts to perform an operation on that object.

Here are some key aspects of ACLs in Active Directory:

1. Security Principal: ACLs define permissions for security principals, which can be individual user accounts, security groups, or computer accounts. Permissions can be assigned to specific security principals or groups, allowing for efficient management of access rights.
2. Access Control Entries (ACEs): ACEs are the individual entries within an ACL. Each ACE contains information about a specific security principal and the permissions granted or denied to that principal for the associated object. ACEs can be explicit (directly assigned) or inherited from parent objects.
3. Permissions: Permissions in an ACL specify the actions that can be performed on an object. Common permissions include read, write, modify, delete, create, and execute. Permissions can be granted or denied to specific security principals or groups at various levels of granularity.
4. Inheritance: ACLs can be inherited from parent objects in the AD hierarchy, such as OUs or containers. Inheritance allows permissions to be applied at higher levels to propagate down to child objects, simplifying the management of access control across a large Active Directory environment.
5. Access Control Rule Evaluation: When a user attempts to access or perform an operation on an object, the ACL associated with that object is evaluated. The ACEs in the ACL are checked to determine whether the user or group has the necessary permissions to perform the requested action.
6. Administrative Control: ACLs in Active Directory can be managed and modified by administrators with the appropriate permissions. Administrators can grant or revoke permissions, modify ACEs, and manage inheritance settings to ensure proper access control across the directory.

By effectively managing ACLs in Active Directory, administrators can ensure that the right users or groups have the appropriate level of access to Active Directory objects, enforcing security policies and protecting sensitive information within the directory.

Common Pitfalls

Misconfigurations of ACLs can be due to many reasons, some are:

• Excessive Permissions: Assigning excessive permissions to users, groups, or objects can create a vulnerability. It is important to follow the principle of least privilege to prevent privilege creeps.
• Lack of Regular Review: Failure to regularly review and update ACL configurations can lead to security gaps.
• Inadequate Separation of Duties: Poorly defined separation of duties can result in a single user having excessive control or access to critical AD components. It is crucial to establish proper segregation of duties.
• Incorrect Inheritance Settings: Misconfigured inheritance settings can result in unintended access or permissions propagation.
• Misconfigured Group Membership: Incorrectly assigning users to groups or mismanaging group membership can lead to unintended access privileges.
• Insufficient Logging and Monitoring: Implementing robust auditing and monitoring mechanisms allow for timely detection and response to potential security breaches.

There are some access rights that adversaries may look for to further execute their attack. DS-Replication-Get-Changes and DS-Replication-Get-Changes-In-Filtered-Set are two Service Access Control entries (ACEs) that control the replication of directory changes between domain controllers in an Active Directory environment. This means that this user can be leveraged to perform a GenericAll attack.

In Active Directory, the GenericAll access right is a high-level permission that grants complete control over an object or a set of objects. When an entity (such as a user or group) is granted the GenericAll permission on an object, it has full administrative rights and can perform any operation on that object, including modifying permissions, deleting the object, or making any changes to its attributes.

ForceChangePassword is also an ACE which can be useful from an adversary’s perspective. It is a special permission which forces the user which it is applied to, to change its password upon their next login. If an adversary has access to change a user’s permissions and adds this ACE, the adversary can then change the user’s password and login.

By using the PowerView command Find-InterestingDomainACL, objects in the domain with modification rights over non-built-in objects can be identified.

>Find-InterestingDomainAcl -Domain DOMAIN.NAME -ResolveGUIDs

DCSync

A DCSync attack, also known as Directory Synchronization attack, is a type of attack that targets the synchronization process. The aim is to gain unauthorized access, manipulate data, or propagate malicious changes across multiple domains or directories. The attack takes advantage of the trust relationships and synchronization protocols between different directory services, such as Active Directory forests or domains.

To be able to perform DCSync, it requires a user to be delegated a combination of the following three rights:

• Replicating Directory Changes (DS-Replication-Get-Changes)
• Replicating Directory Changes All (DS-Replication-Get-Changes-All)
• Replicating Directory Changes In Filtered Set (DS-Replication-Get-Changes-In-Filtered-Set)

To search for all users that have these rights, Get-ObjectACL can be used to enumerate these users.

>Get-ObjectACL "DC=placeholder,DC= placeholder " -ResolveGUIDs | ? { ($_.ActiveDirectoryRights -match 'GenericAll') -or ($_.ObjectAceType -match 'Replication-Get')} | Select-Object SecurityIdentifier | Sort-Object -Property SecurityIdentifier -Unique

In a typical DCSync attack scenario, the attacker first identifies and compromises a source directory service, which is responsible for storing and managing user accounts, permissions, and other directory objects. The aim is to find a suitable victim. The attacker then focuses on manipulating the synchronization mechanism that allows data to be replicated from the compromised source directory to other target directories.

By exploiting vulnerabilities in the synchronization process, the attacker can achieve several objectives:

1. Unauthorized Access
2. Data Manipulation
3. Privilege Escalation

Let's consider a concrete example to illustrate a DCSync attack:

1. The attacker compromises a domain controller in a source AD forest that manages user accounts and access permissions.
2. The attacker identifies vulnerabilities in the synchronization mechanism used between the source AD forest and a target forest, which holds sensitive data and critical resources.
3. Exploiting the vulnerabilities, the attacker injects a malicious user account into the source AD forest, granting it administrative privileges.
4. The synchronization process replicates the malicious user account to the target forest, granting the attacker unauthorized administrative access.
5. With the compromised administrative privileges in the target forest, the attacker can further manipulate data, access sensitive resources, or even propagate the attack to other interconnected domains or forests.

There are multiple ways to mitigate these kinds of attacks, mostly by following best practices, this can be achieved.

• Access controls: Implement strong access controls and regularly review and update permissions and trust relationships within and between directory services.

• Patch management: Regularly apply security patches and updates to ensure vulnerabilities in the synchronization process are addressed promptly.
• Monitoring: Monitor synchronization activities and detect any unusual or suspicious behaviour, such as unauthorized changes or unexpected replication patterns.
• Detection and response: Employ intrusion detection and prevention systems (IDS/IPS) to identify and block malicious synchronization attempts.
• Authentication: Implement strong authentication protocols, such as multi-factor authentication, to protect against unauthorized access and credential theft.
  
  

Next

In conclusion, proper implementation and maintenance of trusts and ACLs are as important as keeping the attacker out of your system in the first place. These concepts could be the thing cutting them of at the knees, hindering lateral movement and further damage.

Hide your service accounts, because next we're about to dive into Kerberoasting!

This post is the third in a blog series on Active Directory. You will find the rest of them here (as they are published):

Active Directory: Introduction

Active Directory Part 1: Power Shell