回归最本质的信息安全

;

信域信任机制的攻击技术指南(五)

2018年1月23日发布

114,820
0
2

导语:信任天启——利用SID跳出林内信任 这是我在过去几年在安全方面学到的最喜欢的技能之一。就像大多数人第一次记住 Mimikatz能从内存中提取明文密码一样,我至今记忆犹新。 在2015年6月,我在本杰明·德比(Benjamin Delpy)的推特上看到了令人

信任天启——利用SID跳出林内信任

这是我在过去几年在安全方面学到的最喜欢的技能之一。就像大多数人第一次记住 Mimikatz能从内存中提取明文密码一样,我至今记忆犹新。

在2015年6月,我在本杰明·德比(Benjamin Delpy)的推特上看到了令人兴奋的内容,起初我并不了解其中的含义:

image.png

与本杰明聊天交流后,我确认了我的想法,他的回答是“对不起你的头:)”

image.png

这都要归功于 本杰明梅特卡夫(Sean Metcalf)为了让黄金票证更加“金黄”而努力付出的工作。2015年8月,我在博客上发表了一篇题为“信任天启” 的文章。

在此之前,我们的策略是映射出外部用户/组成员身份,并且从子域的信任“手工”跳转到林根域,这种情况往往是在拥有很多域的大网络环境中比较艰苦的过程。如“信任攻击策略”部分所述,由于“企业管理员”组的存在,因此我们总是将信任解释为从林根域到子域的“向下流动”。然而,微软多年来一直表示“林是Active Directory的安全边界”,自2005年以来,有安全研究人员已经发现了一个针对林内域的攻击

但首先,为了使这一点完全合理,我必须解释sidHistory 和SID过滤安全机制,以及这对林中的域来说又有着什么样的意义。

sidHistory 是与Windows 2000 Active Directory一起添加到Windows中的,旨在帮助用户从一个域迁移到另一个域。如果用户被迁移,则可以选择将其原来旧的安全标识符(SID)以及之前所属任何组的SID添加到其新用户帐户的sidHistory属性中。当新用户尝试访问资源时,“如果SID或SID历史记录匹配,则根据ACL中指定的访问权限授予或拒绝访问资源。“意思是说,在用户的sidHistory属性中设置的任何组或旧用户SID授予他们访问权限,就好像他们是这些用户或这些组的成员一样。

由于信任在Active Directory林中工作原理的原因,sidHistory属性(PAC中的“ExtraSids”)在林的域内比较重要,因为这些SID在“SID筛选”保护的跨域引用中未被滤除掉。因此,将其sidHistory 或 ExtraSids设置为“Enterprise Admins”SID(仅存在于林根中的域用户组)的子域中的任何用户将有效地工作,就好像他们是企业管理员一样。正如微软已经知道这是一个问题,而且至少从 2005年的ITPro Windows文章以及几乎可以肯定之前的知识已经完全公开,sidHistory 是一个非常难以修改的受保护的属性。

以前,滥用这个过程是一个相当复杂的过程,包括修改关联域的Active Directory数据库(ntds.dit)中的sidHistory。关于更多的详细说明可以在 “SID过滤” 部分找到。

这就是为什么林是活动目录中的“信任边界”,而不是域!

Benjamin和Sean意识到,通过引入Mimikatz的“黄金票证”,攻击者可以随意设置为票证而创建的KERB_VALIDATION_INFO结构中的ExtraSids 部分(该结构“定义了由DC提供的用户登录和授权信息 ”)。所述的ExtraSids 部分被描述为“一个指向KERB_SID_AND_ATTRIBUTES结构列表的指针,该列表包含了对应于组而不是其主要所属的帐户域以外的域的SID”(该KERB_SID_AND_ATTRIBUTES结构的定义可以在这里找到。)

这意味着,如果攻击者拿到“域管理员”权限(或等同于实际上只是任何一个可以指向DCSync的帐户),那么他可以只需要5分钟的时间,就可以获取到林中的任何子域的KRBTGT哈希值并且可以将sid:<sid_of_enterprise_admins_in_forest_root> 添加到Mimikatz构造的票证中,而无需修改Active Directory数据库。这使攻击者有能力“跳跃”林信任关系,并危及林根域。

如果这是你第一次听到这个技巧,那我会像本杰明说的那样来一句:“对不起,:)”

对于我们的操作性的攻击策略,这意味着如果我们目前处于子域,并且可能危害DCSync 或DA访问,或者如果我们可以在攻击链的任何子域中拿到这个访问级别的权限,我们就可以放弃繁重的外部关系枚举,从而迅速地对林的根域发起入侵。我们在这个领域做到了这一点,是的,这真的是太棒了。:)对于具体的操作咨询和指导,请查看 我之前在2015年发表的Trustpocalypse文章

这只适用于在林内的信任之间跳跃。由于SID过滤,这不适用于外部或林之间的信任,在本文的结尾部分:SID过滤 部分中将会有更详细的描述。

案例研究

所以,再考虑一下我们作为演示的信任图示:

image.png

假设我们在external.local中登录了一个帐户。由于sub.dev.testlab.local 信任 external.local ,因此external.local 可以从sub.dev.testlab.local 查询到信息,而SUB不能对EXTERNAL执行相同的操作。从外部上下文中,我们可以查询SUB具有的信任:

image.png

但是这只能返回sub.dev.testlab 与其他域(dev.testlab.local 和external.local )的直接信任关系。其实我们还可以从sub.dev.testlab 查询全局编录(不一定可以查询),并返回整个林中的所有域信任!

image.png

请注意,因为这是一个单向的非传递外部信任到sub.dev.testlab.local ,所以我们不能查询contoso.local 中来自EXTERNAL的上下文中的信任,因为我们的Kerberos通信不会被正确地引用。下图的内容就是这个错误通常意味着什么,如果你碰到过它的话:

image.png

所以,从这里我们将运行Get-DomainForeignGroupMember -Domain sub.dev.testlab.local 来查看SUB中包含的任何组是否包含了EXTERNAL中的成员:

image.png

从那里,我们将尝试有针对性的帐户入侵并跳转到sub.dev.testlab.local的信任。由于有关链接值复制和在“外部关系枚举”部分中描述的信任,所以Get-DomainForeignUser命令在这里是是没有用的。

然而,由于external.local – > sub.dev.testlab.local 是外部信任关系,并隐含了非传递性,所以无法查询的dev.testlab.local 或testlab.local域的本地组成员。

如果我们再能拿到sub.dev.testlab.local的域管理员(或同等权限)证书,那么根据“信任天启”部分中的描述,我们可以建立一个SID历史信任跳跃的黄金票证来入侵testlab.local 的林根域。如果我们无法获取提升的访问权限,我们将运行Get-DomainForeignUser 来查看是否有来自sub.dev.testlab.local的用户访问了林中的其他组。同样,请记住以前有关范围界定的信息,只有通用组的成员身份才会出现在这里:

image.png

我们还将运行Get-DomainForeignGroupMember -Domain dev.testlab.local 和Get-DomainForeignGroupMember -Domain testlab.local 来查看那些在其他林域中的组中具有“入站”访问权限的用户:

image.png

image.png

一旦我们利用之前描述过的任意一种方法拿到了部分或全部的testlab.local的林根域权限,我们会运行Get-DomainForeignGroupMember -Domain contoso.local和Get-DomainForeignGroupMember -Domain prod.contoso.local来看看TESTLAB林中是否有任何用户在CONTOSO林中拥有外部组成员资格。

image.png

在整个过程中,我们可以针对服务器(包括DC)来运行Get-NetLocalGroupMember <foreign,server>来查看是否有用户通过机器本地组越过了边界。我们还可以使用具有各种过滤器的目标Get-DomainObjectACL -Domain <foreign.domain> 来检查外部ACL成员资格。

或者我们可以用BloodHound把所有东西都搞出来,然后依靠模式来模拟跨林跳跃。:)

如若转载,请注明原文地址: http://www.4hou.com/technology/10049.html

点赞 2
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

丝绸之路

嘶吼认证-特约作者/译者

发私信

发表评论