在实际的内网攻防中，攻击者常常会选择打一些例如堡垒机、运维管理平台、域控这样的集权系统，因为接管了这些集权系统就可能相当于接管了整个内网环境。在实战中单域出现的概率远大于域森林出现的概率，但在一些大型公司或企业可能会见到。本篇主要是针对域控的在复杂内网环境中的攻击方式来进行梳理并且介绍了域信任、利用域信任进行横向移动以及一些在信任利用中涉及到的知识和概念。
主要介绍域环境的类型、域信任关系分类以及下面基于域信任进行利用的相关知识：
域环境分单域、父子域、域树和域森林，在实战中单域是最常见的，也是相对最简单的，但是想要在域森林中进行横向移动就必须要了解单域中的利用方式和相关原理。接下来说父子域，父子域就是一个域(父域)下分出了很多个子域，可能子域下还有子域，当这种关系复杂化之后就形成了域树，当域树多了之后就形成了域森林，在下个章节中搭建的其实就是一个最简单的域森林。
域信任的关系又分为内部信任、外部信任、单向信任、双向信任、可传递信任、不可传递信任、林信任、快捷信任和林信任。
– 外部信任关系指两个不同域林中的域之间的信任关系，这种信任关系是不可传递的信任且，需要在两个域上进行设置单向信任。
– 单向信任就是域A可以访问域B但是反过来不行，双向信任就是可以相互访问。
– 可传递信任和不可传递信任涉及的就是已经建立信任关系的两个域的信任关系是否还可以传递到第三个域。并且在域中信任流是从下向上传递的。拿下面我搭建的环境为例，fire.goal.lab和goal.lab域是父子域关系，这个域信任关系默认就是双向的，如何理解信任流的传递方向，当我给fire.goal.lab在创建一个子域的时候，信任流会往上传递到goal.lab此时这个新域就和父域建立了信任关系。
– 快捷信任就是在同一个林内的两个子域之间直接建立信任关系，好处是可以减少认证和授权的时间和步骤。
– 林信任关系指两个域林的林根域通过单个信任关系联系起来以提供跨域认证和授权。林信任关系是不可以扩展到第三个域林中的，即没有传递性。
– 领域信任是为了让域控和非windows系统的kerberos建立关系后而建立的信任。
为什么要创建域信任？
首先域信任是一种安全机制，但不是安全边界。引入域信任的目的就是为了不同的域之间能够单向或者双向的访问资源(即资源共享)，这里是通过配置DNS来实现的，随便说一下，如果域环境中的员工机开启缓慢可以检查一下DNS是否配置正常，因为找不到域控的DNS所以就会从本地DCC中找缓存所以登录比较慢。
根域和子域是如何进行划分的，又或者说根域和子域是如何进行权限划分的。
答案就是通过enterprise admins组来进行划分，就是根域下存在这个组，子域并不存在这个组，又或者说在域森林中只有根域有这个组因此根域的管理员能操作整个域，我们在域森林中横向的目的也是最终拿下这个组下的用户。企业管理员的RID为519。
ForeignSecurityPrincipals代表域中来自森林外部域的组中的成员：
m01-admin1/admin1.. 172.16.202.201 父域 goal.lab Administrator\Admin1..
m02-admin2/admin2.. 172.16.202.203 marks.com Administrator\Admin2..
m03-admin3/admin3.. 172.16.202.204 子域 fire.goal.lab Administrator\Admin3..
到这里一个域森林环境搭建就搭建完成了
接下来给goal.lab创建一个子域
枚举域名信任，我们需要的信息主要就是:是否存在域信任，是否存在外部信任，信任是单向的还是双向的，根域的SID、信任秘钥等等
查看是否存在域信任
收集sid
ldap导出
通过powerview.ps1
这个可能是最简单的一种跨域攻击的方式，和密码复用、密码喷洒、密码爆破的利用方式原理相同就不复现了，简单来说就是利用当前域名已有的凭据碰撞另一个域，比如通过kerbrute进行密码喷洒、批量pth等。
在域森林环境中，当我们拿下了子域的控制权限之后(DA权限)，就可以向父域、根域进行横向移动，抛开域信任，如果目标域网段内其他服务器(或者域内机器)存在漏洞，比如17010、zerologon、web漏洞(比如webdav结合xxe打relay)、打印机漏洞、exchange漏洞等进行攻击然后再结合在单域中的一些域漏洞进行利用即可。
同样也受SID过滤的影响
当客户端向KDC发起身份认证并且通过了预身份认证的时候，KDC就会给客户端返回一个用krbtgt用户的hash加密的TGT。其中包含用户所属的组（包括林中其他域的组，例如通用组）、标志，如果包含了PAC还会返回PAC。
接下来客户端带着TGT去申请目标服务的ST，通过后会得到一张用服务账号hash加密的ST，这一步并不会判断用户时候有权限访问服务，意思就是只要有TGT就能申请到ST，并且TGT的生命周期为10h，也就是说只要我们拿到了TGT，10h之内可以一直申请ST。在这个过程中KRBTGT加密的TGT是基石，如果拿到了它的hash就可以制作TGT进而申请ST（黄金票据）。
上面的过程在林中是行不通的
大致意思就是因为一个域中的 Kerberos 服务 (KDC) 不能在另一个域中签发服务票 (TGS)。由于TGS只能使用目标服务的密码数据来建立，而域控制器（DC）只包含他们自己域中的安全负责人（用户、计算机等）的密码数据，所以DC没有目标服务的密码数据，不能创建TGS。为了解决这个问题，在同一AD森林中的两个域之间有一个信任密码，用作跨域的Kerberos认证的桥梁。
当使用信任关系时，两个域的域控制器需要共享一个信任密钥以保证通信安全。当设置域B 到域A 的单向信任时（B信任A），将在域A中创建一个名为B$ 的信任帐户。当域 A 中的用户请求域 B 中的服务票证时，此信任帐户的Hash 用于加密域间 TGT。
到这里成功从marks.com域横向到goal.lab域（拿到了goal的管理员hash）
从子域fire.goal.lab到父域goal.lab的操作也是一样的，重要的是要获取到信任秘钥
信任秘钥和domain SID可以通过mimikatz来搜集（在获取了子域的DA权限后）
利用的最重要的前提是获得了当前域的krbtgt的hash，并且关闭了SID过滤
为什么传统的黄金票据不行？
因为在多域 AD 林中，如果创建金票的域不包含 Enterprise Admins 组，则申请到的金票不会向林中的其他域提供管理员权限
验证下，制作黄金票据：
验证了上面的说法，我们制作的金票并不能跨域
了解了上面的原理，接下来制作能够跨域的金票。
(利用SID-history进行跨域攻击的原理会在下面的绕过SID过滤中讲到)
可以看到成功在父域goal.lab上执行了命令
前面一直在提到SID过滤，到底什么是SID过滤，这里需要先说一下什么是SID-History(前面提了一下跨域的利用)
SID-History作为一个属性是微软在提出域迁移方案时提出的一个概念，简单来说SID-History出现的目的是保留原来域内用户的访问权限，也就是当用户从A域被迁移到B域时仍然可以访问其在A域能够访问的资源。这个过程就是通过SID-history属性来实现的，比如当用户tony从A域被迁移到B域时如果它的SID发生了变化，系统会将其原来的SID添加到迁移用户的SID History属性中。但是如何通过这种方式进行攻击->比如获取到了域管的凭据，可以给普通用户的
SID History属性中添加高权限用户的SID进行权限维持(单域中用来进行权限维持，域林中进行跨域横向移动)。
再次通过mimikatz演示下
简单说一下SID-history在域林(A林和B林之间)中是利用原理：
1. 首先申请A林的TGT，然后拿着A林的TGT申请B林的TGT(通过域信任秘钥)
2. 现在已经拿到了访问林B的TGT，接下来去申请访问林B资源的ST，这一步需要用到PAC（此次环境的PAC信息可以看下面），在域中PAC有一个字段为Extra Sids(如果存在SID-history将值放在这里成为PAC的一部分，在此环境中就证明我就是这个用户(rid为519的企业管理员))，除了这个字段还有Resource Group Domain SID和groups，这些字段都是为了可以帮助林A申请到访问林B的资源
3. 接下来就是访问资源阶段…..
简单的来说就是在域林A和B中，当我给域林A中的用户添加SID-history（RID为519）时，再用它去申请访问林B的ST时，林B的KDC会以为我是RID为519的用户，也就是企业管理员。
下面是从marks.com申请访问goal.lab的ST的debug，可以得到一些信息
解密了ccache查看PAC，比上面的debug结果更详细
外部信任和林信任中存在SID过滤机制，所以无法利用SID History获取权限，SID过滤机制在林内部默认被禁用。但是可以通过netdom命令手动开启即允许跨域林信任的SID-history
SID过滤机制是如何工作的，以及SID过滤机制过滤了哪些SID
在域林A和外部域林B中，存在SID过滤，比如域林A中的用户请求林B中的资源，会过滤SID-history属性值（过滤不属于林A中的用户SID，因为在跨域的金票制作中，我们会将根域的企业管理员用户的SID放进ExtraSids中，但是在这种过滤下，这种方法不在有效），但是试想一下，如果林A中的用户在林B中被赋予了特殊权限，我们还是可以通过这种方法进行利用的，或者通过netdom（偷图）
ldap导出 TrustAttributes结构，可以看到TREAT_AS_EXTERNAL标志
微软关于这个标志位的说明如下
如果设置了此位，则出于 SID 过滤的目的，对域的跨林信任将被视为外部信任。跨林信任比外部信任过滤得更严格。此属性将那些跨林信任放宽为等同于外部信任。有关如何过滤每种信任类型的更多信息，请参阅 [MS-PAC] 第 4.1.2.2 节。
在林A和林B中SID过滤机制会过滤林A中的SID，我们分析TREAT_AS_EXTERNAL这个标志了解到如果设置了此位（netdom命令），则出于 SID 过滤的目的，对域的跨林信任将被视为外部信任~，也就是说减小了我们的限制，此时我们依然可以将林B中的用户SID放进ExtraSids中，但是仍然会过滤一些用户的sid如DA/EA/Account Operators组的用户，总结的来说就是虽然减小了限制，但是只能通过SID-history攻击sid为1000以上的用户(如果高权限组自定义为1000以上了也是可以利用的，比如exchange相关的一些组)。
这种利用方式的原理和SID没有任何关系，只不过前面几种方式都限制在了SID过滤。SQLServer的信任连接(Linked Servers）是跨林的所以我们也可以利用这点来进横向。下面是微软关于(Linked Servers）的解释，我们只需要大致了解它的使用场景并且知道Linked Servers是可以跨域的就可以了。使用SQL Server时，可能会这种情况，需要从一个SQL Server服务器A中，查询另一个SQL Server服务器B中的表，然后将SQL Server服务器A中的表和SQL Server服务器B中的表进行JOIN，像类似这种跨SQL Server服务器的SQL语句操作，我们就可以通过在SQL Server中建立Linked Servers来实现。利用过程就是在林A的SQL上发现了林B的信任链接，那就代表可以使用这个链接，此后就可以在林B的SQL上执行SQL语句(MSSQL的利用方式了，到了这里还可以通过烂番茄实现本地提权)
创建漏洞环境
结果类似下面这样
GPO是Group Policy Object的缩写，译为组策略对象，作用在于控制用户可以干什么不可以干什么，比如密码必须要符合要求，特定文件夹访问权，安装附加功能或者以管理身份运行某些软件等等，这一套策略就叫组策略对象。GPO支持任务计划是从windows2008开始。如批量下发GPO中利用的就是通过GPO下发任务计划，但域内组策略更新的时间为90分钟，需要通过命令(gpupdate)来强制进行触发，因为GPO可以实现跨域同步，所以可以用来进行跨域攻击。
在子域域控上以system(否则会报错)可以链接GPO到AD 复制站点，包括父域DC所在的站点
将fire.goal.lab的名为pentest的GPO链接到父域goal.lab
利用委派可以看到m03配置了非约束委派，其实域控默认都是配置了非约束委派的，也就是说如果父域访问m03就会留下父域的TGT，假设我们已经拿下了子域fire.goal.lab的域控m03
在子域的域控上进行监听
接下来开始强制认证
开启了webclient(不开也可以触发成功)，可以用PetitPotam强制进行认证，我尝试了以下几个trigger，但只有PetitPotam成功进行了强制触发，并且在低版本系统中PetitPotam是可以进行性匿名强制触发的。
使用不同的trigger强制触发认证
收到凭据
处理后dcsync拿到企业管理员hash
同样可以登录子域域控
总结了在在域森林中进行横向移动的利用手段，除了上面的几种方式以外，还可以通过bloodhound导出域结构然后分析存在问题的ACL、GPO，有可能会找到存在跨域信任的ACL。总的来说，想要充分了解域信任还是要去抓包分析在域林下的kerberos认证流程，最后感谢前辈们的优秀文章。
https://learn.microsoft.com/en-us/sql/relational-databases/linked-servers/linked-servers-database-engine?view=sql-server-ver16
https://harmj0y.medium.com/a-guide-to-attacking-domain-trusts-ef5f8992bb9d
https://zhuanlan.zhihu.com/p/28375248
It’s All About Trust – Forging Kerberos Trust Tickets to Spoof Access across Active Directory Trusts
https://harmj0y.medium.com/a-guide-to-attacking-domain-trusts-ef5f8992bb9d
https://dirkjanm.io/active-directory-forest-trusts-part-one-how-does-sid-filtering-work/
https://github.com/Semperis/GoldenGMSA
