[Edit 8/13/15] – Here is how the old version 1.9 cmdlets in this post translate to PowerView 2.0:
- Get-NetForestTrusts -> Get-NetForestTrusts
- Get-NetForestDomains -> Get-NetForestDomain
- Get-NetDomainTrust -> Get-NetDomainTrust
How often do you investigate trust relationships between Windows domains during a penetration test? You may have domain admin or other privileged access on your target and not even know it. Abusing active directory trust relationships is an effective tactic to expand access both during penetration tests and red team engagements. In this post, I’ll offer some background on domain trusts, how to enumerate and abuse them, and describe how PowerView‘s features can help you with these tasks.
Background
Windows domain trust relationships are trusts between two or more Active Directory domains. Veris Group’s Adaptive Red Team Tactics training class describes them this way:
A domain trust establishes the ability for users in one domain to authenticate to resources in another domain. Microsoft has a lot of information out there about domain trusts, and it can get confusing. Trusts allow organizations with multiple domains to grant users in separate domains access to shared resources. As Microsoft describes, “Most organizations that have more than one domain have a legitimate need for users to access shared resources located in a different domain“.
Domain forests are collections of domain containers that trust each other. Forests may also have trusts between them. Microsoft has excellent post about how domain and forest trusts work. If you’re not familiar with this topic, I recommend that you read it.
A trust links up the authentication systems of two (or more) domains and allows authentication traffic to flow between them. This means that users from one domain can exist in groups on another domain and get rights to specific resources. Except for enterprise admin, there is no inherent privileged access that comes with this relationship. An enterprise admin is an administrator for ALL domains in a forest. This means an enterprise admin in a parent domain automatically has domain administrator access in all of its child domains.
There are one-way and two-way trusts. A one-way trust means users and computers in a trusted domain can access resources in another trusting domain. A one-way trust is one way only [hence the name]. Users and computers in the trusting domain can not access resources in the trusted domain. Microsoft has a nice diagram of how this all flows:
A two-way trust means that users and computers in both domains can access resources in each other. Within a forest, each domain has a two-way transitive trust with both its parent an each of its children.
Trusts are transitive or non-transitive, “A transitive trust extends trust relationships to other domains; a nontransitive trust does not extend trust relationships to other domains.” This means that transitive trusts can be chained, so users can potentially access resources in multiple domains.
When a trust is present between domains, privileged accounts in one domain may have access to systems in another domain that trusts it. I say “may” because administrators need to go an extra step and enable privileged access. Fortunately for attackers, many enterprise environments with trusts enable these privileges. An attacker may focus their efforts to compromise accounts or machines in one domain and leverage that trust to take systems in another domain.
Even without privileged access, a domain trust relationship allows you to query users, machines, and more information between domains. A savvy attacker may use this information to better plan an attack against targets in the other domain.
Another nice side effect for attackers is that the domain controllers for domains with a trust MUST be able to talk to each other. If you can’t reach a target domain, but your current domain has a trust with the target, hop to one of your current DCs and you should have access. We’re frequently able to poke holes in firewall setups using this very method :)
Enumerate and Abuse
Microsoft’s nltest tool is one way to enumerate domain trusts. This tool, built for Windows Administrators, lists all trusts for the current domain and it shows domain controllers for trusted domains too. Nltest is native for Windows Server 2008/Windows 7 and up, but isn’t present on Server 2003 or XP.
From this screenshot, the domain test.local is the root of the AD forest. The sub.test.local domain has a parent-child trust with the test.local domain. Because this is a parent-child relationship, the domain trust is inherently two-way. Enterprise admins in test.local would have administrator access in sub.test.local even without additional configuration.
Another way to enumerate trusts is with PowerShell. The System.DirectoryServices.ActiveDirectory namespace provides functions (cmdlets in PowerShell-speak) to enumerate forest/domain attributes and trust relationships.
To get all the domains for the current forest, use:
([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()).Domains
To look up current domain trusts, try:
([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships()
The following screenshot shows these commands in action.
PowerView
Active Directory Service Interfaces (ADSI) and System.DirectoryServices.ActiveDirectory functions are useful to query users and machines, find domain controllers, and enumerate domain groups and members. You don’t have to limit yourself to the current domain though. You may use these functions to enumerate trusted domains too.
PowerView offers several cmdlets to help you enumerate domain trusts and query information on these other domains. The cmdlets are:
- Get-NetForest to get information about the current domain forest.
- Get-NetForestTrusts to enumerate all existing forest trusts.
- Get-NetForestDomains to list information about all domains that are a part of the forest, including parents/domain controllers/etc.
- Get-NetDomainTrusts to nicely enumerate all domain trusts à la nltest.
Here’s a screenshot with these cmdlets in action:
Many of PowerView’s functions also accept a “-Domain <name>” flag. Use this flag to specify which domain to pull information from. The functions that take this flag are: Get-NetDomainControllers, Get-NetUsers, Get-NetUser, Get-NetComputers, Get-NetGroups, Get-NetGroup, Get-NetFileServers, Get-UserProperties, Invoke-UserFieldSearch, Invoke-Netview, Invoke-UserHunter, Invoke-StealthUserHunter, Invoke-ShareFinder, Invoke-FileFinder, Invoke-FindLocalAdminAccess, Invoke-FindVulnSystems, and Invoke-EnumerateLocalAdmin.
Here’s an example of the -Domain flag in action:
These updates allow you to use PowerView’s capability with the domain trusts you come across. If domain trusts and their abuse interest you, and you’re planning on being at DerbyCon this year, come check out the talk I’m co-presenting titled “Passing the Torch: Old School Red Teaming, New School Tactics?” on Friday at 3pm!
I would also love to hear any issues you have or ideas/feature requests. Hit me up at will [at] harmj0y.net, on twitter at @harmj0y, Freednode (harmj0y in #veil or #armitage), or submit an issue on the official Github page.
Pingback: Nodal Analysis of Domain Trusts – Maximizing the Win! « @Sixdub
Pingback: My Favorite PowerShell Post-Exploitation Tools | Strategic Cyber LLC
As a offsec student, (try harder), thanks a million for posting this. PowerView looks awesome.
Pingback: Advanced Threat Tactics – Course and Notes | Strategic Cyber LLC