Pentesting Quick Reference OSCP and Beyond
  • Basic Tools & Techniques
  • Linux Basics
  • Windows Basics
  • Shells
  • Uploading Shells/ Transferring Files
  • FootPrinting
  • Host Discovery
  • Scanning
  • Vulnerability assessment
  • Metasploit and Meterpreter
    • Payloads
  • Brute Forcing/ Password Cracking
    • Attacking LSASS Passwords
    • Credentials Hunting Windows
    • Credential Hunting in Linux
    • Passwd, Shadow & Opasswd
    • Pass the Hash (PtH)
    • Protected Files
    • Protected Archives
    • Password Policies
    • Password Managers
    • Breached Credentials
    • Mimikatz
  • Linux Remote Management Protocols
  • Windows Remote Management Protocols
  • Port 20/21 - FTP Pentesting
  • Port 23 Telnet
  • Port 25 - SMTP
  • IMAP/ POP3
  • Port 53 DNS
  • Port 445 - SMB
  • Port 111 -RPC Bind
  • Port 135 - RPC
  • Port 137 NetBios
  • Port 161 SNMP
  • Port 1433 - MSSQL
  • Port 1521 Oracle TNS
  • Port 1833 - MQTT
  • Port 2049 - NFS
  • Port 3306 MySQL
  • Port 3389 - RDP
  • Port 5985 - Winrm
  • Port 632 (UDP) IPMI
  • Redis (6379)
  • Port 10000 Webmin
  • Privilege Escalation
    • Windows Priv esc
    • Linux Priv esc
  • Active Directory
    • AD Basics
      • AD Management Basics
    • Initial Enumeration of AD
      • Enumerating AD Users
    • Password Spraying
      • Enumerating & Retrieving Password Policies
      • Password Spraying - Making a Target User List
      • Internal Password Spraying - from Linux
      • Internal Password Spraying - from Windows
      • Enumerating Security Controls
    • LLMNR Poisoning
    • SMB/ NTLM Relay Attacks
    • IPv6 Attacks
      • IPV6 DNS takeover
      • WPAD
    • Passback Attacks
    • AS-REP roasting
    • AD Shell
    • AD Enumeration
      • Credentialed Enumeration - from Linux
      • Credentialed Enumeration - from Windows
      • Living off the Land
      • BloodHound
      • Plumhound
      • Bloodhound CE
      • ldapdomaindump
      • PingCastle
    • Post Compromise
      • Kerberosting
        • Kerberos "Double Hop" Problem
      • Pass Attacks
        • Pass the Hash
        • Pass the Ticket
          • Pass the Ticket (PtT) from Windows
          • Pass the Ticket (PtT) from Linux
      • Token Impersonation
      • LNK File Attacks
      • Miscellaneous Misconfigurations
    • Access Control List (ACL) Abuse Primer
      • ACL Enumeration
      • ACL Abuse Tactics
      • DCSync
        • DCSync Example Forest HTB
    • Post Owning Domain
      • Attacking Active Directory & NTDS.dit 1
      • Golden Ticket Attacks
    • Privilege Escaltion
    • Bleeding Edge Vulnerabilities
    • Domain Trusts
      • Attacking Domain Trusts - Child -> Parent Trusts - from Windows
      • Attacking Domain Trusts - Child -> Parent Trusts - from Linux
      • Attacking Domain Trusts - Cross-Forest Trust Abuse - from Windows
      • Attacking Domain Trusts - Cross-Forest Trust Abuse - from Linux
    • Hardening Active Directory
    • Additional AD Auditing Techniques
    • HTB AD Enumeration & Attacks - Skills Assessment Part I
  • Web Pentesting
    • Subdomains, directories and Vhost listing
    • Command Injection
    • XSS
    • SQL Injection
    • Authentication Bypass
  • Cryptography
  • More Resources
  • Forensics
  • IoT Security
  • API Security
  • Binary Exploitation
    • Assembly Cheatsheat for Hackers
    • Malware Analysis
      • Basic Static Malware Analysis
  • Boxes/ Machines
    • Try Hack Me
      • Vulnversity
      • Basic Pentesting
      • Kenobi
      • Steel Mountain
    • Vulnhub
      • Tiki
    • HTB
      • Beep
      • Active
      • Forest
      • Devel
    • Metasploitable 2
    • PWN.COLLEGE Talking Web
    • PWN COLLGE Web Hacking
  • Private Challenges
    • Pwn
    • Forensics
  • Misc tools
    • NetExec
  • SOC Analyst Resources
  • OSCP Tips and Misc
  • Mobile Hacking
  • Buffer Overflow
  • Wordpress
  • Web3 and Blockchain Security
  • WIFI Hacking
    • WPS Hacking
    • Misc Tools
Powered by GitBook
On this page
  • Scenario
  • Domain Trusts Overview
  • Enumerating Trust Relationships
  1. Active Directory

Domain Trusts

PreviousBleeding Edge VulnerabilitiesNextAttacking Domain Trusts - Child -> Parent Trusts - from Windows

Last updated 2 months ago

Scenario

Many large organizations will acquire new companies over time and bring them into the fold. One way this is done for ease of use is to establish a trust relationship with the new domain. In doing so, you can avoid migrating all the established objects, making integration much quicker. This trust can also introduce weaknesses into the customer's environment if they are not careful. A subdomain with an exploitable flaw or vulnerability can provide us with a quick route into the target domain. Companies may also establish trusts with other companies (such as an MSP), a customer, or other business units of the same company (such as a division of the company in another geographical region). Let's explore domain trusts more and how we can abuse built-in functionality during our assessments.


Domain Trusts Overview

A is used to establish forest-forest or domain-domain (intra-domain) authentication, which allows users to access resources in (or perform administrative tasks) another domain, outside of the main domain where their account resides. A trust creates a link between the authentication systems of two domains and may allow either one-way or two-way (bidirectional) communication. An organization can create various types of trusts:

  • Parent-child: Two or more domains within the same forest. The child domain has a two-way transitive trust with the parent domain, meaning that users in the child domain corp.inlanefreight.local could authenticate into the parent domain inlanefreight.local, and vice-versa.

  • Cross-link: A trust between child domains to speed up authentication.

  • External: A non-transitive trust between two separate domains in separate forests which are not already joined by a forest trust. This type of trust utilizes or filters out authentication requests (by SID) not from the trusted domain.

  • Tree-root: A two-way transitive trust between a forest root domain and a new tree root domain. They are created by design when you set up a new tree root domain within a forest.

  • Forest: A transitive trust between two forest root domains.

  • : A bastion forest used to manage Active Directory.

When establishing a trust, certain elements can be modified depending on the business case.

Trusts can be transitive or non-transitive.

  • A transitive trust means that trust is extended to objects that the child domain trusts. For example, let's say we have three domains. In a transitive relationship, if Domain A has a trust with Domain B, and Domain B has a transitive trust with Domain C, then Domain A will automatically trust Domain C.

  • In a non-transitive trust, the child domain itself is the only one trusted.

image

Trust Table Side By Side

Transitive
Non-Transitive

Shared, 1 to many

Direct trust

The trust is shared with anyone in the forest

Not extended to next level child domains

Forest, tree-root, parent-child, and cross-link trusts are transitive

Typical for external or custom trust setups

An easy comparison to make can be package delivery to your house. For a transitive trust, you have extended the permission to anyone in your household (forest) to accept a package on your behalf. For a non-transitive trust, you have given strict orders with the package that no one other than the delivery service and you can handle the package, and only you can sign for it.

Trusts can be set up in two directions: one-way or two-way (bidirectional).

  • One-way trust: Users in a trusted domain can access resources in a trusting domain, not vice-versa.

  • Bidirectional trust: Users from both trusting domains can access resources in the other domain. For example, in a bidirectional trust between INLANEFREIGHT.LOCAL and FREIGHTLOGISTICS.LOCAL, users in INLANEFREIGHT.LOCAL would be able to access resources in FREIGHTLOGISTICS.LOCAL, and vice-versa.

Domain trusts are often set up incorrectly and can provide us with critical unintended attack paths. Also, trusts set up for ease of use may not be reviewed later for potential security implications if security is not considered before establishing the trust relationship. A Merger & Acquisition (M&A) between two companies can result in bidirectional trusts with acquired companies, which can unknowingly introduce risk into the acquiring company’s environment if the security posture of the acquired company is unknown and untested. If someone wanted to target your organization, they could also look at the other company you acquired for a potentially softer target to attack, allowing them to get into your organization indirectly. It is not uncommon to be able to perform an attack such as Kerberoasting against a domain outside the principal domain and obtain a user that has administrative access within the principal domain. I have performed many penetration tests where this was the case: I was unable to find a foothold in the principal domain, but was able to find a flaw in a trusted domain which, in turn, gave me a foothold, or even full admin rights in the principal domain. This type of "end-around" attack could be prevented if security is considered as paramount before establishing any kind of domain trust. As we examine trust relationships, keep these thoughts in mind for reporting. Often, we will find that the larger organization is unaware that a trust relationship exists with one or more domains.

Below is a graphical representation of the various trust types.


Enumerating Trust Relationships

Using Get-ADTrust

PS C:\htb> Import-Module activedirectory
PS C:\htb> Get-ADTrust -Filter *

Direction               : BiDirectional
DisallowTransivity      : False
DistinguishedName       : CN=LOGISTICS.INLANEFREIGHT.LOCAL,CN=System,DC=INLANEFREIGHT,DC=LOCAL
ForestTransitive        : False
IntraForest             : True
IsTreeParent            : False
IsTreeRoot              : False
Name                    : LOGISTICS.INLANEFREIGHT.LOCAL
ObjectClass             : trustedDomain
ObjectGUID              : f48a1169-2e58-42c1-ba32-a6ccb10057ec
SelectiveAuthentication : False
SIDFilteringForestAware : False
SIDFilteringQuarantined : False
Source                  : DC=INLANEFREIGHT,DC=LOCAL
Target                  : LOGISTICS.INLANEFREIGHT.LOCAL
TGTDelegation           : False
TrustAttributes         : 32
TrustedPolicy           :
TrustingPolicy          :
TrustType               : Uplevel
UplevelOnly             : False
UsesAESKeys             : False
UsesRC4Encryption       : False

Direction               : BiDirectional
DisallowTransivity      : False
DistinguishedName       : CN=FREIGHTLOGISTICS.LOCAL,CN=System,DC=INLANEFREIGHT,DC=LOCAL
ForestTransitive        : True
IntraForest             : False
IsTreeParent            : False
IsTreeRoot              : False
Name                    : FREIGHTLOGISTICS.LOCAL
ObjectClass             : trustedDomain
ObjectGUID              : 1597717f-89b7-49b8-9cd9-0801d52475ca
SelectiveAuthentication : False
SIDFilteringForestAware : False
SIDFilteringQuarantined : False
Source                  : DC=INLANEFREIGHT,DC=LOCAL
Target                  : FREIGHTLOGISTICS.LOCAL
TGTDelegation           : False
TrustAttributes         : 8
TrustedPolicy           :
TrustingPolicy          :
TrustType               : Uplevel
UplevelOnly             : False
UsesAESKeys             : False
UsesRC4Encryption       : False

The above output shows that our current domain INLANEFREIGHT.LOCAL has two domain trusts. The first is with LOGISTICS.INLANEFREIGHT.LOCAL, and the IntraForest property shows that this is a child domain, and we are currently positioned in the root domain of the forest. The second trust is with the domain FREIGHTLOGISTICS.LOCAL, and the ForestTransitive property is set to True, which means that this is a forest trust or external trust. We can see that both trusts are set up to be bidirectional, meaning that users can authenticate back and forth across both trusts. This is important to note down during an assessment. If we cannot authenticate across a trust, we cannot perform any enumeration or attacks across the trust.

Checking for Existing Trusts using Get-DomainTrust

PS C:\htb> Get-DomainTrust 

SourceName      : INLANEFREIGHT.LOCAL
TargetName      : LOGISTICS.INLANEFREIGHT.LOCAL
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : WITHIN_FOREST
TrustDirection  : Bidirectional
WhenCreated     : 11/1/2021 6:20:22 PM
WhenChanged     : 2/26/2022 11:55:55 PM

SourceName      : INLANEFREIGHT.LOCAL
TargetName      : FREIGHTLOGISTICS.LOCAL
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : FOREST_TRANSITIVE
TrustDirection  : Bidirectional
WhenCreated     : 11/1/2021 8:07:09 PM
WhenChanged     : 2/27/2022 12:02:39 AM

PowerView can be used to perform a domain trust mapping and provide information such as the type of trust (parent/child, external, forest) and the direction of the trust (one-way or bidirectional). This information is beneficial once a foothold is obtained, and we plan to compromise the environment further.

Using Get-DomainTrustMapping

PS C:\htb> Get-DomainTrustMapping

SourceName      : INLANEFREIGHT.LOCAL
TargetName      : LOGISTICS.INLANEFREIGHT.LOCAL
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : WITHIN_FOREST
TrustDirection  : Bidirectional
WhenCreated     : 11/1/2021 6:20:22 PM
WhenChanged     : 2/26/2022 11:55:55 PM

SourceName      : INLANEFREIGHT.LOCAL
TargetName      : FREIGHTLOGISTICS.LOCAL
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : FOREST_TRANSITIVE
TrustDirection  : Bidirectional
WhenCreated     : 11/1/2021 8:07:09 PM
WhenChanged     : 2/27/2022 12:02:39 AM

SourceName      : FREIGHTLOGISTICS.LOCAL
TargetName      : INLANEFREIGHT.LOCAL
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : FOREST_TRANSITIVE
TrustDirection  : Bidirectional
WhenCreated     : 11/1/2021 8:07:08 PM
WhenChanged     : 2/27/2022 12:02:41 AM

SourceName      : LOGISTICS.INLANEFREIGHT.LOCAL
TargetName      : INLANEFREIGHT.LOCAL
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : WITHIN_FOREST
TrustDirection  : Bidirectional
WhenCreated     : 11/1/2021 6:20:22 PM
WhenChanged     : 2/26/2022 11:55:55 PM

From here, we could begin performing enumeration across the trusts. For example, we could look at all users in the child domain:

Checking Users in the Child Domain using Get-DomainUser

PS C:\htb> Get-DomainUser -Domain LOGISTICS.INLANEFREIGHT.LOCAL | select SamAccountName

samaccountname
--------------
htb-student_adm
Administrator
Guest
lab_adm
krbtgt

Another tool we can use to get Domain Trust is netdom. The netdom query sub-command of the netdom command-line tool in Windows can retrieve information about the domain, including a list of workstations, servers, and domain trusts.

Using netdom to query domain trust

C:\htb> netdom query /domain:inlanefreight.local trust
Direction Trusted\Trusting domain                         Trust type
========= =======================                         ==========

<->       LOGISTICS.INLANEFREIGHT.LOCAL
Direct
 Not found

<->       FREIGHTLOGISTICS.LOCAL
Direct
 Not found

The command completed successfully.

Using netdom to query domain controllers

C:\htb> netdom query /domain:inlanefreight.local dc
List of domain controllers with accounts in the domain:

ACADEMY-EA-DC01
The command completed successfully.

Using netdom to query workstations and servers

C:\htb> netdom query /domain:inlanefreight.local workstation
List of workstations with accounts in the domain:

ACADEMY-EA-MS01
ACADEMY-EA-MX01      ( Workstation or Server )

SQL01      ( Workstation or Server )
ILF-XRG      ( Workstation or Server )
MAINLON      ( Workstation or Server )
CISERVER      ( Workstation or Server )
INDEX-DEV-LON      ( Workstation or Server )
...SNIP...

We can also use BloodHound to visualize these trust relationships by using the Map Domain Trusts pre-built query. Here we can easily see that two bidirectional trusts exist.

Visualizing Trust Relationships in BloodHound

Adapted from

image

We can use the cmdlet to enumerate domain trust relationships. This is especially helpful if we are limited to just using built-in tools.

Aside from using built-in AD tools such as the Active Directory PowerShell module, both PowerView and BloodHound can be utilized to enumerate trust relationships, the type of trusts established, and the authentication flow. After importing PowerView, we can use the function to enumerate what trusts exist, if any.

image
here
Get-ADTrust
Get-DomainTrust
trust
SID filtering
ESAE