域渗透之在活动目录中搜寻: 不受限制的委派和林信任
导语:在这篇文章中,我将针对威尔的文章中解释的攻击变量提供初步的侦查指导,主要关注一些通常由强制机器帐户认证方法生成的安全事件。
在这篇文章中,我将针对威尔的文章中解释的攻击变量提供初步的侦查指导,主要关注一些通常由强制机器帐户认证方法生成的安全事件。 我还会提供一些具体的指标,说明 Rubeus 监控 TGTs 所产生的 Windows 安全事件,以及 Lee Christensen 开发的唯一公开的概念验证代码 SpoolSample ("printer bug")的执行情况。 SpoolSample 用于强制授权到一个无约束的服务器。 还有数百台 RPC 服务器尚未进行分析,比如 SpoolSample 代码中使用的 打印机服务器。 因此,我们不能假设攻击者总是使用 RPC 打印机服务器来执行这种攻击。 此外,重要的是要明白,像这样的攻击不会在真空中发生。 还有其他事件和行动,可能需要在发生之前,期间和之后,以实现行动的主要目标。
攻击解释
威尔在他的文章中从进攻的角度提供了很多关于攻击如何进行的信息。 作为防御者,了解敌方采取的每个步骤以确定可以提供足够信息以帮助侦测攻击活动的潜在数据源是非常重要的。 他引用了"一个攻击者在一个森林中入侵了一个域控制器或服务器(或者任何在该森林中具有无限授权的服务器) ,可以强迫外部森林中的域控制器通过"打印机漏洞"验证到攻击者控制的服务器,由于各种授权设置,外部域控制器的票据授予票据(TGT)可以在攻击者控制的服务器上提取、重新应用,并用于破坏外部林中的证书。"
理解攻击中使用的概念
在我们开始模拟和记录这种攻击的检测之前,了解攻击者做了什么以及为什么这样做非常重要。 在本节中,我将提供几篇帮助我更好地理解这种攻击的文章和文档。 关于威尔的文章中描述的攻击方式,有几件事情支持了我的想法:
· 无约束委派服务器
· 森林信托(双向信托)
· “打印机漏洞”强制认证
什么是委派?
简单地说,委派允许服务器应用程序在服务器连接到其他网络资源时模拟客户端。 根据微软官方文档的说明,微软将委派定义为向服务器授权并允许它代表客户机在环境中使用其他远程系统的操作。服务器与其他服务器通信以代表客户机执行任务是很常见的情况。
Kerberos 委派的类型
Kerberos 委派有三种类型,下表概述了这些类型的具体情况:
Kerberos 无约束委派有什么有趣的地方?
根据微软的官方文档,当用户通过另一个服务(前端服务器具有无限制的委派)请求访问一个服务(后端服务器)时,会发生以下情况:
1. 用户通过发送 KRB_AS_REQ消息、身份验证服务(AS)交换中的请求消息,向密钥分发中心(KDC)进行身份验证,并请求一个可转发的 TGT。
2. KDC 在 KRB_AS_REP消息中返回了一个可转发的 TGT,这是身份验证服务(AS)交换中的响应消息。
3. 从步骤2开始,用户基于可转发的 TGT 请求一个转发的 TGT。 这是通过 KRB_TGS_REQ 消息完成的。
4. KDC 在 KRB_TGS_REP 消息中为用户返回一个转发的 TGT。
5. 用户使用步骤2中返回的 TGT 请求服务票证到服务1。 这是通过KRB_TGS_REQ 消息完成的。
6. 票据授予服务(TGS)以 KRB_TGS_REP 的形式返回服务票据。
7. 用户通过发送 KRB_AP_REQ 消息向 服务1发出请求,提供服务票证、转发的 TGT 和转发的 TGT 的会话密钥。
8. 为了满足用户的请求,服务1需要服务2代表用户执行一些操作。 服务1使用用户的转发 TGT,并在 KRB_TGS_REQ 中将其发送给 KDC,以用户的名义要求获得服务2的票据。
9. KDC 在 KRB_TGS_REP 消息中返回服务2到服务1的票据,以及服务1可以使用的会话密钥。 票据将客户机标识为用户,而不是服务1。
10. 服务1通过作为用户的 KRB_AP_REQ 向服务2发出请求。
11. 服务2做出响应。
12. 有了这个响应,服务1现在可以在步骤7中响应用户的请求
13. 这里描述的 TGT 转发委派机制不限制 服务1对转发 TGT 的使用。 服务1可以向 KDC 索取以用户名义提供的任何其他服务的票据。
14. KDC 将返回所要求的票证。
15. 然后,服务1可以继续使用服务 N 模拟用户。 例如,如果服务1被破坏,这可能会造成风险。 服务1可以继续伪装成其他服务的合法用户。
16. 服务 N 将响应服务1,就像它是用户的进程一样。
配置了无约束委派的服务器最终可以使用转发的 TGT,不仅可以访问网络中其他未被请求的服务,而且可以执行攻击,如 DCSync,如果它是一个域控制器的 TGT的话。 你可在此浏览有关详情。 如你所知,滥用无约束委派概念并不是什么新鲜玩意儿。 然而,同时非常有趣和糟糕的是,攻击者还可以通过双向信任设置在外部森林中使用这种技术。 森林信任最终不再是安全边界。
更多关于"委派"的信息可以在威尔的文章"关于委派的另一个词"中找到。
什么是森林信任?
微软官方文档将信任定义为域之间建立的一种关系,这种关系使得一个域中的用户可以通过另一个域中的域控制器认证。 威尔还在他的"攻击域信任指南"的文章中提供了关于域和林信任的更多信息。
信任类型
默认的信任
当向根域添加新域时,默认情况下会创建双向传递信任。
其他信任
为了这篇文章的目的,以及契合威尔在他的文章中定义的攻击思路,我们将从防御的角度来看林的双向信任。 理解这一点非常重要,因为可能会有 Windows 安全事件显示攻击期间两个林之间的活动。
什么是「打印机Bug」 ?
Lee 将打印机 bug 描述为 Windows Print System Remote Protocol (MS-RPRN)中的一个老旧但默认启用的方法,拥有域用户帐户的攻击者可以使用 MS-RPRN RpcRemoteFindFirstPrinterChangeNotification (Ex)方法强制任何运行 Spooler 服务的机器通过 Kerberos 或 NTLM 验证攻击者选择的目标。
什么是[ MS-RPRN ]打印系统远程协议?
根据微软的官方文档,它基于远程过程调用(Remote Procedure Call,RPC)协议,支持客户机和服务器之间的同步打印和后台处理操作,包括打印作业控制和打印系统管理。 此外,打印系统远程协议仅在命名管道上使用 RPC。 因此,我希望看到源服务器和目标服务器之间通过端口445进行网络连接。
Rpcremotefindfirstprinterchangenotification (Ex)做了什么?
它可用于创建远程更改通知对象,该对象监视对打印机对象的更改,并向打印客户机发送更改通知。 在"打印系统更改通知"例子中使用的这种方法的一个例子可以在这里找到:
Lee 的 POC 只执行前两个方法(RpcOpenPrinter 和 rpcremotefindfirstprinterchangenoticationex) ,并在通知方法返回非零 Windows 错误代码后停止。 目标(打印机服务器)和客户机(无约束服务器)之间的初始连接是"打印机 bug"工作所需的全部内容。 当执行 RpcOpenPrinter 方法时,它需要返回一个 ERROR success 值来跳转到通知方法,该方法预计会失败,并且具有特定的非零返回值。 Lee 的 POC 监视以下两个返回的 ERROR 值,并提供以下消息:
· ERROR_ACCESS_DENIED: 目标服务器试图进行身份验证,但访问被拒绝。 如果将身份验证强制到 NTLM 挑战-响应捕获工具(例如 responder/inveigh/msf SMB 捕获) ,那么这是符合预期的,并表明强制身份验证有效"
· ERROR_INVALID_HANDLE: "尝试打印机通知并收到无效句柄。 强制认证可能起作用了!"
我希望这些内容有助于你在运行攻击之前了解一些初始背景知识,并记录可能的数据源,这些数据源可以帮助我们验证威尔提供的新技术变体的检测。
模拟攻击变化
要求
双向信任的两个林
一个是已经被入侵的林
· 带有不受限制的委派配置的被入侵的服务器(hygi.covertius.local)。 对于这个用例,攻击者入侵了根域的域控制器/目录(DC) ,并在单独的林中对另一个 DC使用这台域控 。
一个是充当受害者的林
· 由于我们希望充当受害者的林的 TGT 随后通过配置无约束的授权从已被入侵的 DC 执行 DCSync 攻击,因此需要将一个域控制器(rikers.cyberpartners.local)作为受害者
所需的工具
· Rubeus和SpoolSample 可用于配置了无约束委派的服务器。
日志记录:
· Windows 安全事件日志已启用,记录每个事件日志类别和子类别,因为我不想假设事件只显示在特定的事件类别或子类别。 在记录攻击生成的数据之后,我将提供需要启用哪些功能的摘要。
我们在做什么?
威尔在他的这篇文章中提供了一个很好的攻击大图。 我喜欢这张图片,因为它为每一步添加了一些具体的细节。
配置已被入侵的无约束委派服务器的步骤
从提升了权限的提示符(cmd.exe)执行以下命令,根据服务器名称设置替换值:
Rubeus.exe monitor /interval:5 /filteruser:VICTIM-DC-NAME$
从另一个提示(不一定要提升权限),执行下面的命令 :
SpoolSample.exe VICTIM-DC-NAME UNCONSTRAINED-SERVER-DC-NAME
(如果第一步没有得到任何关于 Rubeus 提示符的信息,你可能需要再次运行第二步。 我不得不运行 SpoolSample 两次,因为我没有得到任何东西。
Rubeus 应该捕捉了来自受害者域控制器的身份验证并导出了这台域控的 TGT。
所需的数据源
安全事件序列
本地执行 Rubeus,并开始监视 rikers $Account 中的4624登录事件。
使用 hydrogen.covertius.local的账户 localadmin 执行 SpoolSample POC,并将目标服务器设置为 rikers.cyberpartners.local,将捕获服务器设置为 hydroxy.covertius.local。 换句话说,hydrogen 将强制 rikers 做认证。
hydrogen.covertius.local 中的帐户 localadmin 使用 SPN CYBERPARTNERS.LOCAL 请求 Kerberos 服务票证,用于连接到其他林。 Kerberos 授权的发生是因为 SpoolSample 使用服务器的 DNS 名称而不是服务器的 IP 地址。
Hydrogen.covertius.local 通过 ldap 查询外部 DC rikers.cyberpartners.local
Hydrogen.covertius.local通过88号端口(Kerberos)与 rikers.cyberpartners.local 进行通信,以申请访问 rikers.cyberpartners.local的服务票据。
Rikers.cyberpartners.local收到一个来自hydrogen.covertius.local的带有SPN rikers$ 的 Kerberos 服务票据请求。
帐户 localadmin 请求一个带有 SPN krbtgt 和票据选项0x60810010的 Kerberos 服务票据。
Hydrogen.covertius.local 通过 SMB 端口445(Outbound)使用 MS-RPRN RpcOpenPrinter 方法启动与 rikers.cyberpartners.local 的通信,以便从"打印机服务器"(rikers)中检索打印机句柄。
Rikers.cyberpartners.local接收到一个来自 hydrogen.covertius.local 的localadmin 账户的成功的身份验证。
名为 IPC$的命名管道共享可以在 rikers.cyberpartners.local 上通过使用 covertius 域的 localadmin 进行访问,以便绑定到 spoolss 服务。
rikers.cyberpartners.local请求一个带有 SPN COVERTIUS.LOCAL 的 Kerberos 服务票据,用于连接回被入侵的林并通过配置的不受限制的委派验证到服务器(hygi.COVERTIUS.LOCAL)。 Kerberos 授权的发生是因为 SpoolSample 使用服务器的 DNS 名称而不是它的 IP 地址。
Rikers.cyberpartners.local查询域控hydrogen.covertius.local。
Rikers.cyberpartners.local 通过端口88(Kerberos)建立了到域控 hydrogen.covertius.local 的连接。
Hydrogen.covertius.local收到一个 Kerberos 服务票据请求,该请求要求从 rikers$获得SPN hydrogen$ 。
rikers.cyberpartners.local通过 445端口返回一个连接到 hydroxy.covertius.local 作为打印机 bug 活动的一部分。
当 riker$认证到 hydroxy.covertius.local 时,会发生 SID 过滤,因为 riker$在缺省情况下与其他域控一样,是企业域控制器组(SID Enterprise Domain Controllers (S-1-5-9))的一部分。 一些额外信息: 微软官方文档。
帐户 localadmin 请求了一个带有 SPN krbtgt 和 票据选项0x60810010的 Kerberos 服务票据。 由于委派的存在,我们可以看到本地管理员看起来像是来自10.7.30.100(rikers server)这台服务器。
hydrogen.covertius.local 收到了一条来自 rikers.cyberpartners.local 的 rikers$ 账户的成功认证请求。 这确认 rikers$被强制通过不受限制的委派配置验证到了我们的服务器。
由于委派的存在,本地管理员也成功地登录到了域控hydrogen (它本身) ,但源 IP 值被设置为了 rikers 的 IP 地址。
特殊权限分配给了新的登录会话。
名为 IPC$的命名管道共享可以在 hydroxy.covertius.local 上由 rikers.cyberpartners.local 机进行访问,以便绑定到客户机上的 spoolss 服务。 需要指出的是,访问 IPC$的帐户是来自 COVERTIUS域的本地管理员,而不是 rikers$(委派)用户。
一旦 Rubeus 捕捉到从 rikers$到 Hydrogen的4624登录事件,它将提取 rikers$的TGT。 它首先使用一个助手程序(helper)建立到 LSA 服务器的连接,并验证调用者是否是登录应用程序。 如果第一步失败,那么可能是运行 rubeus 的用户没有获取到 LSA 句柄的适当权限。 事实也就是这样的:
一旦失败,Rubeus 使用自己的 GetSystem 函数通过令牌模拟将本地管理帐户提升到 SYSTEM。 然后,它将再次尝试执行,现在它就能够获得到 LSA 句柄并执行 Kerberos 票据枚举。
作为 LSA 句柄的一部分,Rubeus 用3"SSS"注册了登录应用程序名——"User32LogonProcesss"。 正确的名称应该是 User32LogonProcess,它是微软官方文档中 LsaRegisterLogonProcess 函数的 LogonProcessName 参数的一个示例。
到目前为止,没有其他事件发生。 攻击接下来能做什么取决于它们希望使用提取的 TGT 完成什么。 这篇文章的目的是记录在执行威尔的文章中所提到的攻击方法的主要步骤中产生的安全事件。
初步检测建议:
Rubeus
· Rubeus 是可以在磁盘上执行的概念证明(POC),因此你可以基于命令行参数构建基本签名。 请记住,命令行的值具有很高的攻击影响等级,这意味着命令参数可以被攻击者操纵,这样就可以轻松地绕过原始参数的签名。
· 在记录事件日志时,当 Rubeus 列举 Kerberos 票据时,发现了一个 Rubeus 签名的入侵检测指标。 这个过程涉及到在获取 LSA 句柄时登录过程的应用程序名称。 Rubeus 注册以下名称: User32LogonProcesss (是的,最后有三个"s")。 在安全事件4611中,这应该会立即显示在你的环境日志中。 此外,即使拼写正确,"User32LogonProcess"也不像其他登录应用程序名称(如 Winlogon)那样常见,因此值得对此进行监控。
· 另一种检测 Rubeus 的方法是将注意力集中在它更普遍的行为上。 当 Rubeus 尝试获取 LSA 句柄时,如果它使用的帐户没有设置 SeTcbPrivilege 特权,那么它调用 LsaRegisterLogonProcess 特权服务时就会失败。 检查安全事件4673中非系统用户正在调用的特权服务和审计失败记录。
不受限制的委派和双向信任森林
攻击的这种特定变体迫使域控制器通过双向林信任配置的不受约束的委派验证到了被入侵的服务器。 因此,正如我们在这个事件序列中看到的,期望无约束服务器上的 SID 筛选事件(安全事件4675) ,使用筛选的 SID 匹配企业域控制器(S-1-5-9)。
· 获取一个配置了无约束委派的服务器列表,并对安全事件 4675的每个实例进行堆叠。
· 通过 SID S-1-5-9过滤结果。 你将从其他林获得有关多个域控的通信(潜在受害者或常规行为)。
· 你还可以堆叠由 Tdo (可信域对象) 域sid 进行的第一次聚合所获得的值。 这将告诉你特定的可信域的 sid 通过双向信任与潜在的不受限制的服务器进行了通信。
监视成功的网络登录(类型3)发生在服务器上,无约束的委派配置来自域控制器"dcname$",它属于跨独立林的外部域。
SpoolSample
· Spoolsample 工具的检测非常直接明了。 你可以使用安全事件5145监视访问名为IPC$的管道共享的无约束委派服务器,以便通过域控制器绑定到单独域中的后台服务。 请记住,除了 SpoolSample POC 之外,还有其他 RPC 服务器可能用于强制身份验证。 因此,从不受限制的服务器上通过 IPC$寻找对 spoolss 服务的访问只涉及这种攻击方法的实现。
我希望这篇文章能够帮助那些刚刚从我的队友威尔那里读到的"非安全边界: 破坏森林信任"的博客文章的读者,并且希望了解更多关于攻击执行时在端点级生成的大部分数据。 本文仅涉及一个端点数据源。 我将很快用更多的端点和网络数据源更新这篇文章,为这次攻击添加更多的上下文。 此外,攻击者决定使用 DC TGT 做的事情是为其他几篇文章提供内容。
最后,正如我在前面的文章中提到的,像这样的对抗性技巧不会在理想世界中发生。 因此,由于在特定环境中生成了大量类似的活动,你可能无法通过监视推荐的几个事件来捕获它们。 但是,在执行 DCSync 或其他一些方法时,你可能会在创建新进程并将票证导入到新的登录会话时捕获到一些事件。
我想感谢威尔对我的耐心指导,感谢他回答了我在写这篇文章时遇到的所有问题。 更多的更新检测方法和攻击的变化将很快会添加到我的博客中。
参考文献:
· https://www.harmj0y.net/blog/redteaming/another-word-on-delegation/
· https://msdn.microsoft.com/en-us/library/cc246071.aspx
· https://www.harmj0y.net/blog/redteaming/a-guide-to-attacking-domain-trusts/
· https://www.youtube.com/watch?v=-bcWZQCLk_4
· https://www.slideshare.net/harmj0y/the-unintended-risks-of-trusting-active-directory
· https://msdn.microsoft.com/en-us/library/cc237940.aspx
· https://blogs.technet.microsoft.com/networking/2009/04/28/rpc-to-go-v-3-named-pipes/
· https://docs.microsoft.com/en-us/windows/desktop/printdocs/findfirstprinterchangenotification
发表评论