内容简介:哈希传递(Pass-the-hash)是一种非常古老的技术,最初由 Paul Ashton 在1997年发布的。尽管如此,“哈希传递”的存在已经超过了10年。 它在大多数勒索软件攻击中被大量使用,比如在马斯特里赫特大学(University of Maastricht)。但为什么这仍然是个问题呢?首先,让我们对这种攻击有一个高层次的概述。 Pass-the-hash 是一种技术,攻击者在获得本地管理员权限之后,通过这种技术从被入侵的工作站或服务器上的内存中捕获 NT (LM) 哈希。 使用这些被盗用的凭据,
引言
哈希传递(Pass-the-hash)是一种非常古老的技术,最初由 Paul Ashton 在1997年发布的。尽管如此,“哈希传递”的存在已经超过了10年。 它在大多数勒索软件攻击中被大量使用,比如在马斯特里赫特大学(University of Maastricht)。但为什么这仍然是个问题呢?
首先,让我们对这种攻击有一个高层次的概述。 Pass-the-hash 是一种技术,攻击者在获得本地管理员权限之后,通过这种技术从被入侵的工作站或服务器上的内存中捕获 NT (LM) 哈希。 使用这些被盗用的凭据,他们可以代表受到威胁的用户打开一个新的身份验证会话,以后还可以这样做。 使用 PsExec、 WinRM、 RDP 等按照该用户的侧向移动。
对于 Pass-the-Hash 攻击并没有真正的修复,因为它利用了 SSO (Single-Sign On)协议。 任何使用 SSO 的系统都容易受到类似的攻击,比如 PtH。 因为大多数组织都使用活动目录作为其身份服务,而 AD 将 SSO 作为其主要特性。这意味着许多组织必须处理这个问题,否则,它们就不能很好地抵御“传递哈希”攻击。
SSO 是一个身份验证过程,允许用户使用一组凭据登录,以访问网络上的资源,而无需再次输入密码。
假设你以用户 Bob (DBA)的身份登录,并希望访问 SQL 服务器上的 SQL 数据库。 而不是再次输入你的密码。 你只需要点击“连接”。
按下连接按钮后。 你已经进入并且可以访问所有被监听的 SQL 数据库。
你不必再次键入密码的原因是,因为 Windows 将你的凭据缓存在内存中,以提供 SSO 体验。
这也是为什么你不能完全防止哈希传递攻击,因为这意味着你必须干掉单点登录。 然而,因为很难防止这种攻击,这并不意味着你对此无能为力。 事实上,微软已经在这方面提供了很多指导,可以减轻这种攻击。
凭证存取 -T1003
在攻击者可以执行传递哈希攻击之前。首先需要获得凭证,并且所有凭据都存储在 LSASS 进程内存中,因此每次用户登录时,他或她的凭证被缓存在内存中,以提供我们前面讨论过的 SSO 体验。 当用户登录到一台机器时,无论是通过 RDP 本地登录,还是通过 Runas 在另一个帐户下执行操作,凭证都会被缓存。
下面是一个示例,其中我们从 WINDOWS2012 机器上的内存中提取凭据。
现在让我们假设我们已经设法欺骗 Alice 登录到我们已经入侵的机器上,那么会发生什么呢?
因为Alice已经登录了我们的跳板机器。 她的凭据已经丢失,这意味着我们现在可以从内存中提取凭据并开始模拟 Alice 以代表她访问资源。
哈希传递 – T1705
我们现在已经从 Alice 那里获得了凭据,因此我们现在可以开始执行 哈希传递攻击以模拟她并代表她访问所有资源。
现在,由于 Alice 可以访问 FILESERVER,我们可以作为用户 Alice 横向移动到这个服务器。
由于我们对 FILESERVER 拥有完全的管理特权,现在我们也可以将凭据转储到这台服务器上。
现在我们已经设法从 Bob 那里获得了凭据,因为他最近登录了这个服务器。 Bob 是域管理员,所以如果我们模仿Bob。 我们可以接触到任何东西。
与前面一样,我们现在要执行哈希传递攻击来模拟 Bob 并代表他访问资源。
数据外泄
例如,我们现在可以横向移动到域控制器服务器,它也被称为最关键的服务器,因为它拥有每个用户和计算机的所有凭证。
访问域控制器是一回事,但是攻击者的最终目标是泄露数据。攻击者并不关心他们是否成为DA或访问DC。当数据泄露时,它会影响你的生意。
这是一个例子,我们可以访问 SQL 服务器,因为我们已经是 Domain Admin(域管理员),但是正如前面所说的。 DA 无关紧要,重要的是数据。 下面是存储在硬盘驱动器上的所有 SQL 数据库的示例。 也许这些数据对我们有很大的价值,如果这些数据泄露出去,可能会对我们的业务造成影响。
检测
检测凭证访问和哈希传递技术一直是相当困难的。 如果真像我们想的那么简单。 那么大多数组织就已经有了适当的检测规则。
一个伟大的事情是,微软发布了 Defender ATP,这是一个 EDR 解决方案,利用了云的力量。 如果你必须选择一个 EDR 解决方案。 我建议选择Defender ATP。 这是一个很好的解决方案,可以提高所有端点的可见性,并且使你的生活更加容易,因为你可以通过门户获得无时间的警报。
下面是我们从 LSASS 进程内存中提取凭据之后收到的一个示例。
上面的警报与另一个事件有关,即哈希传递。
建议
第一件事是确保你做了基本的工作,也就是确保所有的 IT 管理员对他们的管理任务有一个单独的帐户,并且如果你想要完美地完成这些任务的话。 甚至建议使用单独的加固工作站来执行所有管理任务。
缓解哈希传递攻击的最佳方法是查看 微软管理层模型 ——这是一种安全模型,通过确保较高层不能登录较低层来减轻凭证盗窃,反之亦然。
- 第0层=可以访问网络上所有关键服务器的域管理员或同等级别的管理员
- 第1层=服务器管理员/系统管理员,他们可以访问重要的服务器,但不是“关键”的
- 第2层=工作站管理员/帮助台,可以访问客户的工作站,但不能访问第1层和第0层管理员的独立的加固工作站
现在你可能想知道,当你实现这个层模型时,它看起来是什么样的。 也许你还想知道你的组织是否有安全措施来减轻哈希传递。
部署管理层模型可能需要一段时间,但这是值得的。 这是一个关于在 AD 中如何设计一个层模型的例子。
我们创建了一些OU,在这些OU中。它包含不同的对象。作为一个例子。在第0层OU,我们有不同的子OU。你可以看到设备和第0层服务器。在设备OU中,它包含你的域管理员或同等人员的独立加固工作站。在第0层服务器中,它包含最关键的服务器对象,比如域控制器、Azure AD Connect、ADFS、PKI、SCCM等等。
现在有另一个 OU 叫做 Tier 1,它包含了不同的子 OU,以及设备和 Tier 1 服务器。 在设备 OU 中,它包含服务器管理员的独立硬化工作站和第一层服务器 OU。 它包含所有重要的服务器,但不是关键的。
在你指定之后。 一个 GPO 需要被创建和链接到设备 & 第1层(Tier 1)服务器 OU,这个 GPO 拒绝域管理员和等价物的登录权(第0层管理员)。
在这里你可以看到,我已经创建了一个 GPO 与拒绝登录权限的设备和第一层服务器。 所有0级管理员不能登录到第1层管理员设备或第1层服务器。
- 拒绝从网络访问此计算机
- 拒绝作为批处理作业登录
- 拒绝作为服务登录
- 拒绝本地登录
- 拒绝通过远程桌面服务登录
让我们验证我们不能登录到第1层资产。 例如,我们正在尝试登录第1层中的 FILESERVER。 访问被拒绝,因为我们的 GPO 拒绝了登录访问。
现在,当我们试图使用 PsExec 登录到文件服务器时,我们也会被拒绝。
最后,但并非最不重要。 还有第二层,它包含了客户端的所有工作站。 此层由帮助台/工作站管理员管理。
现在创建另一个 GPO ,但这一次这个 GPO 需要拒绝登录权限。 我们必须指定,第0层和第1层管理员都不允许登录客户的工作站和第2层管理员的单独工作站。
- 拒绝从网络访问此计算机
- 拒绝作为批处理作业登录
- 拒绝作为服务登录
- 拒绝本地登录
- 拒绝通过远程桌面服务登录
现在,当我们试图将RDP作为第0/1层管理员发送到客户机的工作站时,我们的访问将被拒绝,因为客户的工作站位于第2层区域。
我经常看到的几个例子,可能会导致层模型绕过,是链接到0层资产的GPO,来自第1层的用户可以修改它的设置。 确保所有链接到域对象的 GPO 和所有0级资产都由0级管理员管理。
另外,如果你在域管理员中有服务帐户,并且这些服务帐户作为具有 DA 特权的服务器上的服务运行,那么最好知道这一点。 这意味着你需要将该服务器视为一个第0层资产。
总结
管理层模型(Administrative Tier Model)是一个很好的安全架构,可以防止凭证被盗用,因为较高的层不能登录较低的层,反之亦然,这意味着例如域管理员的凭证永远不能在打印服务器或客户机的工作站上公开。 没有什么是完美的,但部署层模型和在所有工作站和服务器上安装 Defender ATP 将使攻击者更加困难。
如果你没有任何类似的安全措施,如上所示。 我们可能得出结论,你根本没有实现哈希传递攻击的缓解措施,这没有关系,但是现在是时候实现它了。
【责任编辑:赵宁宁 TEL:(010)68476606】
以上所述就是小编给大家介绍的《哈希传递攻击仍然是一种威胁》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- C++ 值传递、指针传递、引用传递详解
- 简明笔记:指针传递和值传递
- golang中的函数参数值传递和引用传递
- 现代编程语言的值传递与引用传递
- 这一次,彻底解决Java的值传递和引用传递
- Python函数中参数是值传递,还是引用传递?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。